Claude Code vs. Codex:终极指南

Claude Code vs. Codex:终极指南

翻译自:Claude Code vs. Codex: The Definitive Guide

我用了几个月 Claude Code,后来转投 Codex,最近又换回了 Claude。选它的原因跟 benchmark 跑分无关。我也拿同一个任务测试过两者。

本文内容:我会聊聊 Claude Code 和 Codex 的各个方面,驱动它们的旗舰模型 Opus 4.6 vs. GPT-5.3-Codex 有什么区别,哪些因素真正影响你的 AI 编程体验,以及一个小型案例——我是如何用这两个工具搭建同一个 RAG pipeline 的。

先说清楚,这篇文章大概需要 12 分钟阅读时间。如果你打算每个月花 200 美元订阅其中之一,这时间花得值。


💡 国内稳定访问 Claude/GPT5.4: weelinking -国内稳定访问 Claude/GPT5.4 Opus 4.6 vs. GPT-5.3-Codex:任务完成时间跨度

Codex 和 Claude Code 之间有一个可靠的对比维度:任务完成时间跨度(Completion Time Horizon),来自 METR(Model Evaluation and Threat Research) 的研究。

这个指标回答的问题是:这个模型能可靠地完成多长时间的任务? 任务完成时间跨度指的是模型以一定可靠性成功完成任务的时长(按人类专家完成时间衡量)。所以一个”2小时跨度 50%成功率”意味着:给你一个人类专家需要 2 小时的任务,AI 大约有五成把握能搞定。

这项研究为每个模型配置了合适的 scaffold,包括 Claude Code 和 Codex。所以虽然焦点在模型本身而非 scaffold,但我们也能借此了解这些 scaffold 有多可靠。它告诉我们这些编程 agent 能处理多难、多长的任务。

如图所示,Opus 4.6 和 GPT-5.3-Codex 之间差距很大。 根据 METR 2026年2月20日发布的数据,Opus 4.6 在 50% 成功率下的任务完成时长约为 14.5 小时(95%置信区间:6小时至98小时),而 GPT-5.3-Codex 约为 6.5 小时。这个差距在 80% 成功率时有所缩小。

METR 的研究还揭示了一个趋势:AI编程 agent 的能力大约每 4个月翻一倍,这个增速本身就值得关注。

这清楚地表明两个模型之间存在差距,进而也体现在 Claude Code 和 Codex 上——它们处理困难任务的能力有所不同。但这个差距不一定直接映射到你用它们做的事上,心里有点数就行。

参考:METR Time Horizons、METR: Measuring with Claude Code and Codex


Claude 比 Codex 快是出了名的。但跟编程 agent 打交道是长期过程。

如果一个 agent 完成任务只用了一半时间,但之后需要你花 10 分钟调试那破玩意儿,而另一个虽然多花了点时间实现,但完成后不用你盯着——那多出来的时间 100% 值得花。

这不是说 Claude Code 或 Codex 更容易犯错的——只是你自己评估这些 agent,或者听别人吹嘘它们的编程速度时,这句话值得记在心里。


Codex 和 Claude Code 的表现取决于你用它做什么任务。在 AI 工程任务中,可能一个表现更好;但在 Web 开发任务中,同一个模型可能被吊打。

哪个编程任务更适合 Codex 或 Claude Code?这个研究做得还不够。

比如说,低级编程(low-level programming)该用哪个就不清楚。理想情况下,你应该在简单可验证的环境中先测试两者,再决定 all in。但对大多数人来说,花 300-400 美元两个都买下来不太现实。

要全面对比两个 agent 在各种编程任务中的表现,是个有趣的研究方向。但也没那么轻松,因为这些 agent 和驱动它们的模型每隔几个月就会大幅变脸。


Claude Code:从副业到十亿美元产品

Claude Code 最初是 Anthropic 的 Boris Cherny(@bcherny)做的副业项目。他在 2024 年 9 月加入 Anthropic 后,用 Claude 3.6 做了个终端原型,能跟 Claude API 交互、读文件、跑 bash 命令。最初的原型甚至是连接 AppleScript 的——能告诉你当前在播什么音乐。真正转向编程工具方向,是他和创始 PM Cat Wu 讨论后决定的。

