AI 修補基準忽視實務品質，研究揭示重大差距

西北大學的研究團隊在 112 個真實漏洞上對程式碼代理進行了系統性測試，這些漏洞分別取自 84 個使用 C/C++、Go 與 Rust 的開源專案。資料集同時收錄了原始概念驗證（PoC）觸發的崩潰測試，以及專案維護者自行提供的額外回歸測試，形成完整的驗證環境。

最引人注目的結果出現在 Claude Opus 4.7 模型身上。該模型在約 90 % 的案例中成功阻止了程式崩潰，但僅有 61 % 的情況通過了維護者提供的完整測試套件，凸顯防止崩潰與真正功能正確性之間的顯著落差。

僅以防止崩潰為基準的誤導性

傳統的修補基準往往只要修補能防止程式崩潰就視為成功，將此等結果等同於概念驗證。這種過於簡化的評估方式忽略了開發者為確保修補符合原始設計意圖且不引入回歸所撰寫的更深入驗證步驟。

在西北大學的實驗中，大約三分之一的 Claude Opus 4.7 修補在消除崩潰後仍未通過維護者的對齊測試——約有四成的修補表面上看起來有效，卻未滿足完整的開發者檢查。

基準設計中的偏見來源

arXiv 論文《On the Reliability of LLM‑Based Vulnerability Patching Benchmarks》指出，基準設計存在三個主要偏見維度：代理層面的因素（例如提示與工具的選擇）、評估框架的問題（包括權限錯誤、基礎設施漏洞與逾時處理）以及資料集層面的問題（單一 PoC 測試無法捕捉漏洞的根本原因）。

該研究的作者同樣使用了相同的 112 個漏洞集合，但額外加入了用於判斷是否符合原始設計原則的回歸測試與開發者測試。分析結果證實，即使是最新模型在這些額外測試上也僅有微幅提升，仍遠低於基線表現。

明確指示的影響

西北大學的研究人員報告指出，若向 AI 明確說明如何建置與測試程式碼，其在 C/C++ 漏洞上的成功率提升了整整 20 個百分點。此改善並未改變底層模型本身，凸顯了提示工程與測試導向指示的重要性。

兩項研究皆認為，基準分數對評估結果極為敏感。取得 Git 歷史、資料集內預載回應，或是逾時計算方式的差異，都可能人為抬升或壓低報告的效能指標。

• 確認維護者測試是否計入分數
• 驗證代理是否能存取 Internet 或 Git 歷史
• 記錄建置與測試指示所使用的完整提示
• 了解逾時與管線錯誤的計算方式

研究建議在審視任何 AI 修補工具的報告數據時，必須以這四項標準作為檢查點。缺乏此類盡職調查，組織可能會採用看似亮眼卻無法提供可靠、向上相容修補的解決方案。

對於使用中文的企業而言，關鍵結論十分明確：僅有高比例的崩潰防止率並不保證修補能通過完整的開發者測試。決策者應要求基準方法納入維護者自行撰寫的回歸測試、揭露任何外部資料存取，並對提示設計與逾時處理保持透明，才能信賴 AI 產生的修補能安全整合至生產程式碼中。

未來研究方向

未來的研究應持續探索如何在基準中加入更全面的功能驗證，並針對不同程式語言的特性設計專屬測試，以減少單一指標帶來的偏誤。同時，提升代理在受限環境下的可操作性，確保其能在不依賴外部網路或 Git 歷史的情況下完成修補與驗證。

最後，業界與學術界需要共同制定透明的報告格式，明確列出所有提示、建置指令與逾時設定，讓評估結果可被獨立復現，從而提升 AI 修補技術在實務中的可信度。