Claude、GPT、Gemini 全滅，SWE-Bench作者新作把AI圈干沉默了

編輯｜Sia

SWE-Bench 的創建者，剛剛又放出了一個地獄級新 benchmark。

結果相當震撼：

Claude Opus 4.7、GPT-5.4、GPT-5 mini、Gemini 3.1 Pro、Gemini 3 Flash——這一代幾乎所有最強的一線模型，全部 0% 完成率。

沒有一個模型，能夠真正完整重建一個軟件項目。

這意味著什么？

今天的大模型，已經很會寫代碼了，但依然不會做軟件工程。

最近，Meta FAIR 聯合斯坦福、哈佛等機構發布了一項很有意思的新 benchmark，本質上是在重新定義 AI Coding 的評估方式：

ProgramBench: Can Language Models Rebuild Programs From Scratch?

過去的大模型編程 benchmark，大多測的是局部能力：補全函數、修復 bug、實現 feature……本質上，仍然是在已有代碼結構里做局部修改。

而 ProgramBench 第一次把問題推進到了真正的軟件工程層面：如果只給 AI 一個程序的功能描述和 usage docs，它能不能像真正的工程師一樣，從零開始，重新構建一個真實、可執行的軟件系統？比如 ffmpeg、SQLite、ripgrep。

而且——不能聯網。

換句話說：模型到底有沒有工程智能？

為了測試這一點，研究團隊直接刪除了原始源碼和測試，只保留 executable 和 usage docs，模型需要自己決定語言、架構、模塊拆分、數據結構乃至整個 repo 的組織方式。

更關鍵的是，ProgramBench 不再按照源碼相似度打分。它采用的是 behavioral equivalence，行為等價。也就是說，你可以用完全不同的語言、算法、架構，甚至完全不同的工程實現。只要最終輸入輸出行為與原程序一致，就算通過。

研究團隊甚至使用了 agent-driven fuzzing，自動生成大量端到端行為測試。

這是第一次，一個 benchmark 真正開始逼近現實世界的軟件工程，而不再只是代碼做題。結果出來之后，整個 AI 圈都沉默了。

所有模型：0% 完成率。

Table 2 負責制造震撼，那么 Figure 4 負責解釋震撼背后的細節。它告訴我們，模型并不是完全不會做，而是經常能做出一部分，甚至在少數任務上接近完成；但只要要求 100% 行為等價，所有模型都會倒下。但這最后一公里，正是軟件工程和普通代碼生成最大的區別。另外，如果矮子里面拔將軍，Claude 系列（尤其是 Opus 4.7 和 4.6）表現相對最好。

即便論文專門增加了一個Almost指標——統計那些完成度超過 95% 的任務。目前表現最強的 Claude Opus 4.7，也只有 3% 的任務接近完成。

論文里，有一句特別關鍵的話：

Models favor monolithic, single-file implementations that diverge sharply from human-written code.

翻譯過來就是：模型極度傾向于生成單體化代碼。大量邏輯被塞進單文件；目錄結構極淺；模塊拆分極少；函數超長；整個 repo 看起來像一坨巨型腳本。

這和優秀人類工程師的習慣，幾乎完全相反。

后者往往講究模塊和關注點分離，會把代碼拆得很優雅——配置放config.json，工具函數放utils.py，數據庫操作放db.py，然后通過import相互調用。

這其實暴露出了一個非常核心的問題：AI 擅長的是局部代碼生成，但不擅長全局系統規劃。而真實的軟件工程，本質上恰恰是后者。

這也是為什么模型在 LeetCode、SWE-Bench、Copilot 場景里已經非常強，一旦進入真實世界的大型工程系統，就會迅速掉進深水區。

當前 AI Coding 的真正瓶頸已經不再是代碼生成能力，而是長期的軟件系統構建能力。

另一個很有意思的結果，是不同語言之間的表現差異。

研究團隊分別統計了模型在 C/C++、Go、Rust 等不同語言項目上的表現。可以明顯看到，傳統 C/C++ 項目完成度最高，而 Rust 表現最差。

