在衡量大語言模型（LLM）代碼生成能力的競賽中，一個(gè)日益嚴(yán)峻的問題正浮出水面：當(dāng)模型在 HumanEval、MBPP 等經(jīng)典基準(zhǔn)上紛紛取得近乎飽和的成績時(shí)，我們究竟是在評估其真實(shí)的泛化推理能力，還是在檢驗(yàn)其對訓(xùn)練語料庫的「記憶力」？

現(xiàn)有的代碼基準(zhǔn)正面臨兩大核心挑戰(zhàn)：數(shù)據(jù)污染的風(fēng)險(xiǎn)，以及測試嚴(yán)謹(jǐn)性不足。前者使評測可能退化為「開卷考試」，后者則常常導(dǎo)致一種「正確的幻覺」（Illusion of Correctness）—— 模型生成的代碼或許能通過少數(shù)示例，卻在復(fù)雜的真實(shí)世界邊緣場景中不堪一擊。

為了打破這種「高分幻覺」，來自北京航空航天大學(xué)的研究團(tuán)隊(duì)提出了一種全新的基準(zhǔn)構(gòu)建哲學(xué) ——雙重?cái)U(kuò)展（Dual Scaling），并基于此構(gòu)建了端到端的自動(dòng)化框架Code2Bench。該研究旨在為代碼大模型的評估，建立一個(gè)更動(dòng)態(tài)、更嚴(yán)苛、也更具診斷性的新范式。

目前，該論文已被 ICLR 2026 接收。

• 論文標(biāo)題：Code2Bench: Scaling Source and Rigor for Dynamic Benchmark Construction
• 論文鏈接： https://arxiv.org/pdf/2508.07180
• 榜單鏈接：https://code2bench.github.io/

我們需要什么樣的 Benchmark 構(gòu)建方法？

理想的代碼評測基準(zhǔn)不應(yīng)是靜態(tài)題庫的簡單堆砌，而應(yīng)是一個(gè)持續(xù)演化的對抗環(huán)境。它必須同時(shí)滿足兩個(gè)條件：題目對模型絕對「新鮮」，以杜絕記憶作弊；測試足夠嚴(yán)苛，以暴露邏輯深處的脆弱性。

然而，當(dāng)前絕大多數(shù)評測體系仍困于「一次性構(gòu)建、長期復(fù)用」的舊范式。它們要么依賴人工編寫（易污染），要么從競賽平臺抓�。撾x工程實(shí)際）；測試用例則普遍稀疏且淺層，無法區(qū)分「功能可用」與「生產(chǎn)可靠」。

表一：現(xiàn)有主流代碼生成基準(zhǔn)多維度對比

表一清晰地勾勒出了當(dāng)前評測界的「能力缺口」：大多數(shù)基準(zhǔn)要么依賴人工編寫（極易被后續(xù)訓(xùn)練集污染），要么從競賽平臺抓取（往往脫離工程實(shí)際邏輯）。更致命的是，它們的測試用例普遍稀疏且淺層，只能驗(yàn)證「功能可用」，卻無法甄別 「生產(chǎn)可靠」。

為了填補(bǔ)這一空白，一個(gè)面向未來的基準(zhǔn)構(gòu)建方法必須具備以下四大特質(zhì)：

• 動(dòng)態(tài)性（Dynamic）：問題來源必須是持續(xù)更新的，以從根本上對抗數(shù)據(jù)污染。
• 真實(shí)性（Real-world）：問題應(yīng)源自真實(shí)的、復(fù)雜的項(xiàng)目代碼庫，而非人工編寫的「玩具問題」。
• 嚴(yán)謹(jǐn)性（Rigorous）：測試必須是深入且全面的，能夠挖掘出最細(xì)微的邏輯缺陷。
• 全面性（Comprehensive）：應(yīng)能處理復(fù)雜的外部庫依賴，并具備向多語言擴(kuò)展的能力。

正是在對這四大目標(biāo)的追求下，Code2Bench 的核心構(gòu)建哲學(xué)應(yīng)運(yùn)而生。

「雙重?cái)U(kuò)展」：重構(gòu)代碼基準(zhǔn)的構(gòu)建邏輯

