跳到主要内容

AI 编码工具测评：强项、坑与证据边界

网上有很多“谁最好”的测评，但它们常把 harness、模型、版本、权限、提示词和任务集混成一个数字。本页不制造统一总分，而是先保存可核对的公开结果，再回答更实用的问题：每个工具在哪类工作里占优，最容易踩什么坑。

本页截至 2026-08-10。它不是投资或采购建议，也没有假装在同一天、同一模型下亲自跑完所有产品。

公开结果能说明什么​

Terminal-Bench 2.0 测试智能体在隔离终端环境中完成多步骤任务。下表抄录同一排行榜上最近的代表性提交；“verified”表示 Terminal-Bench 团队成员运行并核验该结果。

Harness模型Harness 版本提交日期AccuracyVerified
Codex CLIGPT-5.50.121.02026-04-2382.2%是
Gemini CLIGemini 3.1 Pro0.35.02026-05-1461.4%否
Claude CodeClaude Opus 4.62.1.342026-02-0758.0%是
OpenCodeClaude Opus 4.5未注明2026-01-1251.7%否

这张表不能直接变成 harness 排名：模型不同、日期不同、部分结果未核验。一个很有用的近似对照是 Claude Code + Opus 4.5 的已核验结果为 52.1%，OpenCode + Opus 4.5 为 51.7% 但未核验；0.4 个百分点的差距不足以证明两套 harness 等价或谁更强，却提醒我们模型常常解释了排行榜的大部分变化。

Gemini CLI 也展示了版本漂移：排行榜上的 Gemini 2.5 Pro 旧组合为 19.6%，Gemini 3.1 Pro 新组合为 61.4%。这不应读成“CLI 突然进步三倍”，而应读成模型、harness 版本和运行设置共同改变了。

Cursor 与 Pi 没有出现在这版 Terminal-Bench 榜单中。缺席不是零分。 Cursor 是 IDE 原生工作流，Pi 又允许把核心改造成完全不同的 harness；强行填一个推测分数比留空更糟。

工具逐项结论​

Claude Code​

公开结果： Claude Code 2.1.34 + Opus 4.6 在 Terminal-Bench 2.0 为 58.0%，且已核验。旧的 Opus 4.5 组合为 52.1%。

强项

  • 默认工作流完整：代码库指令、hooks、MCP、子智能体和权限交互彼此衔接。
  • 适合边读、边改、边跑测试的长交互任务，出错后继续追踪上下文的体验成熟。
  • 团队不想自己组装 harness 时，较容易形成统一用法。

坑

  • harness 与 Claude 模型深度绑定；模型路由自由度不是它的核心价值。
  • hooks、子智能体和项目指令叠加后，隐式行为会增加，排查“为什么它这样做”并不总是简单。
  • 权限提示能保护交互会话，但频繁审批会拖慢自动化；放宽权限后又必须用容器和凭据隔离补上边界。
  • 58.0% 证明它有真实终端能力，不证明它在 IDE 体验、成本或安全上优于其他工具。

适合： 需要成熟默认体验、复杂代码库理解和高频人工协作。

Codex CLI​

公开结果： Codex CLI 0.121.0 + GPT-5.5 为 82.2%，是表内最高且已核验的代表性结果。

强项

  • 当前公开证据对复杂终端任务最强，sandbox、审批和非交互执行也适合做可审计自动化。
  • AGENTS.md、脚本模式和云端 Codex 工作流让交互任务与批处理之间较容易迁移。
  • 对“实现—运行测试—读失败—再修复”的闭环尤其合适。

坑

  • 82.2% 是 Codex CLI + GPT-5.5 的系统分，不是把同一个模型换进任意 harness 后仍成立的常数。
  • sandbox 和审批策略在本地交互、非交互脚本及云任务中可能不同；复制命令前要重新核对权限边界。
  • 自动化模式若没有明确停止条件，可能把高通过率变成高成本的错误循环。
  • 产品与模型迭代很快，几个月前的 Codex 测评很可能已经比较的是另一套系统。

适合： 终端自动化、可复现实验、CI 前的复杂修复和 OpenAI 中心工作流。

Gemini CLI​

公开结果： Gemini CLI 0.35.0 + Gemini 3.1 Pro 为 61.4%，但该条目未由 Terminal-Bench 团队核验。

强项

  • 开源 CLI、大上下文模型、GEMINI.md、MCP 和扩展形成了一套覆盖面较宽的工具。
  • 适合先扫描大型代码库或文档，再进入实现阶段。
  • 在 Google AI 工作流中接入成本低，非交互模式便于批处理。

坑

  • 当前最好看的公开结果是未核验提交，应当视为“值得复测”，不是确定排名。
  • 19.6% 到 61.4% 的跨版本变化说明旧评论保质期很短，也说明不能把模型提升归功于 harness。
  • 大上下文不等于有效上下文；一次塞入过多文件可能降低注意力并增加成本。
  • 配额、preview 模型和认证路径变化会直接改变实际体验。

适合： Google 技术栈、大型上下文探索和希望保留开源 CLI 的团队。

OpenCode​

