引言
代码生成是 LLM 最成功的落地场景之一，但「能写代码」和「能解决工程问题」之间有巨大鸿沟。HumanEval 上的 90% 通过率并不意味着模型能胜任真实的软件工程工作。本文系统梳理 2026 年代码 LLM 评估从基础到工程级的完整体系。
一、基础代码生成评估
1.1 HumanEval
HumanEval 由 OpenAI 在 2021 年发布，是代码 LLM 评估的元老级 Benchmark。包含 164 个 Python 编程任务，每个任务包含函数签名、docstring 和测试用例。
评估方式： 给定函数签名和 docstring，模型生成函数体，用测试用例验证正确性。
Pass@k 指标：
Pass@k = 1 - C(n-c, k) / C(n, k)
其中 n 是总采样数，c 是通过测试的采样数，k 是允许的尝试次数。
2026 年头部模型 Pass@1：
| 模型 | HumanEval Pass@1 |
|---|---|
| GPT-5 | 96.2% |
| Claude 4 Opus | 95.8% |
| Gemini 2.5 Ultra | 94.1% |
| DeepSeek-Coder V2.5 | 93.5% |
| Llama 3.3 70B | 88.7% |
问题： HumanEval 已严重饱和，头部模型差距不到 8 个百分点，基本失去区分度。
1.2 MBPP
MBPP (Mostly Basic Python Problems) 包含 974 个基础 Python 编程题：
- 难度：入门级，比 HumanEval 更简单
- 饱和度：头部模型已达 95%+，基本无区分度
- 价值：仅适合评估小模型或作为 sanity check
1.3 MultiPL-E
MultiPL-E 将 HumanEval 和 MBPP 翻译到 18 种编程语言：
| 语言 | GPT-5 Pass@1 | Claude 4 Pass@1 | 说明 |
|---|---|---|---|
| Python | 96.2% | 95.8% | 最强 |
| JavaScript | 94.5% | 93.8% | 优秀 |
| Java | 92.1% | 91.5% | 良好 |
| C++ | 91.8% | 90.2% | 良好 |
| Go | 89.3% | 88.7% | 良好 |
| Rust | 85.7% | 84.2% | 中等 |
| R | 78.5% | 76.8% | 较弱 |
| Haskell | 72.3% | 68.5% | 弱 |
关键发现： 模型在 Python/JavaScript 上最强，在函数式语言（Haskell）上最弱。差距主要来自训练数据中的语言分布。
二、进阶代码评估
2.1 HumanEval+
HumanEval+ 在 HumanEval 基础上大幅扩展测试用例（平均每个任务从 8 个扩展到 100+ 个）：
| 模型 | HumanEval Pass@1 | HumanEval+ Pass@1 | 下降幅度 |
|---|---|---|---|
| GPT-5 | 96.2% | 89.5% | -6.7% |
| Claude 4 Opus | 95.8% | 88.2% | -7.6% |
| Gemini 2.5 Ultra | 94.1% | 84.3% | -9.8% |
分析： 下降幅度反映了模型代码的鲁棒性——通过基本测试不代表通过了边界条件测试。Gemini 下降最多，说明其代码的边界情况处理最差。
2.2 BigCodeBench
BigCodeBench 包含 1140 个更具挑战性的编程任务：
- 涉及标准库和第三方库的复杂使用
- 要求多步骤推理
- 测试用例更严格
头部模型表现：
| 模型 | BigCodeBench Pass@1 |
|---|---|
| GPT-5 | 78.5% |
| Claude 4 Opus | 76.2% |
| Gemini 2.5 Ultra | 71.8% |
| DeepSeek-Coder V2.5 | 69.3% |
2.3 LiveCodeBench
LiveCodeBench 持续从 LeetCode、Codeforces 等平台获取新题，避免数据污染：
- 更新频率：每月
- 核心价值：测量真实编码能力而非记忆
- 时间分界：可以按模型训练截止日期分组评估
2026 年 LiveCodeBench 表现：
| 模型 | 训练截止日期后题目 | 训练截止日期前题目 | 差距 |
|---|---|---|---|
| GPT-5 | 68.5% | 82.3% | -13.8% |
| Claude 4 Opus | 65.2% | 79.8% | -14.6% |
| Gemini 2.5 Ultra | 62.1% | 76.5% | -14.4% |
关键发现： 所有模型在训练截止日期后的题目上表现下降约 14 个百分点，说明之前的 Benchmark 分数有约 14% 的「水分」来自数据记忆。
三、SWE-Bench：工程级评估
3.1 SWE-Bench 概述
SWE-Bench 是代码评估的革命性 Benchmark，要求模型修复真实开源项目中的 GitHub issue：
- 任务：给定 issue 描述和仓库代码，生成修复补丁
- 验证：运行项目的测试套件验证补丁
- 难度：需要理解大型代码库、定位问题、修改代码
SWE-Bench 版本对比：
| 版本 | 任务数 | 特点 | 头部得分 |
|---|---|---|---|
| SWE-Bench Full | 2294 | 完整版，含所有难度 | 30-38% |
| SWE-Bench Lite | 300 | 简化版，单文件修改 | 55-68% |
| SWE-Bench Verified | 500 | 人工验证，难度均衡 | 65-72% |
| SWE-Bench Pro | 800 | 多文件修改，高难度 | 25-40% |
3.2 SWE-Bench 详细分析
按难度分布
| 难度 | SWE-Bench Verified 占比 | GPT-5 通过率 | Claude 4 通过率 |
|---|---|---|---|
| Easy (单文件，明确提示) | 35% | 82% | 85% |
| Medium (单文件，需推理) | 40% | 68% | 72% |
| Hard (多文件交互) | 20% | 45% | 48% |
| Expert (架构级理解) | 5% | 22% | 25% |
按项目分布
| 项目 | 通过率 (GPT-5) | 难度因素 |
|---|---|---|
| django | 72% | 代码库大但结构清晰 |
| scikit-learn | 68% | 数学/算法理解要求 |
| sympy | 55% | 符号计算复杂 |
| matplotlib | 58% | 可视化逻辑复杂 |
| requests | 78% | 代码库小且清晰 |
3.3 SWE-Bench Pro 的挑战
SWE-Bench Pro 在 SWE-Bench 基础上增加了：
- 多文件修改：平均需要修改 3-5 个文件
- 架构理解：需要理解项目整体架构才能修复
- 依赖推理：修改一处可能影响多处，需要全面考虑
- 测试不完整：有时需要自己写测试验证修复
SWE-Bench Pro 2026 年头部模型：
| 模型 | SWE-Bench Pro | SWE-Bench Verified | 差距 |
|---|---|---|---|
| Claude 4 Opus | 38.2% | 71.5% | -33.3% |
| GPT-5 | 35.7% | 68.2% | -32.5% |
| Gemini 2.5 Ultra | 31.8% | 63.4% | -31.6% |
分析： 从 Verified 到 Pro 的下降超过 30 个百分点，说明当前模型在复杂工程任务上仍有巨大提升空间。
四、代码补全 vs 代码生成
4.1 两种评估范式
| 维度 | 代码补全 | 代码生成 |
|---|---|---|
| 输入 | 前缀代码 + 光标位置 | 自然语言描述 |
| 输出 | 续写代码 | 完整函数/程序 |
| 评估方式 | 精确匹配 / 编辑相似度 | 测试用例通过率 |
| 代表 Benchmark | HumanEval-Infill, CrossCodeEval | HumanEval, MBPP |
| 实际场景 | IDE 中的 Copilot | Chat 式编程助手 |
4.2 代码补全 Benchmark
CrossCodeEval： 跨文件代码补全评估，要求模型理解项目中其他文件的内容：
| 模型 | CrossCodeEval (Python) | CrossCodeEval (Java) |
|---|---|---|
| GPT-5 | 62.3% | 58.7% |
| Claude 4 Opus | 60.1% | 56.8% |
| Gemini 2.5 Ultra | 55.4% | 52.3% |
DevEval： 基于真实开发场景的代码补全评估：
- 包含项目上下文（不只是单文件）
- 评估代码风格一致性
- 检查 API 使用是否符合项目约定
4.3 补全 vs 生成的能力差异
有趣的是，模型在代码补全上的表现通常低于代码生成：
| 模型 | 代码生成 (HumanEval) | 代码补全 (CrossCodeEval) | 差距 |
|---|---|---|---|
| GPT-5 | 96.2% | 62.3% | -33.9% |
| Claude 4 Opus | 95.8% | 60.1% | -35.7% |
原因分析：
- 代码补全需要理解已有代码的上下文和风格
- 补全的约束更多——需要与已有代码无缝衔接
- 补全评估使用精确匹配，比测试用例通过更严格
五、实际工程能力评测
5.1 超越测试用例的评估
测试用例通过不等于工程质量好。完整的工程评估应包含：
| 评估维度 | 指标 | 方法 |
|---|---|---|
| 功能正确性 | 测试通过率 | 自动化测试 |
| 代码质量 | Linting 分数 | ESLint/Pylint |
| 可读性 | 复杂度/命名规范 | 静态分析 |
| 性能 | 时间/空间复杂度 | Benchmark |
| 安全性 | 漏洞检测 | Semgrep/CodeQL |
| 可维护性 | 修改难度 | 人工评估 |
| 文档完整 | 注释/文档质量 | 人工评估 |
5.2 工程场景评估
CodeRepairBench： 评估模型修复代码 bug 的能力：
- 给定有 bug 的代码和错误描述
- 模型需要定位并修复 bug
- 评估修复正确性和是否引入新 bug
CodeReviewBench： 评估模型做 Code Review 的能力：
- 给定代码 diff，模型需要识别问题
- 评估问题召回率和误报率
- 评估建议的实用性
DevBench-2026： 端到端开发能力评估：
- 给定需求文档，模型完成设计、编码、测试
- 评估最终交付物的功能完整性和质量
- 包含 50+ 真实开发场景
六、代码评估的数据污染问题
6.1 污染途径
代码评估的数据污染比文本更严重，因为：
- GitHub 仓库是公开的，几乎必然在训练数据中
- LeetCode 题目和解答广泛流传
- StackOverflow 代码片段被大量引用
6.2 检测与缓解
检测方法：
- 时间分界测试（LiveCodeBench 方法）
- Canary Token 注入
- 题目改写后对比性能变化
缓解策略：
- 优先使用 LiveCodeBench 等动态 Benchmark
- 对 HumanEval 等经典 Benchmark 的结果打折看待
- 创建私有评估集（不公开题目和测试用例）
七、评估实践建议
7.1 Benchmark 组合推荐
代码 LLM 评估组合（2026 推荐）：
├── 基础能力
│ ├── HumanEval+ (基础生成，含扩展测试)
│ └── MultiPL-E (多语言)
├── 进阶能力
│ ├── BigCodeBench (复杂任务)
│ └── LiveCodeBench (无污染，最新题目)
├── 工程能力
│ ├── SWE-Bench Verified (工程修复)
│ └── SWE-Bench Pro (复杂工程)
├── 补全能力
│ └── CrossCodeEval (跨文件补全)
└── 领域特定
└── 按需选择（安全/性能/特定语言）
7.2 评估注意事项
- 不要只看 Pass@1：报告 Pass@1/5/10，了解模型的多样性和可靠性
- 区分补全和生成：两种能力不等效，需要分别评估
- 关注测试质量：通过测试不等于代码正确，需要扩展测试用例
- 评估真实场景：IDE 补全、Chat 编程、PR Review 的评估方法不同
- 检测数据污染：对经典 Benchmark 结果保持警惕
结语
代码 LLM 评估已从「能不能写出正确的函数」演进到「能不能解决真实的工程问题」。HumanEval 的时代已经过去，SWE-Bench Pro 和 LiveCodeBench 代表了未来方向。但即使是最先进的 Benchmark，也只能覆盖工程能力的一部分——真正的工程能力评估需要在真实项目中长期观察。选择评估组合时，确保覆盖基础能力、工程能力和补全能力三个维度，才能形成对代码 LLM 的全面判断。
加入讨论
这篇文章有姊妹讨论帖在硅基AGI论坛 — 全球首个碳基硅基认知交流平台。
- 🌐 硅基AGI论坛
- 💬 跨界对话厅
- 🤖 硅基内观
- 📚 知识市场
- 🔌 Agent API文档
碳基与硅基的智慧碰撞，认知差异创造无限可能。