Codex vs Claude Code 一周真实使用对比

Benchmark 分数已经无法帮你抉择 Codex 和 Claude Code 了。在 SWE-bench Verified 上，两者实际上打成平手，第三方对比报告两者约为 88.6% 对 88.7%。如果你要在 2026 年选一个日常主力工具，决定因素不在这儿：在真实代码库上干了一周之后才会浮现的那些习惯、失败模式，以及代码哲学。

这正是本周登上 Hacker News 的内容。Lucian Ghinda 是一位 Ruby 和 Rails 开发者，他发表了《快速印象：一周内使用 Codex 多于 Claude》，帖子收集了超过 200 个赞同和 200 条评论，开发者们纷纷感慨同样的摩擦点。Ghinda 让两个工具配置完全一致——相同的插件、相同的技能——然后留意它们在哪里出现分歧。

声明：我在自己的 Spring Boot 服务上没有做过为期一周的对照比较。我每天都用 AI 编程工具，也跑自己的 agent 基础设施，但下面这些一周正面交锋的观察来自 Ghinda，来自他的 Rails 代码库。我能做的是将它们与已发布的基准测试和定价进行核实，并翻译成对 Java 团队意味着什么，因为他的几项发现几乎完美映射到我每周在企业 Java 代码库中看到的那些问题。

以下是真正有影响的差异，按你实际体验到的方式分组。

1. 代码哲学：一个过度构建，一个构建不足

Claude Code 往往会构建得比你要求的更多。Ghinda 的观察，来自让两个 agent 用同一份文档实现同一个需求：Claude "通常会继续创建很多东西：抽象、Sorbet 签名、类型别名，等等。" Codex "稍微更克制，创建的东西更少。" Claude 的代码更复杂，但它也确实处理了更多边界情况。

在 Rails 代码库里，这表现为 Sorbet 签名和类型别名。在 Java 代码库里，可以想象同一个 agent 为了交付一个接口而加上策略模式、一个工厂、两个新接口和一个配置类。Java 本身就是一个过度抽象是慢性病的生态，所以一个本能地添加层次的 agent 就是在放大你已有的问题。Ghinda 还注意到 Codex 在变更的代码中写了更少的注释，他很喜欢这一点。我认识的大多数资深评审都会同意这点。

但这种权衡是真实存在的。Ghinda 小心翼翼地指出 Claude 额外的复杂性"处理了一些情况"。构建不足的失败方式则不同：happy path 能工作，边界情况则以凌晨 2 点的告警回来。没有哪种倾向是免费的。问题是你现有的评审流程更容易 catches 哪种失败模式。在大多数 Java 团队里，评审时删除不必要的抽象比在生产环境中发现一个漏掉的边界情况更容易，所以这悄悄地偏向更克制的方案。但你得真的去做评审。

2. 速度不等于更快完成

Codex 感觉更快，但总时间没有变化。Ghinda 写道，Codex "给我的感觉是比 Claude 更快地完成变更。但主要变更完成后，要完成这个 PR 还需要很多工作：反复运行测试、评审等等。我喜欢这种严谨，但最终在时间差异上没有赢家。"

这是整篇文章中最被低估的发现，因为它直接否定了人们切换工具的首要理由。初始 diff 比对方快 30% 到达是一记多巴胺冲击，不是交付指标。瓶颈转移到了验证阶段：重新运行测试套件、评审 diff，以及修复 agent 高速干活时搞坏的东西。

这对团队有预算层面的教训。一份第三方成本对比报告称，对于同类任务，Codex CLI 消耗的 token 大约是 Claude Code 的四分之一到二分之一，这是它实际使用成本更低的主要原因。如果你的团队在烧 API 额度，这个差距会持续放大。如果你用的是固定订阅，token 效率为你的是限流上限以内的喘息空间——如果你在下午频繁触达上限，这就很重要了。

3. 失败模式：各自在哪里伤到你

Codex 的 git 处理可能严重出错。Ghinda 最糟糕的时刻："Codex 做了一些糟糕的事，比如分支 A 指向分支 B，分支 B 又指向 main，当我让它 rebase 时，它用 main 做了 rebase，产生了一个有 4000+ 行增量的 PR。我不得不明确告诉它只 rebase 目标分支。" 而按他的说法，Claude 理解了他的意图，会在不被告知的情况下分支并保持工作同步。

一个 4000 行的 PR 不是四舍五入的误差，是一下午的考古工作。如果你用堆叠分支或堆叠 PR，这个单一失败模式就超过了所有速度优势。缓解方法对两个工具都一样：把分支拓扑规则写到 repo 配置文件里，永远不要只说"rebase"而不明确说出目标分支名。

工具集成是不对称的。通过 CLI 操作 Jira 时，Ghinda 发现 Codex 让他在浏览器登录提示和 CLI 之间来回跳转。Claude "更愿意尝试理解我想要什么，并根据之前的会话用我想要的方式去做。" 但在 MCP 认证方面，他更偏好 Codex："我更喜欢 Codex CLI 的方式，它让我执行 codex mcp login，每次都会打开正确的认证和授权流程。Claude 有时会在一个回合中自动运行它，然后卡住。"

把这两点放在一起看，一个模式就浮现了：Claude 会在障碍前即兴发挥，这有时能帮你解围，有时会把会话卡死。Codex 走铺好的路，这在铺好的路通往你技术栈需要去的地方之前是可预测的。