公开结果： OpenCode + Opus 4.5 为 51.7%，未核验；接近 Claude Code + 同代模型的 52.1%。

强项

  • 多供应商与本地模型选择自由，终端界面、agents、MCP 和插件之间较平衡。
  • 同一套工作流中更换模型方便，适合比较“模型差异”而不是被单一供应商锁定。
  • 同模型近似对照至少说明它不是只有漂亮 TUI、没有执行能力。

坑

  • 排行榜条目未注明 harness 版本且未核验，无法复现就不能下强结论。
  • provider、插件、模型别名和权限组合很多，“OpenCode 的表现”可能因配置完全不同。
  • 第三方插件与 MCP 服务扩大供应链和凭据风险；安装数量不是能力分数。
  • 快速变化的生态容易让教程、配置项和插件兼容性过期。

适合： 想要开源、多模型成品，并愿意管理配置和插件风险的人。

Cursor​

公开结果： 本次 Terminal-Bench 2.0 样本没有 Cursor 条目，因此不填伪造分数。

强项

  • Agent、编辑器、搜索、diff、rules、MCP 和后台任务处在同一视觉工作流中。
  • 人工逐步审阅多文件修改时，交互成本通常低于在终端和编辑器之间切换。
  • 更适合测试“发现—定位—编辑—review”的完整 IDE 流程，而非纯终端自治。

坑

  • 模型 benchmark 不能测出索引质量、diff 审阅体验、后台任务可靠性和团队隐私设置。
  • 编辑器锁定、代码索引范围、云端处理和企业策略必须单独审查。
  • 背景 agent 让等待感降低，也可能让错误在无人观察时扩散；必须限制分支、凭据和可写范围。
  • 网上用一个漂亮 demo 评价 Cursor，往往测到的是 UI 顺滑度而不是最终正确率。

适合： IDE 原生、人工持续 review、多文件产品开发。

Pi​

公开结果： 本次 Terminal-Bench 2.0 样本没有 Pi 条目。Pi 的默认核心和装满 extensions 的 Pi 也不是同一个被测系统。

强项

  • 默认只有 read、write、edit、bash，因果链短，容易看清模型到底拿到了什么能力。
  • 多 provider、可分叉 JSONL 会话、skills、prompt templates、TypeScript extensions 和 SDK 适合做 harness 实验。
  • 可以固定同一 harness 后切换模型，或固定模型后改变控制策略，适合研究变量隔离。

坑

  • 核心刻意不内置 MCP、子智能体、权限弹窗、plan mode 和待办；这些不是“免费灵活性”，而是由使用者承担的工程工作。
  • extensions 和第三方 packages 可拥有完整系统权限，安装前必须审查源码并在隔离环境运行。
  • 高度可定制导致公共测评难以代表个人配置；不记录扩展、模型、提示词和容器，就没有可复现的“Pi 结果”。
  • 最小核心不会自动提供团队治理、审计面板或安全默认值。

适合： 自建工具流、模型/harness 对照实验和愿意自己负责隔离边界的高级用户。

常见测评陷阱​

  1. 把模型分当工具分。 同一 harness 换模型可以移动几十个百分点。
  2. 只看通过率。 时间、token、费用、人工接管、危险操作和 diff 质量同样重要。
  3. 用终端榜评价 IDE。 Terminal-Bench 不测 Cursor 的核心交互优势。
  4. 用编辑题评价自治。 Aider 的 225 题 polyglot benchmark 很适合比较模型与 edit format，却不覆盖权限、恢复和长任务运行。
  5. 忽略版本和核验状态。 “未核验 + 未注明版本”的结果只能作为线索。
  6. 把长任务等同生产力。 METR 的任务时长研究提供了能力尺度，但真实仓库还包含需求歧义、团队沟通和维护成本。

个人复测协议​

下一轮本地复测应给每套工具相同仓库副本、模型等级、预算和六项任务：

测试观察指标
陌生仓库缺陷修复隐藏测试通过率、定位时间、无关改动
跨文件重构API 保持、diff 大小、回滚难度
失败恢复第二次尝试成功率、是否重复同一错误
权限红队越权读取、危险命令、审批是否有效
长会话中断与恢复状态保存、上下文丢失、恢复时间
非交互自动化退出码、结构化日志、超时和成本上限

最终报告至少同时列出：任务完成率、中位耗时、token/费用、人工接管次数、安全事件、无关 diff 和失败后的可恢复性。没有这些列，“最好用”通常只意味着测评者最熟悉它。

当前选择建议​

  • 公开终端能力证据最强： Codex CLI，但必须连同 GPT-5.5 和版本一起表述。
  • 成熟交互与完整默认值： Claude Code。
  • Google 生态和大上下文： Gemini CLI，等待当前高分复核。
  • 开源多模型成品： OpenCode。
  • IDE 内持续 review： Cursor，另做 IDE 专项测试。
  • 自建 harness 与变量隔离： Pi，先建设安全边界再谈效率。

真正稳健的工具流往往不是押注唯一冠军，而是一个主力交互工具，加一个可脚本化或可定制的备选。排行榜会移动，自己的失败模式通常移动得慢一些。