AI 編程圈最近出現了一個新的基準測試：ProgramBench。表面上看，它給出的結果很讓程式設計師安心：九個主流模型在 fully resolved 指標上全部是 0%，沒有任何模型能完整通過一個任務。

但這件事真正值得緊張的地方，不是今天的大模型還做不到，而是完整軟體工程第一次被清楚地做成了一套可評測、可排名、可反覆優化的題。

一旦任務被定義清楚，AI 行業最擅長的事情就會發生：刷題、迭代、追榜，然後把原來做不到的事情一點點推到可用邊緣。

ProgramBench 到底在測什麼

很多編程基準測試，測的是補函式、改 bug、通過單元測試，或者在已有專案裡完成一個小功能。ProgramBench 更狠，它不給原始碼，也不給專案結構，更不給現成測試用例。

它給模型的材料主要只有兩類：

1. 一個已經編譯好的可執行檔。
2. 這個程式的使用文件。

模型需要自己執行可執行檔，觀察輸入輸出行為，理解命令列參數、邊界情況、錯誤訊息、資料儲存方式，然後重新實作一個行為一致的程式。

這已經不是「寫一段程式碼」，而是一個簡化但完整的軟體工程任務：要理解需求、探索行為、選擇語言、設計結構、寫原始碼、提供建置方式，並盡量通過隱藏測試。

根據 ProgramBench 官方介紹，它目前包含 200 個任務，覆蓋從小型命令列工具到 PHP、FFmpeg、SQLite 等大型真實專案。測試集由 agent-driven fuzzing 生成，總量超過 248,000 個行為測試。

如果把測試流程拆開，ProgramBench 大致是在考四件事：

1. 讀懂文件：理解程式應該提供哪些命令、參數和輸出。
2. 探索行為：反覆執行二進位程式，觀察正常輸入、異常輸入和邊界情況。
3. 重建實作：自己選擇語言和專案結構，寫出一個行為接近的替代程式。
4. 通過隱藏測試：不只常規行為要對，錯誤處理、輸出格式和邊界條件也要盡量一致。

所以它的搜尋價值不只是「又一個跑分」，而是回答一個更具體的問題：大模型能不能在沒有原始碼的情況下，只靠文件和黑箱行為，從零復刻一個真實軟體。

為什麼結果是 0%

ProgramBench 的主要指標是 fully resolved，也就是一個任務裡的測試全部通過才算完成。當前 leaderboard 上，九個模型在這個指標上都是 0%。

參與測試的模型包括 Claude、GPT、Gemini 等系列，統一使用 mini-SWE-agent 作為基線 agent。Claude Opus 4.7 在 almost resolved 指標上表現最好，大約有 3.0% 的任務通過了至少 95% 的測試；Claude Opus 4.6 是 2.5%，Claude Sonnet 4.6 是 1.0%。GPT 5.4、GPT 5.4 mini、Gemini 3.1 Pro、Gemini 3 Flash 等在 almost resolved 上都是 0.0%。

這說明今天的大模型加一個輕量級 agent，還無法從零重建完整軟體。即使是最簡單的任務，也很難做到所有細節都完全對齊。

但也要注意：這次測試用的是 mini-SWE-agent，不是 Claude Code，也不是 Codex。換成更強的 coding agent、更多工具鏈支援、更長時間的探索流程，結果可能會提高。所以這個結果更準確的說法是：當前模型加輕量 agent，還不足以穩定完成完整軟體重建。

fully resolved 和 almost resolved 是什麼意思

讀 ProgramBench 的結果時，最容易誤解的是這兩個指標。

fully resolved 是最嚴格的指標：一個任務裡的所有隱藏測試都通過，才算完整解決。只要還漏掉一個邊界條件、一個報錯格式、一個命令參數行為，就不能算 fully resolved。

almost resolved 則更像「接近完成」：如果一個任務至少通過了 95% 的測試，就算進入 almost resolved。它能反映模型有沒有把大部分行為做出來，但還不能代表程式已經可以替代原軟體。

這也是為什麼 0% 要分開看。fully resolved 的 0% 說明模型還無法完整交付；almost resolved 的差距則能看出哪些模型已經在部分任務上接近復刻成功。比如 Claude Opus 4.7 的 almost resolved 約為 3.0%，說明它確實在少量相對簡單的任務上更接近完成，但距離穩定重建完整軟體仍然很遠。

為什麼 mini-SWE-agent 會影響測試結果

這次測試使用統一的 mini-SWE-agent，好處是公平：不同模型都跑在同一套輕量 agent 框架裡，結果更容易橫向比較。

但它也會限制上限。完整軟體重建不只取決於模型本身，還取決於 agent 是否會規劃探索策略、是否能管理長期任務、是否會自動生成測試、是否能反覆定位失敗原因、是否能整理專案結構。

mini-SWE-agent 更像一個統一基線，而不是最強工程環境。

Claude Code、Codex 這類更完整的 coding agent，通常會提供更強的工具呼叫、上下文組織、任務拆解和多輪修復能力。如果換成這些工具，結果可能會更好。

所以 ProgramBench 這次結果更適合理解為：當前模型在輕量 agent 環境下還做不到完整軟體重建。它不是在證明「模型永遠做不到」，也不是在完整評估所有商業 coding agent 的上限。

它和 SWE-bench 的差別

SWE-bench 已經是 AI 編程領域裡很重要的基準。它讓模型在真實 GitHub 倉庫裡讀 issue、改程式碼、提交補丁，用來測試模型解決真實 bug 的能力。