不同模型在任務難度上的排序高度一致：nnn、fzf、gron 這類相對簡單的 CLI 工具，模型普遍能拿到更高通過率；但 FFmpeg、php-src、typst、ast-grep 這類復雜系統，幾乎所有模型都很難推進。這說明 ProgramBench 測到的不是某個模型偶然失手，而是復雜軟件系統本身對當前模型形成了穩定壓制。

這其實并不讓人意外。

互聯網里關于 C/C++ 的歷史代碼、工程實踐和 Stack Overflow 內容實在太多了，模型已經被這些模式浸泡了很多年。

而 Rust 的工程哲學本身就更強調模塊化、ownership、trait system 和長期可維護性，這些恰恰是當前模型最不擅長的東西。

某種意義上，Rust 測出來的，其實不是代碼能力，而是工程能力。

隨著 ProgramBench 引發熱議，圍繞這項 benchmark 的爭論也開始迅速擴散。其中最主要的質疑之一是：這不就是在考模型有沒有背過 FFmpeg 嗎？畢竟，ProgramBench 里的很多項目本身就是公開開源軟件。

對此，知名硅谷投資人 Deedy Das 專門發文回應：任何 benchmark 都可能被 overfit。

SWE-Bench 可以被記住 bug，LeetCode 可以被背題，甚至 ARC-AGI 未來也可能通過隱藏題庫來避免泄漏。單純討論是否存在記憶本身，其實并不能否定 benchmark 的價值。

他認為：如果模型真的試圖用 brute force 的方式去硬背這些程序，它往往會在別的地方明顯退化。

因為真正的大模型訓練，并不是簡單把整個 FFmpeg 塞進參數里。更何況，研究人員還可以通過比對生成代碼與原始源碼的相似度，去檢測是否存在直接 memorization。

他真正想強調的，從底層重建一個真實世界的軟件系統，本身就是一種高 utility、長時間跨度的復雜任務。如果模型真的能夠推理并完成這類任務，那么這種能力很可能會泛化到大量其他工程場景中

另一類爭議則更有意思。有人吐槽說：連人類都不可能從零重寫 FFmpeg，這 benchmark 根本不合理。

Deedy Das 回應，那又怎樣？今天很多 LLM 能做到的事情，人類平均水平也做不到。

benchmark 的目標，從來不是模擬普通人的平均能力，而是推動模型向更高層次的智能逼近。人類做不到，并不意味著 benchmark 沒價值。

比如，AlphaGo 下棋超過絕大多數人，并不影響它推動了 AI；同樣，一個遠高于普通工程師能力邊界的 benchmark，也可能是未來 Agent 系統必須攻克的問題。

當然，他也承認，ProgramBench 仍然存在不少缺陷。比如，目前它沒有測試 Claude Code、Codex 這類完整的 agent harness；只統計是否完成，沒有更細粒度地衡量進展。

同時還限制了聯網能力，以避免一些明顯作弊行為。

Deedy Das 同意，這可能導致模型為了在特定指標上得分而走偏（Hill-climbing on the wrong thing）。不過，人們也隨時可以增加一項在有網絡訪問權限下的性能測試作為對比。

還有人建議：為什么不用真正沒人解決過的新問題？對此，Deedy Das 表示，因為那會讓 benchmark 幾乎無法構建。

你很難為一個沒有標準答案的問題設計完備測試；也很難判斷任務是否真的屬于現實世界工程任務，還是研究者憑空捏造出來的 challenge。

但這些問題，其實都可以隨著 benchmark 演進繼續修正。

真正重要的是：ProgramBench 第一次把 AI Coding 的評估，從函數級拉到了系統級。它暴露出的，也是整個行業當前最大的斷層：真正的軟件開發，從來都不是寫一個函數，而是如何做出一個能被維護、被擴展、被團隊協作的工程系統。

今天的大模型，已經非常擅長生成局部代碼。但依然缺乏長期、一致、穩定地維護復雜系統的能力。

所以你會發現，最近整個行業都開始瘋狂研究另一批關鍵詞：memory、agents、repo-level reasoning、long-horizon planning、autonomous software engineering。

因為下一階段的競爭，可能已經不再是誰能一次性生成更長的代碼，而是誰能在長時間、多輪交互、復雜上下文中，持續穩定地維護一個活著的軟件系統。

論文鏈接：

https://programbench.com/static/paper.pdf