# FrontierCode Diamond：50 個困難任務中 13.4% 的修補程式可合併（2026 年 6 月） > 2026 年 6 月 FrontierCode 結果：Diamond 50 個困難任務為 13.4%，Extended 為 51.8%；以及如何檢查 AI 生成修補程式。 Source: https://ailoot.ai/blog/zh-hant-tw/frontiercode-benchmark-mergeable-ai-code/ Canonical: https://ailoot.ai/blog/zh-hant-tw/frontiercode-benchmark-mergeable-ai-code/ Language: zh-Hant-TW Publisher: Ailoot (https://ailoot.ai/) Translation: guide-173 Revision: sha256-fcc6a53b0bb967aa62089fb850f778266892f0695c7e88806c7967df4772d156
重點摘要 2026 年 6 月 8 日，Cognition 發布了 FrontierCode。這項基準測試衡量真實開放原始碼儲存庫的維護者，是否會同意將 AI 產生的程式碼合併到自己的專案中。最受矚目的結果是：即使是業界最強的模型 Claude Opus 4.8，在最困難的 50 項任務中也只通過 13.4%。HumanEval 和 SWE-bench 等舊基準測試衡量的是「程式碼能不能執行」；新的基準測試衡量的是「維護者會不會接受這個 PR？」這改變了所有將 AI 產生的程式碼推上正式環境的人所採用的評估標準。
工具設定的其他資料請參閱 [Ailoot 文件](https://ailoot.ai/docs/)。
[Ailoot 指南](https://ailoot.ai/docs/)
## FrontierCode 是什麼？為什麼它很重要？
重點摘要 FrontierCode 是 Cognition 推出的 AI 程式碼品質基準測試，於 2026 年 6 月 8 日發布。它評估修補程式是否符合基準以維護者為導向的合併標準。這是定義明確的基準結果，不代表所有 AI 程式碼的正式環境就緒率。20 多位大型開放原始碼專案的維護者，每項任務花費超過 40 小時，設計出不只要求正確性，還要求風格、安全性與測試的情境。
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 嗎？」
重點摘要 FrontierCode 以 6 個面向評估每個解法：修補程式是否解決任務、是否避免破壞其他程式碼、是否通過建置與 lint 檢查、是否有有效的測試、是否符合範圍，以及程式碼是否易讀。修補程式必須通過全部 6 個面向，才算可合併。只要一項沒通過，PR 就不會合併。評估標準因此從自動化測試轉向真實維護者的判斷。
六個評估面向（摘自 Cognition 官方部落格）： 1. **行為正確性** — 修補程式有解決任務嗎？ 2. **回歸安全性** — 有避免破壞既有程式碼嗎？ 3. **機械品質** — 有通過建置、lint 和風格檢查嗎？ 4. **測試正確性** — 代理程式撰寫的測試有效嗎（任何程式碼都能通過的測試不算）？ 5. **範圍** — 修補程式有避免修改未要求的檔案嗎？ 6. **程式碼品質** — 程式碼有遵循專案慣例，而且易讀嗎？ 修補程式必須通過**全部六個面向**，才算可合併。只要一項沒通過，就不會合併。 這就是觀點上的主要轉變。正如 Cognition 所說：「正確性現在只是基本門檻。」過去，基準測試問的是：「程式碼通過測試了嗎？」現在問的是：「真正的技術主管會把這段程式碼納入專案嗎？」 Cognition 引入了三種新的評分技術： - **Reverse-Classical**：代理程式撰寫的測試必須在程式碼的錯誤版本上失敗，否則這個測試就是假的。 - **Code Scope**：自動檢查器會確認修補程式是否遵守任務約定的檔案範圍與行數。 - **Adaptive Classical Grading**：LLM 工具「mutagent」會讓嚴格的測試適應有效解法的不同變體。 ## 為什麼舊基準測試已經不管用了？
重點摘要 HumanEval（Codex，2021 年）和 SWE-bench 檢查程式碼是否通過自動化測試。它們無法發現測試通過、但沒有人願意接受 PR 的情況：程式碼很粗糙、破壞相鄰模組，或超出任務範圍。2026 年 3 月，一項獨立研究找來 4 位真正的維護者，評估 SWE-bench Verified 中 296 個 AI 產生的 PR：維護者的決定平均比自動評估器低 24 個百分點。這表示大約一半「成功」的 PR 不會合併進真正的儲存庫。
到了 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%
重點摘要 Cognition 發布了涵蓋三個子集、共 12 個模型的排行榜。Anthropic 的 Claude Opus 4.8 在 Diamond 以 13.4% 領先。接下來是 GPT-5.5 的 6.3%、Claude Opus 4.7 的 5.2%，以及 Google Gemini 3.1 Pro 的 4.7%。最佳開放程式碼模型是 Moonshot 的 Kimi K2.6，得分為 3.8%。Cognition 自家的 SWE-1.6 模型則位於表格後段，得分為 2.5%。這是反駁自我吹捧指控的重要證據。
| 模型 | Diamond（50） | Main（100） | Extended（150） | |---------------------------------|--------------|------------|----------------| | **Claude Opus 4.8**（Anthropic） | **13.4%** | 34.3% | 51.8% | | GPT-5.5（OpenAI） | 6.3% | \- | \- | | Claude Opus 4.7（Anthropic） | 5.2% | \- | \- | | Gemini 3.1 Pro（Google） | 4.7% | \- | \- | | GPT-5.4-mini（OpenAI） | 4.6% | \- | \- | | Kimi K2.6（最佳開放程式碼模型） | 3.8% | \- | \- | | Claude Sonnet 4.6 | 3.5% | \- | \- | | **SWE-1.6**（Cognition） | **2.5%** | \- | \- | | MiniMax M2.7 | 2.4% | \- | \- | | MiniMax M2.5 | 1.1% | \- | \- | | Kimi K2.5 | 1.0% | \- | \- | | Gemini 3.1 Flash Lite | 0.7% | \- | \- | 表格中值得注意的幾點： - **領先者明確。** 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% 可合併」代表什麼？
重點摘要 依報告中 Opus 4.8 對 Diamond 精選 50 個困難任務的執行結果，13.4% 修補程式符合基準合併標準，86.6% 不符合。這不能證明所有被拒修補都看似正確，也不能套用到一般專案工作。實際進行氛圍式程式設計時，這表示遇到困難的變更，不能只看測試變綠就直接推送。新專案中的簡單變更則是另一回事；AI 擅長處理這些工作。「何時推送、何時手動完善」的界線已經改變。
首先，要重新理解一件重要的事：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 個面向之一。
[Ailoot 指南](https://ailoot.ai/docs/)
## AI 在困難任務中會犯哪 6 類錯誤？
重點摘要 FrontierCode 的 6 個面向，對應 AI 代理程式經常犯的 6 類錯誤。這些是弱結果中可預期的模式。隨機挑一份 Claude 或 Codex 產生的修補程式，依照這 6 個面向評估，只要有一項不合格，真正的技術主管就不會接受。若要放心將程式碼推上正式環境，你必須在合併前自行檢查這 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 個步驟
重點摘要 這份 5 步驟檢查清單涵蓋 FrontierCode 的 6 個面向和安全檢查。Claude 或 Codex 產生的每份修補程式，都要在發布前依照清單逐項檢查。步驟不多，每項只花幾分鐘，回報卻很可觀：花 10 分鐘跑完清單，總比花 4 小時用 git rewind 回復正式環境專案，再從備份還原資料庫好。
1. ### 執行完整測試套件，而不只是與變更相關的測試 AI 常會修改超出任務範圍的程式碼，問題可能會出現在相鄰測試中。我會執行完整測試套件，只用單一命令 `npm test`（不指定路徑），而不只執行特定檔案的測試。大型專案可以使用 git worktree 平行執行（請參閱[Claude Code 中的 Git worktree](https://ailoot.ai/blog/zh-hant-tw/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 和人工審查自動檢查。 ## 究竟什麼能提升程式碼可合併的機率？
重點摘要 FrontierCode 描述了問題。解決方法在於與 AI 協作的方法論；單純更換模型在這裡幾乎沒有差別。真正帶來差異的是三項做法：專案規則、專案地圖和上下文工程。沒有它們，即使 Opus 4.8 也會產生看似合理的垃圾。這些做法讓代理得到更清楚限制，但困難變更仍須經過儲存庫檢查與審查，才可合併。
在未經準備的專案裡，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 的想法相同：將「撰寫者」和「技術主管」的角色分開。 另請參閱：[氛圍式程式設計安全](https://ailoot.ai/blog/zh-hant-tw/vibe-coding-security/)、[如何設定 Claude Code，避免它在夜間破壞專案](https://ailoot.ai/blog/zh-hant-tw/claude-code-safe-overnight-setup/)，以及 Context Engineering 這個概念。
### 來源 - [Cognition - FrontierCode 介紹（2026 年 6 月 8 日）](https://cognition.com/blog/frontier-code) - [Cursor Bugbot - 程式碼審查代理程式](https://cursor.com/bugbot)
工具使用方式的其他資料請參閱 [Ailoot 文件](https://ailoot.ai/docs/)。
[Ailoot 指南](https://ailoot.ai/docs/)
[前往 Ailoot](https://ailoot.ai/)
## 常見問題：FrontierCode Diamond：50 個困難任務中 13.4% 的修補程式可合併（2026 年 6 月） ### 13.4% 代表所有 AI 程式碼只有這個比例適合正式環境嗎？ 不是。這是報告中 Opus 4.8 在 FrontierCode Diamond 精選 50 個困難任務上的可合併結果。同表 150 個任務的 Extended 為 51.8%；兩者都不衡量全部 AI 生成程式碼。 ### 測試通過，為什麼仍不足以合併修補程式？ 基準還檢查回歸、建置與風格、測試能否抓出錯誤實作、範圍及程式碼品質。請檢查實際差異並執行儲存庫驗收；單一綠燈不能證明所有條件都符合。 ## Ailoot · 公司及其專案組合 Ailoot以累積的營運經驗、廣大的客戶群、穩定的服務及持續的KPI管理為基礎。 公司及其專案組合：數百萬客戶，每月銷售額達數十億。 Ailoot將這些營運經驗用於API存取，讓客戶的產品、代理、應用程式及自動化流程使用AI功能。