Code2Bench 并非僅僅發(fā)布了一個(gè)新數(shù)據(jù)集，而是提出了一套端到端、全自動(dòng)、可持續(xù)演進(jìn)的基準(zhǔn)構(gòu)建流水線。如圖一所示，其核心是「雙重?cái)U(kuò)展」哲學(xué) —— 通過系統(tǒng)性地?cái)U(kuò)展來源廣度與測試深度，確保我們總能源源不斷地生成高質(zhì)量、抗污染、高覆蓋的評測任務(wù)。

圖一：Code2Bench Pipeline 總覽

1. 擴(kuò)展代碼來源（Scaling the Source）：與數(shù)據(jù)污染賽跑

為了確保問題的新穎性與真實(shí)性，框架摒棄了靜態(tài)題庫，轉(zhuǎn)而建立了一套動(dòng)態(tài)獲取代碼的流水線：

• 動(dòng)態(tài)獲取與時(shí)間戳過濾：直接從海量、活躍的 GitHub 開源項(xiàng)目中提取函數(shù)，并嚴(yán)格依據(jù)各待評測模型的知識截止日期（Knowledge Cutoff Date），僅篩選在此之后提交的代碼。這不僅杜絕了「背題」，更意味著只要 GitHub 有新代碼，Code2Bench 就能源源不斷產(chǎn)出新題目。
• 語言無關(guān)的 Scope Graph 分析：作為系統(tǒng)化分類的技術(shù)核心，該方法不依賴特定語言語法，而是通過高度抽象的邏輯作用域圖（Scope Graph）精準(zhǔn)識別外部依賴，自動(dòng)將任務(wù)分為：

• 自包含任務(wù)（SC）：無外部依賴，專注考核核心邏輯合成能力；
• 弱自包含任務(wù)（WSC）：僅依賴標(biāo)準(zhǔn)庫或白名單庫（如 NumPy），考核真實(shí)開發(fā)中的 API 應(yīng)用能力。

這一設(shè)計(jì)使框架天然支持多語言擴(kuò)展，為未來納入 Go、JavaScript 等語言奠定基礎(chǔ)。

2. 擴(kuò)展測試嚴(yán)謹(jǐn)性（Scaling the Rigor）：以工業(yè)級標(biāo)準(zhǔn)終結(jié)「正確性幻覺」

面對傳統(tǒng)基準(zhǔn)測試用例稀疏的弊病，Code2Bench 引入了極致的嚴(yán)謹(jǐn)性作為核心準(zhǔn)則：

• 基于屬性的測試（Property-Based Testing, PBT）：框架為每個(gè)候選函數(shù)自動(dòng)生成包含數(shù)百乃至上千個(gè)輸入的測試套件，這些輸入覆蓋了典型值、邊界值和復(fù)雜的嵌套結(jié)構(gòu)。
• 「Great Filter」——100% 分支覆蓋率：這是 Code2Bench 最具標(biāo)志性的設(shè)計(jì)。一個(gè)函數(shù)及其對應(yīng)的 PBT 測試套件，只有在執(zhí)行時(shí)能夠覆蓋到函數(shù)內(nèi)每一個(gè)邏輯分支（如 if/else 的所有情況），才會被最終采納。這一看似簡單的要求，卻是一個(gè)極其嚴(yán)苛的質(zhì)量門，它確保了基準(zhǔn)中的每一個(gè)問題都是一個(gè)邏輯完備且可被深度驗(yàn)證的挑戰(zhàn)。

Code2Bench-2509 基準(zhǔn)

為了驗(yàn)證「雙擴(kuò)展」哲學(xué)的有效性，研究團(tuán)隊(duì)基于該框架自動(dòng)構(gòu)建了Code2Bench-2509基準(zhǔn)套件。這是一份動(dòng)態(tài)攝取自 2025 年 5 月至 9 月 GitHub 最新提交的「實(shí)戰(zhàn)考卷」，包含 Python 與 Java 的原生實(shí)例。

表二的量化指標(biāo)直觀地揭示了 Code2Bench-2509 在工程維度上對傳統(tǒng)基準(zhǔn)的 「代差」優(yōu)勢：

表二：Code2Bench-2509 核心指標(biāo)

