最终，还是有很多人不知道如何正确使用 Codex 和 Claude Code 吧？
其实是你想复杂了，整理一下就会发现，它们并没有那么复杂。
你可能这两个都接触过。但你是不是处于这种状态？
- 听说过名字，但要你说出区别，你就卡壳了。
- 看过对比文章，但没记住什么，所以得不出结论。
- 无法判断哪个更适合你的工作，所以哪个都没真正用起来。
- 被上级或下属问到时，回答起来没底气。
这篇文章不是要评判哪个更好，而是要说明它们各自不同的用法。先给结论：一起用才是最现实的做法。
等你读完，你就能用自己的话解释 Codex 和 Claude Code 的区别，并判断如何将它们用于自己的任务中了。
就我个人而言，我把 Codex 作为主力工具，尤其是在研究和图像生成方面。我会从“把 Claude Code 作为辅助工具”的角度来写这篇文章。请允许我稍微偏向 Codex 一些。
为什么要现在整理？
“Codex vs Claude Code” 这个话题已经被讨论过很多次了。
即便如此，现在仍然值得重新整理一下。原因在于，在过去的两个月里，这两个工具都进化成了完全不同的东西。
导火索是 OpenAI 的一次重大战略转向。2026 年 3 月 24 日，OpenAI 暂停了其视频生成工具 Sora。原因是推理成本每天高达 1500 万美元，而 Sora 的总收入却只有 210 万美元。在“一个 10 秒视频成本 130 美元”的结构下，Fidji Simo 向员工解释说，他们“没有奢侈的资本继续做这些支线任务了”。
那么，由此释放出来的算力资源被用在哪里了呢？投向了 Codex。
两周后的 4 月 16 日，一场名为“Codex 几乎可以做所有事”的重大更新被宣布，一次性引入了 Computer Use、应用内浏览器、GitHub PR 审查、图像生成、记忆功能以及超过 90 个插件。同一天，Anthropic 发布了 Opus 4.7，使 Claude Code 能够在后台处理长时间任务。
换句话说，这两个工具几乎在同一时间，都摆脱了“仅仅是编码 AI”的外壳。如果你还只记得“聊天 vs. 异步”这种老旧的对比，就看不清现在的真实情况了。
这就是现在需要整理清楚的原因。这件事需要尽快理清。
过去一年发生了什么？
看看时间线，就能轻松理解其中的结构。
Claude Code 于 2025 年 2 月发布了其 CLI 预览版，在 AI 编码市场上取得了领先地位。Anthropic 以创纪录的速度突破了 10 亿美元的 ARR，目前规模已达 25 亿美元。Claude Code 的存在极大地推动了这一增长。
Codex 在 2025 年 4 月发布了其 CLI，晚了两个月。在大约一年的时间里，Claude Code 一直处于领先地位。这种情况在 2026 年 4 月的重大更新中发生了改变，Codex 开始了猛烈的追赶。他们将 Sora 释放出来的所有算力都投入了进去，将 GPT-5.5 设为默认模型，并公布了内部业务用例。
市场份额数据也相当惊人。根据 Menlo Ventures 的 2026 年数据，编码市场份额是 Anthropic 占 54%，OpenAI 占 21%。考虑到 Anthropic 六个月前还是 42%，他们是在一边扩大份额一边奔跑。在 Ramp 的 AI 指数中，73% 购买新 AI 工具的公司选择了 Anthropic，从 10 周前的五五开和 12 月初 OpenAI 六比四的领先优势，迅速发生了转变。
然而，在企业 LLM 总支出中，Anthropic 占 40%，OpenAI 占 27%，所以它们仍处于相互竞争的区间。最好不要简单地说这是一个“Anthropic 全面胜利”的故事。尽管 Claude Code 引领了编码市场，但 Codex 自 2026 年 4 月以来的扩张势头非常强劲。
最新信息显示，Codex 的使用率已经超过了 Claude Code，其势头不可阻挡……
这就是“先行者和认真的追赶者”的现状。
业务环境、驾驭方式与设计理念的差异
现在进入正题。Codex 和 Claude Code 从其核心设计理念开始就有所不同。
本质上，Codex 是 OpenAI 版的业务执行代理环境，而 Claude Code 是一个控制代理的开发/运维驾驭工具。
看看 Codex 这边就很容易理解了。
列举一下在 2026 年 4 月到 5 月添加的功能：一个能在登录状态下跨 Salesforce、LinkedIn 和 Gmail 工作的 Chrome 扩展程序；使用 /goal 的目标驱动循环；用于将代理嵌入公司应用的 App Server；用于财务、营销和数据科学等非开发任务的 GPT-5.5；以及超过 90 个连接到业务应用的插件。
看看 OpenAI Academy 官方发布的“Codex 十大顶级工作用例”：日常行政助理、周报、幻灯片、从研究到决策的备忘录、文件整理、电子表格集成、业务组合优先级排序、月度财务审查、产品发布活动工具包和工作流审计。超过一半是非开发任务。
简而言之，Codex 正在有意识地超越“编写代码的 AI”这个框架。OpenAI 自身也在将 Codex 从一个“用于思考的 ChatGPT”重新定位为一个“接管任务的合作伙伴”。
另一方面，Claude Code 正朝着不同的方向发展：Hooks、Permissions、Skills、Subagents、Agent Teams 和 Scheduled Tasks。
Hooks 允许在工具使用前后或停止时插入自定义处理，Permissions 则详细管理允许/询问/拒绝的设置。Anthropic 的官方描述仍然是一个“能够读取和编辑代码库、执行命令、并与开发工具集成的代理编码工具”，控制机制正是建立在此基础之上。
我认为这个设计差异至关重要。
很多人记得的是“聊天 vs. 异步”，但那是 2025 年的理解。2026 年的本质更接近于“提供业务环境 vs. 提供控制代理的驾驭工具”。
这不是炒作，只是分化已经发生了。在过去的六个月里，两者的轮廓都变得更加清晰。
从 7 个角度对比规格
理解设计理念后，技术规格就更容易看懂了。我把它们整理成七个维度。
1. 模型
Codex 默认使用 GPT-5.5，而 Claude Code 使用 Opus 4.7。Opus 4.7 于 2026 年 4 月 16 日发布，在 SWE-bench 上有显著改进，价格维持在 $5/$25/Mtok，与 4.6 版本相同。
然而，引入了一个新的分词器，这意味着同样的文本可能会被多分词高达 35%，这可能导致实际成本增加 0-35%。直接比较 GPT-5.5 和 Opus 4.7 的公开基准测试结果很零散；现实情况是它们非常接近。
2. 执行方式
Codex 主要使用云沙箱中的异步执行。Claude Code 则以本地交互式执行为中心。
但这一点在 2026 年 4 月 Claude Code 添加后台执行支持后变得模糊了。从功能上讲，两者现在都可以异步运行长时间任务。
但功能支持和实际质量是两回事。根据我的个人经验，Codex 在长期自主运行时保持质量的能力仍然更强（尽管它会消耗更多 token；即使在有 2 倍活动的 $200 套餐上，我也遇到过速率限制……）。
Codex 从一开始就是为了“在长时间内以既定设计自主完成任务”而构建的，包括设计层面的纠正建议和安全停止。虽然 Claude Code 有后台功能，但对于长期任务，稳定性的感觉仍然是 Codex 更高。
如果你构建好驾驭工具，Claude Code 也能很好地用于长期执行，但作为独立工具，对于固定设计的长期任务，Codex 更好；而如果你想在插入人工检查的同时推进，Claude Code 更合适。
3. 图像生成
Codex 可以在 CLI/App 中使用 gpt-image-2，因此代码和图像之间的流程不会中断。着陆页英雄图、文档图表、UI 模型和广告横幅都在同一个工作区中完成。
Claude Code 可以处理图像输入和 UI 审查，但图像生成不是其核心功能。Image-2 性能很高，这使得这一点成为了一个间接但强大的优势。
这是一个决定性的差异，也是我喜欢 Codex 的主要原因之一。“在我正在写的文本旁边立即创建图表”的操作，在 Codex 中要流畅得多。
顺便说一下，高级用户有时会采用组合方式：将 Claude Code 作为主要工具，但使用“codex exec”命令启动 Codex，并用 image-2 执行图像生成。
4. 插件与集成
Codex 有超过 90 个插件。它集成了像 Atlassian Rovo（用于 JIRA）、CircleCI、CodeRabbit、GitLab Issues、微软套件、Neon、Render 和 Superpowers 这样的业务应用。Claude Code 使用 MCP + Skills + Hooks 的组合，在开发方面集成度更高。
可以这样想：如果你想连接到业务应用，选 Codex；如果你想在开发流程中做精细插入，选 Claude Code。
5. 安全性
这是设计理念差异体现得最明显的地方。
Codex 使用 Seatbelt、Landlock、seccomp 和网络关闭，在操作系统内核层锁定安全性，以隔离代理运行的环境。方法虽粗放但可靠。
Claude Code 使用 26 个钩子事件在应用层进行控制。它提供开发者级别的精确性，比如“在调用这个工具之前插入这个确认”。
这是“控制 vs. 隔离”的区别。
6. CLI 成熟度
两者都有强大的 CLI。Codex CLI 0.129.0 于 2026 年 5 月 7 日发布，增加了 Vim composer、resume/fork 选择器、/ide、工作区感知的 /diff、状态行、插件管理和钩子浏览器。Claude Code 已经成熟了像 /loop、/schedule、/plan、/permissions、/skills 和 /agents 这样的斜杠命令。
Codex 在 CLI 上已经不再“落后”。两者都已进入会话管理工具的成熟阶段。
7. 长期自主性
我再重复一遍，因为这是一个至关重要的维度：自主运行长时间任务的实际质量仍然是 Codex 更胜一筹。
即使 Claude Code 有了后台支持，那种“长时间放着不管，然后发现它完全按设计完成”的感受，在 Codex 上仍然更可靠。
这不是一个规格参数，而是一种操作感受。不能仅凭规格来判断，这一点很危险。
虽然我做了很多对比，但它们每天都在互相追赶，很难说哪个是绝对的赢家。
补充一点：Codex 在基础功能上一直更出色，但 Claude Code 在工业化和商业应用的包装上曾经压倒性地好，并且不断主导着市场话题。
最近，Codex 已将重心转向商业应用，所以这个位置完全可能互换。
在商业实施中它们有何不同
现在谈谈对非工程人员来说最重要的部分。从 CEO 或业务负责人的角度来看，哪个更适合什么场景？
在 Codex 这边，OpenAI Academy 的“Codex 十大顶级工作用例”为高管们提供了一个实施路线图。
日常行政助理、周报、幻灯片、从研究到决策的备忘录、文件整理、电子表格集成、业务组合优先级排序、月度财务审查、产品发布活动工具包和工作流审计/自动化规格。
OpenAI 自己的内部例子很具体：财务团队比之前快了两周审查了 24,771 份 K-1 表格（共 71,637 页）。GTM 团队每周在周报上节省了 5-10 个小时。Codex 正在处理那些任何人都能发现价值的任务。
此外，借助 Codex for Chrome，您可以使用 Salesforce、LinkedIn、Gmail 和内部网络工具的登录状态，在浏览器中跨应用处理业务。这对高管来说意义重大。
Claude Code 则朝着略有不同的方向发展。2026 年 5 月 5 日，他们发布了针对推介书、KYC 和月度结账的“Claude for Financial Services agents”模板。它包含与 FactSet、S&P Capital IQ、MSCI、PitchBook 和 Morningstar 的集成。
然而，这不是“Claude 成为跨业务操作系统”，而是“在 Claude 的代理基础设施上构建的业务模板”。它更像是一种使用 CLAUDE.md、Skills 和 Hooks 来构建业务规则的风格。更接近于为每个行业和任务准备模板的方向。
简而言之，Codex 正作为一种跨业务操作系统推广开来，而 Claude Code 则作为业务模板提供者和开发/运维质量把关者推广开来。即使两者都“可用于业务”，它们也是从不同的角度切入的。
关于定价，Codex 是 ChatGPT Plus 每月 $20，Pro 版 $100（5 倍）或 $200（20 倍）以获得更高的并行执行能力。Claude Code 通过 Claude Pro/Max 使用，直接通过 API 使用 Opus 4.7 为 $5/$25/Mtok。两者的起价都是个人可以测试的水平。
我个人如何使用它们
现在是我个人的立场。我来回答这个问题：“那么，你实际是怎么用的？”
直到大约 4 月份，我还把 Claude Code 作为主要工具，但最近我换成了以 Codex 为主、Claude Code 为辅。遇到速率限制时，我就会切换到 Claude Code。
我使用 Codex 的场景：
- 研究。 我使用 /goal 设定一个目标，然后让 Codex 通过 Chrome 或应用内浏览器收集和整理网络信息。这个功能我离不开。
- 图像。 着陆页英雄图、文章图表、文档缩略图、UI 模型。在编写代码或文本的过程中，能够使用 gpt-image-2 生成这些图像，真的很强大。
- 跨业务工作流。 涉及 Salesforce 或 Gmail、更偏向非代码业务的任务。
- “我想固定设计然后长时间放置的任务。” Codex 的长期自主性仍然比 Claude Code 高出一截。
我使用 Claude Code 作为辅助的场景：
- 当实施过程需要修正方向时。 对于“不是这个，试试那个”这种交互式推进，Claude Code 感觉更顺手。
- 当阅读长代码库以形成设计方案时。 其深层上下文理解能力仍然很强。
- 当我想用 Hooks 和 Permissions 构建精细的质量检查点时。
- 像重构现有代码这类需要交互式逐个文件推进的任务。
按场景的决策轴如下所示：
如果任务是明确定义的、你想并行运行它、或者是跨业务的 → 选 Codex。
如果你想交互式地修正方向、阅读长代码库、或者构建精细的开发质量检查点 → 选 Claude Code。
我个人认为，两者结合使用是现实的。而不是“押注在一个上”，最终是“根据目的使用”能带来更好的结果。在 Reddit 上，有例子显示，使用 Claude Code 进行主要实现，使用 Codex 进行 PR 审查和后台任务。另一方面，很多人对花哨的多代理编排设置的可复现性持怀疑态度。
实际上，只用一个工具、小规模运行以获取结果，往往比花哨的设置更强大。即使同时使用两者，在明确各自目的后确定实施顺序也是最重要的。
在选择工具之前需要解决的问题
最后，我要谈谈一件极其重要的事情。
坦率地说，选择 Codex 还是 Claude Code 并不是 AI 应用的本质。
真正重要的，是你能否将工作分解为可验证的单元。
看看 Codex 的 AGENTS.md 和 Claude Code 的 CLAUDE.md 就清楚了。两者都被设计用来存放给代理的 README，你可以在其中写入仓库结构、命令、约定、约束和完成条件。如果你想将工作交给 AI，你必须记录业务规则。
那些 AGENTS.md 写得乱七八糟的团队，AI 每次都会做出不同的判断，导致质量不稳定。
如果你说“好好做”，AI 就会批量生产模糊不清的交付物。换一个更强的模型并不能解决这个问题。
正确的使用方式是这样的：目的、输入、输出、约束、验证。能把这五点写清楚的人才能在 AI 时代胜出。
例如，如果把周报交给 Codex：“目的：为管理层整理本周销售状况。输入：CRM 管道、Slack 销售更新、上周报告。输出：高管摘要、前 5 大风险、前 5 大机会、决策、下一步行动。约束：数字必须注明来源，区分推测与事实，对外共享时隐去客户名称，不清楚的地方写‘未知’。验证：确认与上周存在差异，重要风险已突出显示，下一步行动有负责人和截止日期。”
能否写出这么多内容，会使输出质量产生数量级上的差异。
Codex 和 Claude Code 是能够为具备这种能力的人提供巨大杠杆的工具。反之，对于那些不能定义目的、输入、输出、约束和验证的人来说，它们只会快速生产出大量混乱的结果。
AI 代理时代需要的不是擅长写提示词，而是将工作分解为可验证单元的能力。
说到底，我认为这才是本质。
总结
总结如下：
- Codex 是“业务执行代理环境”，Claude Code 是“控制驾驭工具”。这是目的上的差异，而非优劣之分。
- 两者在 2026 年 4 月至 5 月都迅速扩张。像“聊天 vs. 异步”这样的老旧对比已经无法反映现实情况。
- 功能支持 ≠ 实际质量。Claude Code 增加了后台支持，但长期自主性方面 Codex 仍然占优。
- 对于商业应用，Codex 作为跨业务操作系统切入，而 Claude Code 作为业务模板提供者和质量把关者切入。
- 我个人：Codex 为主（研究 + 图像 + 跨业务）+ Claude Code 为辅（方向修正 + 代码库阅读）。
- 两者一起用是现实的选择。而不是“押注一个”，关键是“根据目的使用”。
- 在 AI 时代制胜的关键是将工作分解为可验证单元的能力，而非提示词工程。
最终，整理好你自己的工作，比选择工具更重要。
Todai Codex Lab 会分享关于 Codex 的实用信息。
感谢您阅读至此，请关注并期待下一篇文章。
