大家好，我是肆〇柒。在 vibe coding 活躍的當下，有時，我們不得不思考一個問題：在軟件開發流程中，我們能否完全依賴、使用 LLM 生成的代碼？大型語言模型（LLM）在代碼生成基準測試中的卓越表現備受矚目，從 HumanEval 到 LiveCodeBench，眾多基準測試平臺見證了 LLM 在代碼生成任務上的飛速進步。然而，隨著 LLM 日趨融入軟件開發，其生成代碼的質量和可靠性評估變得更加關鍵，因為這影響著生產落地應用的品質和服務價值。

那么，代碼驗證作為衡量 LLM 生成代碼質量的核心環節，其評估方法的可靠性，直接影響著我們對模型性能的認知，以及強化學習從可驗證獎勵（RLVR）框架的有效性。但遺憾的是，當前主流代碼生成評估基準存在顯著局限性，這不僅高估了 LLM 的性能，還使得 RLVR 框架中的獎勵估計存在偏差。為此，上海人工智能實驗室聯合西安交通大學等機構的研究者，系統地研究了測試用例生成（TCG）任務，提出了多維度量化測試套件全面性的指標體系，并引入“人 - LLM 協作”方法 SAGA（Strategic Adversarial & Constraint-differential GenerAtive workflow），顯著提升生成測試用例的覆蓋率和質量。并且還開發了 TCGBench，助力 TCG 任務研究。

實驗表明，SAGA 在 TCGBench 上將驗證器準確度（Verifier Accuracy，VAcc，衡量測試套件能否一次性拒絕所有已知錯誤解的指標）提升了 15.86%，基于 SAGA 的 CodeCompass 基準測試使模型 Pass@1 相對下降 9.56%，重塑了模型性能排行榜。這項研究已開源 TCGBench 和 TCGCoder-7B，期望推動 RLVR 研究發展。

這個研究非常有意思，我欣賞到的是一場 AI 原生的“定義任務”-“制定評估”-“人機交互”的一次研究實戰。這拋開研究課題內容本身，對于自己落地 AI，很有借鑒意義。下面我們一起來看看研究歷程。

現有代碼驗證方法的缺陷

主流代碼生成評估基準存在諸多不足，這些缺陷可能導致我們對 LLM 性能的評估過于樂觀，許多潛在錯誤未被發現。以下是現有代碼驗證方法的主要缺陷：

測試用例覆蓋不足

主流代碼生成評估基準的測試用例數量有限且同質化嚴重。HumanEval 平均每個問題僅提供 7.7 個測試用例，MBPP 每個問題僅提供 3 個，EvalPlus 盡管增加了測試數量，卻導致通過率驟降 15%，暴露出測試用例覆蓋面不足、同質化嚴重的問題。

LLM 生成測試用例的偏差

LiveCodeBench 利用 LLM 生成大量測試用例，在提升測試效率方面具有顯著優勢。然而，其生成的測試用例存在明顯偏差，傾向于反映 LLM 自身的典型、同質化錯誤模式，而人類編程錯誤則更加多樣化，涵蓋邏輯錯誤、整數溢出等多種復雜情況。這種偏差導致 LLM 生成的測試用例難以有效檢測人類編寫的錯誤代碼。

下圖（a）顯示，LLM 驗證器對人類代碼的漏檢率顯著高于 LLM 代碼。下圖（b）則揭示，LLM 誘導錯誤高度聚集，而人類錯誤分散。橫縱坐標為前兩主成分，LLM 錯誤呈 “致密團簇”（紅色），人類錯誤呈 “星云狀”（藍色）。距離越近代表錯誤模式越相似，可見 LLM 測試用例對 “團簇外” 的人類錯誤幾乎無感知。這進一步凸顯了現有驗證器在應對多樣化錯誤模式時的不足，強調了改進測試用例生成方法的必要性。

