AI Coding 模型能力如何衡量？从 Benchmark 到真实工程评估

两个模型、六张榜单，看完还是不知道怎么选

你准备给 Claude Code、Codex、Cursor 或内部 Agent 选择一个模型。网上很快就能找到各种说法：

• 模型 A 在某个编码榜单上排名第一；
• 模型 B 做前端的效果更好；
• 模型 C 虽然慢，但推理能力更强；
• 模型 D 价格低，所以“性价比最高”。

数字看起来很精确，却没有回答真正的问题：

我平时主要修 Bug、改接口、补测试，哪个模型更容易交付真正可以合并的代码？

要回答它，得先把 Benchmark 这个词讲明白。然后我们再看看主流模型得分网站究竟在比较什么，最后拿自己已经完成过的工程任务，做一次小而有用的模型测试。

一、Benchmark 是什么？可以把它理解成“模型考试”

Benchmark 没有那么神秘。它通常就是三样东西：

一套题目或任务
+ 所有候选者共同遵守的考试规则
+ 一套评分方法

假设一场考试有 100 道编程题。每道题描述一个需要实现的函数，模型生成代码，后台运行模型看不到的测试；通过一题，就得到一题的分数。如果最终完成 65 道，成绩可能就是 65%。

但这不代表它能完成你公司 65% 的开发工作。它只代表：在这套题目和规则下，它取得了这个成绩。

Benchmark 和排行榜不是一回事

Benchmark 是试卷和考试规则，排行榜是考试成绩单。

排行榜可以帮助我们缩小候选范围，测试方法才能告诉我们这场比较对自己的选型有没有意义。

pass@1 和 pass@5 不能直接比较

在模型榜单里，经常能看到 pass@1、pass@5：

• pass@1 关注第一次提交的答案能不能工作；
• pass@5 会从多次采样里观察是否至少出现一个可用答案，正式计算时通常还会使用相应的统计估计方法。

最早介绍 HumanEval 的研究论文已经展示了重复采样对结果的明显影响。如果产品会同时生成很多候选答案并自动测试，这种能力当然有价值；可如果你只准备支付一次调用、审查一个 Patch，它就不是同一种使用体验。

所以，不要拿别人的 pass@5 和另一张表里的 pass@1 直接比较。

二、常见的 AI Coding Benchmark 分别在考什么？

“编码得分”这个说法太模糊了。下面这些常见 Benchmark，考察的是范围逐渐扩大的几类工作。

HumanEval：像一场函数编程小测验

HumanEval 最初用于测试模型根据函数说明生成正确程序的能力。一道题通常比较独立：读懂函数说明、补全代码、通过测试。

这类题容易理解，也容易自动评分。但是模型不需要在大型仓库里搜索，不需要理解模糊需求，也不需要处理项目本身构建失败的问题。

LiveCodeBench：用较新的竞赛题测试编程能力

LiveCodeBench会持续收集编程竞赛题，并按照题目发布时间划分数据版本。除了代码生成，项目还关注代码执行、Self-repair 和预测测试输出等相关能力。使用持续更新的题目时间窗口，是为了降低陈旧公开题目已经进入训练数据所带来的影响。

它适合观察算法编程和代码推理能力，但竞赛题依然比维护一家公司的业务系统更干净、更独立。

SWE-bench：让 Agent 进入真实仓库修问题

SWE-bench会给 Agent 一个真实 GitHub 仓库和 Issue 描述，让它生成修复 Patch，再通过测试判断问题有没有解决、原有功能有没有被破坏。官方项目把 SWE-bench Verified 描述为经过人工验证的子集，并使用容器环境提高评估的可复现性。

这已经很接近“进入仓库修 Bug”。不过，它反映的仍然是 Benchmark 选择的仓库、语言、Issue、测试环境和 Agent 配置，不是你的私有项目。

Terminal-Bench：让 Agent 真正在终端里完成任务

Terminal-Bench评估的是终端环境中的 Agent。它可能需要查看文件、运行命令、配置软件、分析错误，再验证最终状态。

