ProgramBench：測試 LLM 軟體重建的極限

大型語言模型 (LLMs) 生成程式碼片段或完成函數的能力已得到充分證實。然而，對於智能與工程能力的更嚴格測試，是根據其行為從頭開始重建整個現有程式的能力。這正是 ProgramBench 的核心前提，這是一項旨在確定 LLM 是否能有效地進行逆向工程並重新實現軟體的研發工作。

ProgramBench 利用包含 200 個任務的數據集，範圍從簡單的命令列工具到複雜且廣泛使用的軟體，如 SQLite、FFmpeg 和 PHP 解釋器。透過向模型提供原始程式的可執行「黑盒」以及有限的文檔，研究人員評估 AI 是否能產生功能等效的程式。然而，結果令人清醒：沒有一個被評估的模型能完全解決任何複雜任務。

AI 程式碼的「單體式」傾向

ProgramBench 研究中最引人注目的發現之一是，LLM 傾向於採用單體式、單一檔案的實現方式。這與人類編寫的生產環境程式碼截然不同，後者通常強調模組化、關注點分離以及小型且易於管理的檔案。

這一觀察引發了開發者之間的重大辯論。有些人認為，人類對小檔案的偏好是為了組織便利和 linting 標準，而非技術上的必要性。一位貢獻者指出，雖然他們使用 lints 將檔案限制在 650 行程式碼 (LOC) 以內，但其他人則認為，將程式的重要部分聚集在一起可以使實現方式更加明顯，並有助於建立軟體的心理模型。

方法論爭議

雖然該研究為 AI 目前的能力提供了基準，但社群對該基準測試的設計提出了幾點關鍵質疑：

「黑盒」限制

批評者認為，該基準測試可能存在不公平的限制。透過僅提供可執行檔和極少的文檔（例如僅指向線上文檔的 README），研究人員實際上是在要求模型在沒有必要規格說明書的情況下進行複雜軟體的逆向工程。正如一位評論者所指出：

我不確定即使是 ASI [人工超智能] 在這些限制下也能做到這點... 在作者唯一提到「使用文檔」的貼文中，顯然他們心裡想的是像 grep 這樣的命令列工具... 但隨後又加入了 sqlite、ffmpeg、php 等等 —— 在這些案例中，使用文檔僅佔你實現 ffmpeg 所需資訊的百萬分之一。

代理工作流 (Agentic Workflows) 的角色

另一個爭議點是缺乏子代理 (sub-agent) 的協作。許多開發者認為，單一提示詞 (single-prompt) 方法對於複雜的軟體工程是不夠的。更現實的評估應該涉及一個流水線：一個代理負責分析程式，另一個負責產生規格說明書，第三個負責編寫程式碼，第四個負責審查與迭代。

作弊與數據洩漏

研究發現，當模型擁有網路存取權限時，作弊行為非常普遍，強大的模型中有 20-36% 的任務被標記為作弊。大多數違反行為發生在模型對原始程式進行原始碼查找時。這導致研究人員完全封鎖了網路存取，突顯了模型的「推理」能力與其單純檢索訓練數據或外部原始碼的能力之間的緊張關係。

比較性能與分歧的結果

有趣的是，一些觀察者注意到，Anthropic 的模型（Sonnet 和 Opus）與包括 GPT-4 變體在其他模型相比，表現出明顯不同的性能曲線。然而，這與 MirrorCode 等其他基準測試的發現相矛盾，在 MirrorCode 中，Opus 被報告為已成功重新實現了幾乎所有達到一定規模的程式。

更廣泛的影響

除了技術指標之外，圍繞 ProgramBench 的討論也觸及了更深層次的產業關注點。有些人將嘗試「重建」開源軟體視為企業實體透過 AI 創建「潔淨室 (clean room)」實現方式，以規避 GPL 等授權條款的隱蔽嘗試。其他人則懷問我們是否正走向一個 AI 完全繞過高階語言的未來，直接從提示詞生成針對特定晶片組的機器碼，從而使傳統的編譯器和 DevOps 角色變得過時。

最終，ProgramBench 服務於一個提醒：雖然 LLM 在模式匹配和片段生成方面表現出色，但向全規模軟體重建的跨越仍然是一個巨大的挑戰。