内部版本在 2024 年 11 月上线——第一天就有 20% 的工程师在用,到第五天有一半人开始用了。然后 Claude Code 在 2025 年 2 月 24 日以研究预览版发布,配合 Claude 3.7 Sonnet 一起上线。2025 年 5 月正式 GA(General Availability)。之后 Anthropic 也发布了 VS Code 扩展。

在 GA 后仅 6 个月(2025 年 11 月),Claude Code 就达到了 10 亿美元 ARR 的里程碑。

参考:Boris Cherny 原推(起源故事)、The Pragmatic Engineer: How Claude Code is built、Building Claude Code with Boris Cherny

Codex:从 GPT-3 微调到自我参与构建的模型

OpenAI 这边,最初的 Codex 模型(2021年8月)是 12B 参数的 GPT-3 微调版,基于 GitHub 代码,最终驱动了第一版 GitHub Copilot。但新的 Codex 是完全不同的产品。

2024 年秋天,OpenAI 将构建 aSWE(自主软件工程师)列为 2025 年的顶层目标(由 Greg Brockman 和 Sam Altman 推动)。Codex CLI 在 2025 年 4 月 16 日首发,以 Apache 2.0 协议开源发布在 GitHub 上,搭载 codex-mini-latest 模型(o4-mini 微调版)。2025 年 5 月 16 日,Codex in ChatGPT 以研究预览版上线(云端,使用 o3 微调版)。

2026 年 2 月 2 日,Codex macOS 桌面应用发布。三天后的 2026 年 2 月 5 日,GPT-5.3-Codex 发布——与 Claude Opus 4.6 几乎在同一天(相隔仅数分钟)上线。OpenAI 称其为”第一个参与创造自己的模型“——早期版本帮助调试了自己的训练过程、诊断评估结果、并协助运维任务。

参考:OpenAI: Introducing GPT-5.3-Codex、OpenAI: Introducing the Codex App、The Pragmatic Engineer: How Codex is built、GPT-5.3-Codex System Card (PDF)

两个深度访谈

Gergely Orosz(@GergelyOrosz,The Pragmatic Engineer 作者)做了两个很有意思的深度采访,分别关于 Claude Code 和 Codex 的开发者,涉及技术栈、开发方式、以及各自是怎么起步的。值得一看:

  • How Claude Code is built(2025年9月)— 采访 Boris Cherny(创始工程师)、Sid Bidasaria(第二号工程师,子Agent系统创建者)和 Cat Wu(创始PM)
  • How Codex is built(2026年2月)— 采访 Thibault Sottiaux(Codex负责人)和 Shao-Qian Mah(研究员)

一个惊人的数据:Claude Code 90% 的代码由 Claude Code 自己编写,测试代码更是接近 100%。工程师平均每天提交约 5 个 PR,Boris 本人在并行跑 5 个 Claude 实例时,每天能提交 20-30 个 PR。根据 Anthropic 的内部数据,在采用 Claude Code 后,工程师人均 PR 产出比去年增长了 67%——而同期 Anthropic 的工程团队规模翻了一倍。通常团队扩张时人均产出会下降,这个逆势增长相当说明问题。

有趣的是,Codex 这边也声称 90%+ 的代码由自己编写,周活跃开发者超过 100 万,自 2026 年 1 月以来使用量增长了 5 倍。

参考:Anthropic Research: How AI is Transforming Work at Anthropic


Claude CodeTypeScript 写的,用 React + Ink(React组件渲染CLI)+ Yoga(布局引擎)做终端 UI。打包成单个 Bun 可执行文件。Anthropic 在 2025 年 12 月 2 日收购了 Bun(这是 Anthropic 的首次收购,据报道估值在数亿美元级别)。收购的核心原因就是:Claude Code 以 Bun 可执行文件的形式分发,如果 Bun 出问题,Claude Code 就出问题。收购后 Bun 继续保持开源和 MIT 协议。Claude Code 使用的 Opus 和 Sonnet 模型都支持 100 万 token 的上下文窗口。

