你每天收到一堆邮件，只想让程序判断哪封需要今天处理。通常，你得把每封邮件都发给云端大模型，再等它回答。ProgramAsWeights（PAW）换了个思路：先用英语写下“判断紧急邮件”，一次性把任务“教”进一个小模型；以后新邮件直接交给本地 CPU，不必逐次调用云端 API。
这项工作来自 University of Waterloo 团队。它值得关注，不是因为又多了一个聊天机器人，而是因为它尝试把 AI 从“每次都请通用模型现场判断”，变成“预先制作一个能反复调用的小工具”。不过，本文涉及的功能与效果主要来自项目作者自述及项目方材料，尚缺少独立测试。
“编译”一句英语，究竟编译出了什么？
普通编译器会把人能读懂的程序转换成机器可执行的形式。PAW 借用了这个说法，但它并没有把英语直接变成传统的 CPU 机器码。
它的流程更像老师备课。一个较大的 compiler——负责转换任务描述的模型——先读取英文要求，再生成 LoRA adapter。LoRA adapter 可以理解为一小组附加权重：它挂在固定模型上，调整模型处理某项任务的方式。真正执行任务的是共享的 Qwen3 0.6B interpreter，也就是一个约 6 亿参数的小型“解释器”模型。
因此，所谓 AI function，实际是任务专用的适配器权重、离散伪程序与共享解释器的组合。多个已经编译的函数可以共用同一个 Qwen3 0.6B 基座，不必各自保存一整套模型。
作者展示的调用方式很接近普通 Python 函数：输入“Classify urgent emails”，再把“Need this today”交给编译后的函数，得到“urgent”。这类结构化决策只需返回预先约定的类别、动作或格式，适合分类、路由和动作选择；项目也试图覆盖文本修复、排序等边界较模糊的任务。
云端只负责“教一次”
PAW 的关键变化发生在成本出现的位置。通用大模型通常每接到一个输入，就重新理解一次任务。PAW 则把这部分工作提前到编译阶段：任务描述只编译一次，之后由较小的本地模型重复执行。
SDK 默认仍使用项目方托管的 compiler，所以首次编译并不天然离线。只有 compiled program 和基座模型下载完成后，后续推理才可以断网运行，也不必把每次输入发送给 API。项目方称 compiler weights、Python SDK 和论文均已公开，分别放在 Hugging Face、GitHub 和 arXiv；若要在本地完成编译，还需自行部署这些 compiler weights。
据 University of Waterloo 与 Hugging Face 的项目材料，团队让一个 4B 参数的 compiler 只在编译阶段出场，再由固定的 0.6B interpreter 执行。在其测试中，这个小执行器的表现与直接提示 Qwen3-32B 相当，推理内存约为后者的五十分之一。这些数字来自项目方实验，目前不能视为独立复现结果。
它为什么值得现在看？
我们此前介绍过 Jev 及其开源复刻：让小模型用 logits——模型对候选答案给出的原始分数——或 reranker（候选结果重排器）为动作打分。PAW 延续了结构化决策这条路线，却把重点进一步前移：不只是用小模型现场选择，而是把任务描述预先固化进权重。
这种安排适合大量重复的小判断。作者称，他用约 30 个小型 neural programs（由神经网络执行的小程序）配合普通 decision-tree code（按条件分支的决策树代码），搭建了课程网站助手：某个神经程序判断问题该交给哪类回答器，外围代码再决定下一步。模糊判断交给模型，明确流程留给普通程序，两者各做擅长的部分。
据 Hugging Face，团队还制作了 Alien Taboo 游戏和 Avatar Director 演示：前者让“外星人”根据自由形式线索猜词，后者让用户用自然语言指挥 3D 角色。它们要说明的是，同一个模糊的人类意图识别任务，可以编译后反复运行，而不必每次询问云端大模型。
局限与未知
- 目前没有独立公布的准确率复测、延迟、内存占用、CPU 型号或与其他方案的完整对照。“与 Qwen3-32B 相当”等结论仍是项目方自报。
- “编译”是产品化表达。PAW 生成的是由小模型解释执行的神经程序，不是行为确定、可像传统代码一样逐行检查的原生程序，也不能据此推断任意英语需求都能可靠转换。
- 材料称 compiler weights 已公开，但现有信源不足以核验许可证、复现步骤，以及公开内容是否覆盖完整训练与推理组件。