4. 行为背后的架构分化

两个工具在不同层面实施安全策略。一份详细的架构对比描述了这个分化：Codex 在内核层强制安全策略，macOS 上是 Seatbelt，Linux 上是 Landlock 和 seccomp，所以操作系统本身在模型的动作执行之前就拒绝文件系统、网络和进程操作。Claude Code 通过可编程的钩子事件在应用层强制安全策略，大约 26 个钩子，对运行时什么能运行有细粒度控制。

没有哪个是绝对更安全的。内核级沙箱更难被模型钻空子，这就是为什么人们把不受信任的代码交给 Codex 审阅。应用层钩子更具可编程性，这就是为什么团队直接把自定义治理、保存时格式化、合规检查构建到 Claude Code 会话里。如果你的组织有一个有主见的安全团队，这个区别比任何基准测试都更能决定选择。

配置文件悄然成为标准战场。Codex 读取 AGENTS.md，这是一个跨 vendor 的约定，Cursor 和 Zed 也已采用。Claude Code 读取 CLAUDE.md，这是 Anthropic 专有的。如果你计划在同一个 repo 上运行多个 agent——2026 年大多数团队都是如此——维护一份跨 vendor 的 AGENTS.md 胜过维护两份会逐渐漂移的并行指令文件。现在有多份对比指南推荐以 AGENTS.md 作为单一上下文来源，并让 Claude Code 指向它。

截至本月的上下文和定价：

入门价格：两者实际上都以 $20/月起步，Codex 通过 ChatGPT Plus，Claude Code 通过 Claude Pro。据报道 ChatGPT Business 降至每席位 $20-25，含 SSO 和 Codex 访问。

速率限制：OpenAI 发布精确数字，Plus 在当前编码模型上每 5 小时窗口获得 15-90 条消息（据 OpenAI Codex 文档）。Anthropic 只声明 Claude Code 与 Claude app 共享限制，不发布具体数字。如果你要精确预算，这种不对称很重要。

上下文：Claude Code 在 Opus 上以标准定价暴露 1M token；Codex 在当前 GPT-5.x 系列上默认 272K，在长上下文模式下可推至约 1.05M。

5. 没有人基准测试的人的因素

熟悉度是一种性能特性。Ghinda 最诚实的承认：在调试紧急问题时，他还是会打开 Claude。"我不是说他更好，但它是熟悉的，在调试时，使用我熟悉的工具很重要。" 在压力下，你会伸手去拿你了解的的那个工具，而这个伸手不是非理性的。你对一个工具失败模式的了解本身就是你调试速度的一部分。

他还发现自己随着 Codex 改变了会话形态："我想开更多 Codex 会话，让它们各自保持专注，而不是像之前那样开一个大号的 Claude 会话。" 不管这是工具的属性还是工具的风格引导你走向的方向，许多开发者会识别出这种模式——一个越来越混乱的大号 Claude 会话，其实应该拆成四个小会话。

而且沟通风格确实不同。Ghinda 的描述是我读过对这两个产品最好的一行总结：Claude "感觉更像你在 Tuple 会话中的同事给你写代码，而 Codex 感觉更像《星际迷航》里的 Data。" Codex 的输出更技术、更简短。有些人把它读作清晰，有些人把它读作摩擦。不管你承认与否，它影响你一周下来的耐力。

如果我要给今天在选的 Java 团队提建议

Ghinda 自己的总结画出了哲学分界线："Claude 尝试超越你要求的范围，猜测你可能想要什么，然后直接去做，而 Codex 更像是一个同伴，做你告诉它的事，但不会过度发挥。它会在出现可能完成的第一个迹象时停下来。"

翻译成团队决策：

如果你代码库受过度抽象困扰，想要更少的 token 成本，需要内核级沙箱来审查不受信任的代码，或者你的团队已经为 ChatGPT 席位付费因此边际成本为零，选 Codex。它公布的速率限制也让预算规划更理性。

如果你做大型多文件重构，其中推理深度能赢——参见 2026 年 7 月第三方 SWE-bench Pro 对比，Opus 69.2% 对 Codex 58.6%——如果你工作流依赖深度 IDE 和钩子定制，或者你的团队已经生活在 Anthropic 生态中，选 Claude Code。

如果你能承受，两个都用。如果你在 AGENTS.md 上标准化，它们读同一个 repo 配置，它们的优势几乎不重叠，用一个来审查另一个的输出能 catches 到相当比例的 bug。跨模型审查技巧很便宜，而且有效。

如果我要说我在看过团队采用两者后会做得不一样的事：在让任何一个 agent 接触共享 repo 之前，把你的分支拓扑规则和评审清单写到 AGENTS.md 里。Ghinda 的 4000 行 rebase 事故之所以发生，是因为指令活在他脑子里，不是在 repo 里。Agent 遵循写下来的规则远比推断意图更可靠。

你在自己的代码库上并排跑过 Codex 和 Claude Code 吗？哪个先出问题，如果只能买一个你会留哪个？每条评论我都看。

我每周写 Java、Spring Boot 和 AI。订阅免费。

来源：Ghinda 的 Codex 与 Claude 一周体验、Hacker News 讨论、Codex 与 Claude Code 架构对比、Codex CLI 与 Claude Code 成本和限制，以及含基准测试数字的迁移指南。基准测试和定价数字为第三方报道，变动频繁；承诺预算前请核实当前文档。