PAW：把"说不清楚"的任务，变成一行能跑的代码

> arXiv:2607.02512 | University of Waterloo / Cornell / Harvard > 作者：Wentao Zhang, Liliana Hotsko, Woojeong Kim, Pengyu Nie, Stuart Shieber, Yuntian Deng

---

一、一个问题：你有没有试过写一段"判断"代码？

假设有人让你写个函数，功能很简单：判断一条日志是不是"重要"的。

你第一反应是什么？

"如果是ERROR级别……" "如果包含'failed'或'critical'……" "如果同一秒内出现超过3次……"

然后你在测试集上跑一遍，发现：有人把error拼成了eror，漏了。有人写了一条INFO: critical service heartbeat——这其实是正常的，但你的代码报警了。还有一条failed to connect to backup——在凌晨3点，这确实不重要，但你的代码半夜把你叫醒了。

你写不出完美的规则。 因为"重要"这个概念本身就不是用规则能定义的。它是一种直觉、一种经验、一种语感——人能秒懂，代码却永远差一步。

这就是论文所说的模糊函数（Fuzzy Functions）：那些人类觉得很直觉、但用精确符号写不完整的任务。

传统做法是什么？要么硬写规则然后崩溃，要么每次调用都丢给远程大模型API——贵、慢、还怕被模型静默更新搞坏。论文作者说：我们能不能换个思路？不是每次调用都求大模型，而是让大模型一次帮我们"造好"这个能力，然后本地永久运行？

这就是 PAW（Program-as-Weights，程序即权重） 的核心思想。

---

二、核心类比：钢琴曲不是乐谱，而是调好的琴键

为了理解PAW，我先讲一个费曼式的比喻。

想象一下，你学钢琴，老师给你一首曲子。你拿到的是什么？一张纸，上面写着音符。 这是传统编程：代码就是那张纸，CPU照着音符一个个按。

但钢琴家真正弹的时候，他不是在看纸。他的手指"知道"每个键在哪里，每个力度该多大。如果把纸上的音符变成肌肉记忆，那演奏效率是不是高得多？

PAW干的就是这个：

传统编程：你写Python代码，解释器一行行读，一行行执行。
大模型API：你每次遇到日志，都给GPT发一条消息"请帮我判断这条重要吗？"——每次都要重新"教"它。
PAW：你只用自然语言描述一次"帮我判断日志里哪些重要"，然后一个编译器（大模型）会把这段话翻译成一组调好的参数——像给钢琴调好音色。之后你本地只要一个很小的模型（0.6B参数），就能直接弹出这首"曲子"——判断日志是否重要。不需要再连网，不需要再调API，甚至不需要再写代码。

> 一句话理解 PAW：把"用自然语言描述任务"当成源代码，把"大模型编译出的权重文件"当成可执行文件，把"0.6B小模型"当成CPU。编译一次，运行千万次。

---

三、混合程序：为什么一份"说明书"不够，还得有"肌肉记忆"？

好，这里有个问题：如果PAW程序就是一组LoRA参数，那用户怎么理解这个程序在干什么？怎么调试？

论文的天才设计是：把程序拆成两半。

第一半：离散伪程序（Discrete Pseudo-Program）——"说明书"

这是编译器用自然语言重写的任务描述，加几个输入输出示例。例如：

> 任务：判断日志行是否重要。 > 示例： > - "ERROR: connection timeout" → 重要 > - "INFO: backup completed" → 不重要 > - "WARNING: disk 85% full" → 重要

这部分的存在有两个目的： 1. 给你看：你知道这个程序要干什么，可以检查、修改。 2. 给解释器看：它告诉小模型"要做什么任务"，就像给钢琴家一张曲目单——"今天要弹《月光》"。

第二半：连续参数（LoRA Weights）——"肌肉记忆"

但仅有说明书不够。弹《月光》和弹《野蜂飞舞》需要的手指力度、节奏感完全不同。这些"感觉"是文字无法精确描述的——你要用身体（模型参数）去记忆。

PAW的编译器输出一组LoRA权重（约38.5M参数，量化后23MB），直接注入0.6B解释器的注意力层和MLP层。这相当于：告诉小模型"用什么样的神经状态去处理这个任务"。

> 为什么是LoRA？ 因为不能每次任务都改整个模型（那要几GB），LoRA只改一点点"适配器"，就像给钢琴装一个可拆卸的音色模块——换模块就换曲子，钢琴本身不动。

这两半合在一起，就是PAW的混合程序（Hybrid Program）：

用户输入 → [说明书（离散）] + [肌肉记忆（连续）] → 小模型解释器 → 输出

> 论文原文说得妙："离散部分屏蔽了原始规格中的拼写错误和歧义；连续部分提供了文本无法表达的细粒度行为控制。"

---

四、双阶段编译：先写谱，再调琴

PAW的编译器不是一步到位的。它分两步，像作曲和调琴分开：

阶段一：伪编译器（Pseudo Compiler）——写谱

用现成的4B模型（Qwen3-4B），不训练，纯提示工程。你输入"帮我判断日志重要性"，它输出一段规范化的描述+示例。

论文作者最初试过用强化学习训练这个步骤，但发现无论怎么训练，模型总会收敛到"重述任务+给示例"这个格式。于是他们干脆不训练了，直接用手工提示——省时间、省算力、效果一样。

阶段二：LoRA编译器——调琴

这是真正需要训练的部分。训练目标是什么？

让编译器能"读懂"说明书，然后输出一组LoRA参数，使得解释器（0.6B模型）执行后的结果，与正确答案一致。

具体技术细节（可以跳过）：