这时候，成绩已经不只取决于模型回答。Agent 的工具、命令循环、运行环境、超时设置和失败恢复方式都会影响结果。

把它们压缩成四句话：

HumanEval       → 能不能写对这个函数？
LiveCodeBench   → 能不能解决较新的编程题？
SWE-bench       → 能不能修复这个仓库 Issue？
Terminal-Bench  → 这个 Agent 能不能完成终端任务？

先弄清楚它问的是什么，分数才有意义。

三、去哪里看比较可信、更新较及时的模型成绩？

下面这些网站在 2026 年 8 月 17 日进行了核对。排名和收录模型会继续变化，所以本文不复制一份很快过期的“当前前十名”。真正需要比较时，应该打开实时网站，把分数和方法一起看。

这张表故意放进了三种不同证据：

• 项目维护者或研究机构的榜单，说明候选者在一套明确测试里的表现；
• 人类偏好竞技场，说明用户更喜欢两份输出中的哪一份；
• 商业聚合评测网站，方便把能力、价格和速度放到一起浏览。

它们都有价值，但不能互相替代。

例如，Artificial Analysis 会公开综合 Intelligence Index 的组成、权重和测试方法，同时也分别提供价格、速度和其他指标。这让它很适合做候选初筛，但综合分依然反映的是它的权重选择，不是你的业务优先级。

LMArena 则根据用户对匿名模型回答的两两投票形成排名。这能反映人们觉得哪份回答更好、更自然，可一段很讨喜的代码解释赢得投票，并不表示代码已经在你的测试环境里运行通过。

四、同一个模型，为什么换个 AI Coding 工具就不一样？

可以把底层模型想成发动机，把 Claude Code、Codex、Cursor、Aider 等 AI Coding Agent 想成整辆车。

工具会决定：

• 哪些项目规则和文件进入上下文；
• 怎样搜索仓库；
• 可以使用哪些 Shell、浏览器和 MCP 工具；
• 工具结果怎样返回给模型；
• 历史太长时怎样压缩；
• 一步失败后会不会重试；
• 最长允许任务运行多久。

所以，很多现代榜单真正比较的是一整条路线：

模型版本 + Agent + 工具 + 指令 + 运行预算 + 评分器

这和上一篇 AI Gateway 文章是一脉相承的：调用路线不能只看一个模型名称，评估对象也不能只剩一个模型名称。

某套 Agent 在 SWE-bench 上取得高分，不代表把同一个底层模型直接塞进另一个客户端，就一定能重现结果。

五、看到排行榜的一行成绩，先问六个问题

不要先盯第一名。打开测试方法，逐个检查下面的问题。

1. 它考的是什么任务？

补函数、做竞赛题、修 GitHub Issue、管理终端，还是比较人类偏好？

2. 参赛的到底是谁？

是一个模型 API，还是带着搜索、工具和重试的完整 Agent？

3. 模型版本和测试日期是什么？

会滚动更新的别名不容易复现。明确的模型 Snapshot 和测试日期更有参考价值。

4. 每道题允许尝试几次？

第一次完成、允许两轮修改、采样上百个答案，成本和体验完全不同。

5. 给了多少时间、Token 和工具？

如果更高的分数是用更多时间和 Token 换来的，它仍然可能值得，但这是另一种成本选择。

6. 最后由谁判分？

隐藏测试、精确答案、LLM Judge 和人类投票，各自衡量的东西不一样。OpenAI 官方的评估最佳实践也建议把量化指标与人工判断结合起来，让测试贴近真实任务，并用人工反馈校准自动评分。

可以把阅读卡压缩成一行：

任务 · 参赛对象 · 版本 · 尝试次数 · 预算 · 评分方式 · 日期

如果两条成绩在这些字段上差异很大，百分比往往不能直接比较。

六、为什么榜单第一，到了你的项目里不一定最好？

公开测试里的任务可能是：

• 来自开源仓库、描述清楚的 Python Issue；
• 环境干净，测试命令已经准备好；
• 通过隐藏测试决定成败；
• 不需要参加需求会议，也没有真人 Reviewer 追问设计。

