代码与软件工程 Benchmark 全景报告（2026）
从函数级到仓库级，从文本到多模态——18 个主流及新兴 Benchmark 的系统梳理、横向对比与趋势判断
代码与软件工程 Benchmark 全景报告（2026）
从函数级到仓库级，从文本到多模态——LLM 代码能力评测的演进与前沿
一、为什么需要这份报告
2024–2026 年间，代码生成 Benchmark 经历了一次范式跃迁：从”给函数签名补全实现”到”给一句需求描述从零构建整个代码库”。HumanEval 上 95%+ 的分数已经失去区分度，行业急需更贴近真实工程的评测维度。
本报告系统梳理 18 个主流及新兴 Benchmark，按评测粒度分四层，逐一拆解设计理念、任务构成、评测指标，并给出横向对比和趋势判断。
二、Benchmark 全景图：四层分类
┌──────────────────────────────────────────────────────────┐
│ Layer 4: 端到端工程 (E2E Engineering) │
│ NL2Repo-Bench · Commit0 · WebApp1K · Terminal-Bench │
├──────────────────────────────────────────────────────────┤
│ Layer 3: 仓库级修复与推理 (Repo-Level) │
│ SWE-bench Pro · SWE-bench Verified · Multi-SWE-bench │
│ SWE-bench Multimodal │
├──────────────────────────────────────────────────────────┤
│ Layer 2: 领域特化 (Domain-Specific) │
│ KernelBench · SciCode · MLE-bench · RE-Bench │
│ FullStackBench │
├──────────────────────────────────────────────────────────┤
│ Layer 1: 函数/片段级 (Function-Level) │
│ HumanEval/MBPP · EvalPlus · LiveCodeBench │
│ BigCodeBench · Aider Polyglot · CRUXEval │
└──────────────────────────────────────────────────────────┘三、逐层详解
Layer 1: 函数/片段级——“基本功体检”
1. HumanEval / MBPP
| 维度 | HumanEval | MBPP |
|---|---|---|
| 发布 | OpenAI, 2021 | Google, 2021 |
| 规模 | 164 题 | 974 题 |
| 语言 | Python | Python |
| 指标 | pass@k | pass@k |
| 当前水位 | 前沿模型 95%+ | 前沿模型 90%+ |
| 现状 | ⚠️ 已饱和，不再区分前沿模型 | ⚠️ 已饱和 |
评价：作为代码生成评测的”Hello World”，二者已完成历史使命。1% 的分差属于噪音。仅适合做底线 sanity check。
2. EvalPlus (HumanEval+ / MBPP+)
| 维度 | 详情 |
|---|---|
| 发布 | NUS / Illinois, 2023 |
| 核心改进 | 将 HumanEval 测试用例扩展 80×，MBPP 同理 |
| 目标 | 暴露”通过弱测试但逻辑错误”的代码 |
| 指标 | pass@1（严格模式） |
| 价值 | 同一模型在 HumanEval 和 HumanEval+ 上可差 10+ 个点 |
评价：如果还要用 HumanEval，至少应该用 EvalPlus 版本。揭示了大量”假通过”。
3. LiveCodeBench ⭐
| 维度 | 详情 |
|---|---|
| 发布 | 2024，持续更新 |
| 规模 | 动态扩展（LeetCode + Codeforces + AtCoder 新题） |
| 核心特性 | 抗污染——所有题目发布于模型训练截止日期之后 |
| 指标 | pass@1 |
| 当前水位 | 前沿模型在 Hard 题仅 40-60% |
| 局限 | 竞赛编程 ≠ 软件工程；不测多文件、不测 API 调用 |
评价：当前最可靠的函数级推理能力测试。持续更新机制解决了数据泄露这个老大难问题。
4. BigCodeBench
| 维度 | 详情 |
|---|---|
| 发布 | BigCode Project, 2024 (ICLR’25) |
| 核心特性 | HumanEval 级别的函数生成，但指令更复杂 + 调用多样化函数库 |
| 两个拆分 | Complete（自然语言→代码）+ Instruct（对话式指令→代码） |
| 语言 | Python 为主 |
| 指标 | pass@1 |
评价：填补了 HumanEval 和真实工程之间的空白——不是纯算法题，而是需要理解第三方库 API。
5. Aider Polyglot Benchmark
| 维度 | 详情 |
|---|---|
| 发布 | Paul Gauthier (Aider), 2024 |
| 规模 | 133 题 |
| 核心特性 | 多语言（Python/JS/TS/Go/Rust/C++/Java）的代码编辑能力 |
| 评测方式 | 模型按指令修改已有代码文件 |
| 指标 | 正确率（%） |
| 当前水位 | Opus 4.6 ~85%, Sonnet 4.6 ~82%, GPT-5.3 ~80% |
| 备注 | OpenAI 发布 o3 时选用的三大 Benchmark 之一 |
评价：最贴近”AI 编辑器”真实场景的函数级测试。测的不是从零生成，而是按指令改代码——更实际。
6. CRUXEval / CRUXEval-X
| 维度 | 详情 |
|---|---|
| 发布 | Meta (FAIR), 2024; CRUXEval-X 扩展到多语言, ACL 2025 |
| 规模 | 800 个 Python 函数（3-13 行） |
| 两个任务 | Input Prediction（给输出猜输入）+ Output Prediction（给输入猜输出） |
| 核心特性 | 测代码理解而非生成——能否”人脑执行”代码 |
| 指标 | Exact Match |
评价：独特的角度——不写代码，而是读代码。暴露了模型在代码执行推理上的缺陷。
Layer 2: 领域特化——“专项能力深度检验”
7. KernelBench ⭐⭐
| 维度 | 详情 |
|---|---|
| 发布 | Stanford Scaling Intelligence, 2025 (ICML’25) |
| 规模 | 250 个 PyTorch ML 工作负载 |
| 任务 | 给定 PyTorch 操作，生成等效的高性能 CUDA 内核 |
| 四个难度等级 | Level 1 (100 tasks): 单个原语操作 |
| Level 2 (100 tasks): 操作组合 | |
| Level 3 (50 tasks): 完整模型层/模块 | |
| 核心指标 | fast_p——生成内核正确且比 PyTorch Eager 快 p 倍的概率 |
| 当前水位 | 最佳模型 < 20% 的内核能匹配 PyTorch 基线性能 |
| 开源 | ✅ GitHub + 完整评测环境 |
为什么重要：
- 这是第一个认真测试 LLM 高性能计算代码生成的 Benchmark
fast_p指标同时考量正确性和效率，可调节阈值 p 来控制难度- 提供完整的编译器错误、运行时分析反馈，支持迭代优化
- 模型在利用硬件架构信息（如 SM 数量、shared memory 大小）上几乎无改善
局限：仅覆盖 CUDA/PyTorch 生态，不涉及 Triton/MLIR 等新兴 DSL。
8. SciCode
| 维度 | 详情 |
|---|---|
| 发布 | 2024 |
| 特性 | 来自 16 个科学领域的真实科研编程问题（非考试题） |
| 核心挑战 | 需要领域知识 + 数值计算 + 多步推理 |
| 指标 | 功能正确性 |
| 当前水位 | 模型在复杂科学计算上表现低迷 |
评价：弥补了”代码 Benchmark 都是 CS 题”的偏见。物理模拟、化学计算、生物信息学对 LLM 是全新挑战。
9. MLE-bench
| 维度 | 详情 |
|---|---|
| 发布 | OpenAI, 2024 |
| 规模 | 75 个离线 Kaggle 竞赛 |
| 任务 | 端到端机器学习工程——数据处理、特征工程、模型训练、提交 |
| 指标 | Kaggle 竞赛排名百分位 |
| 当前水位 | Agent 能在部分竞赛中达到前 50% |
评价：最接近”ML 工程师日常”的 Benchmark。但 Kaggle 竞赛本身有套路化问题。
10. RE-Bench
| 维度 | 详情 |
|---|---|
| 发布 | METR (前 ARC Evals), 2024 |
| 核心目标 | 评估 Agent 进行 AI R&D（研究与开发）的能力 |
| 特性 | 长时间跨度任务（数小时级）+ 与人类专家直接对比 |
| 指标 | 任务完成度 + 与人类 baseline 对比 |
| 差异 | 比 MLE-bench 更聚焦于研究性任务而非工程性任务 |
评价：AI 安全领域最关注的 Benchmark 之一——直接回答”AI Agent 能否自主做 AI 研究”。
11. FullStackBench
| 维度 | 详情 |
|---|---|
| 发布 | 字节跳动 / M-A-P, 2024 |
| 核心特性 | 全栈编程 + 多语言评测（不限于 Python） |
| 覆盖 | 前端、后端、数据库、DevOps 等全栈场景 |
| 语言 | 16+ 语言 |
| 指标 | pass@1 |
评价：弥补了大部分 Benchmark 只测 Python 的短板。全栈视角更贴近真实开发。
Layer 3: 仓库级修复与推理——“软件工程实战”
12. SWE-bench 家族
这是当前影响力最大的 Benchmark 家族，已分化为多个变体：
| 变体 | 规模 | 语言 | 核心特性 | 当前最高分 | 问题 |
|---|---|---|---|---|---|
| Verified | 500 任务 | Python | 人工验证子集 | ~81% | ⚠️ 严重数据污染；顶部饱和 |
| Pro ⭐ | 1,865 任务 | 多语言 | Scale AI 运营；抗污染；更难 | ~46% (标准) / ~57% (自定义) | 脚手架差异大 |
| Multimodal | 617 任务 | JavaScript | 视觉 UI 相关 bug 修复 | 待稳定 | 需截图/前端渲染能力 |
| Multi-SWE | 1,632 任务 | 7 种语言 | 多语言真实 issue 修复 | 待稳定 | 字节跳动 Seed 主导 |
关键转折：OpenAI 于 2026 年 2 月正式宣布 SWE-bench Verified 退役，承认数据污染问题。行业重心转向 SWE-bench Pro。
SWE-bench Pro 为什么更好：
- 使用 GPL + 专有代码，训练时难以泄露
- 平均每个任务修改 107 行 × 4.1 个文件（Verified 只改 1-2 个文件）
- SEAL 平台标准化脚手架（250 轮限制），公平对比
Layer 4: 端到端工程——“从零到一”
13. NL2Repo-Bench ⭐⭐
| 维度 | 详情 |
|---|---|
| 发布 | 字节跳动 Seed, 2025.12 |
| 输入 | 一个自然语言需求文档 + 空工作区 |
| 输出 | 完整可安装的 Python 库（多模块、有依赖、有测试） |
| 评测 | 真实 pytest 测试套件的通过率 |
| 当前水位 | 最强模型平均测试通过率 < 40% |
| 任务来源 | 具有模块化架构和 pytest 测试的真实 Python 库 |
典型失败模式（论文详细分析）：
- 过早终止——Agent 在完成少数文件后就停止
- 全局连贯性缺失——各模块接口不匹配
- 跨文件依赖脆弱——import 链断裂
- 规划不足——在数百个交互步骤中迷失方向
为什么重要： 这是目前最接近”给需求文档，交付可运行软件”的评测。揭示了长程推理是 Coding Agent 的核心瓶颈。
14. Commit0
| 维度 | 详情 |
|---|---|
| 发布 | 2024.12 |
| 规模 | 54 个核心 Python 库 |
| 任务 | 从 commit 0 开始，实现整个库（通过单元测试验证） |
| 核心理念 | ”Can you create a library from scratch?” |
| 差异于 NL2Repo | 提供了目标库的完整测试套件作为规范 |
评价：与 NL2Repo-Bench 互补——后者给需求文档，Commit0 给测试套件。都指向同一个能力：从零构建。
15. WebApp1K
| 维度 | 详情 |
|---|---|
| 发布 | ONEKQ Lab, 2024 |
| 规模 | 1,000 个挑战，覆盖 20 个应用领域 |
| 任务 | TDD 驱动的 Web 应用开发 |
| 特性 | 测试用例同时作为任务提示和验证手段 |
| 覆盖领域 | 博客、电商、社交网络、管理后台等 |
评价：唯一专注于 Web 应用全栈开发的 Benchmark，且规模可观。
16. Terminal-Bench
| 维度 | 详情 |
|---|---|
| 发布 | 2025，已迭代到 2.0 |
| 核心任务 | 在真实终端环境中完成复杂开发任务 |
| 覆盖 | 文件编辑、git 操作、测试运行、多步调试、环境配置 |
| 执行方式 | Docker 容器中的真实 Linux 终端 |
| 当前水位 | GPT-5.3 Codex / Gemini 3.1 Pro ~77%, Claude Code ~72% |
评价：把”用终端干活”独立出来测试，非常实际。大量真实开发工作发生在终端里。
四、横向对比矩阵
| Benchmark | 粒度 | 语言 | 规模 | 抗污染 | 动态更新 | 测效率 | 测理解 | 长程推理 | 前沿模型水位 |
|---|---|---|---|---|---|---|---|---|---|
| HumanEval/MBPP | 函数 | Python | 164/974 | ❌ | ❌ | ❌ | ❌ | ❌ | 95%+ ⚠️饱和 |
| EvalPlus | 函数 | Python | 164/974 (80× test) | ❌ | ❌ | ❌ | ❌ | ❌ | ~85% |
| LiveCodeBench | 函数 | Python+ | 动态 | ✅ | ✅ | ❌ | ❌ | ❌ | 40-60% (Hard) |
| BigCodeBench | 函数 | Python | 1,140 | ⚠️ | ❌ | ❌ | ❌ | ❌ | ~70% |
| Aider Polyglot | 函数/编辑 | 多语言 | 133 | ⚠️ | ❌ | ❌ | ❌ | ❌ | ~85% |
| CRUXEval | 片段 | Python | 800 | ❌ | ❌ | ❌ | ✅ | ❌ | ~70% |
| KernelBench | 模块 | CUDA | 250 | ✅ | ❌ | ✅ | ❌ | ❌ | <20% |
| SciCode | 模块 | Python | 多领域 | ✅ | ❌ | ❌ | ✅ | ⚠️ | 低 |
| MLE-bench | 项目 | Python | 75 | ⚠️ | ❌ | ❌ | ❌ | ✅ | 中 |
| RE-Bench | 项目 | Python | 少量 | ✅ | ❌ | ❌ | ❌ | ✅ | 与人类差距大 |
| FullStackBench | 模块 | 16+ 语言 | 大 | ⚠️ | ❌ | ❌ | ❌ | ❌ | ~65% |
| SWE-bench Verified | 仓库 | Python | 500 | ❌ | ❌ | ❌ | ❌ | ⚠️ | ~81% ⚠️污染 |
| SWE-bench Pro | 仓库 | 多语言 | 1,865 | ✅ | ❌ | ❌ | ❌ | ✅ | ~46% |
| SWE-bench Multimodal | 仓库 | JavaScript | 617 | ✅ | ❌ | ❌ | ❌ | ✅ | 低 |
| Multi-SWE-bench | 仓库 | 7 语言 | 1,632 | ✅ | ❌ | ❌ | ❌ | ✅ | 待定 |
| NL2Repo-Bench | 完整仓库 | Python | 多 | ✅ | ❌ | ❌ | ❌ | ✅✅ | <40% |
| Commit0 | 完整仓库 | Python | 54 | ✅ | ❌ | ❌ | ❌ | ✅✅ | 低 |
| WebApp1K | 完整应用 | Web 全栈 | 1,000 | ⚠️ | ❌ | ❌ | ❌ | ✅ | 中 |
| Terminal-Bench | 终端操作 | 多 | 动态 | ✅ | ✅ | ❌ | ❌ | ✅ | ~77% |
五、关键趋势
趋势 1: 从”正确性”到”正确性 × 效率”
KernelBench 的 fast_p 指标开了先河：光能跑通不够，还得跑得快。这将扩展到更多领域——生成的代码不仅要正确，还要考虑时间复杂度、内存占用、并发安全。预计会出现更多 EvalPerf 类指标。
趋势 2: 从”补丁”到”从零构建”
SWE-bench 系列测的是”给已有仓库打补丁”，NL2Repo-Bench 和 Commit0 测的是”从零开始建造”。后者才是 Coding Agent 的终极形态——接收需求，交付软件。目前模型在这个维度上还远远不够（< 40%），这是未来 2-3 年的主战场。
趋势 3: 从”Python Only”到”多语言+多模态”
| 演进 | 代表 |
|---|---|
| Python Only | HumanEval, MBPP, SWE-bench |
| 多语言 | Multi-SWE-bench (7 语言), Aider Polyglot, FullStackBench (16+ 语言) |
| 多模态 | SWE-bench Multimodal (视觉 bug), 未来: 语音指令→代码 |
趋势 4: 抗污染成为硬约束
| 策略 | 代表 |
|---|---|
| 持续出新题 | LiveCodeBench |
| 使用 GPL/专有代码 | SWE-bench Pro |
| 训练截止日期后的代码 | Terminal-Bench 2.0 |
| Mutation Testing | Saving SWE-Bench (对测试用例做变异) |
OpenAI 正式承认 SWE-bench Verified 数据泄露并推动退役，标志着行业达成共识：不抗污染的 Benchmark 就是失效的 Benchmark。
趋势 5: Agent 架构成为隐变量
同一个模型在不同脚手架下分数差距巨大（SWE-bench Pro: 标准脚手架 46% vs 自定义脚手架 57%）。Benchmark 需要标准化”Agent 基建”，否则测的是脚手架工程而非模型能力。SEAL 平台和 Sigmabench 正在朝这个方向努力。
六、推荐评测组合
根据不同目的，推荐以下组合：
场景 A：选模型（基座模型选型）
Aider Polyglot + LiveCodeBench + BigCodeBench理由：测原始代码能力，不依赖 Agent 框架。
场景 B：评 Coding Agent（端到端能力）
SWE-bench Pro + Terminal-Bench + NL2Repo-Bench理由：覆盖修复→终端操作→从零构建三个维度。
场景 C：评 GPU/HPC 代码生成
KernelBench + 自建领域 Benchmark理由：KernelBench 是唯一成熟的 GPU 内核评测。
场景 D：评科研编程能力
SciCode + RE-Bench + MLE-bench理由：覆盖科学计算、AI R&D、ML 工程三个方向。
七、展望：下一代 Benchmark 应该长什么样
7.1 短期（6-12 个月内大概率出现）
- KernelBench → 更多硬件后端：扩展到 Triton、MLIR、Metal/WebGPU，覆盖不只是 NVIDIA 生态。
- NL2Repo → 多语言版本：目前只测 Python，Java/Go/Rust 的仓库级生成评测是空白。
- SWE-bench Pro → 更大规模 + 更多语言：1,865 题仍然不够，且需要覆盖更多的软件领域（嵌入式、移动端）。
- 实时动态 Benchmark 平台化：LiveCodeBench 的模式会扩展到仓库级——持续从新的 GitHub Issue 中提取任务。
7.2 中期（1-2 年内值得押注）
- 协作式 Benchmark：测试多个 Agent 协同完成一个项目（PR Review Agent + Coding Agent + Testing Agent）。目前所有 Benchmark 都假设一个 Agent 干所有事。
- 增量式开发 Benchmark：不是”一次性生成”，而是测试 Agent 在持续迭代中维护和演进代码库的能力——更接近真实软件开发周期。
- 成本效率 Benchmark：同一个任务，不同模型/Agent 的 Token 消耗和延迟差多少？SWE-bench Pro 上花 100 美元和 1 美元解同一道题，体验差距在哪？
- 安全性 Benchmark：生成的代码有多少安全漏洞？目前没有 Benchmark 系统性测试这个维度。
7.3 长期（需要根本性创新的方向）
- Cross-Repo Benchmark：跨多个仓库协调修改（改了底层库，上层依赖也要同步调整）。这是真实大型工程的日常，但目前没有任何 Benchmark 触及。
- Human-in-the-Loop Benchmark：Agent 能否有效与人类协作？什么时候该问人、什么时候该自己干、如何处理模糊需求？这比纯自动化更接近现实。
- 自我进化 Benchmark：Agent 能否从自己的历史错误中学习，在同系列任务上越做越好？目前所有 Benchmark 都是无状态的。
八、结论
代码 Benchmark 正经历从”考试”到”实战”的转型。三个核心判断：
- 函数级已死：HumanEval/MBPP 失去意义，LiveCodeBench 是唯一值得跟踪的函数级评测。
- 仓库级是主战场：SWE-bench Pro + NL2Repo-Bench 定义了 2026 年的能力边界。前沿模型在修复任务上 ~46%、在从零构建上 < 40%，还有很大空间。
- 效率维度刚起步：KernelBench 打开了一个全新维度——不止正确，还要快。这个方向会向更多领域扩散。
对从事大模型预训练/中训练的研究者来说，这些 Benchmark 指向一个清晰的数据信号：模型在长程规划、跨文件一致性、性能优化三个维度上的训练数据严重不足。未来的训练数据工程需要有针对性地补齐这些能力。