20-Claude Code vs Codex vs OpenCode：真实项目横向评测

摸鱼同学

1858人浏览 · 2026-06-17 10:22:30

摸鱼同学 · 2026-06-17 10:22:30 发布

Claude Code vs Codex vs OpenCode：真实项目横向评测

前 19 篇文章分别深入了三大工具。但"哪个更好"这个问题，只有放在同一个需求面前才能真实回答。这篇文章用同一个项目需求，分别交给三个工具独立完成，从四个维度做客观对比。

评测方法

测试需求

为了公平对比，选择了一个中等复杂度的真实需求：

"为一个 FastAPI 后端项目添加 API Key 认证功能。要求：

支持创建/吊销 API Key

API Key 用 SHA-256 哈希存储（不存明文）

中间件验证 API Key，验证失败返回 401

支持 Key 的过期时间

写完整测试"

评测环境

项目背景：已有的 FastAPI 后端项目（12 个文件）
CLAUDE.md / AGENTS.md：已经写好，三个工具用同一份约束
MCP 配置：三个工具都配了 GitHub MCP
模型：
  Claude Code → Claude Sonnet 4.6
  Codex CLI  → GPT-5.3-Codex
  OpenCode   → Claude Sonnet 4.6（和 Claude Code 同模型，对比工具差异）

评测维度

维度	评估方法
代码质量	安全性、正确性、可维护性、测试覆盖
开发速度	从开始到跑通全部测试的时间
交互体验	需要的对话轮数、中断次数、返工次数
Token 成本	实际消耗的 Token 量 × 单价

实测过程

Claude Code：4 轮对话，22 分钟

第 1 轮（3 分钟）：
👤 "帮我添加 API Key 认证功能。要求：创建/吊销 Key，
    SHA-256 哈希存储，中间件验证，支持过期时间。"

🤖 开始干活：
  - 直接创建 api_key.py（model + CRUD）
  - 直接创建 middleware.py（验证中间件）
  - 注册路由到 main.py
  → 初版完成，但 API Key 的权限模型没做

第 2 轮（5 分钟）：
👤 "不错。但还需要给每个 Key 关联一个 scope（权限范围），
    中间件验证时要检查 scope 是否匹配当前路由。"

🤖 修改 model 加 scope 字段 → 修改 middleware 加 scope 检查
  → 修改创建/吊销接口支持 scope 参数
  → 修改测试覆盖 scope 场景
  → 运行测试：3 个 fail
  → 自动修复：scope 默认值处理不当
  → 再跑：全部通过

第 3 轮（8 分钟）：
👤 "再加一个功能：管理员可以查看所有 Key 的使用统计——
    每个 Key 被调用了多少次、最后一次调用时间。"

🤖 新增 APIKeyUsage 表 → 新增统计接口
  → 修改 middleware 每次验证后记录使用
  → 写测试
  → 跑测试：1 个 fail（并发记录问题）
  → 修复：改用异步写入
  → 通过

第 4 轮（6 分钟）：
👤 "最后加完整测试：happy path + 过期 Key + 错误 scope + 吊销后的 Key"

🤖 写了 12 个测试用例 → 跑测试 → 全部通过
  → /review 自查 → 没有安全问题

总计：4 轮对话，22 分钟，22 个测试全部通过。

Codex CLI：3 轮对话，31 分钟

第 1 轮（12 分钟）：
👤 同样的需求描述

🤖 自动触发 /plan：
  → 输出 6 步计划
  → 我等了 2 分钟读计划 → 确认

  计划执行：
  → 创建 api_key.py → 创建 middleware.py → 注册路由
  → 每步执行后自动检查
  → 写完就跑测试：全部通过
  → 比 Claude Code 慢，但每一步都很稳

第 2 轮（10 分钟）：
👤 "加上 scope 权限控制和使用统计"

🤖 再次 /plan → 输出 3 步子计划 → 我确认
  → 执行。这次没有 test fail。
  → 但多花了时间在"过度谨慎"上——
    改一个字段，Codex 会确认两遍。

第 3 轮（9 分钟）：
👤 "加完整测试"

🤖  自动生成 14 个测试 → 跑测试 → 全部通过
  → /review 自查 → "建议给统计接口加缓存，避免频繁查询"

总计：3 轮对话，31 分钟，22 个测试全部通过。

OpenCode：5 轮对话，28 分钟

第 1 轮（7 分钟）：
👤 同样的需求描述

