從「過單測」到「能 merge」：coding 評測的方法論轉向

FrontierCode 告訴你，那些通過的 PR，多數不會被真正的 maintainer merge 進 main。

這個矛盾一直存在，只是沒人把它量清楚。Cognition 研究團隊設計 FrontierCode，靈感來自 FrontierMath 的哲學：用足夠難、足夠真實的題目，探出真正的能力上限。題目由開源專案維護者參與建構，每題超過 40 小時，評分維度包括 regression safety（迴歸安全性）、cleanliness、scope 控制、test correctness 與 maintainability。核心問題只有一個：這份 PR，maintainer 敢 merge 嗎？

這是方法論轉向，不只是難度升級。SWE-Bench 式評測問的是「能不能讓 test suite 變綠」，可以靠補測試或繞過框架弱點刷分。FrontierCode 問的是程式碼改動是否有品質、有紀律、風險可控，這需要模型真正理解 codebase 結構與維護者的隱性偏好。結果：目前看來最強的 Opus 4.8 在最難子集只有約 13%。METR 的研究也從另一個角度印證：通過 SWE-Bench 的軌跡，在真實 PR review 中大量無法過關。

這意味著，過去幾年的 benchmark 進展，有相當一部分量的是「讓評測框架的 test 過」，而非「寫出可以活在真實 codebase 的程式碼」。這兩件事差很遠。

對自建 coding agent 評測的團隊，信號很直接：如果你的指標只有 test pass rate，你可能在優化一個和真實工程品質高度脫鉤的數字。可以考慮的方向：讓真實維護者做盲測 review、評估「改動是否縮小而非擴大 scope」、或明確追蹤 PR 在真實 review 的通過率。FrontierCode 示範了一件事：把評測設計權交給真正要 merge 程式碼的人，問題的性質就會不一樣。

Coding 遠未被解決。產業過去幾年一直在量錯東西，只是數字夠漂亮，少有人停下來問。現在輪到各個團隊決定要不要調整自己的尺。