• 復(fù)雜度躍升：在純邏輯（SC-Python）任務(wù)中，平均圈復(fù)雜度（Cyclomatic Complexity）達(dá)到 5.3，遠(yuǎn)高于 HumanEval 的 2.8。
• 嚴(yán)謹(jǐn)性碾壓：不同于 HumanEval 平均每題僅約 7.8 個(gè)測試用例，Code2Bench 為每道題生成了約 500 個(gè)測試用例。
• 生態(tài)多樣性：在 WSC 任務(wù)中，基準(zhǔn)涵蓋了超過 30 個(gè)主流第三方庫（如 NumPy、Pandas、Scipy 等），真實(shí)模擬了現(xiàn)代軟件開發(fā)對 API 應(yīng)用能力的依賴。

圖二的多維評估景觀圖（Figure 2）則清晰地展示了這一跨越：

圖二：Code2Bench-2509 與主流基準(zhǔn)在測試嚴(yán)謹(jǐn)性、依賴深度與可擴(kuò)展性上的多維對比

相比于 HumanEval 和 BigCodeBench 等主流基準(zhǔn)，Code2Bench 在測試嚴(yán)謹(jǐn)性（Testing Rigor）、依賴深度（Dependency Level）以及框架可擴(kuò)展性（Extensibility）三個(gè)維度上均實(shí)現(xiàn)了顯著的位移。

它不再僅僅停留于考察模型「能否寫出正確的代碼」，而是通過「語言擴(kuò)展」和 「依賴擴(kuò)展」，將評估推向了更廣闊的軟件工程生態(tài)。這種多維度的跨越，為后續(xù)揭示模型更深層的能力缺陷奠定了基礎(chǔ)。

診斷指紋：揭示能力鴻溝與「性能腳手架」效應(yīng)

傳統(tǒng)的 Pass@1 分?jǐn)?shù)往往是一個(gè)「黑盒」：它記錄了結(jié)果，卻掩蓋了模型思維的過程。正是得益于 Code2Bench 對測試強(qiáng)度的量級擴(kuò)展（從個(gè)位數(shù)躍升至～500 個(gè)用例），我們才獲得了足以勾勒「錯(cuò)誤光譜」的高分辨率視角。

這種「診斷指紋（Diagnostic Fingerprint）」將評估從單一維度的「得分」統(tǒng)計(jì)，進(jìn)化為對模型思維失效模式的深度透視。

從表 3 的 Pass@1 數(shù)據(jù)中，我們可以觀察到不同模型在不同賽道上的 “偏科” 現(xiàn)象：

• 在純算法任務(wù)（SC-Python）上，Claude-4-Sonnet 以40.1%的勝率領(lǐng)跑，凸顯了其在無依賴邏輯推理上的深厚底蘊(yùn)；
• 在API 應(yīng)用任務(wù)（WSC-Python）上，Mistral-small-3.1 表現(xiàn)亮眼（38.7%），與 Claude 持平，顯示出其對庫調(diào)用極高的熟練度；
• 在Java 算法任務(wù)（SC-Java）上，DeepSeek-V3 則以 47.8% 的驚人成績冠絕全場。

表三：Pass@1 performance (%) on the Code2Bench-2509 suite.

然而，真正的洞察隱藏在圖三中 —— 指紋圖譜中失敗分布的偏移，揭示了兩個(gè)被單一分?jǐn)?shù)掩蓋的關(guān)鍵事實(shí)：

圖三：模型診斷指紋對比：SC-Python、WSC-Python 與 SC-Java 的結(jié)果分布

1. 能力鴻溝：擅長「調(diào) API」，卻在「寫算法」上掙扎。

指紋圖揭示了模型在面對不同任務(wù)時(shí)截然不同的思維狀態(tài)：在純算法（SC-Python）任務(wù)中，失敗峰值集中于邏輯錯(cuò)誤 (LogicErr)；而一旦涉及調(diào)用外部庫（WSC-Python），峰值則迅速轉(zhuǎn)向了運(yùn)行時(shí)錯(cuò)誤 (RuntimeErr)。這清晰地表明，模型目前的瓶頸已從 “記不住 API 參數(shù)” 轉(zhuǎn)向了更深層的 “無法自主構(gòu)建復(fù)雜邏輯”。

2.「性能腳手架」效應(yīng)：語言范式如何塑造模型表現(xiàn)。