Codex CLIRust 写的,追求性能、正确性和可移植性。团队在 TypeScript、Go 和 Rust 之间做了评估,最终选择 Rust 是基于性能和工程文化的考量。终端 UI 使用 Ratatui 框架(前身为 tui-rs)+ Crossterm(终端事件处理)。代码库组织为 Cargo 工作区,包含 49 个成员 crate。OpenAI 甚至把 Ratatui 的维护者挖来了团队。

两个 CLI 工具都是围绕模型包了层薄薄的外壳,通过 API 调用。我注意到用 Claude Code CLI 时有些小”故障”,在 Codex 上不太明显——考虑到技术栈差异(TypeScript/Bun vs Rust),这也意料之中。不过这些故障也就是轻微烦人而已,真的不影响编程体验。

参考:Anthropic: Acquires Bun as Claude Code Reaches $1B Milestone、Bun Blog: Bun is joining Anthropic、GitHub: codex-rs README


最大的性能差异不是准确率,而是 Token 效率。Morph LLM 的 Opus vs Codex 全面评测 揭示了一个有趣的差距。

在相同任务上,Claude Code 比 Codex 多消耗 3.2–4.2 倍的 Token。 具体数据:

任务 Claude Code Codex 倍数 Figma 插件 620 万 Token 150 万 Token ~4.1x Job Scheduler 23.5 万 Token 7.3 万 Token ~3.2x

在 SWE-bench Pro 上,Claude Code(59%)略优于 Codex(56.8%),但代价是显著更高的 Token 消耗。GPT-5.3-Codex 被描述为”每任务 Token 消耗比 Opus 少 2-4 倍”。

如果这是真的,意味着你花同样的钱订阅 Claude Code,更容易撞到 Token 上限。这是一个不容忽视的隐性成本差异。

参考:Morph LLM: Codex vs Claude Code、Morph LLM: Best AI Model for Coding、Adaline Labs: Claude Code vs OpenAI Codex


Claude 像个帮你干活的高级工程师,Codex 像个承包商,你把任务丢给它,然后回来取结果。

这是开发者描述两者差异的普遍方式。

据报 Claude Code 有很强的交互感,还有深度推理能力——这跟 Opus 的定位相符。它会问你问题,展示推理过程,解释它的做法。虽然我那一次对比实验里没这种情况,但从用了好几个月的经验来看,我能确认这是真的。

Codex 以第一次尝试的准确率著称,代价是实现速度稍微慢一点。

话虽如此,如果你在 AGENTS.md 里具体说明你想要什么,两者行为的差异会大幅缩小。

什么是 AGENTS.md?

AGENTS.md 是一个开放约定文件(纯 Markdown),为 AI 编程 agent 提供指令——本质上是”给 agent 看的 README”。它补充了 README.md,包含 agent 特有的上下文:构建步骤、测试命令、编码规范、项目特定指引。

这个约定的历史:2025 年春天 Sourcegraph 提出了 AGENT.md,到 2025 年 6 月底,主流工具(Codex、OpenCode、Gemini CLI、Jules、Factory A)统一采用了复数形式的 AGENTS.md。2025 年 7 月 16 日,OpenAI 宣布与 Sourcegraph 和 Google 合作正式标准化这个约定,并拿下了 agents.md 域名。目前 OpenAI 自己的 Codex 仓库里就有 88 个 AGENTS.md 文件

如果你明确要求模型在开始干活前跟你确认实现计划,它就会照做——不管你用的是”高级工程师”agent 还是”承包商”agent。

这不是说两者真的没区别——区claude code 教程别是有的。只是没你在 X 上看到的那么夸张。

参考:AGENTS.md 官方网站、GitHub: agentsmd/agents.md、OpenAI Developer Docs: Custom instructions with AGENTS.md


指标 Claude Code Codex VS Code 安装量 ~520万+(评分 4.0/5,600+评论) ~490万+(评分 3.4/5,270+评论) GitHub Stars ~76.3K ~64.4K

注:VS Code 数据来自 Visual Studio Magazine 2026年2月报道,实际数字随时间增长中。作为对比,GitHub Copilot 的 VS Code 安装量约 7200 万,仍是绝对领先者。


