GPT-5.6在Claude Code中为何比Codex表现更好？深度解析

科技博主 Theo（t3.gg）近期发布了一段颇具争议的实测视频，得出一个连他自己都感到意外的结论：OpenAI 的 GPT-5.6 模型在 Anthropic 的 Claude Code 中运行，反而比在自家的 Codex 中表现更好。这个看似荒谬的组合，背后揭示了 AI 编程工具（harness）设计上的深层差异。本文基于该视频内容，深度解析 Codex 与 Claude Code 在系统提示词、子代理编排等核心机制上的关键区别。

一个反直觉的实验：把 GPT-5.6 放进 Claude Code

Theo 坦言，几个月前如果有人告诉他会做这样一期视频，他会觉得对方很奇怪。但随着他对 Codex 作为 CLI 工具的挫败感日益加深，他决定深入尝试在 Claude Code 中运行 GPT-5.6 模型——注意，这里不是让 Claude Code 去调用 Codex CLI，而是直接把 GPT-5.6 作为在 Claude Code 内部工作的核心模型。

结果彻底改变了他的看法。他强调，优势不仅仅在于 Claude Code 拥有更好的终端 UI（虽然确实如此），真正的收益来自 Claude Code 在底层机制上的不同设计：从子代理（subagents）的思路，到系统提示词，再到各种集成能力。

说个细节，Theo 特别澄清这并非针对 Pi、OpenCode 等其他工具的攻击。他将焦点集中在 Codex 与 Claude Code 上，是因为这一代新模型带来了全新的能力，而理解这些工具在做对什么、做错什么，对于最大化利用模型至关重要。

核心差异一：子代理编排机制对比

Codex 混乱的子代理系统

Theo 对 Codex 最大的不满在于其子代理机制。目前 Codex 存在两个版本：

• V1：稳定且简单，允许顶层代理派生一批深度只有一层的子代理，分配具体任务，完成后返回结果。
• V2：新的未完成版本，需手动启用。它默认复制整个上下文窗口（这一点令人恼火），并允许子代理向下派生自己命名的子代理，形成层级结构和消息传递。这把原本简单的层级搞得极其复杂，添加了大量通信所需的工具，结果相当混乱，显然仍在调优——这也是它默认关闭的原因。

Claude Code 的工作流（Workflows）

相比之下，Theo 盛赞 Claude Code 的工作流功能。它不是让子代理随机派生，而是由模型预先定义一个程序化的工作流：不同的阶段、不同的提示词、每个阶段配置不同的子代理，全部写在一个从上到下执行的 JavaScript 文件里。

由于工作流本质是代码，它们会真正结束。这一点在使用 GPT-5.6 时被证明是巨大的优势——GPT-5.6 系列模型往往会"一头扎进去"停不下来，而通过工作流执行，即便是相同任务，Ultra 模式可能无限运行，工作流却会终止。Theo 观察到，输出质量相同甚至更好，但 token 消耗仅为原来的四分之一，效率大幅提升。

关键区别在于：OpenAI 在 Codex 中直接内置代码，模型必须正确调用；而 Claude Code 让模型自己编写工作流和子代理的代码，Theo 认为这种方式整体上要好得多。

核心差异二：系统提示词质量天壤之别

Claude Code 的系统提示词：少即是多

Theo 做了一个有趣的实验：他让 GPT-5.6 分别在两个环境中生成网页设计，发现 Claude Code 中生成的页面质量明显更高，甚至"看起来像 Claude 自己做的"。

他起初假设 Claude Code 的系统提示词里一定藏着大量前端设计指导。于是他通读了整个 Claude Code 系统提示词——结果"front-end"这个词只出现了三次，且都不是实质性的设计指导，仅仅是让模型启动开发服务器、在浏览器中验证工作而已。系统提示词里几乎没有关于设计的内容。

Codex 系统提示词：过度规定的设计灾难

