FrontierCode: 產業界級程式碼品質的新基準
從正確性轉向可合併性
FrontierCode 是一個全新的程式碼基準測試，旨在衡量 AI 模型是否能產出高品質、具備可維護性，且人類維護者實際上會合併到正式生產環境程式碼庫中的程式碼。雖然之前的基準測試（如 SWE-Bench）主要關注功能正確性（程式碼是否能運作），但 FrontierCode 評估的是「可合併性」——這是正確性、測試品質、範圍紀律、風格以及對特定程式碼庫標準遵循程度的綜合體。
即使是目前最強大的模型也難以達到此標準。在難度最高的子集 FrontierCode Diamond 中，表現最好的模型 Claude Opus 4.8 僅獲得了 13.4% 的分數，緊隨其後的是 GPT-5.5 (6.3%) 和 Gemini 3.1 Pro (4.7%)。
基準測試結構與難度
FrontierCode 分為三個難度遞增的嵌套子集，以提供模型性能的細粒度視圖：
- Diamond: 最困難的 50 個任務。
- Main: 最困難的 100 個任務（包含 Diamond）。
- Extended: 全部的 150 個任務。
性能衡量透過兩個主要指標進行：通過率（解決方案是否通過了會阻止合併的所有「阻礙」標準）以及分數（評分準則項目的加權總和，若解決方案未能通過阻礙標準，則得分為零）。
解決現有基準測試的缺陷
Cognition 開發 FrontierCode 是為了解决 SWE-Bench Verified 和 Pro 等第一代基準測試中發現的三個主要問題：
1. 分類錯誤
現有的基準測試經常受到偽陽性（由於測試覆蓋率不足而獎勵了錯誤的解決方案）和偽陰性（由於測試過於特定而懲罰了正確的解決方案）的困擾。FrontierCode 透過採用更嚴格的品質控制流程，報告其偽陽性率比 SWE-Bench Pro 低了 81%。
2. 多樣性不足
FrontierCode 的任務並非透過程式化抓取單一 PR，而是由維護者從多個 PR 鏈和自由形式的請求中手選出來的。與 SWE-Bench Pro 相比，此基準測試所代表的程式語言數量也增加了三倍。
3. 過度規範化
許多基準測試提供過於詳細的提示詞，這會對模型進行「手把手」式的引導。FrontierCode 使用類似人類的、簡潔的任務描述——長度大約只有 SWE-Bench Pro 的三分之一——這要求代理程式 (agent) 必須從程式碼庫的上下文來推斷維護者的意圖。
方法論：FrontierCode 如何構建
專家主導的任務創建
Cognition 與來自 36 個旗艦開源專案的維護者合作。每位維護者在每個任務上花費了超過 40 小時，以定義其特定專案中「可合併」的含義，確保基準測試反映的是真實世界的專業判斷，而非簡單的 CI 通過/失敗邏輯。
多維度評估
FrontierCode 超越了簡單的單元測試，從六個維度來評估程式碼：
| Category | Method | Goal | | :--- | :--- | :--- | :--- | | Behavioral Correctness | Classical / Adaptive | 確保補丁 (patch) 解決了問題。 | Regression Safety | Command | 確保現有的功能不會損壞。 | Mechanical Cleanliness | Command | 通過構建、lint 和風格檢查。 | Test Correctness | Reverse-Classical | 驗證代理程式編寫的測試在原始損壞的程式碼上會失敗。 | Scope | Scope | 確保補丁僅修改必要的檔案/行數。 | Code Quality | Prompt (LLM) | 驗證對設計模式和可讀性的遵循程度。 |
新穎的評分技術
為了增加穩健性，此基準測試引入了三種特定技術：
- Reverse-Classical Testing: 強制代理程式編寫的測試在基礎提交 (commit) 上失敗，以證明代理程式確實理解了錯誤 (bug)。
- Code Scope Constraints: 自動對修改的檔案和行數增長施加限制，以防止不必要的重構。
- Adaptive Classical Grading: 使用名為
mutagent的工具來精確地修補測試環境，允許對可能在表面實作細節（例如函數名稱）上有所不同的開放式解決方案進行確定性測試。
社群洞察與評論
在發布之後，技術討論強調了關於此基準測試的影響和方法論的幾個關鍵點：
關於效率與智能的權衡： 一些觀察者指出，雖然 Claude Opus 4.8 在原始分數上領先，但 GPT-5.5 經常使用顯著更少的 token，達到具有競爭力的結果（在某些情況下甚至少達 4 倍），這表明其具有更好的成本與智能的權衡。
關於程式碼代理程式 (Coding Agents) 的本質： 批評者認為，程式碼代理程式的目標不應是「完美」的一次性提示詞到完成，而應是一個協作式助手。一位貢獻者指出：
"Handling comments and asking good clarifying questions when needed are real capabilities. Human SWEs interact plenty and real engineering has a certain density of questions about requirements, taste, and taste, and other big vague things."
關於評估的嚴謹性： 雖然此基準測試因其對偽陽性/偽陰性的關注而受到讚譽，如此使用者對「程式碼品質」的主觀性表示懷疑，認為既然人類無法總對於一個通用的品質標準達成共識，那麼為 LLM 衡量品質仍然是一個挑戰。