本能上，更多模型意味着更好的答案。再打开一个标签页，再多一个视角，通过三角测量找到真相。这在大约三个模型的时候有效，然后反转得很厉害。超过那个点，你添加的每个模型所花费的协调成本都超过了它带来的洞察，第一个退化的不是你的速度。而是你对哪个答案是正确的判断。
关键要点：一个模型强制清晰思维。两个或三个给你一个真正的第二意见。超过那个点，你不是在编排模型，你是在主持一个记不住自己十分钟前同意了什么的委员会。
我在一个月后画了这条曲线，在那个月里我大致永久地打开了六个模型，感到非常有效率，但交付的工作明显更差。
六个模型打开让我在一个重定向地图上浪费了一天
在我最差的时候，我在一个架构问题上用Opus 5，在实现中途用Codex，在编辑器中实时运行Composer，打开Grok进行第二次阅读，还有Qwen和Kimi停放在另外两个标签页中，因为X上有人说他们在这方面做得很好。感觉像一个驾驶舱。实际上是一个没有人读过简报的群聊。
这笔成本出现在一个重定向映射中。我在一个大型程序化网站上合并了几百个旧URL，这类工作95%正确就等于灾难，因为那5%会悄悄地用301把流量重定向到死胡同。我问了三个模型，关于尾部斜杠链获得了三个都站得住脚的答案。我没有选择其中一个然后推理下去，而是把它们合并了。这个混合方案比任何单独的都要糟，因为每一个内部都自洽，但合并后就不自洽了。花了一整天才理清楚，完全是自找的。
一个模型能强制你清晰地思考
单一模型被低估的特性是，它把规范的责任推回给你。只有一个东西可以问，你就必须写一份真正的简报：输入是什么，输出必须满足什么，什么在范围之外，什么叫"完成"。这个写的过程就是大部分工程。我在写提示词时发现的设计缺陷比任何代码审查都多。
同时打开六个模型，那种纪律就悄悄消失了。你停止写简报，开始进行投票，一个模糊的问题丢给六个模型会换来六个自信的答案。自信不是证据，这只是这些系统听起来的样子。我Claude Code工作流中几乎所有的价值都在模型的上游。
两三个模型才是真正的甜蜜点
三个模型之所以有效，是因为这些模型在做不同的工作，而不是并行做同一个工作。分工是加法的。重复则不然。一个模型掌握计划，一个写代码，一个冷静地把它读回给你。没人在投票。
两个模型开始做同样的工作的那一刻，你买到的不是冗余。你买到的是一个只有你才能解决的平局，而你是这场对话中休息最少的参与者。
专家模型真正值得占用一个标签页的时候
专家模型值得投资的条件是它们在结构上不同，而不仅仅是品牌不同。我的测试很简单：它是否以一种我能从中学到东西的方式与其他模型产生分歧？一个同意所有观点的模型只是一个非常昂贵的应声虫。
Codex在实现方面值得占用一个标签页，特别是在跨多个文件的长机械式改动中，我想要一个diff而不是一场对话。Composer 2.5在编辑器内值得占用，因为这里的价值是延迟而不是深度。Grok在产品和定位问题上值得占用，因为它会很乐意告诉我这个想法很无聊。Qwen和Kimi在我想要一个不同的训练分布而不是来自同一个邻域的另一次投票时值得占用。我在UI审计脚本中专门接入了Kimi，正是因为它会注意到其他模型已经学会了对之视而不见的东西。
最后这个区别就是关键所在。大多数时候，当人们添加第五个模型时，他们不是在寻求另一个观点，而是在寻求另一个确认。这两者在当下感觉一样，但实际上是相反的。
隐性成本是协调，而非切换
上下文切换是每个人都会提到的成本，而且是真实存在的：因为你记不住你在哪个标签页里提到了那个约束，所以你重新读了同一个文件四次。但这不是最昂贵的成本。
昂贵的成本在于你成了合并冲突的仲裁者。两个模型给你一个分歧需要判决。三个给你三个。六个给你十五对两两之间的分歧，每一个都需要同一个疲惫的人类来做决定。你的整个技术栈中没有任何东西在为你做这个协调工作。你就是那个集成层，在一天结束时运行，处理一个你已经读过六种略微不同表述方式的问题。
而且模型在这里帮不了你，因为它们谁也不知道别人说了什么。只有你拥有完整的上下文，而这正是你试图委托出去的位置。
AI 编排通常是一个人的问题
当人们说他们需要更好的编排时，他们通常是说他们需要一份更清晰的简报。如果三个模型给你三个完全不同的答案，那几乎不是能力差距。几乎总是问题中的歧义，没有任何路由逻辑能解决一个定义不清的问题。它只是把问题分散了。
我现在用的诊断方法：如果我写不出两句话来说明一个正确答案必须满足什么，那开另一个模型就是一个带进度条的拖延。先写出那两句话。有时候那两句话就是答案，我会关掉所有标签页。
我今天实际运行的工作流
Opus 5 用来思考。架构、权衡取舍、那个尴尬的问题——这个东西到底应不应该被开发。这是我花费提示词努力的地方，因为这里的坏决定以后是无法通过更好的代码来弥补的。
实现的代码规范。一旦确定了形状，把规格给它，让它工作。我审查diff，不审查推理。
Composer 2.5 用于编码协助。编辑器内，速度快，范围小。它是更好的自动补全，不是同事，把它当同事是怎么你得到了400行你没要求的代码的方式。
Grok 用于另一种视角。刻意不放在关键路径上。当我怀疑自己已经说服了自己时，我就去那里。
当我想要另一个意见而不是另一个确认时，使用 Qwen 或 Kimi。很少。有意为之。
重要的部分不是这个列表。重要的是这些几乎从不同时打开。是一个序列，不是驾驶舱：思考，然后实现，然后审查，每个阶段一个模型掌握笔。这个图表峰值为三是因为三是好的一天中有多少个阶段真正处于活跃状态。我在 Claude Code 与 Cursor 中比较了其中两个。
更好的提示词胜过更多的标签页
一个定义良好的问题交给一个好模型胜过一个模糊的问题交给六个，而且差距很大。更多模型感觉更好是因为打开一个标签页是瞬间的，而写一份简报是工作。AI FOMO 是相信下一个模型会做你一直在回避的思考。它不会。它会对错误的问题更有说服力。
纪律是不起眼的，而且它会复利。我认识的用这些工具输出最好工作的人不是在运行最多模型的人。他们是有意识地运行两个或三个，有明确的劳动分工和书面规格，他们对本周模型的讨论感到厌倦。
今天做一件事
关闭除了一个之外的每个 AI 标签页。拿你正在做的任务，写两句话：输入是什么，以及正确的输出必须满足什么。把这两句话给你留下的那个模型。如果答案很好，你的瓶颈从来不是模型容量。如果答案很差，你现在知道了两句话中哪一个是错的，这是六个模型本来不能告诉你的事。
常见问题
我应该同时使用多少个AI模型?
两个或三个，各司其职：一个用来思考问题，一个用来实现，还有一个可选的用来审查或提出反对意见。超过三个以后，调和相互冲突答案的成本增长速度会快于额外视角的价值增长，因为只有你知道它们都说了什么。
对同一个任务使用多个AI模型是不是不好?
在完全相同的任务上运行两个模型通常是浪费。这不会为你买来冗余，而是买来一个只有你能解决的平手。当模型有不同的角色时，比如规划对比实现，它们会有所帮助；当它们相互重复时，它们就会有害。
在AI模型之间切换的真实成本是什么?
显而易见的成本是重新建立上下文和重新阅读相同的文件。更大的成本是调和：有六个模型时，你有十五对两两之间的分歧要裁决，而你的整个技术栈中没有任何东西能为你做这件事。你成了集成层。
Codex、Grok、Qwen或Kimi这样的专业模型真的有帮助吗?
有帮助，但前提是它们在结构上有差异而不仅仅是品牌不同，并且它们有明确的工作职能。测试方法是这个模型是否以你能学到东西的方式与你的其他模型不同。如果它大多与其他模型一致，你付的是确认费，不是洞见费。
相关内容：我的Claude Code工作流，体现了这个论点所主张的单模型纪律，或者如果你想让别人来处理这个问题，可以考虑聘请一个Claude Code开发者。