前段时间，我在用 Codex 做开发协作时，遇到一个很真实的问题：

周额度只剩 20% 了。

这时候我没有继续让更重的模型顶上，而是把它切换成了更轻量的模型，去修那些边界清楚、目标明确、验证路径也很直接的小问题。

结果很直接：

很多明确的 Bug，真的不需要最贵的模型。

这件事让我更坚定了一个判断：

在 AI 编程里，最浪费成本的做法，不是模型不够强，反而是“让最强的模型做所有事情”。

---

---

真正贵的，不是调用次数，而是“错误地使用高成本模型”

很多团队在引入 AI 编程时，最容易走向一个默认路径：

• 最强模型负责规划
• 最强模型负责实现
• 最强模型负责检查
• 最强模型最好还能并行开几个线程一起做

看起来很猛，实际上很容易出现一个问题：

成本上去了，但真正创造价值的部分并没有同比增加。

因为在真实开发里，不是每一个任务都需要高强度推理。

有些任务，真正难的是：

• 把需求讲清楚
• 把边界切干净
• 把验证路径提前定义好
• 提前识别哪些地方不能碰

而一旦这些事情已经做完，后面的实现往往就变成了：

按范围改代码、补测试、跑验证、提交结果。

这时候，再继续堆最强模型，很多时候并不划算。

---

我现在更认可的一种分工：Planner 负责想清楚，Implementer 负责做出来

我现在越来越倾向于把 AI 编程协作拆成两类角色：

1）Planner：负责规划、控范围、拆任务

它的价值不是“写更多代码”，而是：

• 澄清需求
• 控制范围
• 拆 ticket
• 指定验证方式
• 告诉执行模型：哪里能动，哪里不能动

2）Implementer：负责执行已经定义清楚的任务

它的价值不是“重新发明方案”，而是：

• 按 ticket 改代码
• 补测试
• 按要求做文档更新
• 按要求执行验证
• 到达 stop condition 时及时停下来

这套分工最重要的一点是：

贵模型负责减少歧义，便宜模型负责消化确定性。

也就是说，真正该花钱的地方，不是“写代码”本身，而是：

• 需求还不清楚的时候
• 风险还没识别完的时候
• 任务边界还没切干净的时候
• 你还不知道应该怎么验证的时候

---

