DWILL
GitHub RSS

2026/04/04 - 2 分钟阅读

收束与发散：GPT-5.4 和 Claude Opus 4.6 如何组成一个更强的开发搭档

从我的真实协作经验出发，结合 Anthropic 与 OpenAI 的官方思路，谈为什么多模型分工比单模型最强更重要。

本页目录

我最近在用两套东西一起开发：

  • Codex App 里的 GPT-5.4
  • Windsurf IDE 里的 Claude Opus 4.6

结果非常直接：效率和质量都明显上去了。

而真正让我觉得有意思的，并不是“两个都很强”这种废话，而是我越来越确认，它们强的地方其实不一样。

  • GPT-5.4 更像一个会收束的人
  • Claude Opus 4.6 更像一个会发散的人

前者擅长把问题框住、把方向拧正、把风险挑出来、把代码审过一遍。
后者擅长把东西真正铺开、做深、做完整、把工程往前推。

我现在越来越不相信“找一个最强单模型”这件事了。
我更相信的是：

最强模型，不如最强分工。

我是怎么分工的

我现在最稳定的一种用法，大概是这样：

  • GPT-5.4 做 planner、reviewer、auditor
  • Claude Opus 4.6 做 engineer、implementer、expander

也就是说：

  • 需求不清楚时，让 GPT 帮我收束问题、拆解任务、列风险和验收标准
  • 代码真正开始落地时，让 Claude 去展开、补齐、跨文件推进实现
  • 做完后，再让 GPT 回来看结构、命名、边界、遗漏和“有没有跑偏”

这套分工看起来有点像“一个人负责规划，一个人负责施工”，但它的关键不只是角色名称，而是认知倾向的互补。

有些模型很会“推进”，但不一定很会“刹车”；
有些模型很会“判断”，但不一定最适合长时间铺开实现。

而我最近这组搭配，恰好是：

  • 一个偏收束
  • 一个偏发散

这件事一旦跑顺，你会明显感觉到：
AI 协作开始有了团队感，而不是单兵作战感。

为什么我说 GPT-5.4 更像收束者

这里说的“收束”，不是说 GPT 更保守，而是说它更像那个会不断问：

  • 这件事的边界到底是什么？
  • 这样改会不会破坏已有结构？
  • 有没有更合理的拆分方式？
  • 当前实现是不是已经足够，不要再继续扩张了？
  • 哪些地方真正值得做，哪些地方只是过度设计？

在我最近的实际使用里，GPT-5.4 特别适合做这些事情：

  • 审查代码
  • 检查计划
  • 复核修改方向
  • 评估权衡
  • 帮我把模糊需求变成更明确的实施步骤

它给我的感觉，更像一个有“收口意识”的人。

很多时候，一个工程任务真正的难点不是“写不出来”，而是：

会不会越写越散，越改越偏，越做越不像最初要解决的问题。

在这种时候，GPT-5.4 的价值就很高。

为什么我说 Claude Opus 4.6 更像发散者

与之相对，Claude Opus 4.6 在我这里更像那个真正干活的工程师。

它很适合：

  • 把一个 feature 真的铺开做完
  • 在复杂代码上下文里持续推进
  • 一边看已有实现一边补齐缺口
  • 在不完全确定的情况下继续往前试探
  • 把一个方案从骨架推进到“可以跑起来”

这种能力，我更愿意叫“发散”。

不是漫无目的地散，而是：

一旦目标有了，Claude 很擅长把可能路径都打开，然后快速进入实现状态。

这也是为什么我越来越不愿意让一个模型既当 planner 又当 implementer。
因为很多时候，这两种角色的心理模型其实是冲突的：

  • planner 要收边界
  • implementer 要开路径

让同一个模型同时扮演这两个角色，并不是不行，但很容易出现一种情况：

它既在想“要不要这样做”，又在想“那我先写了再说”，最后不是太保守，就是太放飞。

我为什么觉得这不只是模型对比，而是一种更大的协作方向

这件事真正让我兴奋的地方，不在于“我最近找到一套顺手玩法”，而在于它像是某种更大的趋势缩影。

也就是：

AI 协作的未来，很可能不是单模型通吃，而是多模型分工。

这不是我的臆想。
我觉得 Anthropic 和 OpenAI 最近的很多公开表达，其实都在往这个方向收敛。

Anthropic 给出的启发：别急着上框架，先理解原语

Anthropic 在《Building effective agents》里给了一个我非常认同的判断：

  • 最成功的 agent 实践，往往不是建立在复杂框架上
  • 而是建立在简单、可组合的模式上

他们还明确建议开发者先直接从 LLM API 出发，因为很多模式其实几行代码就能做出来；如果要用框架，也要先搞懂底层发生了什么。

