随着 ，大家是不是也像我一样被下面这张表刷屏了？

特别是 SWE-bench Pro 80.3% 的得分，可以说是完全“碾压” GPT-5.5 的58.6% 。

由于模型放出的时间太短，各路大神都在火热的测试，我们让子弹多飞一会，不讨论 Fable5 的效果是否惊艳、也不管它是不是 Token 爆炸机……

我们今天来聊聊大模型的 Coding Benchmark，特别是 SWE-bench Pro，深入的了解Benchmark得分到底意味着什么？ 以及 能不能用Benchmark来选择模型。

Coding Benchmark 的四代演进

先简要回顾一下 Coding Benchmark 的发展。

1.函数级短代码题

最早的期的 Benchmark，主要应用场景是辅助编程中的代码补全。代表有 HumanEval、MBPP、BigCodeBench，测试的是模型“会不会写一个函数”。

题目本身都很短，而且多数也不需要理解代码库、不需要调试、不需要读文档。

题库很老，污染严重。对于当下的顶级模型来说基本可以说是毫无挑战，所以实际使用时，参考价值无限接近于0。

2.竞赛编程 / 算法题

从真实的竞赛或是算法题库中选择题目，代表有 LiveCodeBench、Codeforces、LeetCode、AtCoder 等。 能够测“算法、推理、边界条件、时间复杂度”。

比起 Coding，这些题目更像是考验抽象能力，不一定是实际工作中会用到的编程类型，而且……你都能刷题，大模型刷题不是更容易？

3.仓库级真实 issue 修复

为了修复前两代测试更偏向应试风格，从真实的 Github Issue 中选取，代表是 SWE-bench 系列。测试范围从答题拓宽到“能不能读代码库、定位问题、改多个文件、通过测试”。

原始 SWE-bench 有 2,294 个真实 issue。后来又衍生出多个版本：

• SWE-bench Lite：300 个任务，方便低成本评测；
• SWE-bench Verified：500 个经过人类过滤的任务，确保问题描述清楚、测试正确、任务可解；
• SWE-bench Multimodal：517 个带截图、设计稿、视觉错误信息的软件 issue；
• SWE-bench Multilingual：300 个多语言任务，避免只测 Python；
• SWE-bench Live：持续更新的新任务，降低数据污染风险；
• SWE-bench Pro：更复杂、更长程、更接近企业工程任务的版本。

其中 SWE-bench Verified和 Pro 是 Coding 的主流评测标准。

4.真实工作流型

针对 Agentic Coding 专门推出的评测集，测试“能不能像工程 agent 一样完成任务”。更贴近真实工作环境。

代表有 Terminal-Bench、Aider Polyglot、RepoBench、CursorBench、FrontierCode、ViBench。

这代 Benchmark 经常有私有题集或商业口径，透明度差异很大。

下面汇总了主流 coding benchmark 横向比较表，方便大家快速查询：

SWE-bench Pro 是什么

SWE-bench Pro 由 Scale AI 发布，总计 1,865 个任务，覆盖 41 个代码库。其中：

• 731 个 public 任务；
• 858 个 held-out（不对外公开的测试题目集） 任务；
• 276 个 commercial 任务，来自私有商业代码库。

这些任务平均要修改 107 行代码、跨 4 个文件，覆盖 consumer app、B2B 服务、开发者工具等更接近企业真实环境的代码库。

能完成评测，意味着：

模型能处理专业工程师需要花数小时甚至数天才能完成的真实任务。

Benchmark 缺陷

Benchmark 得分越高，能不能代表能力越强呢？

从社群反馈和我们的个人体验来说，答案是：不能。

Scaffold 污染

很多人看 benchmark，会默认它测的是模型智商。

到了 coding benchmark，尤其是 SWE-bench 这种仓库级任务，这个理解就太简单了。

一个模型在 SWE-bench 上的成绩，至少混合了下列因素：

