AI编程能力评估全景：从HumanEval到SWE-bench，基准测试的演进与选择

版权声明与免责声明 本文基于 HumanEval、SWE-bench、LiveCodeBench、APPS、CodeContests、EvalPlus、Aider Leaderboards 等公开资料进行综合解读。原文版权归各自作者与研究机构所有。

原文参考

• HumanEval — OpenAI: https://github.com/openai/human-eval
• SWE-bench — Princeton/UCB: https://www.swebench.com/
• LiveCodeBench — UCB/MIT/Cornell: https://livecodebench.github.io/
• APPS — Stanford: https://github.com/hendrycks/apps
• CodeContests — DeepMind: https://github.com/deepmind/code_contests
• Aider Leaderboards — Paul Gauthier: https://aider.chat/docs/leaderboards/

原创性质 本文不是逐基准的摘要合集，而是通过并置多来源、提炼评估维度和选择框架，帮助读者建立系统化的基准测试认知。

---

开头：基准测试不是榜单，而是测量边界的工具

如果你已经接受第 1 篇的判断：开发者不能只做 AI 编程助手的使用者，还要承担 Coding Mentor 的角色，那么很快会遇到第二个问题：你用什么来判断 AI 的能力边界？

只看一次输出是否能跑，不够。只看模型厂商的演示，不够。只看社区口碑，也不够。AI 编程能力不是一个单一分数，它至少包含函数生成、算法推理、代码编辑、真实仓库修复、测试生成、错误定位、上下文利用、成本和稳定性等多个维度。

公开基准测试的价值正在这里。HumanEval、APPS、CodeContests、SWE-bench、LiveCodeBench、Aider Leaderboards 不是给读者提供一个“谁最强”的永久答案，而是提供一组测量方法：不同基准把 AI 放进不同任务环境里，看它在什么条件下可靠，又在什么条件下失效。

阅读基准测试时，最重要的不是记住某个榜单排名，而是回答三个问题：

问题	为什么重要
这个基准实际测的是什么任务	同样叫“代码能力”，函数生成和真实仓库修复不是一类能力
这个基准没有测什么	未覆盖的部分，不能从分数里推断出来
它能否迁移到你的团队场景	公开分数只能做外部参照，不能替代私有 eval

这篇文章会按这个读法展开。你会看到基准如何从小函数题演进到真实 GitHub issue，看到不同基准适合回答哪些问题，也会看到怎样把公开基准转化为团队自己的评估集。

六类基准的全景对比

公开基准的发展路径，可以粗略理解为从“函数级正确性”走向“真实工程任务”。这不是简单的难度升级，而是评估对象发生了变化：从单个函数，到算法竞赛题，到真实仓库里的 issue，再到持续更新和代码编辑场景。

基准	发布/维护方	核心任务	主要回答的问题	典型盲区
HumanEval	OpenAI	根据函数签名和说明补全 Python 函数	模型是否具备基础函数生成能力	上下文、工程约束和污染风险
EvalPlus	社区维护	扩展 HumanEval/MBPP 测试用例	原有函数题是否被薄弱测试高估	仍以函数级任务为主
APPS	Stanford	竞赛风格编程题	模型是否具备算法推理和复杂输入处理能力	竞赛能力不等于工程能力
CodeContests	DeepMind	编程竞赛题和多语言提交	模型能否处理高难度算法挑战	缺少真实代码库维护语境
SWE-bench	Princeton/UCB	在真实开源仓库中修复 issue	模型能否理解代码库并生成可验证补丁	环境成本高，任务分布仍有边界
LiveCodeBench	UCB/MIT/Cornell	持续收集新题并按时间切片评估	模型是否在新题上仍然可靠	更偏编程题，不等价于企业代码库
Aider Leaderboards	Paul Gauthier	在代码库上下文中进行代码编辑	模型是否适合日常编辑和多语言修改	结果依赖工具工作流和任务设定

这张表有一个重要结论：没有一个公开基准可以单独代表“AI 编程能力”。每个基准都在测一个切面。把多个切面叠在一起，才可能接近你真正关心的能力边界。

HumanEval：函数级生成能力的起点

HumanEval 的历史意义在于，它把“模型会不会写代码”变成了一个可重复评估的问题。每道题给出函数签名、文档字符串和少量示例，模型需要补全函数实现，再由隐藏测试判断是否通过。

它适合回答一个很窄但很基础的问题：模型能不能在明确输入输出下写出一个独立函数。