更具啟發(fā)性的是 Python 與 Java 的對比。在SC-Java任務(wù)中，Python 中常見的邏輯錯(cuò)誤被大幅抑制，完美通過率（Perfect）顯著飆升。這并非因?yàn)槿蝿?wù)變簡單了，而是 Java 的靜態(tài)類型系統(tǒng)扮演了「性能腳手架」的角色 —— 它在代碼執(zhí)行前就強(qiáng)行攔截了大量低級錯(cuò)誤。

換言之，指紋圖的分布偏移本身，就是語言范式塑造模型能力的直接可視化證據(jù)。它揭示了一個(gè)關(guān)鍵事實(shí)：一個(gè)模型的編程能力并非抽象存在；其表現(xiàn)深度耦合于目標(biāo)語言的生態(tài)系統(tǒng) —— 靜態(tài)類型不是「限制」，而是一種前置的、高性價(jià)比的魯棒性保障。

「近乎完美」的失敗：揭示「正確幻覺」的普遍性

在 Code2Bench 的嚴(yán)苛測試下，平均有6.94%的 SC-Python 任務(wù)提交會陷入 「近乎完美」的失敗 —— 它們能通過 98% 以上的測試用例，卻在最后幾個(gè)微妙的邊緣場景中出錯(cuò)。這些在傳統(tǒng)基準(zhǔn)中極有可能被計(jì)為「成功」的案例，恰恰暴露了模型在邏輯魯棒性上的「最后一公里」缺陷。

表四：「近乎完美」失�。≒ass@≥98% & Pass@<100%）的發(fā)生比例

與現(xiàn)有基準(zhǔn)的對比：動(dòng)態(tài)性 vs 靜態(tài)增強(qiáng)

與當(dāng)前最嚴(yán)謹(jǐn)?shù)撵o態(tài)基準(zhǔn) EvalPlus（HumanEval 的測試增強(qiáng)版）相比，Code2Bench-2509 展現(xiàn)出系統(tǒng)性難度躍升。如圖 4 所示，所有模型在新基準(zhǔn)上的性能均遠(yuǎn)低于其在 HumanEval 上的表現(xiàn) —— 例如，Claude-4-Sonnet 在 HumanEval 上達(dá) 97%，但在 Code2Bench-2509 上驟降至 40.1%。

這一斷崖式下滑揭示了兩個(gè)關(guān)鍵事實(shí)：

1. 傳統(tǒng)高分包含顯著記憶成分 ——EvalPlus 雖強(qiáng)化了測試，但題源仍為多年前人工編寫，極易被模型「背過」；
2. Code2Bench 源于真實(shí)工程代碼 —— 題目動(dòng)態(tài)采自 2025 年后 GitHub 活躍項(xiàng)目，天然具備復(fù)雜控制流與語義深度，無法靠記憶或模式匹配通過。

換言之，EvalPlus 是對舊題目的「加固」，而 Code2Bench 是面向未來的「新戰(zhàn)場」。前者測的是「是否見過」，后者問的是「能否創(chuàng)造」。

圖四：模型在 EvalPlus 和 Code2Bench-2509 上的表現(xiàn)對比

總結(jié)與展望：邁向真實(shí)工程世界的編程評測

Code2Bench 的本質(zhì)，不是又一個(gè) benchmark，而是一套可持續(xù)演進(jìn)的評測基礎(chǔ)設(shè)施。它通過「雙重?cái)U(kuò)展」哲學(xué)，將代碼 LLM 評估從「靜態(tài)謎題的復(fù)現(xiàn)」，推向 「未知工程問題的穩(wěn)健求解」。

未來，研究團(tuán)隊(duì)計(jì)劃進(jìn)一步擴(kuò)展 Code2Bench 的邊界，將代碼安全性、執(zhí)行效率以及倉庫級別的生成能力納入評估范疇。隨著評測基準(zhǔn)從單純的「考場」進(jìn)化為高壓的「練兵場」，我們期待這一框架能驅(qū)動(dòng) LLM 跨越「正確幻覺」的鴻溝，最終成長為真正具備工程魯棒性的智能開發(fā)者。

目前，Code2Bench 的框架代碼、數(shù)據(jù)集以及詳盡的評測結(jié)果已全部開源，研究團(tuán)隊(duì)誠邀社區(qū)共同參與和探索。