• 模型本身能力；
• agent 框架；
• prompt 设计；
• 文件搜索工具；
• 是否能跑测试；
• 是否允许多轮尝试；
• 是否有代码库索引；
• 是否有 reviewer / verifier；
• token budget；
• timeout；
• Docker 和依赖环境稳定性；
• patch 应用和测试脚本。

这就是 harness 污染或 scaffold 污染的问题。

同一个模型，放进不同 agent 系统，分数可能差很多。同一个 benchmark，换了工具调用方式、prompt、测试环境，结果也可能不完全可比。

SWE-bench Verified 官网自己也提醒，mini-SWE-agent v1 和 v2 的结果不一定能直接比较，因为 v2 使用 tool calling，v1 是从模型输出里解析动作。一个评测框架的小变化，都可能影响模型最终表现。

所以当你看到“某模型 SWE-bench 提升 5 个点”时，第一反应不应该是“这个模型一定聪明了 5 个点”，而应该进一步探究评测用的 scaffold、工具、token budget、timeout、题集版本、prompt、是否允许多轮尝试，都会影响最后成绩。

另一个老问题：泄题

正如我们在历史回顾和横评总表中多次提到的，代码 benchmark 特别容易被污染。

HumanEval 和 MBPP 这类经典题库已经公开多年，GitHub、论文、博客、教程、模型评测仓库里到处都是。模型训练数据里是否见过题目、答案、题解，很难完全确认。

污染不一定是厂商故意作弊，考虑到现代LLM训练数据量需求的激增和来源的多样，也可能是 benchmark 本身进入了预训练数据、题解和讨论进入了训练数据、别人用 benchmark 生成的合成数据进入了训练数据、厂商用 benchmark 做模型选择和调参，长期形成过拟合 等原因。

这也是 LiveCodeBench 和 SWE-bench Live 这类动态 benchmark 变重要的原因。它们尽量用新题，或者按题目发布时间切分，让模型在训练截止时间之后的新问题上接受测试。

SWE-bench Pro 也在尝试降低污染风险。它的 public 子集使用强 copyleft / GPL 类仓库，因为这类代码进入商业模型训练集的法律风险更高(注意只是风险)；private commercial 子集来自合作创业公司的私有代码库，更不可能提前出现在训练数据里。

单这依然不能保证绝对干净。

高分低能陷阱

还有一个容易被忽略的问题：SWE-bench 系列来自 GitHub issue，因此它天然更偏“维护型工程”而不是“创造型工程”。

Issue 里当然不只有 bug，也有 feature request、enhancement、性能优化和行为调整；但它的基本范式仍然是“给定现有代码库和相对明确的问题，生成一个能通过测试的 patch”。

所以，单纯的 SWE-bench 分数高，说明模型更可能擅长在已有项目里定位问题、修改代码、通过测试；但这不能直接证明它擅长从 0 到 1 设计新功能、做产品判断或搭建全新系统。

这类测试边界和使用边界的“漂移”，我统称为“高分低能”陷阱。如果不了解评测集本身的构造和目的，就会盲目的以为这是一个综合分数，而忘了多数评测其实只能验证一个极小的能力边界。

很多时候我们实测模型会遇到模型Benchmark分数提高，但模型是通过反复写bug、修bug的方式完成任务，与其说是“作弊”，倒更像是模型为了得高分的“应试”考生。

Benchmark 可靠吗？

上面提到了 Benchmark 的缺点，那 Benchmark 到底能用吗？

回答是，能：

coding benchmark 最大的价值，是帮你筛掉明显不合格的模型.

针对需要落地、尤其是企业用户，我们建议按照下面的逻辑进行筛选：

1. 先排除明显掉队的模型

如果一个模型在主流 coding benchmark 上全面落后一档，比如 HumanEval / MBPP 都不行，LiveCodeBench 明显低，SWE-bench Verified / Pro 跟不上，Terminal-Bench 也完全没表现，那它大概率不是一个适合 coding 的模型。

