把AI"编译"成小程序：一分钟内让语言指令变成可复用的本地函数

你有没有遇到过这种情况：想让邮件客户端自动把"签字截止今天下午"这种邮件标记为紧急，把订阅newsletter标记为不急，但写规则太麻烦，又不想为了这么点小事天天调用ChatGPT的接口？

这事听起来简单，做起来却很尴尬。太模糊了，没法用if-else写死规则；但又太琐碎、太频繁了，值不当为它天天付费调用大模型。这类处于"传统代码搞不定，大模型又太贵太慢"中间地带的小任务，其实特别多。邮件分类、语气润色、格式转换、简单的信息抽取，都是这种性质。

一支来自滑铁卢大学和哈佛大学的团队，就是盯着这个夹缝地带,做出了一个叫"compile by training"（训练式编译）的系统。他们把这套思路和一个叫Program-as-Weights（简称PAW，权重即程序）的老框架结合起来,搞出了一种新的编译方式：用大模型一次性地把你的需求"编译"成一个很小的神经网络程序，编译完之后，这个小程序就能脱离大模型独立运行,重复使用,不用再花钱调用远程接口。

这篇论文最打动我的地方,其实不是准确率提升了多少（虽然提升确实很猛,后面会讲）,而是它把"训练一个AI模型"这件事,变成了软件工程师熟悉的"编译"动作。你写一份需求文档，点一下编译，等一分钟，拿到一个可以打包、版本管理、到处复用的文件。这套心智模型的转变，可能比技术细节本身更有意思。

为什么"编译"这个词用得很准

先说说这篇论文站在谁的肩膀上。它依赖的前置工作叫Program-as-Weights（PAW）。

> Program-as-Weights（PAW）：一种编程范式，让一个"神经网络程序"去特化一个共享的本地解释器模型，使得每个具体功能只需要少量参数就能实现，而不用整个重新训练一个大模型。

PAW原来的做法是搞一个"摊销编译器"（amortized compiler），输入你的需求描述，模型在一次前向传播里直接预测出程序的参数。这个过程只要几秒钟，非常快。但代价是，不管你的需求是简单还是复杂，它都花同样多的计算量，属于"一刀切"式的处理。

这就好比你去一个自动打印店,不管你要打印一份简历还是一整本论文,机器都固定跑十秒钟出结果。简单任务够用了，但复杂任务往往打印得不清不楚，因为机器根本没有针对你的具体需求多花心思。如果不这样设计，摊销编译器要针对每个需求单独优化，那"快速"这个卖点就没了；但既然选择了快速，复杂任务的效果就必然打折扣。这是PAW原始设计里天生的取舍。

compile by training想解决的正是这个问题。它保留PAW的程序格式和运行接口，把摊销编译器算出来的结果当作一个"热启动"的初始点，然后再多花一点时间,用真实数据继续训练，把这个初始程序精细打磨一遍。

从"一句话需求"到"一堆训练数据"

具体怎么做呢？系统分两步走。

第一步，把你的自然语言需求，变成一堆有标准答案的训练样本。

这一步靠的是"教师模型"（teacher models）。

> 教师模型：指的是那些能力很强、成本较高的大语言模型（比如GPT-5.5），它们的任务不是直接服务用户,而是根据你的需求描述,自动生成大量的"输入-输出"示例对，用来教小模型学习。

举个论文里的例子。假设你的需求是"从PDF链接里提取arXiv论文编号，但要忽略abs链接"，教师模型就会自动生成类似这样的例子：输入是一段包含两个链接的文本，一个是pdf链接，一个是abs链接，输出应该只提取pdf链接对应的编号。

这个过程有点像请一个经验丰富的老师帮你出模拟题。你只告诉老师"我想考的是分数加减法"，老师就会自动出十几道题目并附上标准答案，学生（也就是接下来要训练的小模型）拿着这些题目和答案去反复练习。如果没有教师模型这一步，你就得自己手写几百条训练样本，那这套系统对普通开发者来说根本不现实，"一句话生成一个功能"的承诺也就落空了。

系统还专门设计了容错机制。教师模型的输出必须是结构化的JSON格式，编译器会先检查这些数据是不是完整、格式对不对,不合格的批次直接扔掉，绝不让脏数据进入训练环节。公开服务里用的是"混合教师"策略：主要靠一个成本较低的模型（GPT-5.4-mini）生成大部分数据，再搭配一个更强的模型（GPT-5.5）提供一部分补充数据，这样既控制成本又保证质量。

