Claude 运行快速。Codex 发布。

Source: Dev.to

请提供您希望翻译的完整文本内容，我会按照要求将其翻译成简体中文并保留原有的格式、Markdown 语法以及技术术语。谢谢！

摘要

我给 Claude 和 Codex 两个大型编码任务。

• Claude 大约在 一小时 内完成。
• Codex 大约用了 八小时。

乍一看，这似乎是 Claude 的一次彻底胜利，但结果却讲述了不同的故事。

实际发生的情况

Claude

• 快速、自信，但 毫无用处。
• 假设错误，代码损坏，缺少集成点。
• 只遵循了一半规则。
• 产生的结构会让代码库更难维护，即使我把它修补成可工作状态。

我把它丢掉了。

Codex

• 花了一整天的时间，但 阅读了仓库，遵循本地指令，并复用了已有模式。
• 添加了测试，运行检查，第一次运行 成功。

这改变了我对 AI 编码工具的看法。

Context

• 我并不是把这当作一次随意的周末测试。
• 在过去的四个月里，我发布了 三个产品，其中 AI 承担了大量的实现工作。
• 我在 每月 200 美元 的订阅套餐上已经用光了每周的使用额度。
• 这仍然是个人观点，而非基准测试，但它来源于在真实代码库中耗费的长时间——在代码出错时会浪费我的时间。

关键要点

1. Claude 优化运动。
2. Codex 优化落地工作。
3. 快速输出并不等于快速交付，如果你第二天还要花时间清理它的话。
4. Codex 的摩擦令人恼火，但大部分摩擦来自它 阅读、验证并遵守项目规则。
5. Superpowers 改进了两者，但每个代理的工作流遵循方式不同。
6. Claude 的子代理默认设置很有用，但当主代理愿意围绕你的代码库进行创新时，委派并 不能 为你省事。
7. 对于我实际交付的工作，我现在更信任 较慢的代理。

人格类比

Claude 陷阱

1. 进展出现得很快 – 它会编辑、假设、寻找穿过你的规则的路径、写下它认为应该存在的内容，并且可能积极使用子代理。
2. 第一次失败 通常很小（类型不匹配、缺少导入、不存在的组件 API、错误的 hook 模式）。
3. 你请求修复 → Claude 修补症状 → 其他东西出错。
4. 你询问原始问题为何失败 → 它往往不是追溯根本原因，而是跳到另一个补丁。

结果：代码库充斥着 临时补丁。你接受的越多，就越难分辨哪些是必要的，哪些是代理残留。这种脆弱性 并非来自单个错误提交，而是来自许多看似合理却从未证明与系统匹配的提交。

Source: …

为什么 Codex 感觉慢

• 即使是简单的工作，它也会先阅读：打开文件、检查指令、搜索已有模式，并尝试理解当前代码为何如此构造。
• 它远没有因为能做到就急于引入新抽象。

我的设置并不理想

• 那个八小时的运行并不是经过优化的 Codex 设置。
• 我几乎在安装后立刻测试了 Codex，只装了 Superpowers。
• 我还没有调优我的 AGENTS.md，也没有连接更强的代理工作流，或培养出在何时让 Codex 拆分任务的肌肉记忆。
• 大部分时间都是自找的设置摩擦。

实际消耗时间的原因

• Codex 在几乎每一次有意义的更改后都会进行测试——编辑、运行相关检查、读取失败信息、修补、再次运行，如此循环。
• 这比一个写出大幅差异并说“完成”的代理要慢，但正是因此最终结果能够正常工作。
• 我的 Codex 设置缺少默认子代理。Claude 往往更积极地将工作分散；没有明确的子代理指令，更多工作停留在主线程，导致运行时间延长。

耐心的价值

花费的时间并非浪费；它用于那些通常决定代码能否在首次接触仓库时存活的事项：

• 这是否与周围的模块匹配？
• 已经有针对它的辅助函数了吗？
• 是否有项目规则会覆盖显而易见的解决方案？
• 失败是 根本原因，还是仅仅是第一个可见症状？
• 什么是能够证明此更改有效的 最小检查？

我对编码代理的需求

I do not want an agent that wins the stopwatch and loses the branch. I want the branch.

Claude 的局限性

• Claude 只能基于模型知识工作，除非你明确让它去获取最新信息。
• 对于稳定的东西这没问题，但对于现代 SDK、AI 工具、产品文档、定价、CLI 行为、框架发布，或任何可能在上个月发生变化的内容，这就危险。
• 我不想要一个自信地基于六个月前的心理模型编写代码的代理。

Codex 的优势

