FrontierCode Diamond：50 個困難任務中 13.4% 的修補程式可合併（2026 年 6 月）

工具設定的其他資料請參閱 Ailoot 文件。

FrontierCode 是什麼？為什麼它很重要？#

Cognition 是 Devin（2024 年 3 月推出的第一位自主 AI 工程師）和 Windsurf（於 2025 年 7 月收購）背後的公司。他們也正在開發自家的 SWE-1.x 模型系列。這項基準測試發布於公開部落格 cognition.com/blog/frontier-code。

關鍵的轉變不在於新數字，而在於現在衡量事物所採用的尺度。

這項基準測試分為三個難度級別：Extended（150 項任務，完整集合）、Main（最難的 100 項，包含 Diamond）和 Diamond（50 項極難任務）。Cognition 刻意讓 Diamond「大致維持未飽和」狀態——即使是最強的模型，解出的比例也不到 15%。這是為了讓基準測試保有一年的發展空間，避免像 HumanEval 一樣在一個月內飽和。

FrontierCode 衡量什麼：「維護者會合併這個 PR 嗎？」#

六個評估面向（摘自 Cognition 官方部落格）：

1. 行為正確性 — 修補程式有解決任務嗎？
2. 回歸安全性 — 有避免破壞既有程式碼嗎？
3. 機械品質 — 有通過建置、lint 和風格檢查嗎？
4. 測試正確性 — 代理程式撰寫的測試有效嗎（任何程式碼都能通過的測試不算）？
5. 範圍 — 修補程式有避免修改未要求的檔案嗎？
6. 程式碼品質 — 程式碼有遵循專案慣例，而且易讀嗎？

修補程式必須通過全部六個面向，才算可合併。只要一項沒通過，就不會合併。

這就是觀點上的主要轉變。正如 Cognition 所說：「正確性現在只是基本門檻。」過去，基準測試問的是：「程式碼通過測試了嗎？」現在問的是：「真正的技術主管會把這段程式碼納入專案嗎？」

Cognition 引入了三種新的評分技術：

• Reverse-Classical：代理程式撰寫的測試必須在程式碼的錯誤版本上失敗，否則這個測試就是假的。
• Code Scope：自動檢查器會確認修補程式是否遵守任務約定的檔案範圍與行數。
• Adaptive Classical Grading：LLM 工具「mutagent」會讓嚴格的測試適應有效解法的不同變體。

為什麼舊基準測試已經不管用了？#

到了 2024 年，AI 代理程式早已在 HumanEval 上取得高分。SWE-bench Verified 也差不多：2025 年 8 月，OpenAI 公開承認資料污染問題（模型在訓練期間「看過」資料集）。基準測試失去了區分頂尖模型的能力。

動搖舊有衡量標準的關鍵研究發表於 2026 年 3 月。

研究做法如下：

• 從 3 個儲存庫（scikit-learn、Sphinx、pytest）中選出 4 位活躍維護者。
• 請他們評估 SWE-bench Verified 中 296 個 AI 產生的 PR——這些 PR 全都通過了自動化測試。
• 比較維護者的決定與自動評估器的結果。

換句話說，基準測試說「通過」，維護者卻說「不會合併」——平均每四個案例就有一個會發生這種情況。最常見的三大退件理由，以下按嚴重程度由低至高排列：

1. 程式碼品質 — 不符合儲存庫的風格。
2. 破壞其他程式碼 — 破壞相鄰的程式碼。
3. 核心功能失敗 — 儘管測試通過，仍未完整解決任務。

FrontierCode 正是將這個問題具體化。Cognition 採納這個想法，將它擴展成完整基準測試，參與維護者從 4 位增加到 20 多位。

另一記重擊來自 2025 年 12 月一項關於 AI 生成修補程式安全性的研究。

在這項研究中，使用 Claude 4 Sonnet 的 SWE-Agent 解法有 61% 在功能上正確，但安全的只有 10.5%。

程式碼通過測試，然而每兩個修補程式中就有一個會引入安全漏洞。SWE-bench 基準測試完全看不出這一點，因為它們不衡量安全性。FrontierCode 至少會透過「機械品質」和程式碼品質面向嘗試偵測這類問題。

模型排名：Opus 4.8 為 13.4%，GPT-5.5 為 6.3%#

表格中值得注意的幾點：