🤖 没有 /plan，直接开始
  → 创建 api_key.py（结构有点"教科书"，不够贴合项目现有风格）
  → 创建 middleware.py
  → 和 Claude Code 输出质量接近但稍微粗糙

第 2 轮（6 分钟）：
👤 "model 的风格和项目现有的 models/user.py 不一致，
    看看 user.py 然后改一下"

🤖 读 user.py → 调整 api_key.py 的风格
  → 这次一致了，但多花了一轮对话来修正风格问题

第 3 轮（6 分钟）：
👤 "加 scope 权限控制"
  → 正常完成

第 4 轮（5 分钟）：
👤 "加使用统计"
  → 正常完成，但 middleware 中记录使用的代码有点重复

第 5 轮（4 分钟）：
👤 "加完整测试 + 重构一下 middleware 里重复的代码"
  → 完成

总计：5 轮对话，28 分钟，22 个测试全部通过。

四维对比

一、代码质量

三份最终代码的核心差异：

检查项	Claude Code	Codex CLI	OpenCode
安全性（SQL 注入/Key 泄露）	✅ 参数化查询，哈希存储	✅ 同左	✅ 同左
Key 哈希存储	✅ SHA-256 + salt	✅ SHA-256 + salt	✅ SHA-256（无 salt）
过期时间处理	✅ 时区感知	✅ 时区感知	⚠️ 用了 UTC now but naive
中间件错误处理	✅ 完善的异常处理	✅ 更详细的错误码	✅ 基本覆盖
代码风格一致性	⚠️ 第 4 轮才完全一致	✅ 从开始就一致	❌ 需要修正才能一致
测试覆盖	22 个测试	22 个测试	22 个测试
代码可读性	★★★★☆	★★★★★	★★★☆☆
安全性总分	★★★★☆	★★★★★	★★★☆☆

结论：Codex CLI 代码质量最高（因为 /plan 先行，每一步都经过审查），Claude Code 紧随其后但需要更多迭代修正，OpenCode 需要更多人工干预来对齐项目风格。

二、开发速度

从需求到全部测试通过：

Claude Code  ██████████████████░░░░  22 分钟
OpenCode     ██████████████████████  28 分钟
Codex CLI    ████████████████████████████  31 分钟

但只看时间会得出错误结论。更细致的分析：

Claude Code 快在哪？
  - 不用 /plan，直接动手（省了 3-5 分钟/轮）
  - 对话更自然，不需要"确认计划"这个步骤

Codex CLI 慢在哪？
  - /plan 生成需要 1-2 分钟，阅读和确认需要 1-3 分钟
  - 每步执行后自动检查，多了一道工序
  - 但慢的这 9 分钟换来了更少的返工和更高的代码质量

OpenCode 慢在哪？
  - 风格对齐多消耗了一轮对话（6 分钟）
  - 没有自动的风格学习机制

结论：快速迭代选 Claude Code，一次做对选 Codex CLI。

三、交互体验

维度	Claude Code	Codex CLI	OpenCode
对话轮数	4 轮	3 轮	5 轮
需要我手动纠正次数	2 次	0 次	3 次
返工次数	1 次（scope 默认值）	0 次	1 次（风格对齐）
需要我做的决策	4 个	7 个（确认计划）	5 个
"惊喜"次数（AI 主动做了超出预期的好事）	2 次	1 次	0 次
"惊吓"次数（AI 做了预料之外的错事）	1 次	0 次	1 次

交互风格差异：

Claude Code：
  "你要 X？好，我开干了。" → 速度快，但有时需要你拉住它。

Codex CLI：
  "你要 X？我先想想怎么做。" → 计划阶段让你安心，但每一步都要你点头。

OpenCode：
  "你要 X？好的。" → 像 Claude Code，但没有那么精细的"品味"。

四、成本对比

	Claude Code	Codex CLI	OpenCode
输入 Token	85K	120K（/plan 消耗额外上下文）	78K
输出 Token	18K	15K	20K
模型单价（每 1M Token）	$3 / $15	$3 / $12	$3 / $15
本次任务成本	~$0.53	~$0.54	~$0.53
月估算（重度使用）	$200-500	$150-400	$15-500*

* OpenCode 如果用 DeepSeek 可低至 $15-30/月。

成本结论：同模型下三者成本几乎一样。真正的成本差异来自"你选什么模型"，而不是"你选什么工具"。OpenCode 的成本下限最低（可以用 DeepSeek 等低价模型）。

