用 AI 辅助开发一个中大型项目，很快会撞上一笔经济账：旗舰模型效果好但 token 贵，长项目里 80% 的活其实是"把明确意图翻译成代码"的体力活——全用旗舰模型烧不起，全用便宜模型又怕静默翻车。
我们沉淀出一套双模型分工协议：旗舰模型只做判断（设计、审查、排障），经济模型只做翻译（按规格写代码、跑验收）。核心不是"哪个模型干什么"的静态清单，而是三道闸门——它们决定了弱模型的产出能不能被信任。
熟悉结对编程的读者会发现，这套分工本质上就是一对能力不对称的 pair：旗舰模型领航，经济模型驾驶（详见 §2）。
1. 分工的本质：判断 vs 翻译
| 留给旗舰模型（判断） | 交给经济模型（翻译） |
|---|---|
| 架构/协议设计、任务拆解、写规格 | 按规格实现：样板代码、迁移脚本、DTO/Mapper |
| 并发/流式/事务等高危逻辑 | 有明确用例矩阵的测试扩写 |
| 疑难排障 | 文档初稿（给好大纲）、配置调整 |
| 审查经济模型的所有 diff | 探索性阅读（"读这个模块总结一下"） |
一句话：判断不外包，翻译不亲自动手。
效果的关键在规格质量。"给工具层加失败降级"对弱模型是难题；"在 X 类的 Y 方法里按异常类型分三类，分别返回带【】前缀的文本，执行用虚拟线程+限时"就是翻译题。规格越具体，两个模型的效果差距越小。
2. 换个角度看：这就是结对编程
把两个模型当成一对程序员，这套分工立刻变得眼熟——它就是结对编程的经典角色分配，只是这对 pair 的能力天然不对称：
- 旗舰模型 = 领航员（navigator）：想设计、看全局、盯着每一行要进电脑的代码；
- 经济模型 = 驾驶员（driver）：握着键盘，把明确意图翻译成代码。
结对编程里有一种玩法叫 strong-style pairing："想法要从领航员的脑子进入电脑，必须经过驾驶员的手。"我们的协议正是这个结构——想法以规格的形式从领航员（旗舰模型）出发，经驾驶员（经济模型）的手落成代码，再由领航员审查回流。"判断不外包，翻译不亲自动手"就是 strong-style pairing 的 AI 版表述。
和人类结对的三点对应关系：
| 人类结对 | 双模型协作 |
|---|---|
| 驾驶员写代码，领航员逐行看 | 经济模型实现，旗舰模型只读 diff 兜底审查（闸门三） |
| ping-pong 结对：一人写测试一人实现，靠 commit 交接 | 任务边界切换 + checkpoint commit + 上下文压缩（§5） |
| 结对的前提是两人能互相接住对方的活 | 能力硬不对称 → 角色固定，不轮换 |
第三点是与人类结对最大的不同，也是最值得强调的一点。人类结对强调定期轮换角色——既避免疲劳，也让双方保持投入和上下文同步。双模型协作恰恰不能轮换：让经济模型去领航（做设计、审 diff）等于亲手拆掉三道闸门，省下的 token 会以静默回归的形式加倍还回来。所以这不是"平等的结对"，而是定向结对：角色由能力决定，信任由流程补齐——三道闸门扮演的就是人类 pair 之间"我信你写的代码"的那个信任来源。
3. 闸门一：验收标准前置给执行方
不要让强模型替弱模型跑测试——把不可辩驳的验收标准写进任务规格，由弱模型自己执行、自己贴输出：
任务：给 SQL 查询工具加每会话调用预算
验收（必须全部通过并贴出原始输出）：
1. mvn test -pl infra -Dtest='SqlQuery*' → BUILD SUCCESS
2. mvn compile → 无错误
3. git diff --stat → 只涉及预期文件
4. 不得修改禁区文件清单中的文件
要点：命令 + 预期退出码 + diff 范围约束。"确保不破坏现有功能"这种模糊标准，对弱模型等于没有标准。强模型此时从"执行者"退为"审查者"，token 花在读 diff（便宜）而不是跑流程（贵）上。
4. 闸门二：红线——不许让绿灯"变绿"
弱模型最危险的习惯是验收失败时"绕过"：删掉失败的测试、把 assertEquals 弱化成 assertNotNull、加 @Disabled、注释掉报错的代码。测试全绿 ≠ 实现正确——测试可能本身就被写歪了。
协议里必须明文禁止，并要求验收失败时把失败输出原样贴出、停止、升级，由强模型接手判断。这一条是整套分工的信任基础，值得写进项目的 AI 协作规范文件（如 CLAUDE.md），让任何模型进来都能看到。
配套两条：
- 禁区文件清单：并发、流式、核心编排类代码，弱模型不直接改——这些地方一次静默回归的成本远超省下的 token；
- 连续两次修不好同一问题 → 停止并升级：弱模型在原地烧轮次时，强模型事后读它的失败现场反而更贵。
5. 闸门三：强模型的兜底审查（只读，不重跑）
弱模型自验通过后，强模型的兜底只做三件低成本的事：
- 读 diff 逻辑——实现对不对、有没有顺手改了不该改的；
- 读测试真实性——断言有没有被弱化（这是弱模型的常见病）；
- 核对规格符合度——做的是不是要求的那些事，有没有多出来的"惊喜"。
三项都无可疑就直接过；存疑才自己动手。强模型不重复执行验收——那是弱模型已经做过的事。
6. 操作层面的经验
- 切换放在任务边界（结对编程里的 ping-pong 交接）：不要排查到一半换模型；换之前先 commit checkpoint、压缩上下文（
/compact类机制），压缩后的上下文对弱模型更友好也更便宜； - 一个任务一个会话：带全部历史的巨型会话，每轮都在为两个模型同时烧钱；
- 定义"完成"：完成 = 验收命令全绿 + 输出已贴出，不是"我认为改完了"——弱模型有提前宣布胜利的倾向，看 diff 和测试输出是唯一标准；
- 先建测试基线再分流：这套模式的前提是仓库里有可信的测试与 CI 卡点，否则强模型的兜底审查会被迫变成全量重跑，省 token 就无从谈起。
一句话总结：双模型协作省 token 的本质，是把强模型的角色从"执行者"抬升为"规格制定者 + 审查者"——用结对编程的话说，旗舰模型做领航员、经济模型做驾驶员，三道闸门（可执行验收、反作弊红线、只读兜底）就是这对不对称 pair 之间的信任机制。闸门建好后，效果损失趋近于零，成本随任务中"翻译"的占比线性下降。