• 領先者明確。 Anthropic 的 Opus 4.8 領先最近的競爭對手約兩倍。在 SWE-bench 上不易察覺的差距，在 FrontierCode 上一目了然。
• 開放模型尚未追上。 最佳開放程式碼模型 Kimi K2.6 在 Diamond 的得分為 3.8%，比 Opus 4.8 低 3～4 倍。Cognition 尚未公布 Kimi K2.6 在 Main 和 Extended 的完整結果，因此目前還無法比較完整集合。
• Cognition 坦率地將自家模型列在排行榜後段。

Diamond 子集刻意維持「未飽和」狀態。Cognition 為未來數年預留了安全空間。過去的基準測試會在 12～18 個月內飽和，而 FrontierCode 的設計是要有更高的上限。

對使用 Claude Code 的氛圍式程式設計者來說，「13% 可合併」代表什麼？#

首先，要重新理解一件重要的事：FrontierCode 的 Diamond 集合刻意設計得極難。在沒有 40 個相依模組的新創專案中處理一般任務時，AI 代理程式的表現會明顯更好。同一個 Opus 4.8 在 Extended（完整的 150 項任務）中，取得 51.8% 的可合併率。這呈現的是完全不同的情況。

51.8% 適用於該基準的 150 項 Extended 任務，比 Diamond 結果高；但兩者都無法估計各模型在你自己任務的合併率。其他模型缺少 Main 或 Extended 分數，不能自行補上它們的表現。

對想將程式碼推上正式環境的氛圍式程式設計者來說，這代表：

• 測試通過不再代表「已準備好合併」。 AI 自己撰寫的測試可能毫無用處，因為它們可能對任何程式碼都會通過。FrontierCode 透過 Reverse-Classical 直接衡量這一點：如果測試在錯誤版本上不會失敗，就不算數。
• 儲存庫風格與慣例很重要。 專案已有固定模式，而 AI 沒有遵循時，真正的協作者不會接受這項變更。在沒有規則的個人專案中，這不算大問題；在團隊裡，這是首要問題。
• 測試無法解決安全問題。 記得前面提到的數字：61% 的修補程式正確，但只有 10.5% 安全。你必須另外使用能偵測權杖、.env 檔案和預設密碼的工具進行檢查。
• 超出任務範圍是 AI 的典型錯誤。 你請它修正授權函式，結果它連內部層和記錄功能也一起改寫。這是 FrontierCode 的 6 個面向之一。

AI 在困難任務中會犯哪 6 類錯誤？#

讓我們用淺白的語言逐一說明：

1. 行為正確性 — 修補程式有解決任務嗎？

最基本的面向。AI 常寫出看起來像解法、實際卻解決錯誤問題的程式碼。我請它「為訊息新增已讀回條」，它產生了 markAsRead 函式，卻沒有把函式接到聊天元件。函式測試通過了，但業務任務並未解決。

2. 回歸安全性 — 有避免破壞相鄰程式碼嗎？

AI 修改了一個模組，另一個模組卻不能用了。最常見的情況是：AI 代理程式更改函式簽章，卻忘了還有其他 17 個地方會呼叫它。SWE-bench 看不出這種問題，因為它們只執行單一檔案的測試。FrontierCode 會執行整個儲存庫的測試套件。

3. 機械品質 — 有通過建置、lint 和風格檢查嗎？

AI 可能產生在本機能編譯、但在 CI 中失敗的程式碼：少了 import、用 tab 取代空格、多了兩個行尾空格，或在 eslint.config.js 中出錯。在實際運作的專案裡，風格不是個人喜好，而是團隊規則。

4. 測試正確性 — AI 撰寫的測試有效嗎？

最棘手的面向。AI 寫了一個測試，而且通過了。但它可能對任何程式碼都會通過，包括錯誤的程式碼。我多次見過這種情況：測試檢查的是「指令碼有沒有當掉」，而不是「回傳結果正不正確」。FrontierCode 的 Reverse-Classical 正是用來抓出這種情況。

5. 範圍 — 修補程式有避免碰觸無關檔案嗎？

我請它修正一個函式，結果拿到修改 12 個檔案的修補程式，其中還包括與任務無關的檔案。這就是 AI 那種會破壞正式環境專案的「主動幫忙」：擅自修改我沒要求它動的東西。這個面向在 FrontierCode 中是硬性阻擋條件。

6. 程式碼品質 — 程式碼有遵循儲存庫的慣例嗎？