一个最小闭环，比一上来追求多 Agent 并行更重要`

很多人看到多 Agent，第一反应就是：

• 能不能并行？
• 能不能 fan-out？
• 能不能一个 planner 带多个 implementer 一起做？

我现在更倾向于先把最小闭环跑稳：

1 planner → 1 implementer

原因很简单，因为真正贵的不是并行本身，而是并行之后的协调成本。

比如这些问题，只要有一个没处理好，并行就可能变成“表面提速，后面返工”：

• 文件边界有没有重叠？
• 各自能不能独立验证？
• 合并顺序是否明确？
• 一张 ticket 会不会依赖另一张 ticket 才能成立？
• review 时会不会发现大家其实改的是同一块逻辑？

所以我的经验是：

默认先把 1 → 1 跑稳。 只有在 handoff 足够稳定、任务真正可拆、预算也可控时，再考虑 1 → 2 或 1 → n。

不是不能并行，而是不要为了并行而并行。

---

一个特别实用的判断标准：任务边界清不清楚，比模型强不强更重要

一个任务到底该不该交给更轻的模型，不一定取决于代码量，而更取决于：

这个任务是否已经被定义清楚。

我现在更看重这几个维度：

• 修改范围是否明确
• 排除范围是否明确
• 成功标准是否明确
• 验证命令是否明确
• 失败或异常时是否有清晰停止条件

如果这些条件都满足，很多任务其实很适合交给轻量模型执行。因为很多返工，不是实现模型能力不够，而是规划阶段没有说清楚：

• 包含哪些文件
• 排除哪些模块
• 这次成功的标准是什么
• 应该跑哪些验证
• 遇到什么情况必须停下来，回交 planner

如果这些都没定义好，实现模型很容易开始“自己补脑”：

• 擅自扩大范围
• 顺手重构别的地方
• 重新解释需求
• 用自己的理解改掉不该动的内容

这类返工，成本非常高。

所以我现在越来越认可一个做法：

不要急着升级 implementer，先提升 planner 的拆分质量。

---

我很认同的一种 handoff 方式：短、具体、有边界

Planner 和 Implementer 之间，最好不要交接一大段散文式说明。

真正有效的 handoff，应该满足 3 个条件：

1）足够短

别让交接本身消耗太多 token 和注意力。

2）足够具体

明确写清：

• 包含范围
• 排除范围
• 成功标准
• 验证命令
• 停止条件
• 输出物

3）足够边界化

让 implementer 明确知道：

什么时候继续做，什么时候必须停下来。

因为 AI 协作里最危险的，不是“不做事”，而是：

在不该继续的时候继续做。

---

预算紧的时候，真正该收缩的是“拓扑”，不是只盯着模型名字

我现在很认可一种很朴素的策略：

额度宽裕时

• 以 1 -> 1 为默认
• 条件很干净时，可以谨慎尝试 1 -> 2

额度一般时

• 优先保持 1 -> 1
• 只把并行留给非常独立的小切片

额度紧张时

• 只保留 1 -> 1
• 谨慎升级 planner
• 尽量避免 fan-out

因为预算吃紧时，最容易犯的错误不是“模型不够强”，而是：

还在用扩张型拓扑解决本该收缩的问题。

真正有效的节流，不只是把大模型换成小模型，而是同时去控制：

• 任务拆分方式
• 并发数量
• review 成本
• 回滚风险
• 合并复杂度

---

我自己的任务分级，也越来越偏向这套思路

在实际开发里，我会大致这样看任务：

T0：非常小、非常明确

比如：

• 拼写修正
• 注释调整
• 一行 import 修复
• 显而易见的 snapshot 更新

这种任务，很多时候直接做就行。 如果行为有变化，再补一轮检查。

T1：小型有边界任务

比如：

• 单模块 bug fix
• 局部校验逻辑调整
• 一组聚焦测试

这种任务最适合： planner 定一下范围，implementer 快速落地。

T2：中型但边界还算清楚

比如：

• 小功能切片
• 局部重构
• endpoint + service wiring

这类任务建议优先 1 → 1，确认切分稳定后再考虑扩展。

T3：跨子系统任务

比如：

• backend + client + docs 联动
• schema + service + compatibility layer
• middleware / handler / permission 联动

这类任务，规划质量远比并发更重要。

T4：架构或安全敏感任务

比如：

• 深度重构
• 迁移策略设计
• 权限、隔离、部署链路改动
• 并发风险较高的调整

这类任务最忌讳的，就是还没想清楚就急着 fan-out。

---

这套方法最想解决的，不是“让 AI 更聪明”，而是“让协作更稳、更便宜”

我现在越来越觉得，AI 编程真正要优化的，不是单次回答质量，而是整条工作流：

• 谁负责想清楚
• 谁负责做出来
• 谁负责检查越界
• 谁在关键点接管判断
• 什么情况下继续
• 什么情况下立刻停止

很多时候，只要这些机制清晰了，模型反而不用一直升级。

因为真正可持续的协作，不是“最强模型全包”，而是：

把贵的推理，只花在最值得花的地方。

---

这套方法，我也在持续沉淀进 GitHub 仓库

这篇文章不是纸上谈兵，而是我最近在实际使用 AI 编程协作方式时，一点点总结出来的经验。

我也在持续把这套思路整理进自己的 GitHub 仓库 mo2g/DevLab，方便后续复用、迭代和验证：

如果你也在关注这些问题：

• 怎么让 AI 编程协作更稳
• 怎么减少返工
• 怎么控制高成本模型的使用
• 怎么让 planner / implementer 的分工更清晰

那这个方向也许会对你有参考价值。

---

最后一句

你现在在 AI 编程里最常遇到的问题，到底是什么？

• 预算不够
• 返工太多
• ticket 总切不干净
• 还是模型很强，但协作还是很乱

欢迎留言聊聊。 我后面也会继续把这套方法拆得更细一点，写成更多可直接复用的实战内容。

---

这几年我越来越相信一件事： AI 编程的关键，不只是模型更强，而是协作更清楚、成本更可控。

我会把这类实战思考持续整理到 GitHub，感兴趣的朋友欢迎关注：

GitHub：mo2g/DevLab

Planner / Implementer Cookbook（成本控制版）