设计点	对读者的启发
任务很小	基础能力评估应该先从可隔离任务开始
测试自动化	评估结论必须由可重复测试支撑
使用 pass@k	代码生成具有随机性，单次失败不等于完全不会
隐藏测试	不能只根据公开示例判断正确性

HumanEval 也有明显局限。题目数量有限，流传时间长，数据污染风险高；任务都以独立函数为主，不能代表真实代码库里的依赖、状态、兼容性和架构约束；语言范围也较窄。EvalPlus 通过补充更强测试用例，缓解了原测试过弱的问题，但没有改变函数级评估的基本性质。

对于 Coding Mentor 来说，HumanEval 的价值不是让你照搬 164 道题，而是提醒你：最小评估单元必须有清晰契约和自动验收。你在团队内部设计 eval 种子集时，也需要先有一批“边界明确、成本低、可重复”的基础任务，用来快速发现模型的下限。

APPS 与 CodeContests：算法挑战能测什么，不能测什么

APPS 和 CodeContests 把评估推进到竞赛级编程题。相比 HumanEval，这类任务通常有更复杂的题面、更大的输入范围、更严格的时间限制，也更依赖算法组合和边界处理。

它们适合回答的问题是：模型是否具备复杂推理、算法选择和高强度测试通过能力。

价值	解释
难度分层清晰	竞赛题天然有入门、竞赛、奥赛等难度差异
测试用例更强	很多题经过大量选手提交和边界打磨
能暴露推理短板	复杂约束、极值输入和组合算法会让模型更容易失误

但工程读者不能把竞赛能力等同于软件工程能力。竞赛题通常追求在限定时间内给出一个能 AC 的解法，真实工程更关心可维护性、可读性、局部修改、兼容性、安全约束和长期演进。一个模型擅长竞赛题，不代表它能在你的业务代码里安全改动权限逻辑；一个模型竞赛排名一般，也不代表它不能帮助补测试、改文档或完成局部重构。

所以这类基准更适合用来做“复杂推理压力测试”，而不是作为企业选型的唯一依据。

SWE-bench：从写代码走向修真实问题

SWE-bench 的关键变化，是把评估从“写一个函数”转向“修一个真实仓库里的 issue”。模型拿到 issue 描述和代码库上下文，需要定位相关文件、理解失败原因、生成补丁，并通过测试验证。

这类任务更接近真实软件工程，因为它同时考察多个能力：

能力	SWE-bench 中的体现
需求理解	从 issue 描述中识别真正要修复的问题
代码导航	在多文件代码库里找到相关调用链
根因分析	区分表面报错和真正失败原因
最小修复	修改必要位置，避免大范围无关重构
回归意识	修复目标问题时不能破坏已有行为

它对 Coding Mentor 的启发非常直接：如果你要评估 AI 是否能参与真实交付，不能只给它独立题目，必须把它放进代码库、issue、测试和 review 约束里。

不过，SWE-bench 也不是生产环境的完整镜像。它依赖特定开源项目和可复现测试环境，任务分布不等于你的业务分布，榜单结果也会受到 agent 框架、工具调用、上下文策略和评估配置影响。读 SWE-bench 时，不要只看解决率，还要看任务设置、是否是 Verified 子集、是否使用额外工具、是否允许多轮修复，以及失败样本集中在哪些类型。

LiveCodeBench：为什么时间切片很重要

当一个公开基准被反复用于训练、调参和宣传时，它就会面临数据污染问题。模型在旧题上表现好，可能是能力提升，也可能是训练中见过相似题。LiveCodeBench 的重要价值，是把时间维度引入评估：持续收集新发布题目，并按发布时间切片观察模型表现。

这对读者有两个启发。

第一，公开分数要看时间。一个模型在早期题目上表现很好，不一定能说明它面对新题仍然可靠。对于训练截止日期后的题目，模型更难依赖记忆，只能更多依赖真实推理和生成能力。

第二，任务类型要分开看。代码生成、自我修复、代码执行预测、测试输出预测不是同一个能力。某个模型可能很会生成解法，但不擅长预测已有代码运行结果；也可能能修小错误，但不擅长从空白开始构造完整方案。

Coding Mentor 在团队内部做评估时，也应该保留时间切片思维。不要让评估集多年不变，也不要把所有任务混成一个总分。新增需求、最近事故、刚修复的缺陷、近期代码规范变化，都应该定期进入候选任务池，经过治理后成为新的 eval 样本。

Aider Leaderboards：代码编辑比从零生成更接近日常开发

很多真实开发工作不是从零写代码，而是在现有代码上做编辑：修改一个接口、补一个测试、迁移一个 API、调整一个配置、修复一个回归。Aider Leaderboards 关注的正是这种编辑能力。

