这篇是对论文 Program-as-Weights: A Programming Paradigm for Fuzzy Functions 的学习笔记。
第一次看到“程序即权重”这个说法，很容易误解成一种很玄的口号：是不是以后 Python、JavaScript、SQL 都不要了，所有程序都变成神经网络参数？读完论文后，我觉得它真正想表达的东西更具体，也更工程化：
对于那些很难用规则写死、但又会被反复调用的“模糊函数”，不要每次都请求一个大模型来现场判断；而是让大模型在函数定义阶段当一次编译器，把自然语言规格编译成一小包权重。之后，一个固定的小模型解释器加载这包权重，在本地反复执行这个函数。
换成人话：
过去：每来一条输入，都问一次大模型
现在：先用大模型造一个小工具，以后每条输入都用这个小工具本地跑这才是 PAW 的核心收益：它不是让模型“凭空更聪明”，而是改变大模型参与软件系统的时机。大模型从“每次输入都来解题的人”，变成“先帮你编译一个可复用工具的人”。
1. 先抓住问题：什么叫模糊函数
传统程序擅长处理边界清楚的任务：
排序一个数组
解析合法 JSON
计算矩阵乘法
判断 user_id 是否为空这些任务能写成明确规则。输入满足什么条件，输出是什么，程序员可以用 if/else、正则、状态机、解析器、数据库查询来表达。
但现实里有一类任务不太一样：
判断一条日志值不值得报警
把格式很乱的日期归一化
修复半坏不坏的 JSON
判断搜索结果是否真正匹配用户意图
识别用户反馈是不是严重投诉
从一句自然语言里判断该调用哪个工具这些任务人看起来很自然，但很难完全写成精确规则。你可以写正则，也可以写一堆 if/else，但边界会越补越多，最后变成脆弱的规则泥潭。论文把这类任务称作 fuzzy functions，也就是模糊函数。
今天很多工程团队已经在这么写：
def should_alert(log_line):
return call_llm(
"判断这条日志是否重要，只返回 ALERT 或 QUIET",
log_line,
)这很方便，但有几个硬问题：
- 贵：每条日志、每封邮件、每个搜索候选都调用一次大模型，调用量上来后成本非常不友好。
- 慢：每次都要走 API、排队、网络往返和大模型推理。
- 不可离线：没有网络、没有 API key、服务商不可用时，函数就失效。
- 不可完全复现：远程模型版本可能变，prompt 没变但结果变了。
- 数据外发：日志、邮件、用户输入、公司内部文档每次都要传出去。
PAW 想解决的是这个中间地带：规则太硬，大模型每次调用又太重。
2. PAW 的一句话模型
PAW 可以写成一个非常像传统编程语言的结构：
program = Compiler(spec)
output = Interpreter(program, input)只不过这里的 program 不是 Python 源码，也不是机器码，而是一份神经网络可加载的参数模块。
传统编译链路是：
源代码
→ 编译器
→ 可执行文件 / 字节码
→ CPU / 虚拟机执行PAW 的链路是：
自然语言函数规格
→ 神经编译器
→ pseudo-program + PEFT 权重
→ 冻结的小模型解释器执行这里有三个角色：
| 角色 | 传统软件类比 | PAW 里的含义 |
|---|---|---|
| spec | 源代码/函数定义 | 开发者写的自然语言规格 |
| compiler | 编译器 | 把规格编译成神经程序的模型 |
| interpreter | 运行时/虚拟机 | 固定的小语言模型 |
| program | 可执行文件/库 | 一份 pseudo-program 加一份 LoRA 或 prefix 权重 |
关键点是：解释器固定，程序可替换。
你可以在本地常驻一个小模型解释器，然后为不同任务加载不同权重：
同一个 interpreter
+ urgency-filter.lora → 日志报警函数
+ json-repair.lora → JSON 修复函数
+ search-reranker.lora → 搜索重排函数
+ tool-router.lora → 工具路由函数这就是论文里“one runtime, many programs”的直觉。基础模型像运行时，LoRA/prefix 像程序文件。
3. 为什么这能带来好处
我一开始也卡在这个问题上：如果最终还是一个模型在跑，为什么要多此一举，把程序编译成权重？
答案在于 成本摊销。
假设你有一个“判断日志是否需要报警”的函数，每天调用 100 万次。
直接大模型调用模式：
100 万条日志
→ 100 万次大模型 APIPAW 模式：
写一次规格
→ 编译一次权重
→ 100 万条日志本地小模型执行如果这个函数只跑一次，PAW 没什么意义。真正的价值出现在高频、重复、边界模糊的函数上。
收益可以拆成六个层面：
3.1 成本：把 per-call 成本变成 per-function 成本
Prompting 大模型是按输入调用付费。PAW 是先编译函数，之后本地执行。编译成本仍然存在，但它被摊到后续很多次调用上。
这和传统编译器很像：
写 C++ 时不会每次运行都重新让编译器理解源代码
而是编译一次，之后反复运行二进制PAW 只是把这个思想移到了模糊函数上。
3.2 延迟：小模型本地跑，比远程大模型更像普通函数
论文报告的主线实验里，一个 Qwen3 0.6B 解释器执行 PAW 程序，在 FuzzyBench 上达到 73.78% exact match，高于直接 prompt Qwen3-32B 的 68.70%。更重要的是，它的推理内存约为 1.2GB，而 Qwen3-32B 约为 60GB。
论文还给了本地化数字：量化后，Qwen3 0.6B base 大约 430MB，每个程序的 LoRA adapter 大约 23MB，在 MacBook M3 上可以跑到约 30 tok/s。
这些数字说明 PAW 的目标不是“用小模型无条件打败所有大模型”，而是：对某类函数，把大模型的能力提前压缩到一个小的、可部署的函数工件里。
3.3 隐私：输入可以不再反复出本地
日志、邮件、用户反馈、客户工单、搜索 query 都可能含有敏感信息。直接调用云端 LLM，意味着每次函数调用都要把输入发出去。
PAW 的部署路径是：
编译阶段：规格可能发给编译器
执行阶段：真实业务输入只进本地解释器这对企业内部工具、浏览器端工具、离线设备都很关键。
3.4 可复现：程序文件可以版本化
Prompt 很容易散落在代码里：
"请判断这条日志是否重要..."
"你是一个日志分析专家..."
"只返回 ALERT 或 QUIET..."远程模型一变，结果可能变。PAW 把函数行为凝结成一个可保存的工件：
alert-filter-v1.lora
alert-filter-v2.lora它可以缓存、发布、回滚、做 A/B test，也可以随代码一起纳入版本管理。虽然权重本身仍然不透明，但它至少成为一个明确的依赖，而不是漂浮在 API 后面的动态行为。
3.5 工程接口：它更像库函数，而不是聊天接口
很多 LLM 应用的问题不是模型不会，而是接口太“聊天化”。你希望的是：
label = classify_urgency(log_line)而不是每次都拼一个对话：
messages = [
{"role": "system", "content": "..."},
{"role": "user", "content": log_line},
]
label = client.chat.completions.create(...)PAW 把模糊能力包装成函数。这个函数可以被普通程序调用、组合、测试和监控。
3.6 分工：大模型负责造工具，小模型负责跑工具
这是我觉得论文最值得记住的一点。
现在很多系统把大模型当“运行时智能体”：每来一个输入，大模型现场思考、现场推理、现场决定。这种模式灵活，但成本和不确定性很高。
PAW 把 foundation model 的角色改成“工具构建者”：
大模型：读懂函数规格，编译出专用工具
小模型：加载工具，本地处理大量输入这是一种更软件工程化的 LLM 使用方式。
4. 一个玩具例子：同一个解释器，换权重就是换程序
为了理解“程序即权重”，我跑了一个极简版。它当然不是真实 PAW，但能说明机制。
固定解释器如下：
p = sigmoid(program_weights · text_features + bias)
return "YES" if p >= 0.5 else "NO"解释器代码永远不变。不同“程序”只是不同权重：
程序 A：alert_if_urgent
urgent/asap/eod/down/security 等词权重大
fyi/lunch/newsletter 等词权重小或为负
程序 B：route_to_finance
invoice/payment/billing 等词权重大
lunch/newsletter 等词权重小或为负同一批输入，加载不同权重后，函数行为不同：
PROGRAM = alert_if_urgent
NO | FYI: lunch menu is updated
YES | Production API is down, timeout errors for all users
YES | Need your signature by EOD!
YES | Invoice payment failed, please check ASAP
NO | Weekly newsletter and meeting schedule
PROGRAM = route_to_finance
NO | FYI: lunch menu is updated
NO | Production API is down, timeout errors for all users
NO | Need your signature by EOD!
YES | Invoice payment failed, please check ASAP
NO | Weekly newsletter and meeting schedule这个玩具例子可以对应到真实 PAW：
| 玩具例子 | 真实 PAW |
|---|---|
program_weights | LoRA / prefix-tuning 权重 |
| 固定 sigmoid 解释器 | 冻结的小语言模型解释器 |
| 手写 compile 规则 | 训练出来的神经编译器 |
| 关键词特征 | Transformer hidden state |
| YES/NO 分类 | 任意短文本输出、结构化输出或标签 |
所以“程序即权重”不是说权重能替代所有代码，而是说：对于某些模糊函数，函数行为可以主要由一份可加载的参数模块来表达。
5. PAW 程序不是纯权重，而是“离散 + 连续”的混合体
论文里一个重要细节是：PAW 程序不是只有 LoRA。
它包含两部分：
program = pseudo-program + PEFT module5.1 pseudo-program：人类可读的任务重述
Pseudo-program 是自然语言形式的任务说明，通常包含：
任务描述
输出格式要求
少量输入输出示例
边界条件它的作用有点像更干净、更稳定的 prompt。用户原始 spec 可能含糊、口语化、有错别字。Pseudo compiler 会把它整理成更适合解释器执行的形式。
5.2 PEFT module：人类不直接读的连续控制信号
连续部分可以是 prefix-tuning 的 KV cache，也可以是 LoRA。论文当前主推的是 Text-to-LoRA。
LoRA 的直觉是：不改整个模型，只给模型的若干线性层加一个低秩增量：
W' = W + ΔW
ΔW = A BPAW 的关键是：这个 ΔW 不是为一个固定任务人工训练很久得到的，而是由编译器根据自然语言规格生成出来的。
所以 pseudo-program 解决“可读、可纠偏、可给解释器上下文”的问题；LoRA 解决“光靠文字 prompt 控不住细节”的问题。
6. Text-to-LoRA：论文当前最强的实现路径
论文的系统可以拆成四段：
用户 spec
→ pseudo compiler
→ pseudo-program
→ LoRA compiler + LoRA mapper
→ per-function LoRA
→ frozen interpreter 执行6.1 Pseudo compiler
Pseudo compiler 用的是一个不训练的 Qwen3-4B-Instruct 模型。它做的事情不是直接解题，而是把用户规格改写成更规范的 pseudo-program。
比如用户写：
帮我判断日志重不重要Pseudo-program 会更像：
Classify log lines. Return ONLY one word: ALERT or QUIET.
Input: [Checkpoint] Saved model at step 1000
Output: ALERT
Input: [step 100] loss=0.05 lr=0.0001
Output: QUIET6.2 LoRA compiler
LoRA compiler 是训练出来的 Qwen3-4B 模型。它读入：
原始 spec + pseudo-program + learned prefix tokens然后从它内部的 hidden states 中抽取信号，交给 LoRA mapper。
这里的 compiler 不直接输出文本答案，而是输出“如何调整解释器”的信息。
6.3 LoRA mapper
LoRA mapper 把 compiler hidden states 变成解释器各层可加载的 LoRA 参数。
论文里用了共享 basis 和 mixing coefficients 的设计：不是为每层每模块从零生成完整大矩阵，而是维护一些可学习的基础 LoRA 组件，再由 compiler 输出混合系数。这样能控制参数量，也让每个程序的权重包保持较小。
论文主线里，每个 fuzzy function 会给解释器注入约 38.5M LoRA 参数；部署量化后每个程序 adapter 约 23MB。
6.4 Frozen interpreter
解释器是冻结的小语言模型，比如 Qwen3 0.6B。
执行时做三件事：
1. 把 LoRA 挂到解释器目标模块上
2. 把 pseudo-program 放到输入前面
3. 对用户输入生成输出解释器本身不为每个任务重新训练。换任务时只换 program。
7. 训练：真正训练的是“编译器如何生成适配器”
PAW 不是每来一个任务都现场微调解释器。它训练的是一个通用编译器，使它学会：
看到一个函数规格
→ 生成一份适合这个函数的 PEFT adapter论文构造了 FuzzyBench，一个 1000 万样本的数据集。每条样本大致是：
(specification, input, target output)数据生成流程分两层：
- 先让强模型生成各种 fuzzy function 的自然语言规格。
- 再针对每个规格生成输入输出样例。
训练时：
spec + pseudo-program
→ LoRA compiler
→ LoRA adapter
→ frozen interpreter(input)
→ output
→ 和 target output 算 loss需要注意：解释器冻结，pseudo compiler 也冻结，主要训练的是 PEFT compiler 和 mapper。梯度会通过冻结解释器回传到 mapper 和 compiler hidden states，但解释器权重本身不更新。
这和普通 fine-tuning 的差别很大：
普通 fine-tuning：把模型改成更擅长某类任务
PAW：训练一个编译器，让它能为任意新 spec 生成一份小适配器8. 实验结果怎么读
论文里有几个关键数字值得单独记。
8.1 Prefix-tuning vs Text-to-LoRA
论文比较了两种程序形态：
| 方法 | FuzzyBench accuracy |
|---|---|
| 直接 prompt 小模型 | 9.8% |
| Prefix-tuning | 50.4% |
| Text-to-LoRA 较小配置 | 56.5% |
| Text-to-LoRA 默认配置 | 65.7% |
结论不是“prefix 没用”，而是：在这个文本 fuzzy function 设置下，LoRA 是更强的 PEFT 载体。
8.2 主结果：0.6B 解释器 + PAW 对比大模型 prompting
论文主表里，PAW(Qwen3 0.6B) 在 FuzzyBench verified test set 上达到 73.78% exact match；直接 prompt Qwen3-32B 是 68.70%。
这组数字的意义不是“0.6B 从此大于 32B”。更准确地说：
对于被编译过的 fuzzy function，
0.6B 解释器 + 专用程序权重
可以比 32B 通用模型直接看 spec + input 更有效。这其实符合直觉。通用大模型每次都要从 prompt 里重新理解任务；PAW 已经把任务理解预先压进了适配器。
8.3 本地执行：体积和速度是论文的工程重点
论文给出的部署口径很有工程味：
共享 base：Qwen3 0.6B 量化后约 430MB
每个程序：量化 LoRA adapter 约 23MB
速度：MacBook M3 上约 30 tok/s官方 GitHub 也把它包装成“compile natural language specs into tiny neural functions that run locally”，并给了 Python SDK 和浏览器 SDK 的方向：programasweights GitHub。
如果未来生态成熟，这种形态会很像安装库：
program = paw.compile("Classify if this message requires immediate attention")
fn = paw.function(program.id)
fn("Server is down, customers affected!")编译阶段可能需要云端资源；函数执行阶段可以离线。
9. 它和几个相近概念的区别
9.1 它不是 prompt engineering
Prompt engineering 每次执行都把任务说明塞进上下文。PAW 把任务说明的一部分编译进权重。
Prompt：运行时读说明书
PAW：编译时把说明书变成工具9.2 它不是普通 LoRA fine-tuning
普通 LoRA 是针对一个任务训练一份 adapter。PAW 的目标是训练一个 compiler，让它能根据新 spec 直接生成 adapter。
普通 LoRA：每个任务训练一次
PAW：训练一次编译器，之后每个任务编译一次9.3 它不是模型蒸馏
蒸馏通常把大模型在某类任务上的能力压到小模型里。PAW 更像是把一个具体函数编译成小模型可加载的程序。
蒸馏：让小模型整体学会一类能力
PAW：让小模型加载某个函数的专用行为9.4 它也不是让神经网络替代所有代码
PAW 不适合排序数组、计算税率、校验权限、处理强一致事务。这些任务就应该写确定性代码。
PAW 适合的是那些：
规则很难写全
输出空间相对受控
调用频率高
能接受概率性行为
需要本地/低成本/低延迟的函数。
10. 适合用 PAW 的场景
我会把 PAW 的适用场景总结成一句话：
高频调用、边界模糊、输出可约束的小函数。
具体可以是：
10.1 日志和监控
输入：一段日志
输出：ALERT / QUIET传统规则容易漏掉异常，也容易把普通 warning 全部打成噪音。直接调用大模型又太贵。PAW 适合做第一层 triage。
10.2 搜索重排
输入：query + candidate
输出：exact_match / highly_relevant / somewhat_relevant / not_relevant关键词召回先取 top 20，再用 PAW 做语义重排。这比每个候选调用大模型更便宜，也比纯 BM25 更懂意图。
10.3 Agent 预处理
输入：用户自然语言
输出：需要哪个工具、参数是什么、是否不该调用论文案例里把工具调用拆成多个 PAW 函数：是否需要工具、路由到哪个工具、提取 location/ticker/search query 等参数。确定性的 JSON 拼装仍然交给普通 Python。
这个思路很好：模糊判断交给 PAW，严格结构化和状态管理交给传统代码。
10.4 数据清洗和格式修复
输入：半坏 JSON、乱日期、脏 CSV 字段
输出：规范格式这类任务规则多、异常多，但输出格式可以约束。PAW 可以作为“轻量修复器”。
10.5 浏览器端个人工具
如果 compact interpreter 路线成熟，浏览器里加载一个小解释器和若干程序，就可以做本地分类、抽取、清洗。数据不出浏览器。
这对个人知识库、邮件插件、离线网页工具很有吸引力。
11. 局限：这篇论文不能被过度解读
PAW 很有意思，但它不是已经解决一切的范式。论文自己也列了几个局限。
11.1 编译器和解释器是绑定的
一个 PAW 系统通常是某个 compiler 对某个 interpreter 家族训练出来的。换解释器，比如从 Qwen3 0.6B 换到 Qwen3.5 0.8B，可能需要重新训练 compiler。
这不像传统 Python 字节码那样到处都能跑。
11.2 权重程序不透明
Pseudo-program 可读，但 LoRA / KV cache 不可读。你能知道它是某个函数的 adapter，但很难像读源码一样审查每个行为。
这带来调试问题：
为什么这个输入被判成 ALERT？
到底是哪部分权重影响了输出？
怎么做最小 diff？这些都还不是成熟工具链能很好回答的问题。
11.3 论文主要验证单步函数
FuzzyBench 评测是单输入、单输出。多步长程推理、复杂状态机、长期记忆、跨调用学习，不是这篇论文已经充分证明的范围。
所以 PAW 更像函数库，不像完整智能体。
11.4 训练数据是合成的
FuzzyBench 是由强模型生成的合成数据。论文做了 held-out spec、独立模型验证等控制，但真实世界任务的分布一定更复杂。
这意味着我们读结果时要保守：它证明这个范式有潜力，但不等于所有真实业务场景都能直接拿到同样收益。
11.5 PEFT 形态可能依任务而变
论文发现 LoRA 在文本任务和某些图像分类式任务上强，但 prefix-tuning 在长格式 image-to-markup 任务上可能更合适。
也就是说，“程序应该长成什么权重形态”还没有统一答案。
12. 这篇论文验证充分了吗？
我的判断是：作为 proof-of-concept，验证算比较充分；作为“新编程范式已经成立”，还不充分。
这个问题最好分三层看。
12.1 可行性验证：充分
论文不是只画了一个概念图，而是真的把链路跑通了：
自然语言 spec
→ 4B compiler
→ LoRA adapter
→ frozen 0.6B interpreter
→ fuzzy function output这证明“把一个自然语言函数规格编译成可加载权重，然后由小模型本地执行”不是纯想象。主实验里，PAW(Qwen3 0.6B) 在 FuzzyBench verified test set 上达到 73.78% exact match，超过直接 prompt Qwen3-32B 的 68.70%，同时推理内存从约 60GB 降到约 1.2GB。
所以如果问题是“这个思想能不能实现”，答案已经比较明确：能。
12.2 Benchmark 证据：中强
论文对 benchmark 的处理比普通 demo 严肃很多。
FuzzyBench 有 1000 万样本，覆盖 29 个版本、800+ 子类别。数据按 spec 拆分 train / validation / test，也就是说测试集里的函数规格训练时没见过。verified test set 还要求 gpt-5-mini 和 gpt-5.2 对答案一致，用来过滤掉目标本身太暧昧的样本。
论文还做了不少 ablation：去掉 compiler、只用 fixed LoRA、直接 full fine-tune、只用 prefix-tuning，都明显不如默认的 Text-to-LoRA PAW。这说明效果不是“小模型本来就会”，也不是“多塞一点 prompt 就行”，而是 compiler-generated adapter 确实贡献了能力。
但这里还不能说“完全充分”，因为 FuzzyBench 仍然是一个合成 benchmark。它覆盖面很广，但真实业务数据会更脏、更偏、更长尾，也会有团队自己的语义习惯、错误分布和风险边界。
所以 benchmark 证据可以说是中强：足够让人认真看待，不足以直接宣布生产可靠。
12.3 工程范式结论：还太早
如果问题变成“PAW 能不能成为通用编程范式”，目前证据还不够。
主要原因有五个：
- 真实业务泛化还缺独立验证：测试 spec 虽然未见过，但不等于完全没见过的业务领域、公司内部数据、长尾输入都能稳定工作。
- 论文主要验证单步 fuzzy function：一输入一输出的函数验证比较充分，但多步推理、长期状态、复杂 agent workflow 还不是它已经证明的范围。
- compiler 和 interpreter 强绑定：一个 compiler 是围绕某个 interpreter 家族训练出来的，换底座可能要重训，不像传统字节码那样有清晰跨平台语义。
- 权重程序不透明：LoRA adapter 可以版本化，但很难像源码一样审查、diff、解释失败原因。
- 社区复现还太早：论文是 2026-07-02 刚出的 arXiv preprint。截至我写这篇笔记的 2026-07-06，它还更像早期研究成果，而不是被长期复现和工程打磨过的成熟路线。
因此我会把当前结论定成这样：
研究可行性：强
benchmark 证据：中强
真实业务泛化：待验证
生产可靠性：早期
范式级结论：还太早比较务实的态度是：不要马上把它当成“prompt/API 的替代品”，而是拿一个高频、低风险、输出可验证的 fuzzy function 做小规模试点。比如日志 triage、搜索重排、邮件分类、工具路由前置判断。真正该看的不是论文里的平均分，而是自己数据上的四件事：
准确率有没有接近大模型 prompting
延迟和成本是否明显下降
失败样本能不能被监控和兜底
版本升级和回滚是否可控如果这四项成立，PAW 就不是一个漂亮概念，而是一个能进工程系统的部署形态。
13. 相关论文：Parametric Skills
读 PAW 时，很容易联想到另一篇几乎同期的论文：Parametric Skills。
它们不是同一篇论文换个名字，但思想高度同构：
PAW：把自然语言 fuzzy function spec 编译成 LoRA / 权重程序
Parametric Skills：把 Agent 的文本 skill 编译成 LoRA / 参数化技能共同点是：都不满足于“把能力写进 prompt，然后每次运行时重新读一遍”。它们都在尝试把文本态的可复用能力，变成可以缓存、加载、组合和版本化的参数空间工件。
区别在于层级不同：
| 维度 | PAW | Parametric Skills |
|---|---|---|
| 编译对象 | 函数规格 | 技能文档 / 轨迹经验 |
| 粒度 | input -> output 的模糊函数 | Agent 做事方法、验证流程、失败模式 |
| 典型收益 | 本地、低成本、高频函数调用 | 长上下文鲁棒性、多 skill 合并、自进化 |
| 软件类比 | 编译一个小函数 | 编译一个插件 / 能力模块 |
所以更大的趋势不是单独的“程序即权重”，而是：
可复用认知能力正在从上下文窗口迁移到参数模块。PAW 是函数层面的例子；Parametric Skills 是技能层面的例子。两篇一起看，会比单独看任何一篇都更清楚。
14. 我对这篇论文的理解
这篇论文的价值不只是一个具体系统，而是提出了一个值得记住的软件工程视角：
LLM 不一定要永远在线参与每次调用。
它也可以在开发/编译阶段工作，
把模糊需求变成可部署、可缓存、可版本化的小程序。如果把今天的 LLM 应用分成三层：
1. 规则代码：确定性、便宜、可靠
2. PAW 这类神经函数：模糊、小范围、高频、本地
3. 大模型 Agent：开放式、低频、高复杂度PAW 站在中间。它不试图取代规则代码，也不试图取代通用大模型。它想把一部分“每次都问大模型”的场景下沉成普通软件部件。
对 AI Infra 来说，这个方向很值得关注。因为真正的大规模 AI 应用不可能永远靠“每个小判断都调用一次最大模型”来堆。系统会自然走向分层：
大模型负责生成、编译、规划、处理困难样本
小模型负责本地、高频、低延迟执行
规则代码负责确定性约束和系统边界Program-as-Weights 给了这个分层一个很清晰的接口：函数规格进来，权重程序出去；解释器固定，程序热插拔。
15. 最后用一句话收束
Program-as-Weights 的好处不在于“权重比代码神奇”，而在于它把模糊函数从一次次昂贵的大模型调用，变成了可以缓存、版本化、离线执行的小型神经程序。
它最适合的问题不是“让 AI 写所有程序”，而是：
我有一个规则写不干净的小判断，
它会被调用很多很多次，
我希望它像普通函数一样便宜、稳定、本地可运行。这时，程序即权重才真正有意义。