Codex vs Claude Code实测对比：同一Prompt构建应用的效率与质量差异

AI 编程智能体越来越强，但把同一个任务交给不同工具，结果究竟会差多少？知名 AI 自动化博主 Nate Herk 做了一次极具启发性的实验：他给 Codex 和 Claude Code 完全相同的 prompt，让它们各自独立打造一款「可上线的 Typeform 替代品」。结果不仅产出物差异巨大，连生成过程也天差地别——一个跑了两天半、烧掉近 3000 美元，另一个只用五个半小时、花费约 800 美元。

Typeform 是一家成立于2012年的西班牙SaaS公司，以其独特的「一次一问」对话式表单体验著称，彻底颠覆了传统表单的设计范式。相比 Google Forms 或 SurveyMonkey 的「堆叠式」布局，Typeform 通过全屏沉浸式交互大幅提升了用户完成率。该公司估值曾超过9亿美元，年收入超过1亿美元。正因其商业成功和清晰的产品边界，Typeform 成为 AI 编程智能体测试中常见的「标靶产品」——它足够复杂（涉及表单逻辑、条件跳转、数据收集、分享发布等完整链路），又不至于像 ERP 系统那样庞大到无法评估。

本文基于这次对比实验的完整拆解，梳理两大主流编程智能体各自的擅长领域，以及不同 prompt 风格对结果的深远影响。

实验设置：相同的 Prompt，截然不同的产出

实验设置非常严格：作者在 Codex 和 Claude Code 中都使用了同一个自定义的斜杠指令（slash command），传入完全一致的 prompt。核心要求是打造一款「可上线、有原创品牌的 Typeform 替代产品」，并明确划分了三个阶段的专用智能体：研究阶段、构建阶段、验证阶段。

这里需要理解的是，Codex 是 OpenAI 推出的编程智能体产品，基于其最新的 GPT 系列模型，运行在云端沙箱环境中，支持长时间自主执行复杂编码任务。Claude Code 则是 Anthropic 推出的命令行编程智能体，直接在开发者本地终端运行，能够读写文件、执行命令、进行版本控制。两者代表了当前 AI 编程工具的两种主流架构哲学：Codex 偏向云端托管式自动化，强调安全隔离和并行执行能力；Claude Code 偏向本地集成式协作，强调与开发者工作流的无缝衔接。

斜杠指令是现代 AI 编程工具中的一种标准化交互方式，用户通过输入如 /task 或 /build 等命令触发预定义的工作流。在本实验中，作者使用的斜杠指令实质上是一个「元提示词」（meta-prompt），它定义了多个专用智能体的角色分工：研究智能体负责分析竞品和技术选型，构建智能体负责实际编码，验证智能体负责测试和修复。这种多阶段编排模式源自软件工程中的「管道」（pipeline）思想，也与近年来流行的「智能体工作流」（Agentic Workflow）理念一脉相承——通过将复杂任务分解为多个自治子任务，每个子任务由专门的 AI 角色负责，从而提升整体输出质量。

prompt 的结尾还特别强调了一句关键要求：「不要停在原型或第一次成功构建的阶段，要继续研究、构建、测试、搞坏、修复、再测试，直到应用真正完整为止。」 作者的目标很明确——他想要的是一个第二天就能推向市场的成品，而不是一个演示 demo。

有意思的是，作者事后反思，这个 prompt 并非最优。他认为如果在「研究」和「构建」之间再加一个专门的「规划」阶段，把整个流程梳理清楚，两个系统或许都能产出更好的结果。这个细节也为后续的胜负分析埋下了伏笔。

两款产品的实测体验对比

Codex 的 Realform：设计精致但让人应接不暇

Codex 产出的应用名为 Realform。从落地页看，UI 元素相当扎实——有主视觉图、清晰的文案和引导按钮，普通人不会一眼看出这是 AI 生成的。注册流程也做得不错。

但真正进入表单编辑器后，问题就暴露了。作者的直接反应是「有点让人喘不过气」——UI 里塞的东西太多，一个本该简洁的问题编辑区堆满了各种变量和选项。更糟的是，作者连如何删除一个元素都摸不着头脑，一点删除就把整个内容全清空了。此外还发现了图片上传后预览不可用、确认弹窗位置偏移等 bug。

作者的评价一针见血：Codex 在「管理端」思考得非常周全，比如你想收集什么数据、如何组织数据，但从用户创建表单的角度看，这个体验相当劝退。而且它本质上只做出了一个演示工作区，并没有实现真正完整的功能，这违背了 prompt 的核心要求。

Claude Code 的 Firmora：设计粗糙但功能扎实

Claude Code 产出的应用名为 Firmora。第一印象反而不佳——落地页设计粗糙，作者甚至一时看不懂这是干嘛的。但一旦进入实际使用，体验立刻反转。

「至少作为用户，我很清楚该做什么，不会盯着界面就懵了。」作者表示。Firmora 的工作区切换流畅，表单编辑器提供「对话式」和「堆叠式」两种显示模式，明显更接近 Typeform 的交互逻辑。字段类型丰富（文本、邮箱、下拉、图片选择、评分、排名等），还支持进度条、题号、键盘提示、自动保存、捕获部分回答等实用功能。

当然 Firmora 也有 bug：问题编号始终显示为「1」、进入设计页面后难以返回、部分按钮无法点击等。但关键在于——它实现了真正可用的完整流程。作者成功发布了表单，拿到了分享链接，填写后还能在结果页看到真实的回复数据和提交来源。这才是一个「可上线产品」该有的样子。

成本与效率：资源消耗的巨大鸿沟

两者的资源消耗对比堪称悬殊：

