用了两周 Codex 之后，我准备放弃每月 200 美元的 Claude Code 订阅
在我最初的对比文章发布两周后，两款工具都推出了重大更新。Codex 以 Claude Code 未曾做到的方式挑战了我的产品策略。Claude Code 推出了 Agent Teams 和 AutoMemory。结果是：我准备砍掉每月 200 美元的 Max 订阅——同时用更少的钱获得更好的产出。
两周前，我写了一篇关于同时使用 Codex 和 Claude Code 的文章。那篇文章引起的共鸣超出了我写过的任何内容——原来很多人都在做同样的实验。
当时，我的使用模型很清晰：Claude Code 负责执行质量和质量把控，Codex 负责架构推理和持续规划。两款工具，不同优势，重要工作用跨模型审查。
两周后，两款工具都推出了重大更新，平衡发生了变化。变化不算剧烈——但足以值得写一篇文章。（声明一下，这篇文章我是在 Claude Code 里起草的——不是出于忠诚，而是因为当前计费周期还没结束，我不想浪费已经花出去的钱。这种务实的计算恰恰就是这篇文章的重点。）
2026 年 3 月对两个平台来说都很紧张。Codex 推出了 plugins，集成了 Slack、Gmail、Linear、Figma、Sentry 等——还有用于自动化 GitHub 工作流的 Triggers、GPT-5.4 mini 和 nano 模型，以及 Windows 原生支持。Claude Code 推出了 Agent Teams（多智能体协同，仍处于实验阶段）、AutoMemory、Computer Use（仅限 macOS，Pro/Max 订阅）、通过 /loop 实现的定时任务，以及仅 3 月份就发布了大约 10 个版本。两个平台都在快速迭代。
Newsletter 的故事（为什么这不仅仅是关于代码的）
改变我想法的那个发现，跟写代码一点关系都没有。
我的网站有一套完整的 newsletter 系统——订阅表单、文章 CTA、欢迎邮件、每日定时任务、双重确认、13 种语言支持。从技术上说，一切都能正常运作。问题是：零个已验证的订阅者。
我草拟了一个解决方案：从课程中提取一个引流 PDF，将 Module 1 设置为邮件注册门槛，添加文章中部 CTA，让 AI 聊天机器人接入订阅流程，通过 YouTube 和 LinkedIn 进行分发。一共七个新功能。
我用 Claude Code 制定了这个计划。感觉很有成效。
然后我把同样的需求给了 Codex。它立刻开始质疑。
引流 PDF 是多余的——Module 1 已经是免费的了。同时做太多事——如果你一次性做七个，根本分不清哪个起了作用。问题不在于基础设施，而在于文案。"Stay in the loop" 太笼统了。验证邮件不够有说服力。兴趣选择增加了摩擦。
Codex 的方案：先修好现有的东西（重写文案、改进验证邮件、减少摩擦），只添加一个新触点（博客内嵌 CTA），用 GA 事件衡量效果，然后再考虑做其他的。
我的方案是"多做更多东西"。Codex 的方案是"先让现有的东西真正好用，然后测试一个新东西"。我的方案需要一周时间，而且无法知道哪个有效。Codex 的方案一天就能上线，并且能明确告诉你下一步该投入在哪里。
我必须承认——这让我措手不及。不是因为 Claude 不擅长策略。我觉得如果我更仔细地引导——"先挑战我的假设再执行"——可能也会得到类似的反驳。但默认的推理风格确实不一样。GPT-5.4 的默认模式是"质疑前提"。Claude 的默认模式是"把计划执行好"。
这个区别对产品决策很重要。
速度与引导
有两个我注意到的点，对日常工作流的影响超出预期。
速度和 token 效率： 在高思考模式下，Codex 搭配 GPT-5.4 在同等任务上始终比 Opus 4.6 更快。第三方对比显示 Codex 完成类似工作大约只用三分之一的 token——一项 benchmark 测量了一个 Figma 风格任务，Codex 用了 150 万 token，而 Claude 用了 620 万。Claude "出声思考"更多，这产生了更高质量的推理，但消耗限额也更快。大约从 3 月 20 日开始，Opus 的工具调用似乎比以前更多了——在得出答案之前有更多的中间步骤。我不确定这是模型变化还是巧合，但确实能感觉到。
实时引导： 当工具正在工作时我发送新消息——"等等，不是那个方向，试试这个"——Codex 几乎立刻就能读到并调整。Claude Code 倾向于完成当前执行后才读取修正指令。
这听起来是小事。其实不是。当你看着一个 agent 走向错误的方向，想要纠正航向时，"立刻读到你的修正"和"完成当前操作后才读到"之间的延迟，会在整个工作时段中不断累积。
SSE Bug：一个具体的例子
我当时在开发一个新的 iOS 应用。Claude Code 已经生成了 40 个 Swift 文件，涵盖所有功能——认证、agents、聊天、框架、仪表盘、个人资料。覆盖面令人印象深刻。但有一个关键 bug 始终无法解决：用于实时聊天的 SSE streaming 不工作。
后端是正常的。Curl 可以工作。但 Swift 客户端中的 URLSessionDataDelegate.didReceive(data:) 就是不触发。Claude Code 在这个问题上花了好几个小时。多种方法，多次调试。
我把同样的问题交给了 Codex。几次尝试后：commit 7f592152——"fix(ios): restore real-time chat streaming."
这有代表性吗？也许没有。每个工具都有好的时候和不好的时候。但根据我的经验，当 Claude Code 陷入调试循环——不断尝试同一种方法越来越巧妙的变体——切换到 Codex 往往能打破僵局，因为 GPT-5.4 从一开始就用不同的方式来理解问题。
Claude Code 仍然领先的地方
读到这里，很容易得出结论说 Codex 在全面领先。那是错误的。Claude Code 这个月也在努力发力，它的几项优势实际上还在增强。
Agent Teams。 这个功能在 2 月推出，3 月一直在成熟。多个 Claude Code 实例并行工作——一个探索器、一个代码审查器、一个实现器、一个测试运行器——带有依赖追踪和共享任务列表。它仍然是实验性的，默认关闭，但一旦启用，确实令人印象深刻。Codex 也有多 agent 支持（任务在隔离的云容器中运行），但 Claude Code 的 Agent Teams 感觉协调性更强。对于涉及大量文件的大型重构，Agent Teams 目前体验更好。
AutoMemory。 Claude Code 现在会根据你的习惯自动编写记忆规则。几次会话之后，它就知道你的项目结构、命名规范和偏好。这很细微，但累积效果是 Claude Code 的会话随时间变得越来越高效，而 Codex 的会话目前还做不到这一点。
前端设计。 带有 /frontend-design 插件的 Claude Code 产出的 UI 仍然明显比 Codex 同等能力的 skill 更精致、更符合设计系统。我在 3 月 26 日的一次网站改版中直接对比测试了这一点。Claude 的输出有更好的空间构图、更一致的样式和更连贯的效果。这可能是工具链优势（Claude 的插件系统用更多上下文来运行 skill），但实际效果是明显的。
代码质量。 一项基于 Reddit 500 多条开发者评论的社区分析发现，在盲测对比中约 67% 的情况下开发者更偏好 Claude Code 的输出——指出代码更干净、更符合惯用写法、结构更好。这跟我的体验一致。当代码需要可维护性而不仅仅是能跑通时，Claude Code 有优势。
自动 QA。 仍然是杀手级功能。完成工作后，Claude Code 会自动派出审查 agent——代码审查、一致性检查、缺口分析——无需我主动要求。Codex 还没有这个功能。对于正确性比速度更重要的工作，仅凭这一点就让 Claude Code 在工作流中不可或缺。
可靠性问题
我想分享一些大多数对比文章回避的内容。
以下是截至 2026 年 3 月下旬两个状态页面的 90 天正常运行时间数据：
| 服务 | Anthropic | OpenAI |
|---|---|---|
| 主平台 | claude.ai: 99.16% | ChatGPT: 99.91% |
| API | api.anthropic.com: 99.24% | APIs: 99.99% |
| 开发者工具 | Claude Code: 99.48% | — |
| 控制台 | platform.claude.com: 99.41% | — |
差距是真实存在的。在 90 天内，Anthropic 的服务大约经历了 OpenAI 的 8-10 倍的停机时间。3 月 25 日有一次具体事件——"Claude Opus 4.6 上的错误率上升"——调查-修复-再调查的循环持续了将近两个小时。
公平地说，这不是全貌。可靠性不仅仅是正常运行时间。BeyondTrust 的 Phantom Labs 公开披露了 Codex 的一个命令注入漏洞，该漏洞可能通过分支名称操纵暴露 GitHub 认证令牌。该缺陷影响了 web UI、CLI、SDK 和 IDE 集成——一个用户可控的分支名称被直接传递到 shell 命令中而未经过滤。OpenAI 已经修复，但这提醒我们稳定性和安全性是可靠性的不同维度，两者都很重要。
分享这些正常运行时间数据不是为了抨击 Anthropic。我每天都在用 Claude Code，它仍然很优秀。但对于任何将专业工作流建立在这些工具之上的人来说，这些数字值得了解。这也正是双工具并用不仅仅是"有也不错"的原因——当一个服务出问题时，你可以切换到另一个继续工作。两周内我已经这样做了三次。
插件差距正在缩小
在我最初的文章中，我提到 Claude Code 的插件生态系统更成熟。两周前是这样的。今天就不太对了。
Codex 在 3 月 27 日推出了插件系统，集成了 Slack、Gmail、Google Drive、Linear、Figma、Sentry、Notion 和 Hugging Face。还有 skills、hooks（包括 SessionStart 和 UserPromptSubmit 事件）、MCP servers，以及应用和 CLI 中的插件目录。
功能集正在趋同。两款工具现在都有：用于可复用工作流的 plugins/skills、用于事件驱动自动化的 hooks、MCP server 集成，以及与外部服务的应用级集成。
Claude Code 仍然领先的地方：现有的插件生态系统更深厚。像 Superpowers（结构化规划）、/feature-dev（引导式开发）和 /frontend-design 这样的插件已经打磨了好几个月。Codex 的插件目录更新，单个插件经过的实战检验也更少。
Codex 正在拉开差距的地方：Triggers。 Codex 可以自动响应 GitHub 事件——一个 issue 到来，Codex 自动修复，开一个 PR。这是一个全新的自动化类别，Claude Code 还没有提供。对于想要自主工程工作流的团队来说，Triggers 是一个重要的差异化优势。
我更新后的使用模型
两周前，我的工作大约按 60/40 分配给 Claude Code/Codex。我有一个清晰的心智模型：需要质量时用 Claude Code，需要架构推理时用 Codex。
这个整齐的划分已经消融了。我现在全天交替使用两者，更多凭感觉而非规则来切换。Codex 做一个任务，Claude Code 做下一个，有时候两个同时审查同一个方案。两款工具的能力已经足够接近，"这个任务该用哪个？"这个问题不像两周前那么重要了。
改变的是经济账。
OpenAI 的 Plus 计划每月 20 美元，限额越来越宽裕。我发现自己越来越多地使用 Codex——不是因为它在某件事上显著更好，而是因为速度、token 效率和 20 美元价格的组合消除了摩擦。不再有"这个任务值不值得消耗 Claude Code 的额度？"这样的心理盘算。
我倾向于把 Claude Code 的订阅从每月 200 美元的 Max 降级到 100 美元的计划，甚至可能降到 20 美元的 Pro 计划。两周前，这样做会让我觉得冒险。现在觉得很务实。我需要 Claude Code 表现出色的地方——前端设计、Agent Teams 编排、那种能抓住我会遗漏的问题的自动 QA——这些都是真实的优势。但如果 Codex 以 20 美元处理了我一半的工作量，可能不需要每月 200 美元。
我意识到这个选择有风险。20 美元的 Claude Code 档有真实的使用限制——如果在关键会话中撞到上限，我会后悔降级。而 OpenAI 宽裕的 20 美元限额很可能是抢占市场份额的策略，不一定会永远持续。但现在，经济账有利于双工具并用。
总成本（20 美元 Codex + 100 甚至 20 美元的 Claude Code）将低于我单独为 Claude Code 支付的费用。而且综合产出比任何价位上单用任何一款工具都更好。
这也许是两周双工具并用最实际的收获：竞争不仅让工具变得更好，还让它们变得更便宜。而更便宜意味着你可以两个都用。
我对接下来的预期
两个平台都在加速。Codex 刚刚推出了 plugins、triggers 和 Windows 客户端。Claude Code 刚刚推出了 Agent Teams、AutoMemory、Computer Use 和定时任务。谁都没有停下来。
Reddit 开发者社区中反复出现的一个主题——我觉得它捕捉到了一些真实的东西——是"Claude Code 质量更高但你会撞到限额。Codex 质量稍低一点但日常使用更顺畅。"随着两者的改进，平衡也在移动。
我的建议和第一篇文章一样，但现在更加坚定：花一周时间试试另一款工具。不是为了切换——是为了叠加。跨模型审查工作流仍然是我发现的最好的东西。而且，拥有两个你信任的工具所带来的运营韧性，会在其中一个宕机的那天拯救你。
作为用户，这是最好的局面。两款优秀的工具在快速进步，互相推动对方前进。竞争的节奏如此激烈，我不认为任何公司能长时间保持舒适的领先——这正是为什么押注单一工具感觉越来越冒险，而押注工作流（双工具并用、跨模型审查）感觉越来越正确。
常见问题
你的看法相比第一篇文章有变化吗？
核心论点——双工具并用胜过选择赢家——只变得更强了。变化的是比例（60/40 变成了 50/50）和原因。Codex 在战略推理方面的实力比它的编码改进更让我意外。
Codex 比 Claude Code 快吗？
在高思考模式下，是的——始终更快，而且第三方对比显示它在同等任务上大约只用三分之一的 token。在默认思考模式下，差距更小。对于需要频繁来回的迭代工作，速度和 token 效率的优势会累积起来。
我应该担心 Claude Code 的正常运行时间吗？
90 天的数据显示差距是真实的（99.2% vs 99.9%）。如果 Claude Code 是你唯一的工具而且你正面临截止日期，要有备选方案。但 Anthropic 仅在 3 月就发布了大约 10 个 Claude Code 版本——他们在功能迭代上很快，即使可靠性落后于 OpenAI。
Codex 的安全漏洞怎么回事？
Codex 的一个命令注入缺陷可能通过分支名称暴露 GitHub token。已被发现并修复。值得了解，但同样值得注意的是安全研究人员在积极测试这些工具——这对整个生态系统是好事。
Newsletter 策略的故事真的是关于工具的吗？
一定程度上是。不同的模型有不同的默认推理风格。GPT-5.4 更倾向于挑战我的假设。Claude 更倾向于帮我把计划执行好。两者都有用——但对于产品策略来说，"你在解决正确的问题吗？"往往比"这是一个好的实现方案"更有价值。
我应该买哪个工具？
两个都买。这不是推卸回答——真的是最好的答案。每月 20 美元的 Codex 加上 20-100 美元的 Claude Code，给你的结果比任何价位上单用任何一款工具都好。我倾向于把 Claude Code 从每月 200 美元降到 100 甚至 20 美元，然后加上 20 美元的 Codex。总成本下降，产出上升。不过，OpenAI 的宽裕限额可能不会持续——所以保持灵活。
就说到这里吧。如果你也在进行自己的双工具并用实验，我真的很想听听你的比例是怎么演变的。是相同的模式，还是完全不同的东西？
Cheers, Chandler
