一道简单题与一个真实Bug

你在HumanEval上测试一个模型：写一个函数判断回文串。它完美通过。你信心满满地把它接入开发流程。然后你让它修一个真实bug：在一个2000行的Python项目中，有一个边缘情况下索引越界的问题，需要定位到第743行的列表操作，修改逻辑，确保不破坏其他4个依赖该函数的模块。

它失败了。这就是HumanEval和SWE-bench之间的鸿沟。

HumanEval的三重局限

HumanEval由164道Python编程题组成，每道题平均不超过10行代码，函数签名和文档字符串都帮你写好了。你只需要生成函数体。这就像驾考科目一和实际开车之间的差距。

第一重局限：任务粒度过细。真实世界的编程任务不是"写一个函数"，而是"理解整个代码库，找到需要修改的位置，做出最小化改动，验证没有引入新bug"。HumanEval完全不测试代码理解、定位和修改能力。

第二重局限：语言单一。HumanEval只有Python。如果你用Java、Rust、TypeScript开发，HumanEval的分数对你毫无参考价值。

第三重局限：没有上下文。真实编程不是在空白文件里写代码，而是在数千行代码的上下文中做出精准修改。HumanEval剥离了所有上下文，测试的是"裸写"能力。

SWE-bench：更接近真实的评测

SWE-bench Verified从GitHub上的真实issue中提取了500个任务，要求模型在完整的代码仓库中定位bug、修改代码、通过测试。这比HumanEval难一个数量级。

2026年，SWE-bench Verified上的最佳成绩是Claude 4 Opus的53.2%。这意味着即使是最强的模型，在面对真实世界的软件工程任务时，也有一半的概率失败。

我们分析了失败的案例，发现三个主要失败模式：

  • 定位失败（35%）：模型找不到需要修改的代码位置
  • 修改不完整（30%）：修了一处但漏了关联的修改
  • 引入新bug（25%）：修改本身引入了新的问题
  • 其他（10%）：环境配置、依赖问题等

如何正确评测代码能力

如果你在选模型做代码工作，不要只看HumanEval。你应该：

  1. 用你自己的代码库做测试：提取10个历史bug，看模型能不能修
  2. 测试多文件修改场景：真实开发很少只改一个文件
  3. 关注Agent模式能力：模型能否自主搜索代码、执行命令、查看输出、迭代修复
  4. 测试代码审查能力：让模型review代码，看它能否发现潜在问题

一个残酷的事实：2026年，没有任何一个模型能独立完成超过50%的真实世界软件工程任务。AI编程助手是加速器，不是自动驾驶。 把它当作一个非常聪明的初级工程师来用，你会有惊喜；把它当作高级工程师来用，你会出事故。