维度	Claude Code	Codex
API 成本	约 800 美元	近 3000 美元
输出 Token	约 200 万	近 1150 万
耗时	5.5 小时	约 62 小时
子智能体	35 个	126 个
工具调用	较少	32500 次
浏览器测试	102 次	391 次
单元测试	296 次	2300+ 次

数据折算下来，Claude Code 这次大约快了 11 倍，成本低了 6.6 倍。

在大语言模型的计费体系中，Token 是最基本的计量单位。一个英文单词通常对应1-2个 Token，中文则约为1个字对应1-2个 Token。当 Codex 输出近1150万 Token 时，这意味着它生成了相当于数百万字的代码和文本——大致相当于一整套中大型企业应用的代码量。按照 GPT-5 系列模型每百万输出 Token 约15-60美元的价格区间计算，仅 Token 消耗就能解释大部分成本差异。值得注意的是，工具调用（tool calls）也会消耗 Token，Codex 的32500次工具调用意味着大量的系统交互开销，包括文件读写、命令执行、浏览器操作等，每次调用都需要将上下文重新编码为 Token 传入模型。

有一个有趣的技术细节：作者启动 Claude Code 时用的是模型 Fable 5，但过程中似乎触发了某种安全检查，最终回退到 Opus 4.8 作为主编排器，再由它调度 Fable 5 智能体执行任务。Fable 5 是 Anthropic 于2025年推出的新一代模型，定位为高创造力、高推理能力的旗舰级模型。Opus 4.8 则属于 Claude 4 系列中的最高性能变体，以其在复杂多步骤任务中的稳定表现著称。实验中出现的「安全检查触发后回退」现象，反映了 Anthropic 在部署新模型时采用的分层安全机制——当系统检测到可能的风险行为或异常模式时，会自动将任务降级到经过更充分安全测试的成熟模型。这种「编排器-执行器」的层级架构也是当前多智能体系统的主流设计：一个高级模型负责整体规划和任务分配，多个专用模型负责具体执行。

而 Codex 全程使用 GPT-5.6（最高性能档位）。这些模型变量的组合，也是导致结果难以预测的重要原因。

胜负评判：取决于你怎么定义「赢」

作者让 Codex 对两份匿名结果做交叉评审，结果 Codex 也判定 Claude Code 的产出更好。但深入分析各维度，会发现胜负其实更加微妙。

Claude Code 胜出的维度

• 产品判断力与范围把控：Claude Code 在「必须做 / 延后做」的决策上更清晰，专注于有价值的差异化功能。反观 Codex 追求了多达 135 项功能，包括几项成本高昂的运营特性，反而让产品臃肿不堪。
• 开发效率：Claude Code 拿到 9.8 分，Codex 仅 5.5 分。

Codex 胜出的维度

• 架构与执行：Codex 构建的系统运行成熟度更高，具备不可变修订、离线恢复、迁移安全、并发处理和云边界等能力。不可变修订意味着数据的每次变更都作为新版本保存而非覆盖原有数据，这在审计、合规和数据恢复场景中至关重要。离线恢复确保用户在网络断开时不丢失数据，重新上线后自动同步。迁移安全则保证数据库结构变更不会导致数据丢失或服务中断。这些特性虽然对最终用户不可见，但对于一个真正要投入生产环境的 SaaS 产品而言，它们决定了系统在高并发、异常场景和长期运维中的可靠性。在需要规模化的后端基础设施方面，Codex 明显更出色。
• 测试与可靠性：Codex 以明显优势胜出，增加了跨浏览器测试、属性测试、故障注入等一大堆测试，甚至覆盖了移动端——这些是 Claude Code 没有做到的。

这也解释了为什么 Codex 消耗了如此多的资源——它在构建一个「正确」的系统，只是忽视了「可用」这个更基本的维度。

核心洞察：不同AI编程工具需要不同的 Prompt 策略

这次实验最重要的启示，其实不是「谁更强」，而是两种智能体需要截然不同的 prompt 策略。

作者的比喻很形象：Claude Code（Fable）像一只「聪明的猫头鹰」，擅长创意、规划和头脑风暴，能帮你想清楚该走哪条路。给它下 prompt 时，你只需给出高层级目标 + 完成标准，然后让它自由发挥，不要挡它的路。

而 Codex 更像一个「听话的执行者」——你说什么它就做什么，而且会认真跑测试、确保任务完成。但它缺乏足够的创造力去揣摩你真正想要的体验，所以用 Codex 时你必须说得非常具体：第一步做什么、第二步做什么、第三步做什么。这次实验中，Codex 显然没能理解 prompt 结尾「打造完整可上线产品」的真实意图，尽管它非常努力、耗时极长，产出却偏离了目标。

换句话说，Codex 这次的「失败」很大程度上是 prompt 不适配造成的，而非工具本身能力不足。作者坦言，他日常约 80% 时间用 Codex 主导开发，20% 用 Claude Code，两个工具他都喜欢，会在不同场景下灵活切换。

给开发者的实用建议

作者的最佳工作流组合值得借鉴：用 Claude Code 做大量开发和规划，用 Codex 做安全评审、发现 bug、修复 bug。很多人用过 Claude Code 的 Codex 插件跑对抗式评审，它几乎总能发现 Claude Code 工作流中漏掉的边界情况。

最后作者提醒：新模型层出不穷（5.6、Fable、Opus 4.8……），变量实在太多，每次调用都像「拉老虎机」，你根本无法预知结果。因此亲自动手做这类小实验至关重要。他还给出了一个中肯的思考角度：不要盲目照搬 Karpathy 等大佬的建议，因为他们用工具做的事情和你不一样——就像三级跳运动员不该完全照搬跳高运动员的技巧，虽然有共通的基础，但终究是两项不同的运动。

核心要点