Benchmark 数据对照

除了自己的实测，还参照了已有的第三方评测：

Benchmark	Claude Code	Codex CLI	OpenCode
SWE-bench Verified	72.3%	68.7%	65.1%*
Terminal-Bench	58.4%	62.1%	51.3%*

* OpenCode 的成绩取决于所使用的底层模型。这里用的是 Claude Sonnet 的结果。如果用 GPT-5.5 或 DeepSeek，成绩会变。

解读：

SWE-bench 测试的是"修复真实 GitHub Issue"的能力——Claude Code 领先
Terminal-Bench 测试的是"终端命令的正确性"——Codex CLI 领先（/plan 的作用）
OpenCode 作为框架，成绩更依赖底层模型选择

各自的甜区和雷区

Claude Code

甜区：
  ✅ 前端开发 + 快速迭代（改 UI 看效果 → 改 → 看 → 改）
  ✅ 日常高频编码（你很清楚要做什么，一小步一小步描述）
  ✅ 重度 Skills/MCP/Hooks 配置（生态最强）
  ✅ 单人项目的端到端开发

雷区：
  ⚠️ 复杂架构重构（没有计划先行，容易跑偏）
  ⚠️ 长任务自主执行（没有 /goal，需要持续引导）
  ⚠️ 高安全要求的项目（比 Codex 的 sandbox 模式弱）

Codex CLI

甜区：
  ✅ 复杂任务（先计划再执行，不会跑偏）
  ✅ 长任务（/goal 挂后台，不用管）
  ✅ 多方协作（Subagent + Worktree 并行）
  ✅ 安全敏感项目（三级权限 + sandbox）

雷区：
  ⚠️ 快速原型（/plan 的 overhead 在这里是累赘）
  ⚠️ 高频微调（每一步都要确认计划，节奏慢）
  ⚠️ 生态不如 Claude Code（缺少 Skills 和 Plugin 系统）

OpenCode

甜区：
  ✅ 预算极度敏感（配低价模型，成本降到 1/10）
  ✅ 私有化部署（数据不能离开内网）
  ✅ 需要多模型混用（不同的任务用不同模型）
  ✅ 深度定制需求（开源，可以改代码）

雷区：
  ⚠️ 开箱体验不如商业产品（需要自己配置和调教）
  ⚠️ 代码风格适应性较弱（不自动学习项目风格）
  ⚠️ 社区生态较小（Skill/Plugin 数量不是一个量级）

什么时候混用更高效

我实际工作中的混用策略：

需求到来
    │
    ├─ 需求是否明确？
    │   ├─ 很明确 → Claude Code 直接执行
    │   └─ 比较复杂 → Codex /plan 生成计划
    │
    ├─ 任务是否可以并行？
    │   ├─ 可以 → Codex + Subagent 并行
    │   └─ 不行 → 单工具串行
    │
    └─ 成本考量？
        ├─ 正常预算 → Claude Code / Codex
        └─ 预算紧张 → OpenCode + DeepSeek

实际协同案例

上周做的一个真实功能——"给 CMS 加全文搜索"：

1. Codex /plan（5 分钟）
   → 生成 8 步计划
   → 我删掉 2 步不必要的，调整顺序

2. Claude Code 执行步骤 1-4（15 分钟）
   → 数据库索引 + 搜索接口 + 前端搜索框
   → 快速迭代，每做完一步我确认

3. Codex /goal 执行步骤 5-8（后台跑了 40 分钟）
   → 中文分词集成 + 高亮 + 搜索结果排序 + E2E 测试
   → 我去开了个会，回来就做好了

4. Claude Code /review（3 分钟）
   → 审查全部改动 → 两个小问题 → 修复 → 合并

总耗时：我实际参与 ~20 分钟，AI 自己跑了 ~40 分钟。
如果用单一工具串行做，预计需要 90 分钟以上。

混用黄金法则

1. 计划交给 Codex，执行交给 Claude Code
   → Codex 的 /plan 是三个工具里最好的计划生成器
   → Claude Code 是三个工具里最快的执行者

2. 简单 + 快节奏 → Claude Code
   复杂 + 需要谨慎 → Codex CLI
   省钱 + 私有化 → OpenCode

3. 不要让任何一个工具做它不擅长的事
   → 别让 Claude Code 做 30 分钟以上的长任务
   → 别让 Codex 做高频的 UI 微调
   → 别让 OpenCode 做需要强大生态支撑的事