前几天我在推特上问了一个问题：使用 AI Agent 开发软件的时候，设计、规划、写代码和 Review 这几项工作，到底哪一项更需要高级模型？
按照传统软件公司的人员安排，似乎应该让能力一般的模型先干活，再让最好的模型负责把关。普通程序员写代码，资深程序员 Review，大家对此已经习以为常。套用到 AI 上，就是先用便宜模型生成代码，最后再请最强模型检查一遍。
不过我现在的实践差不多是反过来的：一开始沟通需求和做设计的时候使用最好的模型，检查设计时可以稍微降一档，具体开发使用中等模型，到了常规 Code 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 画出的边界思考。两个隔离的上下文，才有机会得到两套真正不同的解法。
等两份设计都完成以后，再把它们放在一起比较和整合。它们一致的地方通常比较可靠，分歧大的地方则正好值得继续追问：是不是对需求有不同理解，是不是依赖了没有说出来的假设，还是某一种方案只是更符合其中一个模型的习惯。最后可以让最强的模型负责比较，也可以让人来决定取舍。
这里关键的未必是一定要使用两个不同品牌的模型，而是先保证独立思考，再发生对抗。不同模型可以增加思路的多样性，但如果一开始就让其中一个看到另一个的答案，再多样的模型也容易变成对现有方案的修补者。把答案分开生成，再集中比较，才是真正把额外的模型能力花在了决定方向的地方。
资源有限的时候，与其让便宜模型先选一条路，等走出去很远了再请最好的模型检查，不如一开始就让最好的模型决定往哪边走。后面那些目标明确、容易验证的体力活，交给其他模型慢慢干就好了。