ICLR 2026 | 北航开源Code2Bench：双扩展动态评测，代码大模型告别躺平刷分
在衡量大语言模型（LLM）代码生成能力的竞赛中，一个日益严峻的问题正浮出水面：当模型在 HumanEval、MBPP 等经典基准上纷纷取得近乎饱和的成绩时，我们究竟是在评估其真实的泛化推理能力，还是在检验其对训练语料库的「记忆力」？
现有的代码基准正面临两大核心挑战：数据污染的风险，以及测试严谨性不足。前者使评测可能退化为「开卷考试」，后者则常常导致一种「正确的幻觉」（Illusion of Correctness）—— 模型生成的代码或许能通过少数示例，却在复杂的真实世界边缘场景中不堪一击。
为了打破这种「高分幻觉」，来自北京航空航天大学的研究团队提出了一种全新的基准构建哲学 —— 双重扩展（Dual Scaling），并基于此构建了端到端的自动化框架 Code2Bench。该研究旨在为代码大模型的评估，建立一个更动态、更严苛、也更具诊断性的新范式。
目前，该论文已被 ICLR 2026 接收。
论文标题：Code2Bench: Scaling Source and Rigor for Dynamic Benchmark Construction
论文链接： https://arxiv.org/pdf/2508.07180
榜单链接：https://code2bench.github.io/
我们需要什么样的 Benchmark 构建方法？
理想的代码评测基准不应是静态题库的简单堆砌，而应是一个持续演化的对抗环境。它必须同时满足两个条件：题目对模型绝对「新鲜」，以杜绝记忆作弊；测试足够严苛，以暴露逻辑深处的脆弱性。
然而，当前绝大多数评测体系仍困于「一次性构建、长期复用」的旧范式。它们要么依赖人工编写（易污染），要么从竞赛平台抓取（脱离工程实际）；测试用例则普遍稀疏且浅层，无法区分「功能可用」与「生产可靠」。
表一：现有主流代码生成基准多维度对比
表一清晰地勾勒出了当前评测界的「能力缺口」：大多数基准要么依赖人工编写（极易被后续训练集污染），要么从竞赛平台抓取（往往脱离工程实际逻辑）。更致命的是，它们的测试用例普遍稀疏且浅层，只能验证「功能可用」，却无法甄别 「生产可靠」。
为了填补这一空白，一个面向未来的基准构建方法必须具备以下四大特质：
动态性（Dynamic）：问题来源必须是持续更新的，以从根本上对抗数据污染。
真实性（Real-world）：问题应源自真实的、复杂的项目代码库，而非人工编写的「玩具问题」。
严谨性（Rigorous）：测试必须是深入且全面的，能够挖掘出最细微的逻辑缺陷。
全面性（Comprehensive）：应能处理复杂的外部库依赖，并具备向多语言扩展的能力。
正是在对这四大目标的追求下，Code2Bench 的核心构建哲学应运而生。
「双重扩展」：重构代码基准的构建逻辑
Code2Bench 并非仅仅发布了一个新数据集，而是提出了一套端到端、全自动、可持续演进的基准构建流水线。如图一所示，其核心是「双重扩展」哲学 —— 通过系统性地扩展来源广度与测试深度，确保我们总能源源不断地生成高质量、抗污染、高覆盖的评测任务。
图一：Code2Bench Pipeline 总览
1. 扩展代码来源（Scaling the Source）：与数据污染赛跑
为了确保问题的新颖性与真实性，框架摒弃了静态题库，转而建立了一套动态获取代码的流水线：
动态获取与时间戳过滤：直接从海量、活跃的 GitHub 开源项目中提取函数，并严格依据各待评测模型的知识截止日期（Knowledge Cutoff Date），仅筛选在此之后提交的代码。这不仅杜绝了「背题」，更意味着只要 GitHub 有新代码，Code2Bench 就能源源不断产出新题目。
语言无关的 Scope Graph 分析：作为系统化分类的技术核心，该方法不依赖特定语言语法，而是通过高度抽象的逻辑作用域图（Scope Graph）精准识别外部依赖，自动将任务分为：
自包含任务（SC）：无外部依赖，专注考核核心逻辑合成能力；
弱自包含任务（WSC）：仅依赖标准库或白名单库（如 NumPy），考核真实开发中的 API 应用能力。
这一设计使框架天然支持多语言扩展，为未来纳入 Go、JavaScript 等语言奠定基础。
2. 扩展测试严谨性（Scaling the Rigor）：以工业级标准终结「正确性幻觉」
面对传统基准测试用例稀疏的弊病，Code2Bench 引入了极致的严谨性作为核心准则：
基于属性的测试（Property-Based Testing, PBT）：框架为每个候选函数自动生成包含数百乃至上千个输入的测试套件，这些输入覆盖了典型值、边界值和复杂的嵌套结构。
「Great Filter」——100% 分支覆盖率：这是 Code2Bench 最具标志性的设计。一个函数及其对应的 PBT 测试套件，只有在执行时能够覆盖到函数内每一个逻辑分支（如 if/else 的所有情况），才会被最终采纳。这一看似简单的要求，却是一个极其严苛的质量门，它确保了基准中的每一个问题都是一个逻辑完备且可被深度验证的挑战。
Code2Bench-2509 基准
为了验证「双扩展」哲学的有效性，研究团队基于该框架自动构建了 Code2Bench-2509 基准套件。这是一份动态摄取自 2025 年 5 月至 9 月 GitHub 最新提交的「实战考卷」，包含 Python 与 Java 的原生实例。
表二的量化指标直观地揭示了 Code2Bench-2509 在工程维度上对传统基准的 「代差」优势：
表二：Code2Bench-2509 核心指标
复杂度跃升：在纯逻辑（SC-Python）任务中，平均圈复杂度（Cyclomatic Complexity）达到 5.3，远高于 HumanEval 的 2.8。
严谨性碾压：不同于 HumanEval 平均每题仅约 7.8 个测试用例，Code2Bench 为每道题生成了约 500 个测试用例。
生态多样性：在 WSC 任务中，基准涵盖了超过 30 个主流第三方库（如 NumPy、Pandas、Scipy 等），真实模拟了现代软件开发对 API 应用能力的依赖。
图二的多维评估景观图（Figure 2）则清晰地展示了这一跨越：
图二：Code2Bench-2509 与主流基准在测试严谨性、依赖深度与可扩展性上的多维对比
相比于 HumanEval 和 BigCodeBench 等主流基准，Code2Bench 在测试严谨性（Testing Rigor）、依赖深度（Dependency Level）以及框架可扩展性（Extensibility）三个维度上均实现了显著的位移。
它不再仅仅停留于考察模型「能否写出正确的代码」，而是通过「语言扩展」和 「依赖扩展」，将评估推向了更广阔的软件工程生态。这种多维度的跨越，为后续揭示模型更深层的能力缺陷奠定了基础。
诊断指纹：揭示能力鸿沟与「性能脚手架」效应
传统的 Pass@1 分数往往是一个「黑盒」：它记录了结果，却掩盖了模型思维的过程。正是得益于 Code2Bench 对测试强度的量级扩展（从个位数跃升至～500 个用例），我们才获得了足以勾勒「错误光谱」的高分辨率视角。
这种「诊断指纹（Diagnostic Fingerprint）」将评估从单一维度的「得分」统计，进化为对模型思维失效模式的深度透视。
从表 3 的 Pass@1 数据中，我们可以观察到不同模型在不同赛道上的 “偏科” 现象：
在纯算法任务（SC-Python）上，Claude-4-Sonnet 以 40.1% 的胜率领跑，凸显了其在无依赖逻辑推理上的深厚底蕴；
在 API 应用任务（WSC-Python）上，Mistral-small-3.1 表现亮眼（38.7%），与 Claude 持平，显示出其对库调用极高的熟练度；
在 Java 算法任务（SC-Java）上，DeepSeek-V3 则以 47.8% 的惊人成绩冠绝全场。
表三：Pass@1 performance (%) on the Code2Bench-2509 suite.
然而，真正的洞察隐藏在图三中 —— 指纹图谱中失败分布的偏移，揭示了两个被单一分数掩盖的关键事实：
图三：模型诊断指纹对比：SC-Python、WSC-Python 与 SC-Java 的结果分布
1. 能力鸿沟：擅长「调 API」，却在「写算法」上挣扎。
指纹图揭示了模型在面对不同任务时截然不同的思维状态：在纯算法（SC-Python）任务中，失败峰值集中于逻辑错误 (LogicErr)；而一旦涉及调用外部库（WSC-Python），峰值则迅速转向了运行时错误 (RuntimeErr)。这清晰地表明，模型目前的瓶颈已从 “记不住 API 参数” 转向了更深层的 “无法自主构建复杂逻辑”。
2.「性能脚手架 」效应：语言范式如何塑造模型表现。
更具启发性的是 Python 与 Java 的对比。在 SC-Java 任务中，Python 中常见的逻辑错误被大幅抑制，完美通过率（Perfect）显著飙升。这并非因为任务变简单了，而是 Java 的静态类型系统扮演了「性能脚手架」的角色 —— 它在代码执行前就强行拦截了大量低级错误。
换言之，指纹图的分布偏移本身，就是语言范式塑造模型能力的直接可视化证据。它揭示了一个关键事实：一个模型的编程能力并非抽象存在；其表现深度耦合于目标语言的生态系统 —— 静态类型不是「限制」，而是一种前置的、高性价比的鲁棒性保障。
「近乎完美」的失败：揭示「正确幻觉」的普遍性
在 Code2Bench 的严苛测试下，平均有 6.94% 的 SC-Python 任务提交会陷入 「近乎完美」的失败 —— 它们能通过 98% 以上的测试用例，却在最后几个微妙的边缘场景中出错。这些在传统基准中极有可能被计为「成功」的案例，恰恰暴露了模型在逻辑鲁棒性上的「最后一公里」缺陷。
表四：「近乎完美」失败（Pass@≥98% & Pass@<100%）的发生比例
与现有基准的对比：动态性 vs 静态增强
与当前最严谨的静态基准 EvalPlus（HumanEval 的测试增强版）相比，Code2Bench-2509 展现出系统性难度跃升。如图 4 所示，所有模型在新基准上的性能均远低于其在 HumanEval 上的表现 —— 例如，Claude-4-Sonnet 在 HumanEval 上达 97%，但在 Code2Bench-2509 上骤降至 40.1%。
这一断崖式下滑揭示了两个关键事实：
传统高分包含显著记忆成分 ——EvalPlus 虽强化了测试，但题源仍为多年前人工编写，极易被模型「背过」；
Code2Bench 源于真实工程代码 —— 题目动态采自 2025 年后 GitHub 活跃项目，天然具备复杂控制流与语义深度，无法靠记忆或模式匹配通过。
换言之，EvalPlus 是对旧题目的「加固」，而 Code2Bench 是面向未来的「新战场」。前者测的是「是否见过」，后者问的是「能否创造」。
图四：模型在 EvalPlus 和 Code2Bench-2509 上的表现对比
总结与展望：迈向真实工程世界的编程评测
Code2Bench 的本质，不是又一个 benchmark，而是一套可持续演进的评测基础设施。它通过「双重扩展」哲学，将代码 LLM 评估从「静态谜题的复现」，推向 「未知工程问题的稳健求解」。
未来，研究团队计划进一步扩展 Code2Bench 的边界，将代码安全性、执行效率以及仓库级别的生成能力纳入评估范畴。随着评测基准从单纯的「考场」进化为高压的「练兵场」，我们期待这一框架能驱动 LLM 跨越「正确幻觉」的鸿沟，最终成长为真正具备工程鲁棒性的智能开发者。
目前，Code2Bench 的框架代码、数据集以及详尽的评测结果已全部开源，研究团队诚邀社区共同参与和探索。
