分享 AI Agent 开发中的模型分工实践：把最强模型用于需求与设计，让目标明确、容易验证的实现和常规审查交给其他模型，并通过独立设计比较减少路径依赖。
使用 AI Agent 开发软件时，设计、规划、写代码和 Review，哪一项最需要高级模型？直觉上的安排是先用便宜模型生成代码，再让最强模型把关。但如果最初选错了方向，最后的审查未必能把整个方案救回来。
原作者的实践是反过来的：先把最好的模型用于需求沟通和设计，再根据任务是否明确、结果是否容易验证，逐步降低后续阶段的模型成本。
先看结论：把能力优先投入关键决策
这篇文章的判断可以分为三个层次：
- 先确定方向。 把最好的模型用于需求理解和方案设计。
- 再约束执行。 接口、修改范围和验收条件明确后，实施任务才更适合交给成本较低的模型。
- 把比较提前。 想利用多个模型的能力，先让它们独立设计，再比较分歧，而不是只在代码写完后增加一道审查。
为什么后置审查难以纠正方向
AI 模型有一个挺麻烦的特点，就是很擅长沿着已有的东西继续做，却不太擅长把它整个推翻。
比如先让一个弱模型出一份设计，再交给强模型 Review。强模型通常可以发现一些问题：这里少考虑了一种异常情况，那里接口划分得不够好，某个模块还需要补几项测试。它会给出很多有用的意见，最后把原来的设计修改得更加完整。
但是它很少会退回到最初的需求，完全不理会眼前这份设计，重新想一遍这件事情到底应该怎么做。已有设计会给它划出一个范围，Review 往往就变成了在这个范围内查缺补漏。 即使模型能力很强，也容易得到一份精心改进过的平庸设计。
这不一定只是模型喜欢附和。我们把一份文档交给模型，要求它“Review 一下”，任务本身就在暗示它：这份东西大体上是成立的，你来找找其中的问题。原设计中的模块、概念和技术路线因此成了思考的起点，很难再被当作普通候选方案重新审视。
而且软件开发有很强的惯性。需求理解错了，后面的规划会把这个错误展开；设计方向错了，开发模型会在错误的结构里面认真写代码；等代码、测试和文档都有了，整个方案看起来反而越来越像是经过充分考虑的结果。这时候再请一个强模型进来，它面对的已经不只是一个错误观点，而是一堆互相支持的上下文。
所以越靠前的错误越贵。需求和设计阶段看起来没有产出多少代码，却决定了后面所有代码应该往哪里写。把最好的模型用在这里，收益可能比最后多查出几个 bug 大得多。
按任务的不确定性分配模型
需求阶段面对的是一个开放问题。模型要判断用户真正想解决什么问题，哪些话只是随口举的例子，哪些限制虽然没说出来但必须考虑，还要在多种完全不同的方案之间做选择。这些事情很难写成一份完整的检查清单。
进入开发阶段以后，问题会逐渐变得具体。模型要实现哪个接口、修改哪些文件、满足什么测试，通常已经比较清楚。即使模型写错了，还有编译器、类型系统、单元测试和 CI 帮忙发现问题。一个中等能力的模型只要能正确理解设计，往往就可以把工作完成。
常规 Code Review 的范围更小。 实现是否符合设计、有没有漏掉错误处理、测试是否覆盖边界情况，这些问题都有相对明确的判断标准。Review 模型不需要重新理解整个世界，只要对着需求、设计和代码逐项检查即可。这个工作当然也需要能力，但未必值得使用最昂贵的模型。
下面的分工表是对原文观点的整理，并非固定的模型等级要求：
| 阶段 | 主要判断 | 模型分工思路 | 可检查的产物 |
|---|---|---|---|
| 需求理解 | 真正的问题、隐含约束与范围 | 优先投入最适合该任务的高能力模型 | 目标、约束与验收标准 |
| 方案设计 | 技术路线、模块边界与取舍 | 保持较高的推理投入，必要时独立生成候选方案 | 方案、假设与取舍依据 |
| 具体实现 | 按已明确的设计完成改动 | 在设计和验证充分时评估使用中等模型 | 代码、类型检查与测试结果 |
| 常规审查 | 实现是否符合要求、是否遗漏边界 | 按风险选择能力，不把低成本作为唯一目标 | 缺陷证据与未验证事项 |
从这个角度看，模型的能力不应该按照工作量分配。写代码可能占掉了百分之八十的时间，却不一定需要百分之八十的智能。真正需要好模型的，是那些选择很多、很难验证，而且一旦选错就会影响后面所有工作的决策。
人类审查与模型审查的差别
传统软件团队当然也会让资深工程师参与需求和架构设计，不过大量日常开发确实是由普通工程师完成，再由更资深的人 Review。因为我们相信一个有经验的 Reviewer 不只会检查代码格式，他有自己的经验和判断，发现方向不对时可以直接说：“别改了，这个方案应该重做。”
人类 Reviewer 也不会轻易把已有代码当成不可质疑的前提。他知道代码只是某个人在有限时间里写出来的一种方案，而且他还要对合并后的结果负责。如果推翻重来更划算，他有足够的动机和权力这么做。
模型则不太一样。它没有长期参与项目形成的独立判断，也不真正承担代码合并后的责任。我们让它 Review，它就会努力扮演一个 Reviewer；而这个角色通常意味着改进当前方案，而不是假装当前方案不存在，再从头设计一遍。
因此，传统团队可以在流程后面安排资深人员纠偏，AI 工作流却不能太指望最后一道 Review 把前面的方向性错误全部救回来。最强模型如果最后才进场，可能已经错过了最能发挥作用的时候。
让设计独立生成，再比较分歧
有一种常见做法是交叉使用不同的模型：A 模型写代码，再让 B 模型 Review。不同模型的习惯和盲点不完全一样，这样确实可能多发现一些问题，看起来也形成了一种互相对抗。
但只要 B 看到的是 A 已经写好的代码，它仍然会被带进 A 选择的结构里。它可能不喜欢某个接口，可能发现一处遗漏，也可能提出更好的实现方式，却很少再去追问为什么一开始要这样拆分。换了一个模型可以减少共同的盲点，却没有消除已有产物带来的路径依赖。
如果愿意花两份模型成本，我觉得更值得把这种对抗放在设计阶段。给 A 和 B 同一份原始需求，让它们在彼此不知道对方答案的情况下各自做一份设计。不要先让 A 设计，再把 A 的结果交给 B Review；那样 B 还是会沿着 A 画出的边界思考。两个隔离的上下文，才有机会得到两套真正不同的解法。
等两份设计都完成以后，再把它们放在一起比较和整合。它们一致的地方通常比较可靠， 分歧大的地方则正好值得继续追问：是不是对需求有不同理解，是不是依赖了没有说出来的假设，还是某一种方案只是更符合其中一个模型的习惯。最后可以让最强的模型负责比较，也可以让人来决定取舍。
这里关键的未必是一定要使用两个不同品牌的模型，而是先保证独立思考，再发生对抗。不同模型可以增加思路的多样性，但如果一开始就让其中一个看到另一个的答案，再多样的模型也容易变成对现有方案的修补者。把答案分开生成，再集中比较，才是真正把额外的模型能力花在了决定方向的地方。
如何落实到一次开发任务
资源有限的时候，与其让便宜模型先选一条路，等走出去很远了再请最好的模型检查，不如一开始就让最好的模型决定往哪边走。后面那些目标明确、容易验证的体力活，交给其他模型慢慢干就好了。
可以按下面的顺序实践（本站补充）：
- 写清原始需求。 记录目标、范围、已知约束和完成标准，不把某个技术方案预先当作需求。
- 先审查设计前提。 对关键选择要求给出依据；存在明显分歧时，再让独立上下文生成候选方案。
- 把实现变成可验收任务。 明确接口、修改范围与验证方式，再决定是否使用成本较低的模型。
- 按风险安排审查。 常规问题对照要求逐项检查；涉及关键边界或无法验证的假设时，重新投入更强的判断能力。
评论交流
支持作者