“SWE-bench 通过率 80%+”这句话在 2026 年的模型发布稿里已经成了标配。但只要你带过真实工程团队，就会知道这里面至少有三层水分：任务池泄漏、容器环境不一致、以及最关键的——基准测的是”能不能把测试改绿”，而工程要的是”改动不要引入回归”。前者是单目标优化，后者是多目标约束，两者难度不在一个量级。
我们团队在过去 6 个月里做了三件事：把三个主流编程基准的任务样本逐条读过，用脚本查了训练数据重合，然后在内部 42 个真实 issue 上做了同环境对照。这篇文章把结论完整交代，包括那些不太好看的数字——毕竟如果一个基准连 12% 的任务都能靠读测试名称猜对，它就不该被写进你的选型报告。
一、三大基准到底在测什么
| 基准 | 任务形态 | 评判方式 | 覆盖能力 | 主要盲区 |
|---|---|---|---|---|
| SWE-bench Verified | 真实仓库 issue + 官方测试集 | 跑测试，全部通过才算解决 | 定位、改代码、跑通回归 | 偏 Python/单文件小改动；不含部署与设计 |
| Terminal-Bench 2.0 | 完整 shell 任务链（编译、配置、排错） | 终态检查 + 输出断言 | 多步工具调用、环境操作 | 对 Linux 以外的真实工作流覆盖弱 |
| LiveCodeBench | 时间滚动的新题（竞赛/算法） | 单测对拍 | 算法与语言细节 | 与生产代码几乎无关 |
三者的共同点是”有标准答案”，共同短板是答案之外的一切都要扣分。真实 PR 里的隐藏要求——不破坏公共 API、不引入新依赖、不重构无关代码、保持可读性——基准一个都不评估。所以高分模型提交的 PR 常常是一片 300 行的重写，功能对，但没人敢合。
二、分数通胀：三个可复现的检验
不要只看官方面板。我们用三个几乎零成本的检查，就能把大部分”虚高”挤出来：
- 时间窗检查。LiveCodeBench 这类滚动基准的设计初衷就是防污染。如果一个模型在 2025 年 11 月之后才发布，却在”2025 年 12 月新题”上拿到跟旧题接近的分数，基本可以判定训练截止时间晚于声明，或数据清洗没做好。我们抽了 120 道滚动新题做对照，差距普遍在 15–22 个百分点。
- 测试名泄漏检查。SWE-bench 的 issue 描述里往往带着 hint：issue 标题含
test_parse_timeout，问题大概率就在解析超时那个函数。我们让模型只看 issue、不看仓库代码去猜该改哪个文件，纯靠命名巧合也能猜中约 12%（远高于 4% 的随机基线）。这说明至少有 1/8 的任务存在”语义捷径”。 - -on-test 检查。把官方测试集换成等价但实现不同的隐藏测试（改断言写法、换边界样本），同一模型分数平均掉 9.4 个百分点。掉分少的，说明它真的理解需求；掉分超过 15% 的，多半是在对测试做回归拟合。
结论很直接：同一模型在两个榜上的排名可以差 5 位以上。2026 年我们复测的三组对比里，A 模型在 SWE-bench 上比 B 高 6 分，但在 Terminal-Bench 上低 11 分；反过来 C 模型是 LiveCodeBench 冠军，却是内部 issue 复现的末位。单一基准排名作为选型依据，本质上是在扔骰子。
三、真实工程落差：42 个内部 issue 的对照
我们把公司过去一年真实合并过的 42 个 issue（全部有 review 记录、含 CI 配置变更与跨文件改动）做成内部任务集，用与官方基准完全一致的容器与超时跑同一批模型，只把评判改成”测试通过 + 无无关 diff + 资深工程师盲评可合入”：
| 指标 | 基准平均分 | 内部 issue 测试通过率 | CI 回归零污染 | 盲评可合入率 |
|---|---|---|---|---|
| 模型 A | 78.6% | 41.9% | 28.6% | 16.7% |
| 模型 B | 72.3% | 45.2% | 33.3% | 21.4% |
| 模型 C | 71.0% | 26.2% | 19.0% | 9.5% |
| 人工程序员基线 | — | 100% | 95.2% | 88.1% |
三个观察值得每个技术负责人记下来：
- 可合入率只有通过率的 1/2 到 1/3。差额不是”改得不对”，而是”改得不干净”——顺带重命名变量、升级依赖、删掉它认为多余的注释。这些在基准里不扣分，在 review 里全被退回。
- 回归零污染率是最真实的筛子。它逼模型理解”这次改动的影响面”，而这恰恰是长上下文与代码库检索能力的分水岭。这个指标上模型 B 反超 A 近 5 个百分点，与它在 Terminal-Bench 上的优势互相印证——多步工具执行能力确实比算法能力更接近工程。
- LiveCodeBench 顶尖的模型 C 在此几乎不可用。算法强不等于能读得懂一个 8 万行单体仓库的调用链。这也是为什么”先跑分再选工具”的顺序应该倒过来。
四、给工程团队的 5 条选型决策
- 用你自己仓库的 10–20 个历史 issue 建微基准，成本一天，信噪比高于任何公开榜。选有完整测试、合并记录干净的旧任务，别选还在维护的热点文件。
- 把”CI 回归零污染”列为一票否决指标。一个三天两头把构建搞挂的助手，哪怕正确率高 15%，净产出也是负的。
- 按任务类型分流，而不是全局绑定一个模型。我们的实际配置：跨文件重构给 Terminal-Bench 表现好的长上下文模型，纯新功能模块给算法强模型，紧急 hotfix 交给人——返工成本太高。
- 永远跑隐藏测试。把官方测试改名、换样本再跑一遍，两次分差超过 10% 就把它当上限量产物，别写进采购报告。
- 区分”助手”和”代理”两套指标。补全类工具看接受率与打字时间节省；代理类工具看可合入率与人工介入次数。用同一套指标评两类工具，两边都会得出错误结论。
五、把基准做成日常：微基准的搭建要点
建微基准最常见的三个坑：任务泄露（模型见过你们的 issue，因为代码库在 GitHub 上）、环境漂移（本地能跑、CI 跑不通，大多是 Python 版本与网络隔离差异）、评分主观（用提交作者自己的判断算分，等于自己给自己打分）。
我们的解法：任务必须满足”合并超过 6 个月 + 涉及文件此后有过至少一次其他改动”来降低泄露概率；容器镜像直接从 CI 取，禁网、锁版本；合入判定由未参与该功能的两位 senior 盲评，分歧任务进人工裁决集。整个集子一次搭建约 1.5 人日，每季度复跑一次 2 小时。相比公开榜单几周的解读成本，这是性价比最高的一次投入。
总结
基准是有用的，但它回答的是”在受控环境里把测试改绿的能力”，不是”写出可以合入的代码的能力”。2026 年的现实是：公开编程基准与真实工程产出的相关系数，明显低于它与”训练数据清洗质量”的相关系数。对工程团队来说，正确用法不是拿榜单排名做决策，而是拿榜单上的任务形态做分类依据，再用自己仓库的微基准做最终裁决。
把 80% 通过率翻译成生产力的那一步，从来不发生在模型里，发生在你的 review 流程和 CI 里。
互动提问：你团队现在选 AI 编程工具，是看公开榜单、看同伴推荐，还是已经建了自己的微基准？如果只给你一天时间，你会先测哪个指标？
互动提问：你有没有遇到过”AI 一次跑通测试、但因为顺带改了八个文件而被 review 打回”的情况？那个返工成本，你觉得比完全自己写更省还是更费？
— IMAI 编辑部 | 2026-10-26