(a) LLM 驗證器對人類代碼漏檢率高；(b) LLM 錯誤模式分布與人類錯誤模式分布對比

既然“測得越多≠測得越好”，我們就需要一套更精細的尺子，來衡量“怎樣才算測得足夠好”。下面，我們先給出這套尺子的刻度——TCG 任務的正式定義與多維指標。

測試用例生成任務的形式化定義與多維度評估指標

帶著“尺子”的訴求，我們先把 TCG 任務放在放大鏡下：它到底要解決什么問題，又該用什么刻度來評價？

TCG 任務定義

多維度評估指標

為更精準衡量測試套件質量，提出以下多維度評估指標：

至此，我們有了刻度，下一步自然要問：現有方法到底離“刻度滿分”還有多遠？下面我們來了解一下三大主流范式。

現有 TCG 范式

在探討三種范式之前，我們先通過一張圖直觀對比它們的流程差異。

代碼評估流程與多種 TCG 范式

圖中清晰展示了：

• 直接生成（Direct Generation）
• 輸入解釋器（Input-Interpreter）
• 人類先驗（Human Priors，即本文中的 SAGA 方法）

三者在輸入來源、輸出驗證方式上的關鍵區別。

直接生成范式

直接生成范式通過直接提示 LLM 生成完整測試用例，包括輸入和輸出。然而，這種方法對 LLM 的深度理解能力要求極高，尤其是對邊緣情況的把握。實驗結果顯示，LLM 生成的測試用例保留率低，整體 DR 通常低于 60%，VAcc 低于 10%，且 LLM 生成的解決方案容易通過自身生成的測試用例，表明這些測試用例難以挑戰模型的認知偏差。例如，在生成復雜算法（如圖算法、動態規劃算法）的測試用例時，直接生成范式往往難以覆蓋所有關鍵路徑和邊界條件，導致生成的測試用例質量較低。

下圖（a）展示了 LLM 直接生成的測試用例質量低，下圖（b）顯示了其高自通過率，這表明 LLM 生成的測試用例存在明顯不足，難以有效檢測代碼中的錯誤。

 (a) LLM 直接生成測試用例質量低；(b) LLM 生成測試用例高自通過率

輸入解釋器范式

輸入解釋器范式由 LLM 生成隨機輸入，再由真實解釋器計算對應輸出。雖然這種方法可以生成大量測試用例，但單純增加數量無法根本提升檢測率，因為測試用例之間存在相關性。通過理論推導和實驗驗證，我們發現，隨著生成的測試用例數量 n 趨近于無窮大，在平均檢測概率 p 和平均正相關 p eff 穩定的情況下，檢測率的上限收斂于 。這表明，測試用例的相關性限制了檢測率的提升。例如，在測試一個數學計算函數時，輸入解釋器范式生成的測試用例可能集中在某些特定的數值范圍或計算模式內，導致無法有效檢測出在其他數值范圍或計算模式下的錯誤。

下圖（a）顯示，隨著測試用例數量增加，檢測率逐漸飽和，無法達到 100%。下圖（b）進一步表明，檢測率與測試用例數量的對數呈半對數關系，驗證了相關性對檢測率提升的限制。

(a) 檢測率隨測試用例數量增加而飽和；(b) 檢測率與測試用例數量的對數關系

Human Priors 范式（人類先驗）

Human Priors 范式利用人類的正確解決方案和錯誤解決方案來指導 LLM 生成測試用例。與前兩種范式相比，該方法能夠更好地結合人類的編程經驗和 LLM 的語義理解能力，通過人機交互，從而生成更高質量的測試用例。

三大范式對比

經驗告訴我們：單靠 LLM 或單靠人類直覺都不足以突破天花板。在 LLM 性能日趨強大的今天，我們可以嘗試“人機協作”，把二者擰成一股繩——這就是 SAGA（Strategic Adversarial & Constraint-differential GenerAtive workflow）。