Anthropic 的生态拉力强

选 Codex 还是 Claude Code 不只是编程问题。你订阅任何一个,等于订阅了整个 Anthropic/OpenAI 生态,这个因素值得考虑。

我个人觉得 Claude 正在变成一个像 Apple 那样火热的生态,现在有 Claude Cowork、Claude Chat 和 Claude Code 三驾马车。

Claude Cowork 于 2026 年 1 月以研究预览版发布,把 Claude 变成了一个”数字同事”——一个桌面应用(先 macOS,2 月扩展到 Windows),可以:

  • 直接访问本地文件(无需上传即可读写)
  • 协调子Agent处理复杂任务
  • 生成专业产出物(Excel、PowerPoint等)
  • 运行长时间任务,无对话超时限制
  • 在沙箱虚拟机中运行(macOS 上使用 Apple 的 VZVirtualMachine)

Cowork 包含在所有付费 Claude 计划中。最近(3月7日)还推出了本地定时任务——用自然语言创建重复任务计划(比如”每天早上7:30生成晨报”或”每周五下午4点生成客户周报”),无需 YAML 或 cron 语法。只要电脑醒着它们就会跑。

Anthropic 似乎也在用 Claude app 慢慢搭建一个更安全、更温顺的 OpenClaw(主动式个人 agent),零敲碎打的功能正在逐步推出。

OpenAI 这边,目前我没看到什么诱人的东西。除了 Codex,其他的都挺无聊。我没感觉到一个生态,只感觉是零散的碎片,而且外面有更好的替代品。

我已经在用 Claude Chat 而不是 ChatGPT 了。对我来说,跟 Opus 相比,ChatGPT 现在基本没法用。UI、聊天风格、模型选择,没有一个让我有动力用 ChatGPT。

所以呢,因为我已经在高频使用 Claude Chat,打算折腾 Cowork,目前没看到从 Claude Code 迁移到 Codex 有什么决定性的改进。换回 Claude Code、每月省下 200 美元,这决定做得相当轻松。

这成了影响我决定换回 Claude 的重大因素。

参考:Claude Cowork 产品页、Claude 帮助中心:在 Cowork 中创建定时任务

💡 国内稳定访问 Claude/GPT5.4: weelinking -国内稳定访问 Claude/GPT5.4


Claude Code 和 Codex 的价格基本一样,但有一个关键差异:

档位 Claude Code Codex(捆绑在 ChatGPT 中) 入门 Pro $20/月 Plus $20/月 中档 Max 5x $100/月 暂无(Pro Lite $100/月 已在代码中被发现,尚未正式推出) 重度用户 Max 20x $200/月 Pro $200/月 团队 Team $100/人/月(年付)或 $125/人/月(月付) Business $30/人/月

Claude Code 真正亮眼的是它有个 $100 的中档(Max 5x),而不是从 20 美元疯涨到 200 美元。Max 5x 提供 5 倍 Pro 限额、Opus 4.6 访问、100万上下文窗口和 Agent 团队功能。我相信这个档位对大多数开发者来说足够了。

所以可以说,Claude Code 实际上更便宜,因为它允许你选一个更便宜且够用的档,而不是逼你爬上价格阶梯。

Codex 这边,有一个 $8/月的 Go 入门档(轻量使用),但 $20 到 $200 之间没有正式的中间选项。有报道称 OpenAI 在应用代码中已出现 “Pro Lite” $100/月档位,但截至目前尚未正式上线。

参考:Claude 定价页、Claude Max 计划说明、ScreenApp: ChatGPT Pricing 2026、Codex Rate Card


技能(Skills)在 Claude Code 和 Codex 之间是兼容的,所以用哪个都感觉不出差别。但大多数技能中心和仓库都 Claude Code 命名,可能有点混淆。

其他大多数事情也这样。你在 Reddit、X 或博客上看到的关于编程 agent 的帖子,大多关于 Claude Code 而不是 Codex——尽管两者原理相同。这本身就说明了很多问题:受欢迎程度和社区规模。

Codex 比 Claude Code 晚很久才支持技能和插件。但插件没有技能那么兼容。而且 Codex 的插件支持刚起步,没多少可用。

