胜负已分：Claude Code 对决 Codex，最强 AI 编程之争终于落幕
AAI LABS
Computing/SoftwareSmall Business/StartupsInternet Technology
Transcript
00:00:00长期以来，大家在编写代码时的首选模型一直是 Claude。
00:00:03不仅是因为它表现出色，还因为当时同层级中没有其他选择。
00:00:07随后 GPT 模型发力并缩小了差距，特别是 GPT 5.5 的发布，
00:00:12几乎消除了这种差距。
00:00:14为了比较两者，我们需要将它们放在最适合它们的设计环境中，
00:00:18也就是它们各自的命令行界面（CLI）。
00:00:19因此，我们将对 Opus 4.7 和 GPT 5.5 进行测试，看看它们彼此的
00:00:25表现如何。
00:00:26我们将通过 9 个类别进行测试，找出究竟谁能胜出，
00:00:29到最后，你就会知道哪一个值得在你的工作流中占有一席之地。
00:00:33易用性是 Claude Code 开始让我们失望的地方。
00:00:36我们一直使用它处理大部分任务，包括编码和非编码任务，但在
00:00:402.1.0 版本更新之前，它一直表现良好。
00:00:43在那之后，Claude Code 的情况就开始走下坡路了。
00:00:46用户界面是最令人沮丧的部分，因为它对体验的影响最大。
00:00:50终端卡顿、渲染损坏，很多以前觉得精致的地方现在感觉
00:00:55都不太对劲。
00:00:56它曾是最出色的 TUI 之一，但直到它开始被过度修饰。
00:00:59它现在感觉更破碎了，存在渲染问题、缓存泄漏等多个 bug，
00:01:03不只是我们在抱怨这些问题。
00:01:05更大的问题是，他们删除了“危险跳过权限”模式，并将其替换为
00:01:09默认的自动模式。
00:01:11我们过去在大多数任务中都会运行绕过权限模式，并为不希望
00:01:15Claude 触碰的文件设置钩子。
00:01:17现在即使在这种模式下它也会询问权限，当我们给 Claude 发送创建技能的指令，
00:01:22并切换到另一个 Claude 会话做别的事情时，后来才发现技能创建
00:01:27一直被写入 .claude 文件夹的权限提示阻塞着。
00:01:32我们回来时本以为技能已经创建好了，结果它只是坐在那儿等待。
00:01:36Codex 处理得更好，因为它的 YOLO 模式不像
00:01:40Claude Code 的自动模式那样询问任何权限。
00:01:42由于 CLI 是基于 Rust 构建的，UI 比 Claude Code 的 React 架构更流畅，
00:01:47即使经过长时间的会话，也不会出现任何崩溃。
00:01:49人格配置是 Codex 领先的另一个方面。
00:01:53我们可以将人格设置为更直接、更简洁的语言。
00:01:56这是因为 GPT 5.5 比 Opus 4.7 表现出更明显的阿谀奉承，
00:02:02在每个提示语中都表现得更顺从。
00:02:04这就是为什么在 Codex 中更改人格可以防止模型出现那种默认行为。
00:02:08要让 Opus 4.7 变得直接，我们必须依靠 Claude.md 中的指令，而 Codex
00:02:14只需更改设置即可实现。
00:02:16预装技能是另一个区别。
00:02:18Codex 附带了许多 Claude Code 没有的技能，包括智能代理浏览器技能。
00:02:22这对任何构建应用的人来说都很重要，因为在 Codex 中，我们不需要为了
00:02:26浏览器验证而显式连接 MCP。
00:02:29它在实现任何功能后都会自动完成。
00:02:31它还内置了技能创建器，所以当我们想要一个新技能时，它会生成一个
00:02:35具有正确结构和参考文件的完整技能。
00:02:38在 Claude 中，我们需要单独安装技能创建器才能获得结构合理的
00:02:42技能。
00:02:43否则，它只会写一个 MD 文件。
00:02:45不过，仍有两件事是 Claude Code 做得更好的。
00:02:47Codex 不提供撤回功能，这是我们最常用的功能，所以没有它
00:02:51确实是一个缺点。
00:02:52Claude Code 还可以让我们通过 Ctrl+O 展开来查看它的思考过程，而 Codex
00:02:57在这方面做得不好。
00:02:58查看推理过程很有帮助，因为我们可以在任务中途纠正方法，而不是
00:03:02等实现完成后再推倒重来。
00:03:05考虑到 Claude Code 的用户体验随着每次更新而退化，Codex 在
00:03:10易用性方面得一分。
00:03:11在成本方面，Claude Code 是昂贵得多的工具。
00:03:15不是指实际价格，而是指同等价格下的可用性。
00:03:19Claude Code 完全不提供免费层级，只能从
00:03:23Pro 和 Max 计划开始使用。
00:03:24这些计划的定价几乎完全相同。
00:03:26Pro 计划对于任何具有一定规模的应用来说基本上是不可用的，因为它在
00:03:30处理几个任务后就会达到限制。
00:03:32在 Pro 计划上，我们甚至无法正常使用 Opus 4.7 处理任何有意义的任务。
00:03:36即使是在我们使用的 Max 计划中，额度也会很快耗尽。
00:03:39Codex 从一开始就处于更有利的地位。
00:03:41它甚至在免费计划中也提供，只是使用受限。
00:03:44两者都使用类似的 5 小时窗口机制，所以为了看谁能完成更多工作，
00:03:49我们在相同规模的任务上运行了它们。
00:03:51Claude Code 已经有一个上下文命令，可以直观地显示会话使用了多少 token，
00:03:56但 Codex 没有内置类似的命令，所以我们必须找一个折中方案进行比较。
00:04:00两个工具都将它们的会话存储为 JSON 文件，只是组织方式不同。
00:04:04因此，我们构建了一个小工具来读取它们，并计算每个会话中使用的 token 数量。
00:04:08在同一个应用和类似级别的调试下，Opus 4.7 消耗了 173,000 个 token，而
00:04:15GPT 5.5 仅使用了 82,000 个。
00:04:18这是因为 GPT 5.5 能以更少的 token 和更少的重试次数完成工作。
00:04:23因此，Codex 的持续时间明显更长，并且在同等工作量下被证明成本效益更高。
00:04:28但在继续之前，让我们听听赞助商 Stream 的介绍。
00:04:32你正在构建一个应用，你的用户需要交流、直播和连接。
00:04:35如果你尝试自己处理，3 个月后，你可能还在调试而不是交付。
00:04:39Stream 帮你跳过了这一切。
00:04:40Stream 为你提供开箱即用的一切，从应用内聊天、视频通话到活动
00:04:44提要和 AI 审核，让你专注于交付功能，而不是从头构建基础设施。
00:04:49我们说的是内置的 WhatsApp 式消息传递、Zoom 式视频通话和 Instagram 式提要。
00:04:55真正脱颖而出的是 Stream 的新品发布：Vision Agents。
00:04:58你可以构建智能 AI 代理，让它们在实时视频和音频中进行视觉、听觉和操作，
00:05:02只需几行 Python 代码即可实现。
00:05:05一切都在全球边缘网络上运行，确保各地都有低延迟。
00:05:08从初创公司到规模化应用，社交、健身和社区领域的领先平台都
00:05:13依靠 Stream 为超过 10 亿终端用户提供动力。
00:05:16如果你是正在构建下一个大应用的开发者，Stream 从第一天起就伴随你成长。
00:05:20在 getstream.io 免费开始，链接见置顶评论。
00:05:24对这两个模型真正的测试在于它们如何构建产品。
00:05:27正如我们之前所说，GPT 5.5 更快且消耗更少的 token，因此它交付运行应用的速度更快。
00:05:33Opus 4.7 在思考上花费了更多 token，计划更深入，并同时对应用的各个
00:05:38方面进行迭代。
00:05:40规划是我们第一个想要测试的项目。
00:05:42我们已经使用 Claude Code 的规划模式很长时间了。
00:05:45它涵盖了大部分内容，虽然有些缺陷，但仍然相当可用。
00:05:48所以我们想看看 GPT 5.5 在规划方面的表现，因为 OpenAI 声称它在
00:05:53规划任务和执行方面表现更好。
00:05:55我们启用了计划模式，并在一个已经包含应用后端的文件夹中打开了它，
00:06:00这是一个使用 FastAPI 构建的 API，并要求它为其构建前端。
00:06:04它彻底探索了项目并提了几个问题，但这些问题都相当
00:06:08简单。
00:06:09它本可以更深入地了解我们希望前端呈现的样子，因为对于前端
00:06:13工作来说，这很重要。
00:06:14它制定的计划非常简单。
00:06:16其中包括主要流程摘要、关键更改、要添加的页面以及如何测试
00:06:20它们。
00:06:21它做得很好的一点是清晰地分离了它的假设，所以我们准确地知道它
00:06:25认为什么是理所当然的。
00:06:26我们告诉它继续执行，它在大约 8 分钟内完成了任务。
00:06:28同样的任务在 Claude Code 上花费了 24 分钟。
00:06:31但 Opus 4.7 的计划要深入得多，考虑了应用的更多方面，
00:06:36甚至引入了 shadcn/ui 来提升用户体验。
00:06:39所以 Opus 4.7 在规划方面表现更好。
00:06:42接下来，我们想在全新的应用上测试两者。
00:06:45我们给了它们相同的提示，即创建一个带有 Python Flask 后端和
00:06:50Next.js 前端的 mono repo，以及完整的流程和应用运行的关键要求。
00:06:55由于其架构设计，它自动切换到了规划模式。
00:06:56Codex 没有切换到规划模式，而是直接开始实施。
00:06:59它完成得比 Claude Code 快得多，后者因为规划
00:07:04步骤大约花费了 16 分钟。
00:07:08GPT 5.5 版本的应用 UI 要简单得多，主要专注于确保应用
00:07:09能跑通。
00:07:14它起初运行不正常，所以我们进行了迭代调试。
00:07:15我们注意到的一点是，面试提示语是硬编码的，因为我们没有提供
00:07:17任何 API 密钥。
00:07:22提示语指定使用 Gemini API 作为后端，但由于没有可用的密钥，
00:07:23它实现了一个后备方案，使应用不至于完全崩溃。
00:07:27Codex 实际上在没有任何明确提示的情况下使用了本地追问。
00:07:30我们喜欢这一点，因为像这样的后备机制在生产环境中很有用，因为它们可以防止
00:07:35崩溃。
00:07:39经过几次迭代并添加了 API 密钥后，尽管
00:07:40UI 仍然很简单，但应用的流程运行正常。
00:07:44所以 GPT 5.5 考虑到了边缘情况，并实现了填补空白的机制。
00:07:46另一方面，Opus 4.7 在开始实施之前要求我们提供
00:07:51API 密钥，并围绕该密钥构建了整个应用。
00:07:57因此，与 GPT 5.5 不同，Opus 4.7 没有准备后备方案，只是需要所有东西
00:07:59预先到位。
00:08:05正因如此，当 API 实际不存在时，应用没有后备方案，直接报错。
00:08:06Claude Code 确实同时关注用户体验和功能性，所以它的实现
00:08:10看起来更真实。
00:08:15这就是 Opus 4.7 的 UI 优势所在，我们在之前的视频中
00:08:16提到过 Opus 4.7 在处理 UI 方面要好得多，但它的实现也存在问题。
00:08:21当我们要求它调试时，它并没有像 Codex 那样直接检查实现过程。
00:08:26相反，它开始询问我们可能导致问题的原因，并依赖
00:08:31我们的测试。
00:08:35它添加了调试点，比如 UI 中的指示器和控制台日志，并要求我们检查状态
00:08:36并反馈。
00:08:41经过一番来回，它最终解决了问题，面试功能正常运行。
00:08:42我们更喜欢 Codex 使用智能代理浏览器自行调试的方式。
00:08:46所以在自主工作方面，Codex 的实现更好；而在
00:08:49用户体验方面，Claude Code 做得好得多。
00:08:53我们还想测试两者如何处理 init 命令。
00:08:56Claude Code 的 init 在运行时不会内联展开提示语。
00:08:59它创建了一个简单的 Claude.md 文件，大约 90 行，包含架构、应用流程、
00:09:02前后端结构以及运行应用所需的所有命令。
00:09:08其中很多信息是冗余的，并不能真正让智能代理受益，这就是
00:09:12为什么没有必要保留所有这些内容的原因。
00:09:15Codex 的设置更加精细。
00:09:18它正确地包含了提交指南、拉取请求指南和安全指令，
00:09:20同时保持项目结构部分简洁，而不是充斥着过多的细节。
00:09:24两者都不完美，但 Codex 处理 agents.md 更好一些。
00:09:28现在我们还想测试两者在代码审查方面的表现。
00:09:32我们向 Codex 和 Claude Code 发送了相同的可靠性审查提示，要求它们
00:09:35在同一代码库上工作时，将审查结果记录在单独的文件中。
00:09:40两份报告生成后，我们开启了一个新会话，并要求 Claude 输出
00:09:44两个文件之间的差异，比较审查结果。
00:09:48Claude 的审查要详细得多。
00:09:51它按优先级组织了每一项发现，并包含了组件以及问题背后的
00:09:53确切代码片段。
00:09:57Codex 的报告提到了行号，但没有包含实际的代码片段。
00:09:59两份报告都很透彻，共享了几个发现，同时也各自捕捉到了对方
00:10:03遗漏的一些问题。
00:10:07Claude Code 还报告了安全问题，比如泄露的 API 密钥和漏洞。
00:10:08但由于任务是可靠性审查，那些问题超出了范围。
00:10:12Claude Code 报告了沿途遇到的每一个额外问题，而 Codex 则严格
00:10:17专注于可靠性。
00:10:21因此，Codex 的报告更符合最初的要求，而 Claude Code 的报告虽然更广泛
00:10:22但对特定任务的关注度较低。
00:10:27如果要用构建的角度来描述两者，GPT 5.5 感觉更像是一个后端工程师，
00:10:29专注于首先正确交付应用的功能；而 Opus 4.7 感觉
00:10:34更像是一个全栈工程师，试图平衡功能和用户体验。
00:10:40在上下文管理方面，Codex 的表现比 Claude Code 好得多。
00:10:45Claude Code 具有会话内上下文编辑功能，可以移除对话中
00:10:48不再重要的工具调用和推理步骤。
00:10:53它会清除会话中的冗余信息以避免臃肿。
00:10:55压缩并不完美，但至少它在压缩过程中
00:10:58不会在上下文中保留不必要的部分。
00:11:02Codex 不会编辑它们的上下文。
00:11:03它只是按原样压缩整个对话过程。
00:11:05它做得更好的一点是在内存中保留最后的 20,000 个 token，并且完全不
00:11:08压缩该部分。
00:11:13这有助于防止 Codex 在压缩后出现性能下降，从而使对话
00:11:14可以从下一个提示语开始顺畅流动。
00:11:18我们测试了它的性能，Codex 在压缩后的表现优于 Claude Code。
00:11:21我们测试了它们的性能，Codex 在压缩后的表现优于 Claude Code。
00:11:25因此，尽管 Claude Code 遵循更详细的多步压缩过程，但 Codex 保留的
00:11:30尾部数据让代理在实际应用中更有用。
00:11:33两者的记忆机制运作方式不同。
00:11:35Claude Code 的架构在会话之间大多是无状态的，这意味着每个会话开始时
00:11:39没有任何来自前一个会话的上下文。
00:11:41它现在具备了记忆功能，可以存储持久的偏好或指令。
00:11:46所以如果我们告诉它避免以某种方式做某事，它会存储下来并在以后
00:11:50同一个项目中再次应用。
00:11:52这在单个项目中重复工作时很有帮助。
00:11:54但记忆是项目范围内的，所以切换项目会丢失这些存储的行为。
00:11:58Codex 则采取了相反的路线。
00:12:00它会随着时间的推移巩固多次会话的信息，并构建跨交互的全局记忆，
00:12:05这样它可以保留超出单个项目的模式。
00:12:08这有助于不同任务之间的一致性。
00:12:11简而言之，Claude Code 将记忆更多地限制在项目内，而 Codex 采取了
00:12:15更具跨会话、跨项目的方法，这改变了它们各自随时间
00:12:19适应的方式。
00:12:20由于 Claude Code 存在时间较长，并且为了提升开发人员体验而不断开发，
00:12:24与 Codex 相比，它能提供的东西更多。
00:12:27Claude Code 拥有钩子（hook）系统，让我们可以运行自己的脚本
00:12:32在代理生命周期的特定点，比如工具运行前或运行后，以及其他点，用于
00:12:36拦截不安全命令、运行格式化程序等操作。
00:12:39我们还可以在专用的工作树中运行子代理，这样它们的性能就不会
00:12:43互相影响。
00:12:44我们可以控制模型的努力程度，甚至可以使用像 "ultra-think" 这样的关键词
00:12:48来在特定任务上将推理推向极限。
00:12:51目前 Codex 中没有与之对应的功能。
00:12:54生态系统是 Claude Code 另一个明显的胜点。
00:12:56我们可以通过 Claude 桌面应用运行会话，并从移动应用委派任务。
00:13:01涵盖 Claude Code、桌面应用、网页应用和浏览器扩展，其覆盖面比
00:13:06Codex 广泛得多，后者主要由网页应用和最近才发布的
00:13:11桌面应用组成，且在我们测试时感觉还不够强。
00:13:14会话在 Claude Code 的不同环境间迁移也更容易，这使得
00:13:18跨不同界面工作更加方便。
00:13:20Codex 也有许多有趣的功能。
00:13:22在云端，它有一个尝试标志（attempt flag），可以将同一个任务运行 n 次。
00:13:26它生成几种实现方式并选择最好的一种。
00:13:29Claude Code 也可以做类似的事情，但只能通过配置和指令，而
00:13:33不是作为一个标志。
00:13:34另一个 Codex 独有的功能，也是让它脱颖而出的地方，是它与
00:13:38OpenAI 图像模型的集成。
00:13:39它可以直接在命令行界面（CLI）中使用它们，为正在开发的项目生成图像。
00:13:44Claude 主要依赖基于 SVG 的生成来处理视觉效果，这在质量上
00:13:49甚至无法竞争，因为它目前还没有任何图像模型。
00:13:52如果我们要构建一个需要真实图像的 UI，Codex 是两者中唯一能做到的，
00:13:56甚至不需要显式告知。
00:13:58另外，如果你喜欢我们的内容，请考虑点击点赞按钮，因为这能帮助我们
00:14:03创作更多类似的内容并触及更多观众。
00:14:06两者都使用子代理，尽管这个概念是由 Claude 首先引入的。
00:14:10既然它首先出现在 Claude Code 中，其集成度就更成熟，因为它一直以代理为中心，
00:14:15并且比 OpenAI 更早地专注于编码体验。
00:14:19它支持可以通过远程会话编排的代理，而 Codex 主要
00:14:23支持终端环境内部的多代理工作流。
00:14:27最大的区别在于各自分配子代理的方式。
00:14:29Claude Code 可以在没有明确调用的情况下生成代理，而 Codex 只有在
00:14:35我们在提示词中明确要求时才会创建代理。
00:14:37当 Codex 生成代理时，它会为它们命名并传递适当的提示词。
00:14:41在编码性能方面，两者相当接近，但背后的设计选择有所不同。
00:14:46Claude Code 的子代理使用显式的允许列表，这意味着父代理准确定义了
00:14:51子代理可以访问哪些工具，而 Codex 的子代理默认
00:14:55继承父代理的工具访问权限。
00:14:57Claude Code 还给每个子代理一个完全新鲜的上下文窗口。
00:15:01子代理无法访问对话历史，只能看到来自父代理的提示词，
00:15:06加上系统提示词和全局规则，因为 Claude 专注于上下文隔离。
00:15:10Codex CLI 则相反。
00:15:12它将完整的历史记录分叉到子代理会话中，并把父代理的提示词层叠在顶部。
00:15:17Codex 代理保留了更多关于已讨论内容的上下文，这确实有助于提高
00:15:22它们的性能。
00:15:23在实践中，Claude Code 严格的隔离损害了我们的研究子代理。
00:15:27当我们使用它们时，结果并不够好，因为它们只看到了眼前的
00:15:30提示词，而没有任何先前的上下文。
00:15:33Codex 代理能获取完整历史，可以更有效地迭代，并在注重
00:15:38连贯性的任务上表现更好。
00:15:39这就是本视频的全部内容。
00:15:41如果你想支持本频道并帮助我们继续制作这样的视频，你可以
00:15:45通过点击下方的超级感谢按钮来实现。
00:15:48一如既往，感谢观看，我们下期再见。