评测方法论与数据来源
本次横评不依赖任何单一厂商自报分数，而是以三类公开证据交叉验证：
- METR 2026-03-10 研究：四位活跃维护者（来自 scikit-learn、Sphinx、pytest）盲审 296 个已通过 SWE-bench 自动分级的 AI 生成 PR
- 多基准背离分析：对比 SWE-bench Verified、TerminalBench 2.0、LiveBench 的得分差异
- 厂商公开评测：OpenAI、Anthropic、各 CLI 工具的官方与第三方实测数据
SWE-bench 等公开基准存在训练数据泄露风险，且自动分级只检查测试是否通过。METR 研究虽样本量有限（296 个 PR、3 个仓库），但其「黄金基线」校准（人类手写 PR 合并率 68%）为落差提供了可信锚点。本报告所有数值均标注口径，避免跨口径强行比较。
核心鸿沟：自动分级 vs 维护者合并
SWE-bench Verified 衡量的是「给定 bug 报告与已知良好的代码快照，智能体能否产出通过测试套件的补丁」。这是一个定义清晰、无歧义的自动化任务。但真实世界的 PR 合并衡量的是「人类维护者是否愿意把变更并入生产仓库」——任务本身充满未写明的约定、评审偏好与部署风险容忍度。
| 指标 | 自动分级（SWE-bench） | 维护者实际合并 | 落差 |
|---|---|---|---|
| 前沿模型平均通过率 | 约 72% | 约 48% | −24 个百分点 |
| 人类手写 PR（黄金基线） | — | 68% | 锚点 |
| Claude 4.5 时间视野 | 约 50 分钟 | 约 8 分钟 | 约 6 倍高估 |
一个在 SWE-bench 上拿到 78% 的编码智能体，按此落差推算，落到你的真实代码库里有效的部分可能只有 44%–48%。更关键的是：若你从不追踪打回原因，你根本不知道那 78% 里有多少是「看起来对、实则进不了主干」的。
SWE-bench 衡量「智能体能否写出正确补丁」，生产合并率衡量「团队是否愿意合并这个补丁」。这是两种不同能力，落差在每家智能体上都稳定在 30–40 分。把基准分直接读作「能解决 X% 的真实问题」，是 2026 年工程团队最常见的误读。
维护者为什么打回
METR 的结构化反馈把打回归为三类主因，提示自动分级与人工评审的关注点错位：
| 打回类别 | 含义 | 自动分级能否发现 |
|---|---|---|
| 代码质量问题 | 不符合仓库约定、风格、惯用法 | 否（只测测试是否通过） |
| 破坏其他代码 | 修好了目标问题但引入别处故障 | 否（仅针对该题测试套件） |
| 核心功能失败 | 测试通过但未真正解决问题 | 部分（存在「假阳性」通过） |
值得注意的是，从 Claude 3.5 Sonnet 到 3.7，分数提升的同时「基础功能错误」类打回反而增多；到 Claude 4 Opus，问题从「测试失败」转为「纯代码质量」；Claude 4.5 主要改善代码质量；而 GPT-5 在该研究中的代码质量明显弱于 Anthropic 系模型。这说明分数提升的方向与「能否被合并」的方向并不总是一致。
TerminalBench 的背离信号
如果说 SWE-bench 的落差来自「评审主观」，TerminalBench 则揭示了「任务形态」带来的落差。TerminalBench 测试真实终端工作流，带有大量隐含上下文，对隐含约定的敏感度更高。
| 智能体 | SWE-bench Verified | TerminalBench | 背离 |
|---|---|---|---|
| Claude Code | 约 78% | 约 58% | −20 分 |
| Codex CLI | 约 77% | 77.3%（TerminalBench 2.0） | 接近持平 |
Claude Code 在 TerminalBench 上比 SWE-bench 低约 20 分，因为后者测试的是 CI/CD 流水线等机器可读性更高的任务，而前者大量依赖隐含上下文。这提示：同一模型在不同任务形态上的真实能力可能相差 20 分以上，单一基准无法刻画全貌。
成本维度：LiveBench 的性价比视角
选型不能只看能力，还要看「每美元产出」。LiveBench 2026 的快照显示，智能体编码任务的性价比分化显著：头部开源模型以约 1/5 的成本逼近闭源旗舰，迫使团队在「能力上限」与「运行成本」之间权衡。
| 模型档位 | 相对能力 | 每百万输出 token 成本 | 性价比定位 |
|---|---|---|---|
| 闭源旗舰（Fable 5.1 档） | 最高 | 约 $1.21 | 能力优先 |
| 开源标杆（Muse Spark 档） | 接近旗舰 | 约 $0.22 | 成本优先（约 5.5 倍价差） |
结合前面 24 分的合并率落差，一个务实结论浮现：在真实仓库里，便宜模型叠加更高的评审通过工程化（约定文件、评审规则），往往比昂贵模型裸跑更划算。因为决定「能否进主干」的主要是约定遵守度，而非基准裸分。
主流编码智能体能力对照
| 维度 | Claude Code | Codex CLI | GitHub Copilot | Cursor |
|---|---|---|---|---|
| SWE-bench 取向 | 高分、强自主 | 高分、强终端 | 中、IDE 集成 | 中、多模型 |
| TerminalBench | 约 58% | 77.3%（2.0） | — | — |
| 形态 | 纯 CLI | CLI | 编辑器插件 | IDE Fork |
| 约定文件支持 | CLAUDE.md | AGENTS.md | 有限 | 有限 |
| 审计/权限 | 白名单 + 日志 | 沙箱 + 白名单 | 白名单 + 日志 | Git Worktree 隔离 |
工程团队如何不被分数误导
弥合鸿沟的团队，共性做法是把「隐含约定」显式化，并直接度量真实合并率：
- 写约定文件：把仓库的非书面约定写进 CLAUDE.md / AGENTS.md / GEMINI.md，让智能体在提交前就对齐风格与边界
- 追踪打回原因：记录每个被拒 PR 的三类主因，定位是质量、破坏还是功能问题
- 度量真实合并率：用「每智能体 PR 合并率」替代 SWE-bench 分数作为内部 KPI
- 分层暴露动作：读默许、写显授，把破坏性动作挡在审批桥之后
- 多基准交叉：至少同时看 SWE-bench 与 TerminalBench，避免被单一形态的高分误导
别问「它在 SWE-bench 多少分」，要问「它在我仓库里合并率多少、打回原因是什么」。基准是证据之一，不是判决。