而你的实际工作可能是：

• Java、Go、PHP 或多语言 Monorepo；
• 使用公开训练数据里没有的内部框架；
• 需求只有两句话，还有关键决定没说清楚；
• 原本没有回归测试，需要 Agent 自己补；
• 必须遵守权限、数据和发布规范；
• Reviewer 很在意修改范围和长期维护成本。

METR 在自己的 Time Horizon 结果里也明确写出了类似边界：它的任务主要是自包含、描述清楚的软件工程、机器学习和网络安全任务。其 FAQ 特别提醒，这些结果更接近“一个能力不错但缺少项目背景的外部工程师”，不等于熟悉项目多年的同事能做的日常工作。

所以，公开分数依然有用：它告诉你哪些候选者值得安排一次试做。最后是否录用，要看自己的项目。

七、一个 Bug 就能看出“完成”到底是什么意思

假设团队遇到下面这个问题：

导出的 CSV 包含中文时，用 Excel 打开会乱码。找到原因、修好它，并补一个回归测试。

两条假设的模型路线拿到相同仓库版本、任务描述、项目规则、工具和时间限制。

路线 A

它很快找到导出代码，直接修改了应用的全局响应编码。新测试通过了，但其他下载接口也受到了影响。Reviewer 要求重写。

路线 B

它先查看 CSV 导出路径和现有测试，只修改了 CSV 响应，并增加一条聚焦中文内容的回归测试。Patch 更小，也通过了 Review。

如果评分器只检查新增测试，两条路线都算“通过”。真实工程里的成功要更严格：

需求实现
+ 测试通过
+ 没有不可接受的副作用
+ 人工 Review 接受

八、拿 10～20 个历史任务，做一次自己的小评测

开始时不需要搭建专业评估平台。

第一步：选已经做过的任务，不要重新编算法题

从最近的 Issue 和 PR 里挑一组有代表性的任务：

• 3 个简单 Bug；
• 3 个跨文件修改；
• 2 个补回归测试的任务；
• 2 个必须保持行为不变的重构；
• 2 个团队经常遇到的依赖、配置、前端或浏览器问题。

10～20 个任务无法产生适用于全世界的科学排名，但足以在全员切换模型之前，发现明显的不适配。

第二步：给每个任务写清楚验收条件

例如 CSV 乱码任务：

1. 中文内容可以正确打开；
2. 原有导出行为不受影响；
3. 增加一条回归测试；
4. 不修改无关下载接口；
5. 相关测试全部通过。

第三步：让候选模型使用相同考试条件

保持下面这些内容一致：

• 仓库 Commit；
• 任务描述；
• 项目规则；
• 工具和权限；
• 时间限制；
• 重试或最大轮次。

同时记录明确的模型版本和客户端版本。如果路线 A 可以使用浏览器并重试三次，路线 B 两样都没有，那么测出来的差异就不只是模型差异。

第四步：记录一张小表格

不要急着计算一个“综合智能得分”。先回答三个最有用的问题：

1. 最终有多少任务得到了可以接受的 Patch？
2. 哪类任务总是需要返工？
3. 得到一个真正可以合并的修改，花了多少模型费用和人工时间？

第五步：重要任务多跑几次

模型输出会波动。高价值任务可以重复两三次，看看是否会偶尔产生危险修改、成本是否大幅波动、失败后能不能恢复，而不是只挑表现最好的一次。

九、别把自己的评测也做成另一张误导人的榜单

常见问题都很普通：

• 只选了五道简单题；
• 给其中一个模型写了更清楚的提示；
• 拿一次尝试和多次尝试的结果比较；
• 测试本身不稳定，却把失败记到模型头上；
• 只要生成了代码，就算任务完成；
• 围绕同一批公开任务反复调整 Prompt；
• 只汇报最好的一次，不保存失败结果；
• 因为人工时间不在 API 账单里，就完全忽略 Review 成本。

评分时优先使用可重复的证据：测试、类型检查、Lint、安全扫描、禁止路径检查和最终 Diff；再用一张简短的人工表格检查修改范围、可维护性和风险。

