SWE-bench Verified 被汙染:OpenAI 2 月稽核發現 59% 缺陷案例

2 月 23 日,OpenAI 的 Frontier Evals 團隊發布了一篇文章解釋為什麼停止報告 SWE-bench Verified 分數。稽核發現基準中最難的測試案例中有 59.4% 存在根本性缺陷——測試要求問題陳述中未提到的精確函數名,或者檢查不相關的行為。更具譴責性的是:測試的每個主要前沿模型——GPT-5.2、Claude Opus 4.5、Gemini 3 Flash——都可以僅使用任務 ID 從記憶中逐字複現 gold-patch 解決方案。OpenAI 的結論很直接:「SWE-bench Verified 上的改進不再反映模型在真實世界軟體開發能力上的有意義改進」。他們建議改用 SWE-bench Pro。三個月後,其餘的代理程式碼行業仍在受汙染的基準上對自己進行排名。

目前發布的表格頂部數字是:Opus 4.7 上的 Claude Code 87.6%、GPT-5.5 上的 OpenAI Codex 約 88.7%(第三方追蹤器;OpenAI 本身不自我報告)、Gemini CLI 80.6%、OpenHands 72%、Augment Code 在其自己 harness 上自我報告 70.6%、Cursor 在預設設定下約 51.7%、GitHub Copilot 約 56%。在 SWE-bench Pro——OpenAI 現在推薦的替代品——上,相同的模型分數低得多:Claude Opus 4.7 64.3%,GPT-5.5 58.6%。Terminal-Bench 2.0 是另一個保持可信度的基準:Codex 82.7%,Claude Code 69.4%,Gemini CLI 68.5%。兩個基準家族之間的差距本身就是訊號:當一個評估的分數將模型壓向天花板,而另一個評估的分數將它們分散時,第二個正在做區分的工作。

更深層的問題是 benchmark 最大化和生產力最大化之間的差距。僅代理 scaffolding 就在相同模型上產生約 ±17 個問題的方差,這意味著 harness 選擇可以在任何給定執行中主導模型選擇。所有公開排名都沒有發布的 harness 規範,所以跨供應商的 apples-to-apples 比較實際上沒有進行——只是 apples-vs-每個供應商自己的數字。對建構者的實際含義是,正確的比較不是「哪個代理在 SWE-bench Verified 上領先」,而是「哪個代理在我的程式碼庫上、用我的 CI 和我的樣式約定解決我的任務」。有效的經驗方法是從你的真實積壓中執行 50 到 100 個任務對抗兩到三個候選者,並測量結果而不是分數。

實際符合資料的推薦模式是分層堆疊而不是單一工具押注。終端代理——Claude Code 或 Codex——在多檔案重構、架構變更和那種否則會燒掉高級工程師下午的除錯上賺回其成本。IDE 擴充功能——Cursor 或 GitHub Copilot——在內聯完成、快速編輯和日常工作期間的環境輔助上賺回其成本。開源代理——Aider、Cline、OpenHands——在你想交換模型、避免平台溢價或端到端稽核代理行為時賺回其成本。使用多個不是優柔寡斷;這是對專業化的誠實回答。基準方面:SWE-bench Verified 不再是你的朋友。SWE-bench Pro、Terminal-Bench 2.0 和你自己的程式碼庫才是。