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

編輯｜Sia

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

結(jié)果相當震撼：

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

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

這意味著什么？

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

最近，Meta FAIR 聯(lián)合斯坦福、哈佛等機構(gòu)發(fā)布了一項很有意思的新 benchmark，本質(zhì)上是在重新定義 AI Coding 的評估方式：

ProgramBench: Can Language Models Rebuild Programs From Scratch?

過去的大模型編程 benchmark，大多測的是局部能力：補全函數(shù)、修復(fù) bug、實現(xiàn) feature……本質(zhì)上，仍然是在已有代碼結(jié)構(gòu)里做局部修改。

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

而且——不能聯(lián)網(wǎng)。

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

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

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

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

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

所有模型：0% 完成率。

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

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

論文里，有一句特別關(guān)鍵的話：

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

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

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

后者往往講究模塊和關(guān)注點分離，會把代碼拆得很優(yōu)雅——配置放config.json，工具函數(shù)放utils.py，數(shù)據(jù)庫操作放db.py，然后通過import相互調(diào)用。

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

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

當前 AI Coding 的真正瓶頸已經(jīng)不再是代碼生成能力，而是長期的軟件系統(tǒng)構(gòu)建能力。

另一個很有意思的結(jié)果，是不同語言之間的表現(xiàn)差異。

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

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

這其實并不讓人意外。

互聯(lián)網(wǎng)里關(guān)于 C/C++ 的歷史代碼、工程實踐和 Stack Overflow 內(nèi)容實在太多了，模型已經(jīng)被這些模式浸泡了很多年。

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

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

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

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

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

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

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

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

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

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

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

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

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

同時還限制了聯(lián)網(wǎng)能力，以避免一些明顯作弊行為。

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

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

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

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

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

今天的大模型，已經(jīng)非常擅長生成局部代碼。但依然缺乏長期、一致、穩(wěn)定地維護復(fù)雜系統(tǒng)的能力。

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

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

論文鏈接：

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