HumanEval 衡量了 AI 能否编程，却从未问过代码是否真正工作

HumanEval 要求模型根据文档字符串完成一个 Python 函数，然后检查输出结果是否通过单元测试。这是一个简洁的设置：164 个问题，明确的通过/不通过判定，无需人工评审。正是这种简洁性，使其在整个代码生成大语言模型的早期浪潮中，成为了衡量“这个模型能编码吗”这一说法的参考基准。

但也正是这一点，让它不再有用。这些问题简短、自包含，且年代已久，足以被复制、讨论并在公共仓库中被解决成千上万次。对代码模型记忆能力的研究发现，模型大小与逐字复现已知解决方案的能力之间存在直接关系, , 这与破坏 MMLU 和 GSM8K 的污染模式相同，只不过对象从琐事变成了代码。一个模型可能仅仅因为记住了这些 164 个问题的相近变体就能通过 HumanEval，而这一技能却无法迁移到它从未见过的任何一行代码上。

真正的差距：玩具函数 vs. 真实仓库

然而，更深层的问题并非污染，而是范围。HumanEval 的问题属于早期编程面试中常见的那种：写一个反转字符串的函数，写一个检查数字是否为质数的函数。专业地编写软件与此截然不同。它意味着理解现有代码库、跨多个文件追踪 bug、尊重他人设计的 API，以及不破坏由别人编写的测试。

SWE-bench 正是为了缩小这一差距而构建的，它评估模型处理真实 GitHub 问题的能力，而非合成函数。结果对 HumanEval 时代的叙事并不友好。那些在孤立函数补全上表现强劲的模型，一旦被要求解决实际仓库中的真正票据，其成功率便急剧下降，尤其是在那些无法依赖记忆的私有、近期创建的代码库上。顶级模型在公开、经过筛选的 SWE-bench 问题上通过率可达 70% 到 95%，而同一级别的模型在 SWE-bench Pro 的私有仓库上通过率骤降至约 23%，在其秘密保留集上则更低。这一崩盘才是 HumanEval 从未打算揭示的真实故事。

HumanEval 仍有用的地方

作为一个五分钟的快速冒烟测试，它仍然有效：如果一个模型连反转字符串的函数都无法完成，那肯定出了大问题。但作为某个模型可以被信任用于生产代码库的证据，它从未衡量过大家以为它在衡量的东西。行业向 SWE-bench 的转变，以及向那些测试工具使用和多文件编辑（而非单函数补全）的智能体基准的转变，无异于默认：HumanEval 所回答的问题，远比人们一直在问的问题要狭隘得多。