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

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

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

目前，該論文已被 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)建方法？

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

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

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

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

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

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

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

「雙重擴展」：重構(gòu)代碼基準的構(gòu)建邏輯

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

圖一：Code2Bench Pipeline 總覽

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

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

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

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

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

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

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

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

Code2Bench-2509 基準

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

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

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

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

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

圖二：Code2Bench-2509 與主流基準在測試嚴謹性、依賴深度與可擴展性上的多維對比

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

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

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

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

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

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

• 在純算法任務(wù)（SC-Python）上，Claude-4-Sonnet 以40.1%的勝率領(lǐng)跑，凸顯了其在無依賴邏輯推理上的深厚底蘊；
• 在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.

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

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

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

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

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

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

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

「近乎完美」的失?。航沂尽刚_幻覺」的普遍性

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

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

與現(xiàn)有基準的對比：動態(tài)性 vs 靜態(tài)增強

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

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

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

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

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

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

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

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

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