SAGA：人 - LLM 協作的 TCG 框架

研究者提出 SAGA，正是為了回答“如何利用人類知識，卻不被人類知識的速度和規模所限”這一關鍵問題。

SAGA（Strategic Adversarial & Constraint-differential GenerAtive workflow）是一種創新的人 - LLM 協作框架，致力于生成高質量、多樣化且具有區分性的測試套件。該框架通過結合人類編程見解與 LLM 推理，充分利用正確解決方案和錯誤提交中的信息，以指導 LLM 構建挑戰性測試輸入。

工作流程

SAGA 的工作流程如下：

1. 輸入階段 ：SAGA 接收編程問題描述、正確解決方案以及錯誤提交。

2. 分析階段 ：SAGA 對正確解決方案進行多維度分析，提取約束處理差異和防御模式解構等關鍵信息；同時對錯誤提交進行差異分析，找出約束處理差異、防御完整性缺失和失敗模式。

3. 生成階段 ：SAGA 利用提取的信息指導 LLM 構建挑戰性測試輸入，并生成相應的測試用例。

4. 驗證階段 ：通過自驗證腳本驗證生成的測試用例是否符合問題約束和測試策略，確保測試用例的有效性和準確性。

下圖展示了 SAGA 框架的整體架構，包括輸入、分析、生成和驗證等階段，體現了其人 - LLM 協作的特點。

SAGA 框架架構

多維度分析與差異分析

多維度分析從正確解決方案中提取深刻見解以設計挑戰性測試，主要涵蓋約束處理差異和防御模式解構兩個方面：

• 約束處理差異 ：比較錯誤解決方案 Swrong 和正確解決方案 S′ 在處理問題特定約束上的差異，發現測試用例中約束條件的薄弱環節，從而設計出更能暴露錯誤的測試用例。例如，在一個資源分配問題中，正確解決方案可能嚴格遵循資源限制條件，而錯誤解決方案可能在某些情況下超出資源限制。通過分析這種差異，可以生成專門測試資源限制條件的測試用例。
• 防御模式解構 ：將正確解決方案中的防御邏輯和問題解決策略分解為正式的數學或邏輯約束，如 “等價類：玩家配對”，“邊界值：[(1,2), (N,N?1)]”，使 SAGA 能針對奇點、極端值或特定結構屬性生成邊緣和對抗性測試用例，提升測試用例的多樣性和針對性。例如，在一個網絡請求處理函數中，正確解決方案可能對各種異常請求（如超大請求、非法格式請求）進行了完善的防御處理。通過解構這些防御模式，可以生成相應的異常請求測試用例，驗證代碼在面對惡意攻擊或異常輸入時的魯棒性。

差異分析通過對比錯誤提交 Swrong 與其修正版本 S′ correct，發現常見錯誤模式。主要關注以下幾點：

• 約束處理差異 ：找出 Swrong 和 S′ correct 在處理問題特定約束上的差異。例如，在一個數據處理任務中，錯誤提交可能未正確處理數據的完整性約束，而修正版本則修復了這一問題。通過分析這種差異，可以生成專門測試數據完整性約束的測試用例。
• 防御完整性缺失 ：揭示 Swrong 在處理邊緣情況或邊界輸入方面的不足。例如，錯誤提交可能未對極端輸入值（如非常大或非常小的數值）進行有效的處理，導致程序崩潰或產生錯誤結果。通過差異分析，可以發現這些缺失的防御措施，并生成相應的邊緣輸入測試用例。
• 失敗模式分析 ：生成能觸發 Swrong 失敗但被 S′ correct 正確處理的特定輸入，將這些輸入納入測試套件 T，增強驗證器的區分能力。例如，錯誤提交可能在處理并發訪問時存在死鎖問題，而修正版本通過優化鎖機制解決了這一問題。通過失敗模式分析，可以生成特定的并發測試用例，驗證代碼在高并發場景下的正確性。