但 SWE-bench 本質上仍然是在已有專案上修車：車還在，技術棧、目錄結構、程式碼組織、架構設計都已經有人完成了。模型只需要找到問題，把壞掉的零件修好。

ProgramBench 更接近重新造車：你只知道這台車應該有什麼行為，看到紅燈會停、遇到行人會鳴笛，剩下的結構、語言、模組、建置方式，全都要自己決定。

這就是為什麼它難得多。它不再只考局部補丁能力，而是在考軟體架構、系統推理、行為探索、自動測試、多輪糾錯和長期工程設計。

可以用一張表來理解兩者差別：

這也是為什麼 ProgramBench 更適合被看作下一階段 AI Coding 的目標：它把「修現有程式碼」推進到了「重建完整軟體」。

0% 並不等於安全

看到 0%，很多人的第一反應可能是：程式設計師飯碗暫時保住了。

短期看，這句話沒錯。今天的大模型還不能穩定完成完整軟體工程，尤其是在沒有原始碼、沒有測試用例、沒有專案結構的情況下。需求釐清、架構設計、長期維護、安全控制、團隊協作、業務理解，仍然是人類軟體工程師的重要優勢。

但如果把 0% 理解成「AI 編程到頭了」，就太樂觀了。

ProgramBench 真正改變的是問題定義。以前大家知道 AI 可以補程式碼，也知道 AI 可以修 bug，但「從一個可執行檔和文件重建完整軟體」這件事沒有被清楚地放到統一賽道裡。現在它被做成了 200 道題、統一評測、統一排名。

這意味著模型公司、agent 公司、開發工具公司都知道下一步該往哪裡發力：讓 AI 從寫程式碼片段，進化到維護、重建和交付完整軟體系統。

為什麼要斷網和防作弊

ProgramBench 的設計裡有一個細節很重要：它要防止模型作弊。

早期測試中，模型會嘗試直接從 GitHub 找原始碼，或者通過套件管理器下載包含原始碼的套件，甚至去系統快取目錄裡翻找已經下載過的軟體包。這樣當然會破壞測試目的，因為問題就不再是「能不能從行為重建軟體」，而是「能不能找到原始原始碼」。

所以 ProgramBench 使用了沙箱和斷網環境，不允許存取網際網路，也不允許反編譯、反組譯或讀取可執行檔內容。模型只能執行程式，觀察行為，再自己實作。

這個限制讓測試更乾淨，也更接近它真正想回答的問題：大語言模型能不能從程式行為和文件出發，自己構建一個可執行的軟體專案。

更值得警惕的是程式碼形態變化

ProgramBench 還有一個比 0% 更值得軟體工程師思考的發現：模型生成的程式碼往往不像人類工程師會寫的專案。

公開材料裡提到，模型傾向於生成更少的檔案、更淺的目錄、更少的函式，以及更長的單個函式。也就是說，它可能寫出一個巨大的、能跑的腳本，而不是一個結構清晰、便於人類維護的軟體工程專案。

從傳統軟體工程角度看，這通常是很差的程式碼。檔案太少、函式太長、抽象不足、模組邊界不清，都會讓人類難以維護。

但問題在於，AI 未必需要按照人類維護程式碼的方式寫程式碼。

人類強調抽象、命名、目錄結構和模組邊界，主要是因為人類記憶有限、團隊需要協作、程式碼需要長期復用。AI 如果可以用更長上下文、檢索系統和自動測試反覆重寫程式碼，它可能並不那麼需要人類熟悉的這些工程規範。

這會帶來一個很現實的風險：未來 AI 寫出的軟體也許能跑、甚至很快，但人類越來越難插手維護。

程式設計師真正要升級什麼

ProgramBench 的結果對程式設計師不是簡單的好消息，也不是簡單的壞消息。

短期看，完整軟體工程仍然很難，程式設計師不會因為這次 benchmark 立刻失業。尤其是架構判斷、需求釐清、安全把控、品質驗收和業務理解，仍然需要人類負責。

長期看，程式設計師的工作會繼續上移。真正危險的不是「不會寫程式碼」的人，而是只會寫程式碼、但不會定義問題、驗證結果、組織工具鏈和控制風險的人。

未來的軟體工程師可能更像：

1. 需求定義者：把模糊業務問題變成可執行目標。
2. 系統驗收者：判斷 AI 生成結果是否真的滿足需求。
3. 工具鏈組織者：組合模型、agent、測試、部署和監控。
4. 品質負責人：控制安全、可維護性、邊界條件和長期風險。
5. 業務和技術之間的翻譯者：把真實問題轉成工程系統能處理的約束。

如果 AI 真的從程式碼助手變成完整軟體工程師，人類程式設計師的價值就不再只是親手寫每一行程式碼，而是定義什麼值得寫、怎樣算寫對、哪裡不能出錯。

小結

ProgramBench 的 0% 不是終點，而是新階段的起點。

它說明今天的大模型還不能從零穩定重建完整軟體系統；但它也把下一代 AI Coding agent 的目標定義得非常清楚：從局部補丁走向完整專案，從程式碼片段走向系統交付。

對程式設計師來說，短期可以鬆一口氣，但長期不能只盯著「AI 現在還不行」。更重要的是盡快把自己從程式碼執行者升級為問題定義者、結果驗收者和風險控制者。

真正值得緊張的不是 AI 今天考了 0%，而是題目已經擺出來了。