那么问题出在哪？Theo 转而检查了 Codex 的官方系统提示词，随即"崩溃"了。

他发现 Codex 的系统提示词里塞满了极其具体、僵化的前端设计规则，例如：

• 强制要求 SaaS、CRM 等工具"必须看起来安静、实用、以工作为中心"——这直接导致 Codex 生成的所有 SaaS 页面千篇一律。
• 规定卡片边框圆角必须是 8 像素或更小。
• 指定必须使用 Lucide 图标库。
• 反复六次提到"卡片"（card 出现 12 次），甚至"goblins（哥布林）"出现了两次——比 Claude Code 提到前端 UI 的次数还多。

更糟的是，这套提示词强制"禁止使用可见的说明性文字"、"不允许使用空状态（empty states）"——这解释了为什么 Codex 从来做不好空状态设计。而"每 30 秒提供用户更新"这条规则，则解释了为什么 Codex 总是执着地设置 30 秒定时器。

Theo 尖锐地指出：这套系统提示词一直在消耗用户成百上千万的 token，降低输出质量，浪费时间，而竟然需要一个 YouTuber 才把这些问题暴露出来。他表示正在从零手工编写一套全新的 Codex 系统提示词，并计划在成功后开源分享。

多模型交叉验证

为求客观，Theo 让 GPT-5.6（Claude Code 版）、Fable 5（Claude Code 版）以及 GPT-5.6（Codex 版）分别评价这套 Codex 系统提示词。结果 GPT-5.6 在 Claude Code 中给出评分：作为紧耦合 Codex 运行时的提示词打 7 分，作为通用编码代理提示词仅 4 分，作为面向现代模型的可移植提示词只有 3 分。即便是 Codex 环境中的 GPT-5.6 自己，也只给了这套提示词 4 分。模型指出，前端部分"过于规定化"，相当于一部独立的"前端设计宪法"，即便任务是 CLI、数据库或后端库，它也占据了约四分之一的篇幅。

实测中的小瑕疵

Theo 也坦诚指出了在 Claude Code 中运行 GPT-5.6 遇到的一些问题，不过比预期少：

• 偶尔跟丢任务：可能与上下文管理方式有关，但他认为多半是系统提示词中的小问题。
• 格式化问题：GPT-5.6 对 Claude Code 的 Markdown 格式（如编号列表、链接格式）处理得不太熟练，会出现编号重复等小错误。
• token 用量不实时：GPT-5.6 系列模型直到工作完成才报告 token 用量，而 Fable 会实时更新。

为了让 Claude Code 正确使用工作流并理解 "soul"、"terror" 等模型代号，需要在系统提示词或全局 agents.md 中做相应配置。

为什么不用 Pi、OpenCode 等其他工具？

针对可能的质疑，Theo 提前回应：这些工具虽然系统提示词可能没 Codex 那么糟糕，但它们没有解决他最看重的子代理编排问题。OpenCode 内置了一批硬编码的子代理，质量不高；Pi 虽然优秀，但需要用户自己构建所有的工作流和编排工具。

他的结论很明确：对于真实的日常工作，Claude Code 的工作流是他见过的编排子代理的最佳实现——能让代理把复杂工作拆分给不同模型的其他代理，分阶段轮流执行，启动重要任务、忽略无关任务，并有一个真正的终点。

结语：工具设计与模型本身同等重要

Theo 反复强调，他并不认为所有人都应该转而通过 Claude Code 使用 Codex 订阅。这只是一次结果远超预期的有趣实验。但这个实验揭示的核心洞见值得所有 AI 编程用户深思：在新一代模型时代，工具（harness）的设计——尤其是系统提示词的质量和子代理编排的机制——对最终效果的影响，可能不亚于模型本身。同一个模型，放在不同的工具里，产出质量和 token 效率可能天差地别。这提醒我们，在评估 AI 编程能力时，不能只看模型，更要审视承载模型的整套工程框架。