自驗證腳本

自驗證腳本在確保生成測試輸入符合問題約束和測試策略方面發揮著重要作用。它在執行前驗證測試輸入是否滿足問題要求，如檢查輸入是否符合指定范圍、格式等，從而提升生成測試用例的準確性和有效性，避免生成無效或不符合要求的測試用例。例如，在一個文件解析函數的測試中，自驗證腳本可以檢查生成的測試文件是否符合特定的文件格式規范（如 JSON 格式、XML 格式），確保測試用例的有效性。

SAGA 的優勢

與傳統 TCG 范式相比，SAGA 具備以下優勢：

1. 高質量測試用例生成 ：通過結合人類編程見解與 LLM 推理，SAGA 能夠生成更高質量的測試用例，有效提升測試套件的檢測率和驗證器準確度。

2. 多樣化測試用例 ：SAGA 的多維度分析和差異分析能夠生成多樣化的測試用例，覆蓋更廣泛的錯誤模式，降低測試用例之間的相關性。

3. 適應性強 ：SAGA 對不同的 LLM backbone 具有良好的適應性，即使使用較小的模型也能取得優異的性能。

SAGA 的實驗驗證

通過實驗驗證 SAGA 框架在提升測試用例生成質量方面的有效性，并與現有方法進行對比，分析其優勢和局限性，提出實驗。

實驗設置

在 TCGBench 上對 SAGA 進行了全面驗證。TCGBench 匯集了來自 Atcoder、Codeforces 和 Nowcoder 的 1840 個近期編程問題，每個問題平均包含 36.66 個錯誤用戶提交。我們采用了 DeepSeek-V3-0324、Qwen2.5-72B-Instruct 和 Qwen2.5-Coder-32B-Instruct 等開源 LLM 模型，并運用檢測率（DR）、驗證器準確度（VAcc）、不同錯誤模式覆蓋率（DEPC）和多樣性比率（Diversity Ratio）等指標進行評價。

關鍵發現與圖表引用

實驗結果顯示，SAGA 在檢測率、驗證器準確度等關鍵指標上顯著優于隨機輸入解釋器基線及其單獨分析組件。例如，在 270 道 TCGBench-Lite 難題上，SAGA 將 VAcc@50 從隨機基線的 16.72% 提升到 32.58%，提升 15.86 個百分點，相當于讓每三個原本蒙混過關的錯誤解中多抓出一個。其 AUC@50（0.5445）是基線的 2 倍。這表明 SAGA 能更有效地檢測錯誤，生成更具區分性的測試用例。

下圖（a）展示了 SAGA 在檢測率上的表現遠超基線和單獨分析組件，下圖（b）顯示了 SAGA 在驗證器準確度上的顯著優勢，下圖（c）和下圖（d）分別呈現了 SAGA 在不同錯誤模式覆蓋率和多樣性比率方面的優秀表現。

(a) SAGA 檢測率表現；(b) SAGA 驗證器準確度表現；(c) SAGA 不同錯誤模式覆蓋率；(d) SAGA 多樣性比率表現

進一步分析發現，SAGA 生成的測試用例在不同錯誤模式覆蓋率和多樣性比率方面也表現出色，能夠更廣泛地覆蓋錯誤模式，降低測試用例之間的相關性，從而提高測試套件的整體質量。例如，在一個字符串處理函數的測試中，SAGA 生成的測試用例涵蓋了各種字符串邊界情況（如空字符串、超長字符串、包含特殊字符的字符串），而基線方法生成的測試用例則主要集中在普通字符串情況，未能有效覆蓋邊界情況。

消融實驗

通過對 SAGA 進行消融實驗，研究者深入分析了其各個組件對性能的影響。結果表明，多維度分析和差異分析組件的協同作用是實現 SAGA 優越性能的關鍵。以下是消融實驗結果：

