“你试过 Codex 搭配 GPT-5.5 了吗？我刚用 40 分钟重建了整个认证模块。上周用 Claude 做同样的事花了三个小时。”
我回复了一句"有意思"，然后继续做手头的事。我使用 Claude Code 已近一年，已经围绕它建立了整套工作流——CLAUDE.md 文件、Spec-Driven Development（规格驱动开发），以及我在 Medium 上发表的一系列 AI 文章中所描述的整个体系。它在运转，事情在推进。
但那条消息一直萦绕在我脑海中。
两天后，我在看一张 API 账单。那天早上我跑了一次重构——一个中等复杂度的 Express.js 模块，大约 400 行代码——花费了 140 到 155 美元。我知道 Claude Code 不便宜，我已经把这当作质量的代价接受了。但仅仅一次重构，就让我停下来算了一下我一直在花多少钱。
那就是我决定做这个实验的时刻。
三十天。以 GPT-5.5 通过 Codex 作为我的主要工具。所有我通常在 Claude Code 中做的事情，我都会在 Codex 中完成。同样的任务、同样的工作流、同样的纪律。不为任何一方挑选容易的胜利。
我的发现比预期更复杂，也更有价值。
0、我放弃了什么（以及为什么这很重要）
我想坦诚地说说我一开始的偏见。
我用 Claude Code 构建了真正的东西。这不仅仅是熟悉度，而是一套真正的工作流。那个 CLAUDE.md 文件编码了我项目的架构约束、命名约定，以及我在 SDD 文章中写过的严重性层级。一种规格驱动的方法——在生成任何代码之前规格就已经存在。把 Agent 当作一个有纪律的执行者而非魔法盒子的习惯。
那套体系运行良好。我的生产环境调试会话显著缩短了。上下文漂移——Agent 在长会话中丢失原始意图的失败模式——变得可控了，因为我在主动地工程化上下文，而不是寄希望于它自然存活。
我喜欢 Claude Code。我大量地写过它。我对它有明确的看法。这一切都不让我成为一个中立的评估者。我一开始就知道这一点，我也希望你了解这一点。我在此报告的一切都应在这一背景下阅读。
1、第一周：让我停下来的那些事
第一个意外是成本。
同样的 Express.js 重构，在 Claude Code 中花费 140-155 美元，在 Codex 中只需 12-15 美元。不是 130。不是 100。是十二到十五美元。
我跑了三遍，确保自己没有搞错什么。每次运行的输出各不相同（如你所预期），但成本始终在 10-15 美元的范围内。
这个数字需要诚实的追问，而我诚实的回答有两个部分。
第一：对于那个具体任务，Codex 的输出是好的。快速、整洁、逻辑清晰。单独来看，我会对它满意。
第二：盲审代码评审员——在一项比较两个工具完成相同任务的研究中——67% 的情况下更偏好 Claude Code 的输出，而对 Codex 的偏好只有 25%。所以你大约多付了 10 倍的价格，换取的是独立评审员认为更干净的两三成的输出。
单独看任何一个数字都无法告诉你该怎么做。但它们放在一起，描述的是这场对比核心处真实的张力。第一周我就坐在这张力之中，而不是急于过早地解决它。
第二件让我停下来的事，是我开始称之为"向前失败"的模式。
第四天，我给 Codex 一个我很熟悉的任务：修复一个我一直在开发的 REST API 中的并发 bug。那是一个微妙的问题，session 处理层中的竞态条件。我已经识别出了问题所在。我想看看这个工具如何处理修复。
Codex 以十足的信心生成了回复。它识别了问题，提出了解决方案，并实现了它。代码编译通过了。测试通过了。看起来搞定了。
但它重写了一个不需要重写的模块——一个与 bug 相邻的、干净且正常工作的模块，显然是因为模型将其识别为相关模块，并决定"既然来了就顺便改进一下"。这次重写引入了一个我的测试没有覆盖到的新边界情况。
两天后我才发现了这个问题。花了四十分钟调试。一个本应更快的任务，却创造了我没有预算的后续工作。
这就是我所说的"向前失败"。输出看起来已完成。信心是真实的。错误是微妙且无声的，而这种组合正是我在这系列文章中写了八个月的特定失败模式——一个返回 200 状态码但实际上是错误的 Agent。
Claude Code 用这种方式让我栽跟头的频率更低。不是从来没有，但频率更低。它展示推理过程、标记不确定性、在修改相邻文件之前先询问的习惯，不止一次地捕获了恰好这类错误。那种透明性是一种内置的可观察性，我已经开始视为理所当然。
2、框架揭示了什么？
大约在第二周，我停止了按评审员评估工具的方式来评估这些工具——按任务完成度和速度——而是开始按我思考生产系统的方式来评估它们。
我提出的问题不同了。不是"它完成任务了吗？"而是"在长会话中上下文发生了什么？"不是"多快？"而是"当它出错时，失败的可见性如何？"不是"它能产出好的代码吗？“而是"它能跨多个步骤保持原始意图吗？”
关于上下文管理：Claude Code 胜出，而且不是因为某个单一功能。而是组合的力量。在会话开始时注入的 CLAUDE.md 文件。将规则限定到适用文件目录级指令。在生成任何新内容之前先读取项目现有模式的习惯。
Codex 的方法——紧致的默认值、强自主行为、针对开箱即用体验的优化——为简单任务产生了更好的首次运行结果。但在一个大型代码库中持续三小时的会话里，上下文退化得比我预期的更快。到第二个小时，它已经开始做出与我在第一个小时建立的约束相矛盾的决定。
这并不完全是个意外。它证实了我之前写过的一点：没有架构的上下文只是对话。Codex 的默认值非常出色。但它们不能替代结构化的规格说明。
关于意图保持：我给了两个工具相同的复杂多步骤任务——重构一个涉及六个文件的模块，并对完成后的接口有具体的约束。
使用 Claude Code 时，到第五步约束仍然有效。使用 Codex 时，到第四步它就开始做出看起来合理但超出我所定义范围的决策。不是大错特错，而是以累积的方式微妙地出错。
这一模式与研究结果吻合。Claude Opus 4.7 在多文件重构任务上表现尤为出色，正是因为模型倾向于在整个操作过程中保持其目标的完整上下文，而不仅仅关注当前步骤。
关于可观察性：这是两个工具之间哲学差异最为明显的地方。Claude Code 的设计理念是可读性。它展示推理过程。它标记不确定性。它在做有风险的事情之前会先询问。Codex 的设计理念是自主性。它做得更多，问得更少，行动更快。
两种设计理念都是自洽的。它们产生了真正不同的工作体验。而对于一个生产系统工程师来说——一个思维模型被数月思考"Agent 静默失败时会怎样"所塑造的人——可读性不是锦上添花，而是风险管理工具。
3、决定胜负的三个任务
抽象的比较很容易被忽视。以下是三个产生了最清晰信号的具体任务。
任务 1：范围明确、需求清晰的功能
提示词：为三个 API 端点添加限流。具体需求、无歧义、范围有限。
Codex 更快。输出干净。成本只是 Claude Code 收费的一小部分。如果我在团队中运行这个任务一百次，经济性将是决定性的。
对于这类任务——定义明确、范围有限、架构风险低——Codex 是更好的工具。我对此不做保留。它更快、更便宜，输出质量足够好，不值得为 Claude Code 支付溢价。
任务 2：具有架构影响的复杂重构
提示词：重构认证模块以支持 OAuth，在现有的邮箱/密码认证之外。代码库中没有现有的 OAuth 实现可供参考。
这就是情况发生变化的地方。Codex 行动迅速，产出了看起来完整的代码。Claude Code 更慢一些，问了我两个我没有预料到的澄清问题，产出的方案更保守，但在需要正确的部分也更正确。
那些澄清问题说明了问题。其中一个标记了一个我没有考虑到的 token 刷新边界情况。在 Codex 的输出中找到那个边界情况的修复方案，会比 Claude Code 花在询问上的时间多得多。
任务 3：规格驱动测试
这是没有其他人在做的测试，它产生了我觉得最有趣的结果。
我给了两个工具一份正式的 SPEC.md——我在本系列第一篇文章中描述的完整六元素规格格式。目标、约束、已做出的决策、验收标准。完整的文档。
它们之间的质量差距显著缩小了。
拥有正式规格的 Codex 产出了比没有规格的 Codex 显著更好的输出。拥有规格的 Claude Code 如我预期地运行——可靠地、强约束遵守地运行。
这揭示了什么：我之前归因于"Claude Code 更好"的很大一部分，实际上是"良好规格的任务产出更好的输出"。规格说明承担了我一直归功于工具的工作。
这可能是这次 30 天实验教给我的最重要的事情。
4、我现在实际使用什么？
我没有赢家。我有一个路由决策。
以下是我现在的看法：
在以下情况选择 Codex：任务范围明确、需求无歧义、错误架构决策的风险低，且成本重要时。快速的功能开发、范围有限的修复、验收标准明确的紧密定义任务。这大约覆盖了 60% 的日常工作。
在以下情况选择 Claude Code：任务涉及多个文件、架构影响不明确、微妙错误决策的代价高，或者工作需要接近手术精度般地完成时。复杂的重构、任何需要先理解整个系统再动手的工作，以及任何失败模式是"它能工作但在你不会立即注意到的方面是错误的"场景。
在以下情况同时使用两者：你需要第二意见。我信任的几位工程师已经达成的模式是：Claude Code 用于规划和架构差异对比，Codex 用于范围紧密的后续任务。两者提交到同一分支。你审查合并后的 PR。输出是互补而非竞争的。
我现在每次会话前使用的三问路由框架：
任务是否范围明确且有显式验收标准？→ Codex。任务是否需要在接触任何东西之前理解整个系统？→ Claude Code。我是否在运行一个需要跨长会话持久化上下文的规格驱动工作流？→ Claude Code，同时用 Codex 处理其中的有界子任务。
5、我没预料到会学到的东西
我预期从这个实验中得到一个结论。一个赢家。一个能干净利落地告诉你用什么的东西。我得到的却是更深层的澄清。
这两个工具之间的质量差异——它是真实存在的，我也尽力诚实描述了——小于使用任何一个工具时有适当工程纪律和没有工程纪律之间的质量差异。
我花了 30 天比较 Claude Code 和 Codex。我学到的最有用的事情是，工具的重要性比我假设的要低，而规格说明的重要性比我意识到的要高。
两个工具，在给定适当规格的情况下，都比任何一个工具在没有规格的情况下产生了显著更好的输出。在 Agent 开始执行之前就定义成功的架构师，将从任何一个工具中获得比输入提示然后寄希望的工程师更多的价值。
如果你在期待一个简单的答案，这不是一个令人舒适的结论。但我觉得这是一个诚实的结论。
AI 编码工具的格局变化很快。Claude 的下一次发布可能会改变计算。GPT-5.5 将被更快更便宜的东西取代。我今天告诉你的一切在六个月后会部分过时。
什么不会出错？是在构建之前先定义规格的纪律，主动管理上下文的纪律，从第一天起就建立可观察性的纪律。这种纪律是工具无关的。它让你在使用任何一个工具时都更加出色。
我想，这也是我关于 Agentic AI 及其正确使用的整个系列一直在探讨的核心。
原文链接：Codex vs. Claude Code：我的发现 - 汇智网