小模型怎么被"специализация"

第二步，是真正的训练环节：拿着教师模型生成的数据，去调整一个小模型的参数。

这里有个关键的架构决策：所有的功能都共享同一个基础解释器模型，而不是每个功能单独训练一个完整的大模型。

> Qwen3-0.6B：一款参数量为6亿的小型开源语言模型,由阿里巴巴Qwen团队发布,体积小,适合本地部署,是这套系统里所有"编译后程序"共用的基础解释器。

> LoRA（Low-Rank Adaptation，低秩适配）：一种参数高效的微调技术,不去动原始大模型的全部参数,只在模型里插入少量额外的小参数（适配器）,通过训练这些小参数来让模型适应新任务,大幅降低训练和存储成本。

如果每个用户的每个需求都单独训练一个完整的6亿参数模型，存储和计算成本会立刻爆炸,这套服务也就没法给成千上万个用户同时提供编译。而用LoRA的方式,每个功能对应的只是一个很小的"适配器"文件,可以理解成给同一台收音机换不同的调频旋钮，机器本体没变，只是拧一下旋钮就能收听不同的电台。旋钮很轻便，可以做成很多很多个，但收音机（也就是那个6亿参数的Qwen3模型）永远只有一台，不用重复购买。

训练时的损失函数很直白，就是让模型在看到输入后，尽量提高生成"教师模型标注的正确输出"这句话的概率，这是标准的语言模型训练套路,没有花活。

训练完之后，系统会把三样东西打包在一起：训练好的LoRA适配器、一个专门设计的"运行时脚本"（把用户的需求描述转成结构化的提示词模板），还有原始的需求说明。这个打包文件叫.paw文件，可以像普通软件一样存储、传给别人、装进版本控制系统里。

编译到底值不值得多花那一分钟

这套系统最核心的实验结果，回答了一个很朴素的问题：多花时间训练，真的换来更好的效果吗？

研究团队专门造了一个叫FuzzyBench-Hard的测试集。这个名字里藏着一个很狠的筛选标准：它专门挑选那些"PAW原始的快速编译器一个都没答对"的题目。换句话说，这是给快速方法留的一道坎，专门用来看训练式编译能不能翻盘。

结果相当悬殊。快速编译器（一次前向传播出结果，几秒钟）在这批"困难题"上的语义准确率只有22.4%。而经过训练式编译的方案，准确率跳到了83.6%，绝对提升61.2个百分点。

这里要提一下衡量准确率的方式，因为直接比较文字输出会有个坑。

> LEM（LLM Exact Match，大模型语义匹配）：不是简单比较两段文字是不是一字不差,而是让另一个大模型（GPT-5.5）当裁判,根据需求描述、输入内容、参考答案和模型输出,判断这次输出在语义上是不是正确。比如两份JSON数据的字段顺序不同、空格不同，但内容一样，裁判会判定为正确。

这个裁判模型本身也经过了验证，用128条人工标注的数据测试，准确率达到97.7%，Cohen's kappa系数是0.946（这是统计学里衡量两个评判者一致程度的指标，越接近1说明越靠得住）。

代价当然也不是免费的。快速编译只要3.5秒，训练式编译要花50.9秒。差了将近15倍的时间。这就跟点外卖一样：便利店的速食便当三分钟能吃上,但味道普通;正经餐厅现炒的菜要等半小时,但明显更好吃。如果你只是随便糊口,便利店足够;但如果这顿饭要请客,那多等的时间就值了。这套系统的巧妙之处在于，它把这两种选择都摆在用户面前，让用户自己按场景挑，而不是强迫所有人接受同一种取舍。

哪些细节在悄悄影响最终效果

论文里还做了几组对照实验，专门研究"喂给模型的训练数据该怎么配比"这个问题。

先看教师模型的搭配方式。只用便宜的GPT-5.4-mini生成全部数据时，平均LEM是74.6%；换成2:1比例混合GPT-5.4-mini和更强的GPT-5.5之后，直接跳到85.1%，提升了10.5个百分点。这说明质量更高的教师模型即便只贡献三分之一的数据，也能明显拉高整体水平。

