最近发现一个挺有意思的现象，现在很多人研究 AI 编程，已经不满足于只用一个模型了。 Codex 负责开发，Claude Code 负责审查，Gemini … · @UPing123zzz · TwKit

@UPing123zzz

最近发现一个挺有意思的现象，现在很多人研究 AI 编程，已经不满足于只用一个模型了。 Codex 负责开发，Claude Code 负责审查，Gemini 负责研究方案，最后再找一个模型检查前面几个模型的结论。有些人甚至搭了一整套自动化系统，让不同模型互相提意见、互相修改、互相验证。 刚开始看到这种东西，我也觉得特别牛逼。毕竟每个模型都有自己的优势，如果把它们组合起来，不就相当于让好几个顶级工程师一起做项目了吗？ 但后来仔细想想，事情可能没有这么简单。 不同模型对同一个问题的理解，有时候可能完全不一样。比如你让 Codex 设计一套后端架构，它认为当前业务规模下采用单体架构最合适，代码简单，维护成本也低。然后你把方案交给另一个模型审查，对方可能觉得应该做微服务，方便未来扩展。第三个模型又说不应该过度设计，最好采用另外一种技术方案。 问题来了，到底听谁的？ 如果你自己没有足够的工程判断能力，很容易陷入一种特别尴尬的状态：每个模型讲得都挺有道理，你也不知道哪个更好，最后只能不断把它们的结论互相转发。 Codex 说 A，Claude 说 B，你让 Codex 反驳 Claude，Claude 又指出 Codex 的问题。几个模型来回讨论半天，Token 消耗了一大堆，真正需要解决的业务问题却没怎么推进。 而且不同模型之间不仅存在观点差异，还会产生上下文同步、代码冲突、重复计算和审查成本。 你原本想做的是一个产品，最后却花大量时间研究怎么管理这些模型。 所以最近我开始觉得，多模型协作的关键不是让所有模型都参与所有事情，而是根据任务本身决定有没有必要引入新的模型。 比如我主要使用 Codex 开发项目，那么它就应该对整体工程状态负责。遇到需要审查架构的地方，可以让另一个模型提供独立意见；遇到文案创作，可以使用更擅长表达的模型；遇到安全问题，可以让独立工具和审查流程介入。 但不能每改一个按钮，都让三个模型轮流检查。 更重要的是，模型之间相互认同，不代表结果就一定正确。 三个模型都觉得代码没问题，但实际运行测试失败了，那就是有问题。两个模型都认为需求合理，但客户根本不需要这个功能，那这个需求仍然值得重新考虑。 AI 给出的结论再漂亮，也比不上真实运行结果和实际业务反馈。 我现在更倾向于一个主 Agent 负责整个工程，其他模型按需介入，最终通过测试、文档和人工验收来判断成果。 说到底，AI 是帮助我们降低解决问题的成本，而不是让我们不断创造新的管理复杂度。 不要为了证明自己会用很多模型，最后反而把原来简单的事情搞复杂了。 真正厉害的不是把所有最贵的模型都用一遍，而是知道什么时候该用哪个，什么时候根本没必要用。

曝光 409 · 评论 5 · 点赞 6 · 书签 4