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

編輯｜Sia

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

結(jié)果相當(dāng)震撼：

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

即便論文專門增加了一個Almost指標(biāo)——統(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.

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

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

后者往往講究模塊和關(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)非常強，一旦進(jìn)入真實世界的大型工程系統(tǒng)，就會迅速掉進(jìn)深水區(qū)。

當(dāng)前 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)，幾乎所有模型都很難推進(jìn)。這說明 ProgramBench 測到的不是某個模型偶然失手，而是復(fù)雜軟件系統(tǒng)本身對當(dāng)前模型形成了穩(wěn)定壓制。

這其實并不讓人意外。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

真正重要的是：ProgramBench 第一次把 AI Coding 的評估，從函數(shù)級拉到了系統(tǒng)級。它暴露出的，也是整個行業(yè)當(dāng)前最大的斷層：真正的軟件開發(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