從表中可以看出，SAGA 對 LLM backbone 變化表現出良好的魯棒性，即使使用較小的 Qwen2.5-Coder-7B 模型，也能取得與基線方法相媲美甚至更優的性能。這充分證明了 SAGA 框架的有效性和適應性。

下圖展示了 SAGA 在不同 LLM backbone 下的性能表現，表明其在不同模型和問題來源下均能顯著提升檢測率和驗證器準確度。

SAGA 在不同 LLM backbone 下的檢測率和驗證器準確度表現

基于 SAGA 的高級應用

帶著實驗驗證的信心，研究者讓 SAGA 直接“接管”了 270 道最新競賽題，由此誕生了更嚴苛、更公平的全新基準——CodeComPass。

CodeComPass 基準測試

研究者基于 SAGA 開發了 CodeComPass，這是一個高質量的代碼生成評估基準測試。與 LiveCodeBench-v6 相比，CodeComPass 在驗證器質量、對代碼生成模型評估的區分能力等方面實現了顯著提升。例如，在共享子集上，CodeComPass 的 DR@40 比 LiveCodeBench-v6 高出 14.59 個百分點，VAcc@40 高出 10.78 個百分點，多樣性比率高出 43.13%，AUC@40 高出 43.4%。這些提升表明，CodeComPass 能更準確地評估代碼生成模型的性能。

CodeComPass 在不同難度問題上的平均 Pass@1 表現

上圖顯示了 CodeComPass 在不同難度問題上的平均 Pass@1 表現，表明其對模型性能的區分能力更強。下圖則展示了模型在 CodeComPass 和 LiveCodeBench-v6 上的排名變化，凸顯了 CodeComPass 能更細致地揭示模型之間的性能差異。

模型在 CodeComPass 和 LiveCodeBench-v6 上的排名變化

對 RLVR 的影響

SAGA 生成的高質量驗證器顯著提高了 RLVR 框架的準確性。通過提供更準確的獎勵信號，SAGA 減少了獎勵欺騙現象，使模型在訓練過程中能更真實地反映其性能。例如，在使用 SAGA 生成的測試套件進行訓練時，模型在復雜編程問題（如圖算法問題、動態規劃問題）上的性能提升更為顯著，代碼生成的正確性和魯棒性得到增強。這為開發更強大、更可靠的代碼生成模型奠定了基礎。

至此，從“發現問題”到“定義刻度”再到“交付工具”，我們已經跑完一個完整閉環。這就是一個關于“評估”的研究案例。

總結

本文重新審視了基于 LLM 的 TCG 方法，通過構建 TCGBench、提出 SAGA 框架以及開發 CodeComPass 和 TCGCoder-7B 等實際舉措，為提升 LLM 代碼評估的可靠性提供了切實可行的方案，提升了 RLVR 的性能，也為自動化對抗測試合成和自適應基準整合奠定了基礎。這些成果在優化代碼生成評估方法、提高模型訓練效率和增強代碼生成質量方面具有重要意義。

如同我在文章開頭所說的那樣，這份研究真正吸引我的是研究者對“方法論”的演示。這對于我們在 AI 應用中的“評估”設計以及落地，具有較高的參考價值。以下是我的一點學習后的觀感，分享給大家：

把“評估”做成產品：一次 AI 原生的方法論演練

如果把這篇論文只看成一個“更高明的測試用例生成器”，就低估了它的示范價值。它真正精彩的，是把“評估”本身當成一個可迭代、可度量、可規模化的 AI 產品——從任務定義、指標設計、數據構造、算法框架到最終交付，形成了一條AI-native 的閉環。下面我用五個關鍵詞，把這條閉環抽出來，供任何想在垂直場景落地 AI 的同學做一點參考，如果你覺得我說的不對，我希望能與你成為“覺察流”的社區伙伴，我們一起探討、進化。

1. 痛點溯源：把“感覺不對”翻譯成“指標不對”