代码编辑任务和函数生成任务有本质差别：

维度	从零生成	代码编辑
输入	需求说明和少量上下文	现有文件、调用关系、修改指令
风险	生成结果可能不完整	修改可能破坏既有行为
关键能力	补全、推理、语法正确	定位、局部修改、保持风格、减少无关 diff
验证方式	单元测试或样例测试	测试、diff 审查、回归检查

如果你的团队主要使用 AI 做日常代码修改，代码编辑基准比纯生成基准更有参考价值。但它仍然不能替代私有评估，因为编辑成功率强依赖工具链、上下文注入方式、语言生态和任务类型。

对 Coding Mentor 来说，Aider 这类榜单的意义在于提醒团队：不要只评估“能不能写”，还要评估“能不能少改、改准、改完可验证”。

如何选择适合自己场景的基准

读基准时，建议先从“你要做什么决策”出发，而不是从“哪个榜单更热门”出发。不同决策需要不同证据。

你的问题	首选公开参照	还需要内部补充什么
模型是否具备基础代码生成能力	HumanEval / EvalPlus	团队常用语言和框架的小任务
模型是否能处理复杂算法和边界	APPS / CodeContests	与业务相关的数据结构、性能和极值输入
模型是否能修真实仓库问题	SWE-bench / SWE-bench Verified	团队历史 bugfix、测试逃逸和 review 退回样本
模型是否被旧题高估	LiveCodeBench	新近需求、新近故障和近期规范变化
模型是否适合日常代码编辑	Aider Leaderboards	真实代码库中的局部修改和多语言任务
是否可以采购或切换工具	多基准交叉参考	成本、延迟、安全、权限、数据治理和开发者体验

选择基准时，有一个简单原则：公开基准回答“这个模型在外部参照中处于什么位置”，私有 eval 回答“这个模型能否进入我们的交付流程”。两个问题都重要，但不能互相替代。

指标选择：不要被一个总分带走

很多榜单会给出总分或通过率，但团队真正需要的是能力剖面。总分越高，越容易掩盖局部风险。一个模型可能在函数生成上很强，在真实仓库定位上较弱；也可能编辑成功率高，但成本和延迟不适合大规模使用。

指标	适合衡量什么	容易误导的地方
pass@k	多次采样下通过测试的概率	不代表代码质量、可维护性和安全性
solve rate	真实任务端到端解决率	二值化结果会掩盖失败原因
edit success rate	代码编辑任务是否成功	依赖工具链和任务设定
regression rate	修改是否破坏既有行为	需要足够强的测试集
cost / latency	单任务交付成本和等待时间	不能单独代表质量
human review load	人工审查和返工成本	需要团队长期记录

面向 Coding Mentor 的评估报告，最好不要只输出一个排名，而要输出能力剖面：

能力维度	需要记录的证据
功能正确性	测试通过率、失败用例、修复后验证结果
上下文利用	是否找到正确文件，是否理解调用链和已有约束
修改最小性	diff 范围、无关改动比例、是否引入额外依赖
质量风险	并发、安全、性能、兼容和可维护性问题
协作成本	提示轮次、人工修改量、review 退回原因

这样的报告比“模型 A 比模型 B 高 3 分”更有工程价值，因为它能直接决定 AI 应该在哪些任务上深度参与，在哪些任务上只做草稿，在哪些任务上必须退出。

如何把公开基准转化为团队私有 eval

公开基准不能直接解决团队问题，但可以提供设计原则。团队内部评估集不需要一开始很大，关键是任务来自真实工作，并且每个样本都能被验证、被复盘、被路由。

一个可落地的私有 eval，可以从 30 到 60 个任务开始，覆盖四类样本：

样本类型	来源	评估重点
小功能实现	最近完成的低风险需求	需求理解、实现完整性、测试意识
缺陷修复	历史 bug、测试逃逸、线上事故复盘	根因定位、最小修复、回归风险
测试补强	过去遗漏的边界条件	边界识别、用例设计、断言质量
代码审查	review 退回、架构约束违反、安全问题	风险识别、解释能力、修正建议

每个任务至少要保留六类信息：

字段	作用
任务描述	明确模型要解决什么，不解决什么
代码版本	保证任务可以复现
上下文边界	说明允许访问哪些文件、文档和工具
验收标准	定义什么叫通过、部分通过、失败
参考修复或参考反馈	作为人工评审和后续训练候选的依据
敏感数据处理结果	防止私有数据、凭证和客户信息进入评估或训练