也就是说,很多开发者,包括我,根本不用插件。所以除非你特别需要各种插件支持,这方面不用纠结,也别把它当作选择依据。


我选了一个可以量化评估的任务来对比。问题是做一个落地页这种任务没法量化:一个人可能觉得好看,另一个可能说是紫色渐变的垃圾。

所以我选了个简单的 RAG pipeline 任务,因为生成的答案可以用数字衡量准确性。

如果你想做类似的对比,其他好想法包括:训练 vision model 或微调 LLM,或者测量低级程序的性能。

任务定义

搭建检索 pipeline 是 AI 工程师的常见任务,你工作中可能用到 Claude Code 或 Codex。我让这两个编程 agent 给我搭一个论文问答 RAG pipeline。流程很简单:

  1. 取一批论文,提取文本
  2. 把内容分块(chunk)
  3. 把每块 embedding 到向量空间
  4. 用户提问时,找到跟问题 embedding 最接近的块
  5. 以原始形式检索出相关块(不是 embedding)
  6. 用这个上下文回答用户问题

这个任务足够简单,可以一次 session 做完,但细节很复杂,对输 影响很大:用哪种分块策略、选什么 embedding 模型、用什么向量存储、如何处理”哪个块更接近查询”的置信度、是否重写用户问题来帮助找到更相似的块……

实验设置

我从 HuggingFace 过去一周的每日论文里选了 5 篇,建了一个测试集(100 道题及标准答案),用来测试 Claude 或 Codex 的实现质量。

对两个 coding agent,我都是这么要求的:

  • 做一个 Python RAG pipeline
  • 用 PyMuPDF 处理所有 PDF
  • 为这个用例选一个好的分块策略
  • 创建 embedding 和持久化本地向量索引(你选)
  • 用 llama-3.1-8b-instant 生成最终答案
  • 如果没有足够证据,不要 hallucinate,返回 fallback

对 Codex 和 Claude Code,我都用了最流行且默认的模型:gpt-5.3-codex 和 Opus 4.6,都用 High effort(推理深度)。都没有 AGENTS.md。

它们怎么实现的 pipeline

我没注意到两个 agent 思考任务的方式有什么明显差别,除了 Codex 更啰嗦,会解释它的计划以及要做什么。Claude 直接写文件,执行命令,不说那么多。

Codex 完成任务比 Claude 花了更长时间。

更重要的是,Claude 端到端测试了脚本,确保 pipeline 能用。 Codex 则是做完了实现,但没有测试或运行程序,只是告诉我 依赖然后运行脚本。自然,我跑的时候报错了,Codex 解决了。Claude 的脚本跑起来一点问题没有。

我注意到 Codex 有这个模式:很多脏活累活它留给你做,而不是自己动手。Codex 会告诉你并主动处理环境问题或实现困难,Claude 则自行修复——这取决于你的偏好,可能是好事也可能是坏事。

我还注意到,Codex 在新会话中第一个 token 的响应时间可以高达一分钟,Claude Code 这边短得多。

Claude Code vs. Codex 实现对比

两个 coding agent 的方案惊人地相似:

  • 都选了 all-MiniLM-L6-v2 作为 embedding 模型
  • 都选了 k=5 做 Top-K 检索
  • 都在 system prompt 里限制 LLM 只准用提供的上下文

注:all-MiniLM-L6-v2 在 HuggingFace 上有超过 2 亿次下载,但在最近的基准测试中 Top-5 准确率只有约 56%——更新的模型如 e5-small 已经超过了它。两个 agent 都选了这个”经典但不是最优”的模型,这本身挺有意思。

但这些地方它们走了不同的路:

维度 Claude Code Codex 向量存储 ChromaDB(更适合生产环境,支持持久化) FAISS(更底层的相似度搜索库,更省内存更快) 分块策略 递归字符分割:先 ,然后 ,然后 ,然后 。目标 1000 字符,200 字符重叠。按结构分割(段落→行→句子→词),按字符计量 句子级别词分割:每块最多 220 词,40 词重叠。先按句子切,再打包进词预算的箱子里。尊重句子边界,不会在句子中间切断,但 220 词对学术文本可能太小 检索 Top-5 块,返回原始 L2 距离 Top-5 块,返回内积(cosine)分数 置信度 对最佳 L2 距离用单一阈值(>1.2 = 不相关),检查低/高置信度块的距离平均值 多标准三档:强、中等、不足 代码架构 扁平函数,各模块常量,无模型一致性输入验证 OOP pipeline 类,集中配置,dataclasses,argparse CLI,模型一致性验证。工程化程度明显更高

在代码架构上,Codex 明显工程化程度更高、可配置性更好。在更大更严肃的代码库里,这很关键。

结果

用 GPT-4 做 LLM-as-a-judge,两个 pipeline 的答案按四个标准比较:正确性、完整性、相关性、简洁性

100 道题中,Claude Code 赢了 42 道,Codex 赢了 33 道,25 道平手。

Claude 赢主要是因为它的置信度阈值更松,可能还有生成温度稍高(0.2 vs Codex 的 0.1)。

加点盐

这只是个非常简单的设置。我主要是好奇两个 coding agent 实现同一个封闭任务时有什么不同的做法。在专业环境里,是开发者拍板整体架构:分块方法、向量数据库、检索策略等。而且在专业环境里,做这类系统需要更多测试和迭代改进,以及更可靠的测试集和验证。

不过可以预期,一个不太有经验的初级开发者做 RAG pipeline,会把这些决策交给 AI。


我觉得选 Claude Code 还是 Codex,没有绝对错误的选择。两者都比现有格局的模型强,完成任务的水平差不多。

我的两大因素是:Anthropic 生态,以及 $100/月的价位段。即使我需要升到 200 美元/月档位,还是会为了前者留在 Anthropic 的 Claude Code。

最重要的是你用这些 scaffold 做什么,以及怎么用。

这个比任何 benchmark 都能更好地判断哪个更适合你——没有标准答案,只能凭感觉。你把两个都试过之后,哪个用起来更舒服,答案就在你心里。

有开发者坚决站 Codex,也有人相信 Opus 就是被 OpenAI 模型吊打。

我觉得两边都对,因为他们的工作流不同,对这些 coding agent 的”品味”也不同。

如果你犹豫不定,建议先试两个的 $20/月版本,用跟你相关的编程领域,最好在几个可验证的任务上测试。

最后,跟其他 AI 相关的东西一样,格局几个月就变一次。你现在喜欢哪个,三个月后 agent 行为可能漂移,或者新模型出来了。

AI 领域很少有全球通用的标准答案,这个话题也不是 😉

💡 国内稳定访问 Claude/GPT5.4: weelinking -国内稳定访问 Claude/GPT5.4


参考资料汇总:

  • METR Time Horizons
  • METR: Measuring with Claude Code and Codex
  • Morph LLM: Codex vs Claude Code
  • Adaline Labs: Claude Code vs OpenAI Codex
  • Boris Cherny 原推(起源故事)
  • The Pragmatic Engineer: How Claude Code is built
  • The Pragmatic Engineer: Building Claude Code with Boris Cherny
  • The Pragmatic Engineer: How Codex is built
  • Anthropic Research: How AI is Transforming Work at Anthropic
  • OpenAI: Introducing GPT-5.3-Codex
  • OpenAI: Introducing the Codex App
  • GPT-5.3-Codex System Card (PDF)
  • Anthropic: Acquires Bun
  • Bun Blog: Bun is joining Anthropic
  • GitHub: openai/codex
  • GitHub: anthropics/claude-code
  • AGENTS.md 官方网站
  • OpenAI Developer Docs: AGENTS.md
  • Claude 定价页
  • Claude Cowork 产品页
  • VS Code Marketplace 数据(Visual Studio Magazine)
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请联系我们举报,一经查实,本站将立刻删除。

发布者:Ai探索者,转载请注明出处:https://javaforall.net/273040.html原文链接:https://javaforall.net

(0)
上一篇 2026年3月12日 下午1:07
下一篇 2026年3月12日 下午1:07


相关推荐

关注全栈程序员社区公众号