编译器也是4B Qwen3，但需要训练。
输入：用户规格 + 伪程序 + 64个可学习前缀token。
提取编译器隐藏层状态（相当于"理解了任务后的内部表示"）。
通过一个浅层MLP映射成LoRA混合系数，再组合成最终的LoRA权重。
训练时，冻结解释器（0.6B模型），只训练编译器和映射器。

> 类比：就像一个钢琴调音师（编译器）听了曲子（说明书），然后微调钢琴的每个键（LoRA），让钢琴家（解释器）拿到琴就能弹出正确的曲子——但调音师在训练时，是看着钢琴家弹得对不对来反馈的。

---

五、最惊人的结果：小模型赢了

实验结果用一句话说：0.6B模型跑PAW程序，比32B模型直接提示还准。

方法	参数量	准确率	内存
GPT-5.2 API	未知	96.09%	远程
Qwen3-32B 直接提示	32B	68.70%	~60GB
PAW (Qwen3 0.6B)	0.6B	73.78%	~1.2GB
Qwen3 0.6B 直接提示	0.6B	9.84%	~1.2GB

注意最后两行的对比：同一个0.6B模型，直接提示只有9.84%，但运行编译后的PAW程序达到73.78%。

这意味着什么？模型的能力不是由大小决定的，而是由"怎么用它"决定的。 就像同一把吉他，新手弹是噪音，大师弹是音乐——但PAW的做法更疯狂：它让一个小学生（0.6B模型），拿到一份"大师的手指记忆"（LoRA），也能弹出接近大师的水平。

内存效率：PAW只需要1/50的内存（1.2GB vs 60GB）。

本地运行：MacBook M3上30 token/s，量化后整个系统只要430MB基础模型 + 23MB单任务LoRA。甚至在浏览器里能跑，完全离线。

---

六、跨模态：换把编译器，钢琴还是那台钢琴

PAW最优雅的点在于编译器-解释器分离。

你想做图像任务？好，把文本编译器换成视觉语言模型（Qwen3-VL-4B），但解释器还是那个0.6B文本模型。图像条件全部编码在LoRA参数里，小模型只需要读文本输出。

这就像：钢琴还是那个钢琴，但作曲家换成会画画的人——他把你画的图"翻译"成了钢琴能懂的参数。

论文用6个图像条件下的模糊任务测试：检测肖像照表情、判断图片是否已修图、等。PAW在4个任务上超过32B直接提示，2个任务上接近。

> 这个设计的启示：当我们找到好的抽象（编译器+解释器），跨模态扩展只是换组件，不需要推翻整个架构。

---

七、软件工程视角：版本控制、缓存、分发

PAW还有一个隐藏的巨大好处：它 fits 现有的软件开发流程。

编译出的PAW程序是什么？一个文件。23MB。你可以：

用Git版本控制它
把它缓存到CDN分发
用Python的import加载它
把它写进Docker镜像
甚至提交到PyPI当库用

> 论文作者的原话："A PAW program is a single file that can be cached, version-controlled, and distributed like any other Python module."

想想这意味着什么：

传统AI应用："你开发环境装个模型，然后每次推理都调API。" PAW应用："你开发环境装个模型（0.6B，小），然后每个任务就是个LoRA文件，像pip包一样装。"

这是真正的AI原生软件开发：模型不是服务，是编译器；权重不是配置，是程序。

---

八、费曼视角：为什么这很本质？

让我退一步，用费曼的方式问几个问题：

Q1：为什么大模型直接提示效果不如编译后的小模型？

因为直接提示是通用能力：大模型需要同时理解"任务是什么"+"任务怎么解"+"当前输入的特征"。而PAW把"任务理解"和"任务解法"预编译进权重里，解释器只需要执行——不需要再思考"这是什么任务"。就像你弹琴时不需要再看乐谱，因为手指已经记住了。

Q2：为什么用LoRA而不是微调整个模型？

因为LoRA是模块化的。一个解释器可以服务无限多个PAW程序，热插拔就行。就像一把钢琴可以弹无数首曲子——换的是谱，不是琴。如果每次任务都要换整个模型，那跟传统软件开发里"每个程序都要一台专用电脑"一样荒谬。

Q3：这真的是"编程范式"吗？还是只是PEFT的另一种应用？

论文作者自己也很小心。他们说这不是要取代传统编程，而是填补一个空白：传统编程处理精确问题，PAW处理模糊问题。它确实把"自然语言描述"提升到"源代码"的级别，把"LoRA权重"提升到"可执行文件"的级别——这是范式的重新定义。

Q4：有什么局限？

论文诚实地说：传统NLP分类任务（YouTube、SMS、Yelp、IMDB）上，PAW还不如更大模型直接提示。因为那些任务规则本身不模糊——有明确标签和大量训练数据。PAW的优势在规则写不全、标签不够多的模糊任务上。这恰恰说明PAW不是万能的，而是在特定领域比传统方法更优。

---

九、一句话总结

> PAW教会我们：真正昂贵的不是运行模型的算力，而是每次重新理解任务的认知负担。编译一次，运行千万次——这才是AI应用应该有的样子。

想象一下，几年后你的开发环境：装一个0.6B的基础模型（像装Python解释器），然后从PyPI装各种PAW程序包——日志分析、文档摘要、情感判断、数据清洗……每个包就是一个23MB的LoRA文件。完全离线，完全私有，版本可控。

这不是科幻，这就是论文展示的现实。

---

参考文献

Zhang, W., Hotsko, L., Kim, W., Nie, P., Shieber, S., & Deng, Y. (2026). Program-as-Weights: A Programming Paradigm for Fuzzy Functions. arXiv:2607.02512 [cs.LG]. https://arxiv.org/abs/2607.02512
代码与演示: https://github.com/programasweights / https://programasweights.com

#AI论文 #PAW #编程范式 #LoRA #PEFT #本地AI #大模型 #模糊函数 #费曼解读