• 現象?HumanEval 看似 80+ 分，實則在 LeetCode 真·評測機上 20 %～40 % 的題被打出 WA（Wrong Answer）。
• 翻譯?不是模型菜，而是“測試用例的檢測率 / 驗證器準確度”這兩個維度被嚴重高估。

啟發：先別急著改模型，先改“尺子”。把“我覺得測試不夠”翻譯成可計算的 DR（Detection Rate） 與 VAcc（Verifier Accuracy），問題立刻有了抓手。

2. 任務定義：把“測試生成”升格為 TCG 任務

• 輸入：問題描述 + 題解空間 + 歷史 WA/TLE（Time Limit Exceeded） 代碼
• 輸出：用例集 T
• 目標：最大化 DR（檢測率） & VAcc（驗證器準確度），同時最小化測試冗余， 也就是≈ 最小化 （平均有效相關系數，可以理解為“測試之間不要互相抄答案”）。

啟發：用一句話把任務寫成“帶約束的優化問題”，后面就能用算法和數據來解。

3.據工廠：把公開平臺變成“錯誤市集”

• 從 AtCoder / Codeforces / Nowcoder 抓 1840 道最新題 + 36.66 條真實錯誤提交 / 題
• 人工去噪，但不人為寫用例——讓數據保持“野生”分布

啟發：高質量數據不必從零標注；把公開資源“切一刀”就能變成科研級數據集（TCGBench）。這一招可復制到任何帶評測記錄的開源社區。

4. 人機協作：讓 LLM 做“放大器”，人類做“瞄準鏡”

SAGA 人機協作中，有個很妙的點，就在于雙向蒸餾：

• 正向蒸餾：從 AC（Accepted） 代碼里提煉“等價類 + 邊界值 + 防御模式” → 告訴 LLM “該往哪打”。
• 反向蒸餾：從 WA（Wrong Answer） 代碼里提煉“錯誤觸發路徑” → 告訴 LLM “別人在哪兒跌倒”。最后讓 LLM 寫腳本、寫解釋、寫自檢，完成大規模、低人力的對抗用例倉庫。

啟發：與其讓 LLM 瞎猜，不如用“人類錯題本”給它裝一個導航系統（指導作用）；既解決規模，又保留人類經驗。

5. 產品化交付：把“論文指標”變成“行業基準”

• CodeComPass：270 道最新題 + 50.54 個 SAGA 用例 / 題 —> 直接替換 LiveCodeBench 子集，立刻讓排行榜重排座次。
• TCGCoder-7B：用 15 k 題蒸餾出 7 B 小模型，推理成本降一個量級，效果卻吊打 70B 通用模型。

啟發：評估基礎設施一旦做成“即插即用”的組件，就能反過來喂養訓練、評測、產品迭代的全鏈路。

把“測得更準”升級為“做得更對”

當你把評估工具做成產品，它就不僅是“扣分器”，而成了持續改進的飛輪：

• 對研究者而言：TCGBench + CodeComPass 提供了可復現、可對抗的科研沙盒；
• 對工程師而言：SAGA 用例腳本可以直接嵌入 CI（持續集成），讓每一次 PR 都跑在更嚴苛的測試上；
• 對 RL 訓練者而言：更準確的獎勵信號讓模型不再“鉆測試空子”，而是真正學會“寫對代碼”。

這正是 AI 時代的方法論：把“主觀經驗”轉成“可計算指標”，把“人力痛點”轉成“數據紅利”，把“一次性實驗”轉成“可持續迭代的系統”。

所以，我的理解，SAGA 是一套可遷移的模板。那么，，下一次，無論你是做表格理解、藥物發現還是硬件驗證，都可以復現這條“定義任務 - 設計指標 - 人機協作 - 數據閉環 - 產品化交付”的步驟。

一句話：評估不是成本，而是杠桿；把它做到極致，剩下的就只是時間問題了。