• 更愿意说“这可能已经改变，请先搜索”。
• 已安装的 CLI 甚至提供了 --search，而当前的 Codex 文档有专门的规则和子代理页面。
• 功能表面变化快速，这正是重点：对于快速迭代的工具，搜索不是可选的润色——而是正确性。

That is one of the reasons Codex feels slow: it spends time making sure the premise is still true.

对 Claude 的最终抱怨

我最大的抱怨不是 Claude 笨——而是它 太强大。
问题在于它 过于乐于绕过约束。

• 如果仓库说明 “不要编辑 env 文件”，我不希望代理把 .env.example 当作足够接近的文档。
• 如果仓库说明 “除非被要求，否则不要添加脚本”，我不希望代理仅仅因为让自己的工作流更顺畅就添加便利脚本。
• 如果我问 “为什么这不起作用”，我不想在找到根本原因之前先尝试三次补丁。

Codex 的做法

• 速度较慢，部分原因是 规则在它的脑中占据了很大比重。
• 它把指令视为工作的一部分，而不是装饰。

这在真实的仓库中很重要，因为 正确性 胜过纯粹的速度。

超能力工作流

最快的修复往往是会破坏迁移、钩子、部署任务或其他工程师进行中的工作的修复。

我也在 Claude 和 Codex 中使用 Superpowers。

Superpowers 是 Jesse Vincent 开发的工作流插件。其核心理念很简单：不要让代理直接跳入编码。让它

1. 进行头脑风暴，
2. 制定计划，
3. 分配工作，
4. 在适当时使用测试驱动开发 (TDD)，
5. 审查结果，
6. 在宣称成功之前进行验证。

官方的 Claude 市场页面将其描述为用于头脑风暴、子代理开发、调试、TDD 和技能创作的 技能框架。GitHub 仓库也记录了 Codex 的安装方式，因此这并非仅限于 Claude 的想法。

Claude + 超能力

Claude 在使用 Superpowers 时表现相当不错。它能够理解工作流程，并且在计划确定后能够快速行动。

问题在于 Claude 仍然给人一种 在决定工作流程何时重要 的感觉。

• 有时它会调用正确的技能。
• 有时它把技能当作建议来看待。
• 有时它认为任务显而易见并直接开始行动。

Codex + Superpowers

Codex 的行为不同。如果规则说“使用 Superpowers 来路由”，Codex 更有可能真的这么做。它会

1. 调用路由步骤，
2. 检查适用的技能，和
3. 即使我个人认为任务本可以在两次编辑内完成，它仍会遵循工作流。

这种严格性是我的第一次 Codex 运行耗时如此之长的原因之一：Superpowers 需要路由和规划，而 Codex 把它当作规则，而不是建议。

这既好也坏。

• 对于 大任务，我希望有这种纪律性：先路由，先规划，工作独立时使用子‑agents，完成前先审查。这正是 Superpowers 发光发热的地方。
• 对于 小任务，可能会显得过度。如果我只需要微调文案或一行 bug 修复，我并不总是需要方法论。这与 Codex 本身的权衡相同：让它在大项目上可靠的纪律，在小项目上会感觉沉重。

不过，如果必须在失败模式中做选择，我几乎每次都会宁愿接受 “过程过多” 而不是 “快速错误代码”。

子代理

• Claude 更倾向于使用子代理。
• Codex 也可以使用子代理，但在我的工作流中，我通常需要明确请求或在 AGENTS.md 中编码。这与 Codex 子代理文档相符，文档将它们描述为大型任务的显式助手。在第一次运行时，我还没有进行调优，所以 Codex 承担了过多顺序执行的成本。

这对 Claude 来说是一个真正的优势：子代理可以隔离上下文、拆分工作，使大型任务更快推进。

但委派只有在被委派的工作是有界且有根基时才有帮助。

• 如果父代理做出错误假设，你会得到多个工作者并行实现这些错误假设。这不是杠杆，而是乘法。

• Codex 的默认设置更为保守。除非任务明显受益，否则它不会如此积极地分散工作。有时这会耗费时间；有时它能防止混乱。

我关心的指标

从提示到可发布分支需要多长时间？

• 不是 prompt → diff。
• 不是 prompt → “我已经做了更改。”。
• 不是 prompt → 一个自信的摘要。
• Prompt → 我可以直接发布的代码，而无需担心每一行都要审计以防代理造成的损害。

在该指标上，一小时的 Claude 运行比八小时的 Codex 运行慢，因为 Claude 的输出 没有可信路径——每一行都需要怀疑。而 Codex 的输出已经完成了乏味的工作：检查、编辑、测试、验证。

这就是我即使感到烦恼仍然继续使用 Codex 的原因。

我不需要最快的代理。
我需要的是我可以自信发布的输出。

最初发布于 harryy.me.