我很认同这点。
因为一旦你真正开始搭 agent 系统，你会发现最重要的不是“框架有没有帮你包好”，而是：

  • prompt 到底怎么进来
  • tools 到底怎么注册
  • 状态怎么流动
  • subagent 怎么委派
  • memory 怎么注入
  • 结果怎么验证

也就是说，真正重要的是原语和结构，不是框架名词。

而这种思路也恰好能解释我为什么会开始用多模型分工：

当你不再执着于“一个模型包打天下”，你就会更自然地问：

哪一个模型更适合当前 phase？

OpenAI 给出的启发：核心不是神秘 agent，而是 harness

OpenAI 最近一系列关于 Codex 的文章，我也特别认同。

不管是《Unrolling the Codex agent loop》、
《Harness engineering》，
还是《Unlocking the Codex harness》，

它们都在把注意力从“神秘智能体”拉回到几个非常本质的东西：

  • loop
  • tools
  • session
  • thread
  • approvals
  • event stream
  • legibility
  • harness

换句话说，OpenAI 其实一直在说：

真正重要的不是一个抽象的 agent 神话，而是一套能把模型、工具、上下文、验证和客户端连接起来的工程系统。

而一旦你从 harness 视角看问题，多模型协作就会变得很自然。

因为这个时候，模型不再是唯一主角。
模型只是 harness 里的不同角色组件。

于是你会开始问：

  • 这一 phase 需要收束还是发散？
  • 这一阶段更需要规划还是实现？
  • 当前应该用 reviewer，还是 implementer？

也就是说：

先有结构，再有分工。

而不是先迷信某个最强模型。

我发现，很多人也开始这么做了

我去查了一圈，发现这并不是我一个人的怪癖。

一些社区和博客里，已经能看到越来越多类似做法：

  • 有人明确把 ChatGPT 和 Claude Code 分成“结构探索 / review”与“执行 / 编译”两个角色
  • 也有人公开分享用 GPT-5.4 + Claude Opus 4.6 + ChatGPT 5.4 做多 phase 工作流，把实现、审计、架构思考拆开
  • 甚至还有人在同一工作区里让多个模型分别承担 orchestration、code review、research 等任务

例如：

当然，这些社区经验不一定都能直接照搬。
但它们至少说明一件事：

越来越多人不再问“谁最强”，而是在问“谁更适合哪个角色”。

这正是我最近最有共鸣的地方。

这套协作为什么真的有效

我自己总结下来，主要有这几个原因。

1. 它减少了单模型偏差

只用一个模型时，很容易出现风格惯性：

  • 过度自信
  • 过度保守
  • 太爱继续扩张
  • 太早宣布完成
  • 总是沿着一种固定思路走

而两个模型分工以后，天然会形成一种交叉制衡。

2. 它把“审查”和“实现”拆开了

这是最关键的一点。

现实世界里，最差的情况往往不是代码写不出来，
而是写的人和审的人是同一个脑回路。

那样很容易漏掉自己的盲点。

一个负责推进，一个负责质疑，这种结构比“一个模型自己写自己夸”健康太多。

3. 它更像真实团队

真正有效的工程团队，本来就不是每个人都做同一件事。

  • 有人负责方向
  • 有人负责实现
  • 有人负责 review
  • 有人负责验证

所以我越来越觉得，多模型协作最有价值的地方，不是“多开几个窗口”，而是：

它终于开始逼近真实工程分工。

这对整个 agent 生态意味着什么

如果把这件事再往大一点看，我觉得它其实在挑战一个很流行但越来越站不住的想法：

未来只会属于一个最强的通用 agent。

我越来越不这么看。

我现在更相信的是：

  • 单模型能力当然重要
  • 但角色分工会越来越重要
  • harness 设计会越来越重要
  • context handoff 会越来越重要
  • 审查链和验证链会越来越重要

换句话说，未来真正强的，不一定是“某个模型本身”。
更可能是：

某种由多个模型、多个 phase、多个工具组成的协作系统。

所以这篇文章表面上是在谈 GPT-5.4 和 Claude Opus 4.6。
但我真正想说的其实是：

AI 开发的下一个竞争点，可能不是模型单点能力，而是模型之间的分工结构。

我现在的结论

如果今天有人问我：

“到底是 GPT 更强，还是 Claude 更强？”

我会觉得这个问题已经有点过时了。

我现在更想问的是：

你让谁来做 planner？谁来做 engineer？谁来做 reviewer？

在我的真实使用里，至少到目前为止，这个组合非常顺：

  • GPT-5.4 负责收束、规划、审查
  • Claude Opus 4.6 负责发散、展开、工程实现

它们不是在彼此替代，
而是在彼此成全。

所以我想用一句最简单的话，来给这段时间的体验做个总结：

单模型最强，不如多模型分工最优。

参考资料