Benchmark 最可靠的用途，就是帮你排除明显弱的选项。

如果一个模型连大家都已经普遍能过的线都过不了，就不要为它找借口了，直接 Pass。

2. 同档模型别纠结几个点

如果两个模型 SWE-bench Verified 是 72% 和 74%，LiveCodeBench 是 61% 和 63%，这几个点的差异未必能转化成真实体感。

原因很简单：

• 评测有方差；
• scaffold 会影响结果；
• 你的任务和题库不一样；
• 成本、速度、稳定性可能差很多；
• 模型输出风格也会影响协作体验。

同等级模型之间，几个百分点的 benchmark 差异，经常不如一次真实任务试用有意义。

3. 通用任务看性价比和速度

企业级别能落地的 LLM 的目标很现实：降本、提效、赚钱。

如果是通用任务，比如代码解释、小功能生成、简单 bug 修复、文档生成、SQL 辅助、脚本编写、常规数据处理，那么在能力同档的前提下，价格和速度非常重要。

这也是我个人很喜欢 DeepSeek 和 Mimo 系列的原因：它们未必在所有榜单上都拿第一，但在很多通用任务里，能力、价格和速度的组合很有竞争力。

企业做模型选型时，应该多问几个现实问题：

• 单任务成本是多少？
• 延迟是否影响开发者工作流？
• API 是否稳定？
• 上下文长度是否够用？
• 是否容易接入现有 IDE、CI、代码仓库？
• 数据安全和合规能不能接受？
• 最后到底省了多少人力？

这些问题的优先级，经常比榜单上多 2 分更高。

4. 专项任务走两个极端

如果是专项任务，比如大型代码迁移、安全漏洞修复、复杂重构、生产事故定位、多仓库联动修改、企业内部 coding agent，那么选型逻辑反而更极端。

第一种情况，任务失败成本很高，那就选最能完成任务的模型。贵一点也值得，因为失败一次的时间和机会成本可能比 token 贵得多。

第二种情况，任务可以拆小、可验证、可自动重试，那就选“能完成任务的最低成本模型”，甚至自部署模型。比如大量生成测试、批量改格式、规则明确的迁移，就可以用便宜模型加自动验证来堆吞吐。

专项任务不要看平均分，要看“这个模型能不能稳定完成我的任务”。

要么买最强，要么买刚好够用的最便宜。中间档经常最尴尬。

最该做的：建自己的小测试集

无论是企业用户还是个人用户，最推荐的做法是构建自己的小型测试集，少把精力耗在天天追 leaderboard 上。

不用很大，20 到 100 个真实任务就够有用了（个人可以 2-5 个）。

这些任务可以从过去一个月的真实工作里抽样，常见 bug fix、小功能实现、单元测试生成、代码 review、SQL / 数据处理、文档补全、迁移任务、重构任务、线上问题排查等等。

然后给每类任务设定评分标准：

• 是否通过测试；
• 是否符合业务逻辑；
• 是否引入新风险；
• 代码是否可维护；
• 需要几轮人工干预；
• 单任务成本；
• 端到端耗时；
• review 成本是否下降。

注意，这个测试集不是为了让你变成评测博主。构建自己测试集的目的，是快速做采购和工程决策。

不要把时间浪费在“测遍全世界所有模型”上。选 3 到 5 个候选模型，拿你自己的任务跑一遍，很快就能看出差异。

这里有一个很实用的原则：

最好的 benchmark 往往来自你/你们公司上个月最烦人的 5/50 个真实任务。

结语

Anthropic 这次 Fable 5 在 SWE-bench Pro 上的成绩，确实说明前沿 coding model 又往前走了一步。

但越接近真实工程，benchmark 就越复杂。它测到的不只是模型能力，还包括 agent 框架、工具链、预算、prompt、测试环境和产品工程能力。

最后，谁试了最新的 Fable 5，能不能留下真实的反馈，让大家看看是不是跑分怪？