再看数据量的影响。用1440条独特训练样本时准确率是82.1%，加到2400条涨到83.6%，再加到3600条却停在83.6%没动,直到加到7200条才再往上走到86.6%。

这个现象挺值得琢磨的。数据量从2400加到3600，居然完全没有提升,这不是那种"越多越好"的线性关系,更像是有一个瓶颈区间，跨过去才能看到效果，中间这一段增加数据基本是白费功夫。这提醒我们，简单地"多喂数据"不是万能药，有时候数据配比的质量（比如教师模型的选择）比数据量本身更关键。

一分钟编译，怎么做到不让用户干等

准确率提升了，但如果用户提交一个需求之后要僵在页面上等一分钟，体验肯定很糟。系统在工程层面做了三件事,来把这一分钟"藏"进用户的正常使用节奏里。

第一是让"出题"和"训练"两件事同时进行，而不是排队做。

正常流程应该是：先等教师模型把所有训练数据都生成完，再加载模型开始训练。但教师模型的响应速度参差不齐，有的很快有的很慢，如果死等全部数据到位，GPU就在那干晾着，什么都没干。系统改成了流式处理：训练只要凑够第一批需要的数据就立刻开始，边训练边接收后续生成的数据，除非训练进度追上了数据生成的进度，否则不会停下来等。

这就像自助餐厅后厨,不是等所有菜都炒好了才开始上菜，而是炒一道菜好了就先端上一道，客人边吃边上新菜,整体等待时间就被压缩了。如果非要等全部菜品到位才开餐,后厨明明已经闲着的灶台就是纯粹的浪费。

第二是把编译请求变成一个"排队作业"，而不是一次性网络请求。

系统专门设了一个任务队列，把提交请求、任务调度和实际执行GPU计算这三件事拆开。这样即便有很多人同时提交编译请求，接口本身依然能快速响应，不会因为某个作业在后台训练就把整个网站卡住。而且系统会缓存已经生成过的教师模型输出，如果之前有人问过类似的需求，直接复用现成数据，不用再花钱重新生成。

第三是界面设计上，让编译状态可以持续跟踪，用户可以离开页面、刷新、甚至换设备回来看，进度不会丢。

实测数据显示，这套架构确实撑得住实际使用场景。一次冷启动编译（没有任何缓存可用）在不同硬件上分别花了50.9秒（B300芯片）、68.2秒（H200芯片）、99.2秒（RTX芯片）。而在四个编译任务同时提交的负载测试里，平均排队等待时间只有1.01秒，各个计算节点的负载也比较均衡。教师模型生成数据的耗时才是真正的瓶颈，训练本身反而不是最慢的环节，这也解释了为什么"边生成边训练"这个设计能真正省出时间。

编译好的小程序,能不能拼成大应用

FuzzyBench-Hard测的是单个功能的准确率，但现实世界里，一个应用往往需要好几个编译出来的小功能配合着一起干活，还要跟普通代码衔接。研究团队专门拿了三个实际部署的应用来验证这一点。

第一个案例是一个多站点网站助手，叫paw-helper。这套系统同时给四个网站提供智能问答服务，包括作者本人的个人主页、他在滑铁卢大学教的AI课程网站、一个叫NeuralOS的项目，还有PAW自己的官网。整套系统里打包了30个编译出来的小程序，其中28个真正参与实时的问答路由决策。

举个具体场景：一个学生在课程网站上问"作业1有什么变化"，系统先用一个编译出来的分类器判断这个问题该给链接还是给一段文字回答。判定为需要文字回答后，一个编译出来的"课程页面问答"程序基于课程页面内容起草答案；同时，普通的BM25检索算法（一种传统的关键词匹配搜索技术，不涉及神经网络）去论坛里搜相关帖子，另一个编译出来的程序负责总结论坛里最相关的帖子；最后再有一个编译出来的"决策程序"判断该用课程页面的答案、论坛的答案，还是两者都要。

这个架构最有意思的地方是分工特别清楚：所有"模糊的判断"交给编译出来的神经网络小程序处理，所有"精确的操作"比如检索、缓存、流程控制,交给普通代码来做。就像一个团队里，创意判断的活儿交给有经验的人拿主意，重复性的搬运归档工作交给流水线机器,两边各司其职,不互相取代。

