編輯｜Sia

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

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

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

沒(méi)有一個(gè)模型，能夠真正完整重建一個(gè)軟件項(xiàng)目。

這意味著什么？

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

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

ProgramBench: Can Language Models Rebuild Programs From Scratch?

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

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

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

換句話(huà)說(shuō)：模型到底有沒(méi)有工程智能？

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

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

研究團(tuán)隊(duì)甚至使用了 agent-driven fuzzing，自動(dòng)生成大量端到端行為測(cè)試。

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

所有模型：0% 完成率。

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

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

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

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

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

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

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

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

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

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

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

研究團(tuán)隊(duì)分別統(tǒng)計(jì)了模型在 C/C++、Go、Rust 等不同語(yǔ)言項(xiàng)目上的表現(xiàn)?？梢悦黠@看到，傳統(tǒng) C/C++ 項(xiàng)目完成度最高，而 Rust 表現(xiàn)最差。

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

這其實(shí)并不讓人意外。

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

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

某種意義上，Rust 測(cè)出來(lái)的，其實(shí)不是代碼能力，而是工程能力。

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

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

SWE-Bench 可以被記住 bug，LeetCode 可以被背題，甚至 ARC-AGI 未來(lái)也可能通過(guò)隱藏題庫(kù)來(lái)避免泄漏。單純討論是否存在記憶本身，其實(shí)并不能否定 benchmark 的價(jià)值。

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

因?yàn)檎嬲拇竽Ｐ陀?xùn)練，并不是簡(jiǎn)單把整個(gè) FFmpeg 塞進(jìn)參數(shù)里。更何況，研究人員還可以通過(guò)比對(duì)生成代碼與原始源碼的相似度，去檢測(cè)是否存在直接 memorization。

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

另一類(lèi)爭(zhēng)議則更有意思。有人吐槽說(shuō)：連人類(lèi)都不可能從零重寫(xiě) FFmpeg，這 benchmark 根本不合理。

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

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

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

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

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

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

還有人建議：為什么不用真正沒(méi)人解決過(guò)的新問(wèn)題？對(duì)此，Deedy Das 表示，因?yàn)槟菚?huì)讓 benchmark 幾乎無(wú)法構(gòu)建。

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

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

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

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

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

因?yàn)橄乱浑A段的競(jìng)爭(zhēng)，可能已經(jīng)不再是誰(shuí)能一次性生成更長(zhǎng)的代碼，而是誰(shuí)能在長(zhǎng)時(shí)間、多輪交互、復(fù)雜上下文中，持續(xù)穩(wěn)定地維護(hù)一個(gè)活著的軟件系統(tǒng)。

論文鏈接：

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