写程序的时候，你有没有遇到过这种函数：规则代码写起来又臭又长，改一个条件就崩；直接调大模型又贵又慢，每调一次都像在点外卖？
比如「邮件分流」这种活儿——「signature 要的转立即处理，newsletter 转稍后看，其余问老板」。你可以写一堆 if-else，也可以一句 prompt 甩给 GPT。前者脆，后者贵。
一条更优雅的路：让大模型「教」一次，然后装进一个小模型里长期跑。 这就是 EMNLP 2026 System Demos 上《Compile by Training》做的事——把「微调」重新想象成「编译」，把大模型从运行时依赖降级成编译期老师。
TL;DR
- 一句话规格 → 一个本地函数：开发者写句自然语言描述，系统自动合成示例数据、微调一个极小的 LoRA 适配器，打包成可存储、可版本化、可组合的「神经程序」。
- 效果：在 PAW 快速编译器无能为力的 FuzzyBench-Hard 子集上，语义准确率从 0.224 飙到 0.836（+0.612 绝对提升）；代价是编译从 3.5 秒变成约 51 秒——多等一分钟，买回六成正确性。
- 真实可用：三个应用上线了。一个多站点网站助手、一个「说话控制 3D 角色」、一个英↔Claudish 双向翻译——后者上线 12 天完成了 100,747 次请求。
你们可能想直接看的东西
- 论文（arXiv）：arxiv.org/abs/2609.04…
- 在线试玩：programasweights.com/playground?…
- Claudish 翻译（开源）：github.com/programaswe…
- Avatar 演示：programasweights.com/avatar
前提：程序员都知道的「模糊函数」之痛
先看一个开胃问题。你有一个任务，比如「把用户说的一句话翻译成人话 Excel 公式」，或者「判断商家回复里是不是在推卸责任」。
这种任务的共同点：描述很容易，实现很麻烦。写规则，要考虑的边界条件无穷无尽；写 prompt 调大模型，每笔花费、每次延迟都逃不掉。
论文管这类活叫 模糊函数（fuzzy functions）——不是不知道要什么，而是没法用确定性的规则把它钉死。这类函数是 LLM 应用里最常见的一类「重复劳动」。
现有的解法各有各的坑：
| 方案 | 优点 | 痛点 |
|---|---|---|
| if-else 硬编码 | 快、可控 | 边界条件写到手断，改需求就崩 |
| 每次调大模型 | 灵活、不写代码 | 贵、慢、绑死供应商、延迟抖 |
| Prompt2Model 式微调 | 精度好 | 每个任务训整个模型，贵到没法仓储 |
| LoRA 每个任务一个 | 便宜 | 训练流程重、没有「软件工程」基础设施 |
Compile by Training 的回答是：把中间那条路做对——共享一个冻结的小解释器，每个函数只多一个小适配器，然后把整个流程包装得像 npm install 一样顺手。
思路：把「微调」当「编译」用
一句话讲完这个系统：规格（spec）→ 合成示例 → 微调小模型 → 打包成函数 → 从此本地跑，不再麻烦老师。
开发者写一句规格
↓
Teacher 大模型按模板合成示例对（低档 teacher 供量，高档补质，2:1 混用）
↓
编译器校验，畸形批次整体拒绝
↓
冻结的 Qwen3-0.6B 解释器上微调 rank-64 LoRA（约 50 秒，warm start 来自 PAW 摊销预测）
↓
打包成 .paw 函数（适配器 + 提示模板 + 规格 + 元数据）
↓
运行时：输入 → 拼 prompt → 本地小模型执行，全程不碰大模型
听起来是不是很像「编译」？源码（自然语言描述）→ 编译（teacher 合成 + 微调）→ 产物（.paw 程序卡）。产物能存、能版本化、能当依赖被别人组合——这是传统微调流程从来没有过的基建。
编译流程：合成监督 → LoRA 特化 → 打包；运行时只依赖本地小解释器，不再调用 teacher 大模型
两个关键的小聪明
第一，双 teacher 混用。 便宜的小 teacher（GPT-5.4-mini）负责供量，贵的大 teacher（GPT-5.5）负责补难点。论文做了消融：同样 3600 条规格，单用 mini 的 LEM 是 0.746，混入 1/3 的大 teacher 直接到 0.851——加一点钱，白捡十个点。而数据量 1440→7200 四倍下去，只从 0.821 涨到 0.866——堆数据不如混老师，这是对「合成数据迷信」的一记实证冷水。
第二，把编译当后台 job，绝不是命令行的长达一分钟的阻塞等待。 合成阶段比单个训练 step 慢得多且方差大，系统让 teacher 请求、模型加载、训练流水线重叠——首批示例一到就开始训。跑在 B300 上冷编译约 51 秒，4 个并发用户排队等待平均只有 1.01 秒。用户体验像极了「代码在 CI 里构建」：提交，等，拿产物。
效果：多等一分钟，买回 61 个百分点的正确性
论文在 FuzzyBench-Hard 上正面硬刚基线——这个 benchmark 专门挑的是 PAW 快速编译器没有精确匹配的规格，也就是最难的那批。
FuzzyBench-Hard 上 mean LEM：一次性权重预测 0.224 → 编译 + 训练后 0.836
- 指标是 LEM（LLM Exact Match）：让 GPT-5.5 当判官，判断输出是否「语义上正确」——判官先拿 128 条作者标注校准过，准确率 0.977、一致性 κ=0.946，指标本身可信。
- 0.224 → 0.836：61.2 个百分点的绝对提升，代价是编译时长从 3.5 秒拉到约 51 秒（B300）。这是「秒级凑合」和「分钟级到位」的明确分界线。
数据说明：语义正确性的收益远大于「把话说对」——LEM 判定的是任务达成，不是字面匹配。这正好是模糊函数最在意的东西。
真实世界：不是玩具，三个应用上了线
Demo 论文最怕「PPT 造车」，这篇反而给了最诚实的证据——真实用户真实流量的 case study。
1. 多站点网站助手（paw-helper）
程序员查「Assignment 1 有什么变化」这种问题，得自己翻好几个页面。paw-helper 把问题拆给一组编译出来的小函数：分类器判断问题类型、回答器在检索结果上作答、选择器挑最有用的信息……这些模糊函数各司其职，外围再用确定性代码（BM25 检索、缓存、分支控制）把它们串成程序树。编译函数做「判断」，普通代码做「检索结论」——模糊与确定性协作的架构，比端到端单模型更接近工业可落地形态。
2. 语言控制 3D 角色（Avatar Director）
一句话，比如「让他往前走三步，然后跳一下，同时转身」，编译器把自然语言翻译成一段小型动作 DSL（序列/时长/重复/并行），浏览器解析执行。论文报的手写验证集里 44 条指令有 43 条产出预期动作结构。这就是「人类→自然语言→程序」的一小步演示，但做得很结实。
3. 英↔Claudish 双向翻译（100,747 次请求）
Claudish 是 Claude Code 圈子里流行的一种「文风位面」——把它翻成中文是很多人每天的刚需。作者把它做成双向：英文→Claudish 一个规格一个适配器，Claudish→英文再来一套。2026-08-22 到 09-02，12 天 100,747 次成功请求。二月份没敢想的事：一个编译出来的 0.6B 小函数，扛住了六位数真实流量——这就是「一次教学、长期复用」的落地形状。
Claudish 双向翻译（在线产品，截图来自论文 Figure 7）
泼冷水：三个必须说的保留意见
作为开发者，读完不能只顾着喊「好酷」，有三点得写进自己的决策清单：
1. 评测有点「自己人查自己人」。 训练数据的 teacher 是 GPT 系，判正确性的 judge 也是 GPT-5.5。小模型高分，可能一部分是「学会了猜判官喜欢的输出形态」而不是真懂规格语义。判官校准过（κ=0.946）能挡格式差异，但挡不住同族模型的系统性盲区。落地前建议对关键子集做人工盲测。
2. 基准是被「挑出来的」对手。 FuzzyBench-Hard 定义就是「PAW 快编译器没有精确匹配」的规格——这数据天然对快速预测不利。快编译器在子集上仍有 0.224 的 LEM，说明「无精确匹配」不是「必错」，对比有一点点放大器味道。看完整结果，别只看这一个数。
3. 分布外风险全在你身上。 合成的都是函数式「输入→输出」对。真实世界的输入偏斜、对抗输入、罕见分支，论文没测。51 秒编译买到的是「在合成分布上的正确」——上线前记得拿真实流量回流验证，必要时保留一条确定性回退路径（这也是作者自己在 Limitations 里的原话）。
为什么这篇值得你关注
如果你在做 LLM 应用、Agent 工具、或者任何「重复调用大模型做同一类小事」的服务，这篇论文给出的是一种新的成本结构思维：
大模型不该是运行时依赖，而该是编译期老师。
一次花几十秒教会一个小函数，之后每次调用都便宜、本地、不绑供应商、可版本化、可被别人组合——这才是「把大模型用进软件工程」该有的样子。等这路子成熟，你会看到适配器仓库像 npm 一样遍地开花，而「调一次大模型做一件事」会变成浪费。
论文很短，demo 在线可玩，翻译服务直接开源。没有比这更低成本的考察方式了。
理性看待
- 本文不自称解法唯一：合成监督继承 teacher 错误是明写的限制；需要确定性保证的场景应验证输出或保留规则路径。
- 编译成本（teacher API 费 + GPU 分钟）与长期节省的盈亏平衡点，论文没算——重度使用的场景值得自己算一笔账。
- 团队背景：延续 Program-as-Weights（Zhang et al., 2026）模糊函数范式，属同一研究序列的工程落地。
封面图：picsum.photos（占位，上站时替换为自有图床）
文内图：来自论文 arXiv 2609.04199 原图
