背景

ProgramBench 是一項針對大型語言模型（LLM）軟體工程能力的基準測試，旨在探討 AI 是否具備從零開始重建複雜程式的能力。該研究涵蓋了從簡單的命令列工具到如 FFmpeg、SQLite 及 PHP 解譯器等知名開源專案的 200 個任務。初步測試結果顯示，目前受測的九種模型在面對這些具備一定規模與複雜度的任務時，尚無法完全達成任何一項任務的重建。

社群觀點

針對 ProgramBench 的測試結果，Hacker News 社群展開了激烈的辯論，焦點主要集中在測試方法的有效性以及 AI 撰寫程式的行為模式。部分評論者對測試結果持保留態度，認為這可能與提示詞工程或代理人架構（Agent Swarm）的使用不足有關。他們指出，如果僅使用單一且簡單的提示詞要求 AI 寫出整個程式，模型自然會傾向於產出單一檔案的巨型結構（Monolithic），這與人類開發者習慣將邏輯拆分到不同檔案的實踐大相徑庭。然而，也有開發者反思，過度拆分檔案有時只是追求「乾淨程式碼」的錯覺，反而增加了理解邏輯流轉的難度。對於 AI 而言，將相關實作集中在一起或許更有助於建立正確的邏輯關聯，因為目錄結構雖然能展現組織架構，卻不一定能有效傳達程式的意圖與圖形化的邏輯關係。

另一派討論則聚焦於 AI 在底層語言（如組合語言 ASM）上的表現。有觀點認為，AI 在處理組合語言時可能比高階語言更具優勢，因為組合語言的結構相對扁平且非結構化，模型甚至能直接從硬體手冊中學習。這引發了對未來開發模式的想像：或許有一天編譯器與工具鏈將被 AI 取代，晶片廠商直接提供模型，讓開發者透過自然語言直接生成二進位碼。但隨即有反對聲音指出，LLM 本質上是基於文本訓練的，若缺乏大量人類編寫的機器碼與相關討論作為語料，AI 很難在缺乏抽象層的情況下獨立完成低層級的位元組碼編寫，且一旦 AI 生成的底層代碼出現錯誤，人類將極難進行除錯與推理。

此外，社群中也出現了對不同基準測試結果差異的質疑。有開發者提到另一項名為 MirrorCode 的研究，其結果顯示 Anthropic 的 Claude 3 Opus 模型在重建中小型程式方面表現優異，這與 ProgramBench 的負面結論形成對比。這顯示出目前的 AI 評測仍處於早期階段，測試框架的設計、任務的難易度界定，以及是否允許模型進行多輪規劃與審查，都會極大地影響最終的評價。正如科學研究中單一樣本不具統計意義，在商業應用上，只要 AI 能在特定情境下成功解決問題，就足以支撐其產品價值，而不必過於糾結於其是否能通過所有極端複雜的基準測試。

延伸閱讀

• MirrorCode：由 Epoch AI 進行的初步研究，探討模型重新實作程式的能力。
• Locality of Behaviour：探討程式碼行為局部化的設計哲學。
• HARC Stack：一種強調開發體驗與特定架構組合的技術堆疊。
• s1ugh34d/osc：GitHub 上的開源專案，涉及以行為契約作為程式基準測試的實踐。