第二个案例更有意思，展示的是编译出来的程序不光能输出一段文字，还能生成"可执行的动作"。这个项目叫Avatar Director,让用户用自然语言指挥一个3D虚拟角色做动作，比如说"跳两次然后跳舞"，角色就真的按顺序执行了。

> DSL（Domain-Specific Language，领域特定语言）：一种为特定任务量身定制的小型编程语言,不是通用编程语言,只用来描述某一类具体操作,比如这里用来描述角色动作序列的一套简化指令集。

编译出来的PAW程序负责把用户的自然语言指令翻译成这套动作DSL的代码，浏览器里的普通程序再负责校验和执行这段DSL代码，驱动3D模型做出相应动作。在44条人工编写的测试指令里，这个程序43次都生成了预期的动作结构，准确率相当高。

第三个案例是一个英语和"Claudish"之间的双向翻译工具。Claudish是最近在网上流行起来的一个俗称，指的是AI编程工具Claude Code写代码注释和文档时特有的一种文风,喜欢用对比句式、"门""边界""承重结构"这类隐喻，还喜欢用"X形""X把关的"这种连字符构词。研究团队为这两个翻译方向各写了一份需求说明，一份负责把普通英语翻译成Claudish风格,另一份负责反过来把Claudish"翻译"回直白的英语,然后用同样的训练式编译流程,给6亿参数的解释器分别训练出两个方向的适配器。这个翻译服务从8???22日上线到9月2日，短短十几天里，成功完成了超过10万次翻译请求。

这三个案例合起来说明一件事：编译出来的神经网络小程序，可以当成软件工程里的普通模块来用，可以被调用、被组合、被嵌进更大的流程里，跟传统代码模块没有本质区别，这才是"编译"这个词真正落地的地方。

这套方法的边界在哪儿

论文里也老实承认了局限性。训练数据是教师模型合成出来的，如果教师模型本身理解错了需求或者犯了事实性错误，这些错误会被学习进最终的小程序里。对那些要求绝对正确、不能有任何差错的场景（比如金融计算、医疗建议），研究团队建议还是要加一层人工校验或者保留确定性的代码路径做保底,不能完全信任训练出来的模糊判断。另外，目前关于这套系统在真实用户场景里体验如何的系统性调研还没做,这属于留白的部分。

写在后面

这篇论文让我重新想了一下"训练"和"编译"这两个词的边界，其实以前一直觉得这是两件完全不同的事,一个是慢慢调参数改善模型能力,一个是把代码翻译成机器指令,是瞬间发生的确定性过程。但看完这篇论文之后我意识到,当训练这件事被压缩到一分钟量级,而且产出的是一个可以打包版本管理、脱离原始训练环境独立运行的文件,它在使用体验上已经完全等同于编译了。这个概念的转变可能比技术细节本身更值得记住。

还有一个细节我印象很深，就是那组数据量从2400到3600完全没提升，7200才有提升的实验结果。这跟很多人对"数据越多效果越好"的直觉不太一样,说明模型学习这件事存在阶段性的"卡壳区间"，简单粗暴地堆数据量，有时候是白费功夫，真正起作用的可能是数据配比或者其他质量因素。这个反直觉的小细节，比整篇论文的主结论更让我多想了几分钟。

如果这类"训练式编译"的小程序越来越普及,未来会不会出现一个类似应用商店的地方，专门交易这种针对细分场景训练好的.paw文件？就像今天有人写好的浏览器插件、有人卖现成的Excel模板，会不会以后也有人专门"编译"好各种模糊判断的小功能，拿出来卖或者共享？

Q&A

Q1：compile by training是什么？

A：这是一种把自然语言需求变成可复用神经网络小程序的方法，先用大模型生成训练数据，再训练一个轻量适配器，编译完成后可以脱离大模型独立运行，不用重复调用远程接口。

Q2：compile by training和PAW快速编译器有什么区别？

A：PAW快速编译器一次前向传播就出结果，几秒钟完成但准确率较低；compile by training要多花约一分钟做训练式优化，在困难测试集上准确率从22.4%提升到83.6%。

Q3：训练出来的小程序能用在什么实际场景？

A：论文展示了三个案例，包括多站点网站智能问答助手、语言控制3D虚拟角色动作的系统，以及英语和Claudish文风之间的双向翻译工具，说明这些小程序可以像软件模块一样被组合使用。