AI 可能會「從頭開始」寫一個函式，而不使用 lib/ 中現有的輔助函式；也可能用不符合專案風格的方式命名變數，或把邏輯放在錯誤的架構層。從測試的角度來看，一切正常；但從技術主管的角度來看，這段程式碼不會被合併。

推送前如何檢查 AI 程式碼：5 個步驟#

1. 執行完整測試套件，而不只是與變更相關的測試

   AI 常會修改超出任務範圍的程式碼，問題可能會出現在相鄰測試中。我會執行完整測試套件，只用單一命令 npm test（不指定路徑），而不只執行特定檔案的測試。大型專案可以使用 git worktree 平行執行（請參閱Claude Code 中的 Git worktree）。

2. 執行 lint、風格與型別檢查

   依序執行三個命令：eslint .、prettier --check .、tsc --noEmit。AI 代理程式可能漏掉 tab，也可能漏掉多餘的行尾空格。如果專案有嚴格檢查，請在發布前於本機執行。

3. 測試測試本身

   5 項檢查中最重要的一項。在程式碼中做一個小小的「破壞」（把 return true 改成 return false）。測試應該要失敗。如果測試沒有失敗，表示 AI 寫的只是表面工夫，毫無用處。刪掉這個測試，並要求 AI 重寫，明確規定測試必須在錯誤版本上失敗。

4. 檢查 AI 修改了哪些檔案

   git diff --stat 命令會顯示哪些檔案有變更，以及變更了多少行。如果你說「修好聯絡表單」，AI 卻動了 12 個檔案，那就超出任務範圍了。用一個指定檔案的命令還原多餘的變更。

5. 使用現成的技能執行安全檢查

   測試抓不到 SQL 注入或硬式編碼的密碼。我會使用 Claude Code 的現成安全技能（請參閱754 個現成安全技能）。至少要手動在專案中搜尋「password」、「secret」和「key」，並檢查 .env.example 是否完整。

這 5 個步驟涵蓋 FrontierCode 6 個面向中的 5 個（1～5）。第六個面向——程式碼品質——則透過 lint 和人工審查自動檢查。

究竟什麼能提升程式碼可合併的機率？#

在未經準備的專案裡，AI 代理程式只能看到你為它開啟的檔案。它不知道你過去的決策，也不知道你的慣例，更沒有模組地圖。處理簡單變更時，這不算大問題；處理困難變更時，缺少專案脈絡是值得改善的風險；但基準的 13.4% 並未將脈絡品質單獨確定為原因。

要把這 13% 變成真正能推上正式環境的成果，你需要：

1. 專案規則 — 讓 AI 重現你的推理方式，而不是網路上的平均作法。

這是一套你預先準備好的解法、習慣與經驗法則，採用 AI 代理程式每次收到請求時都會讀取的格式。規則累積到 30 條以上時，AI 就不再捏造「業界平均」作法，而會開始依照你的風格提出建議。要處理超出任務範圍的問題，只要在規則中加上一句：「不要修改請求中未明確指出的檔案。」

2. 專案地圖 — 描述專案的資料夾。

在這裡放入產品、受眾、經濟狀況、指標和設定。每次收到請求之前，AI 代理程式會讀取目錄，了解自己正在處理業務中的哪個部分。這會自動處理前面列出的兩項退件理由：風格與破壞其他程式碼。

3. Context Engineering — 管理請求前 AI 能看到的內容。

重點不是「如何措辭提示」，而是「在提示之前，要放什麼進入上下文視窗」。CLAUDE.md、前置條件，以及連結到目標檔案。這能處理行為正確性與程式碼品質方面的錯誤。

這些做法應用於準備檢查，不代表五個面向已通過。接受修補之前，請對實際變更驗證行為、回歸、測試、範圍與程式碼品質。

另一個加強層是審查代理程式：

• Cursor Bugbot — 每個 PR 都會自動執行審查。根據 Cursor 的說法，這項工具每月處理約 200 萬個 PR。
• Claude Code v2.1.172 的巢狀子代理程式 — 一個代理程式撰寫程式碼，第二個負責審查，第三個執行測試。這與 FrontierCode 的想法相同：將「撰寫者」和「技術主管」的角色分開。

另請參閱：氛圍式程式設計安全、如何設定 Claude Code，避免它在夜間破壞專案，以及 Context Engineering 這個概念。

工具使用方式的其他資料請參閱 Ailoot 文件。