这里的目标不是复刻 SWE-bench，而是学习它的精神：让模型进入真实上下文，用可验证证据判断结果。团队内部的 eval 必须更贴近自己的语言栈、框架、编码规范、发布流程和风险边界。

读榜的正确姿势：先看任务定义，再看排名

截至 2026-03，模型发布节奏、推理模式、工具调用能力和计费方式都在快速变化。任何文章都不应该把某一次榜单截图写成长期结论。更稳妥的做法，是记录读榜方法。

评估入口	读榜重点	适合回答的问题
HumanEval / EvalPlus	是否接近饱和、是否有更强测试、是否存在污染风险	模型基础函数生成能力是否过关
SWE-bench Verified	issue 来源、验证方式、agent 设置、是否允许额外工具	模型能否处理真实仓库修复
LiveCodeBench	发布时间切片、任务类别、训练截止日期之后的表现	模型是否在新题上仍然可靠
Aider Leaderboards	多语言编辑成功率、成本、上下文策略	模型是否适合日常代码编辑
团队私有 eval	业务语言、框架、安全规则、review 退回和成本	模型是否适合进入你的交付流程

读榜顺序建议固定为四步：

步骤	判断问题
先看任务定义	这个榜单到底测什么，不测什么
再看评估配置	模型是否使用工具、agent、额外上下文和多次尝试
再看失败样本	失败集中在理解、定位、实现、测试还是回归
最后做私有复验	结果能否迁移到团队真实任务

如果跳过前三步，只看排名，很容易把外部榜单误读成内部采购结论。

能力边界：公开基准共同揭示了什么

把这些基准放在一起看，可以得到一个更稳健的判断：AI 编程能力已经足以承担大量局部任务，但还不能脱离人类 Mentor 的任务契约、评估标准和验收机制。

AI 通常更擅长：

场景	原因
明确输入输出的小函数	任务边界清楚，测试容易自动化
常见算法和数据结构	训练语料丰富，模式稳定
局部代码编辑	修改范围可控，反馈周期短
标准错误修复	报错、堆栈和常见修复模式较明确

AI 通常更容易失误：

场景	风险
模糊业务语义	模型容易补全看似合理但不符合业务的假设
跨模块架构变化	上下文不完整时容易破坏隐性约束
性能敏感路径	正确性通过不代表资源消耗可接受
安全与权限边界	小改动可能扩大访问范围或绕过校验
低测试覆盖代码库	没有强验证时，错误更难被及时发现

这正好回到本系列主线：基准测试给你外部镜子，Coding Mentor 给你内部判断系统。没有基准，你容易凭感觉选模型；只有基准，你又容易把公共分数误当成生产可信度。

结语：基准是入口，私有 eval 才是落点

公开基准的价值，不在于替团队做最终决策，而在于帮助你建立测量语言。HumanEval 告诉你函数级任务如何自动评估，APPS 和 CodeContests 告诉你复杂推理如何施压，SWE-bench 告诉你真实仓库任务必须进入上下文和测试闭环，LiveCodeBench 告诉你时间切片和污染控制的重要性，Aider 告诉你代码编辑能力应该被单独测量。

但 Coding Mentor 的最终工作，是把这些公共经验转化为团队自己的评估系统：

公共基准提供	团队需要补齐
标准任务范式	真实业务任务和代码库上下文
自动化验证思路	团队验收标准和 review 规则
能力边界参照	私有风险边界和使用策略
模型横向比较	成本、延迟、安全和治理决策

所以，第 2 篇的结论很简单：不要迷信榜单，也不要忽视榜单。公开基准负责帮你看见 AI 编程能力的外部边界，私有 eval 负责回答它能否进入你的工程交付流程。

下一步进入第 3 篇时，问题会进一步收窄：既然公开基准不能直接替代团队评估，那么一套高质量的编程题目和任务样本应该怎样设计。

---

参考与致谢

• HumanEval — Chen et al., OpenAI: https://github.com/openai/human-eval
• EvalPlus — EvalPlus contributors: https://github.com/evalplus/evalplus
• APPS — Hendrycks et al., Stanford: https://github.com/hendrycks/apps
• CodeContests — Li et al., DeepMind: https://github.com/deepmind/code_contests
• SWE-bench — Jimenez et al., Princeton/UCB: https://www.swebench.com/
• LiveCodeBench — Jain et al., UCB/MIT/Cornell: https://livecodebench.github.io/
• Aider Leaderboards — Paul Gauthier: https://aider.chat/docs/leaderboards/