LLM Judge 可以帮助扩大评估规模，但要先拿人工结果校准。模型裁判也可能偏爱更长的回答，或者受两个答案前后顺序影响。

对小团队来说，先守住这条最低标准就够了：

同一仓库 · 同一规则 · 同一预算 · 重复运行 · 自动测试 + 人工 Review

十、最后通常不是选出一个“全能冠军”

评测结果很可能是：

• 便宜路线适合搜索、摘要和简单测试；
• 默认路线适合普通功能与 Bug；
• 强模型路线在跨模块排错时更值得花钱；
• 权限、数据和安全修改依然必须经过人工确认。

最后形成的应该是一套容易执行的规则：

搜索与样板代码       → 经济路线
普通功能和 Bug       → 默认路线
复杂排错             → 强模型路线
敏感修改             → 强模型 + 人工批准
连续失败             → 明确升级，不要静默死循环

这就是评估与 AI Gateway 治理真正连接起来的地方：网关不应该按照市场宣传排名来路由，而应该根据团队真实工作积累下来的证据来路由。

十一、什么时候应该重新评测？

下面这些变化发生后，旧成绩可能已经不能代表当前体验：

• 模型 Snapshot 或 Reasoning 配置改变；
• 更换或升级 Claude Code、Codex、Cursor、Aider；
• 修改 AGENTS.md、项目 Rules 或系统 Prompt；
• 新增 Shell、浏览器、MCP 或搜索工具；
• 调整上下文压缩、Token、超时或重试限制；
• AI Gateway 改变路由或 Fallback；
• 项目主要语言或架构发生明显变化。

不需要因为一处小配置就把所有任务重跑一遍。可以保留一组快速 Smoke Test，在改变默认路线前运行完整任务集，再用低风险任务做小流量试用。

OpenAI 的官方评估指南也把评估描述为持续过程：定义成功、收集相关数据、选择指标、比较结果，并不断把真实失败补充到测试集里。

验证清单

选择一条模型路线之前，确认自己能回答：

• 公开 Benchmark 里是什么任务？
• 榜单那一行是裸模型、Agent，还是完整产品配置？
• 模型版本、日期、尝试次数、预算和评分方式是否公开？
• 比较的是同样的 pass@1 吗？
• 公开题目与自己的语言和仓库有什么差异？
• 是否选出了 10～20 个已经完成的内部任务？
• 每个任务是否有验收条件和固定仓库版本？
• 是否记录了测试、返工、成本、运行时间和 Review 时间？
• 重要任务是否重复运行过？
• 最终结果能否转化成简单、明确的模型路由规则？

Benchmark 帮你找到候选，真实任务帮你作决定

Benchmark 就是一场考试。它有用，是因为所有候选者面对一套明确任务和评分方式。只有当我们忘记考试究竟考了什么，它才容易误导人。

先用实时榜单了解当前候选模型，先读方法，再看名次；然后把值得考虑的候选路线带进自己的项目，做一次小而公平的试做。

问题最终会从“哪个模型天下第一”，变成：

对于这类任务，哪条模型路线能稳定产生可以接受的修改，并且成本和风险都在我们愿意承担的范围内？

这个答案没有全球排行榜那么刺激，却对团队有用得多。

权威资料

• HumanEval 论文：Evaluating Large Language Models Trained on Code：函数代码生成、功能正确性和重复采样。
• SWE-bench 官方仓库与排行榜：真实仓库 Issue、评估环境与项目维护结果。
• LiveCodeBench 官方仓库与排行榜：按时间划分的编程题和多种代码能力测试。
• Terminal-Bench 排行榜：终端 Agent 任务比较。
• Aider LLM Leaderboards：代码编辑成绩、成本、运行命令、版本和 Polyglot 测试说明。
• METR Task-Completion Time Horizons：任务长度测量方法与明确的解释边界。
• OpenAI 评估最佳实践：任务化评估、人工校准、评分器和持续评估。
• LMArena与 Artificial Analysis 方法说明：分别代表人类偏好比较与独立综合评测。