為什麼 LLM 無法建構大型專案軟體？Zed 工程師點出關鍵差異

Zed 編輯器開發團隊的成員 Conrad Irwin 近日在官方部落格撰文，說明為何即便大型語言模型（LLM）已具備不俗的寫程式能力，卻仍無法真正「建構一個大型軟體專案」。他指出，軟體開發不只是輸出程式碼，更是高度依賴系統性思考與心智模型的過程，而這正是 LLM 現階段最欠缺的部分。

軟體開發不只是寫程式，更是循環式的認知作業

Irwin 以一名熟練工程師的工作流程為例，強調優秀開發者會持續在以下循環中運作：

1. 建立需求的心智模型

2. 撰寫初步程式碼

3. 再建構該程式實際運作邏輯的心智模型

4. 對照兩者的落差，調整程式碼或重新定義需求

他指出，這種心智上的來回切換與維持清晰結構的能力，是人類工程師的核心價值。而目前的 LLM 雖然能寫出可執行的程式碼，甚至能回應錯誤訊息並嘗試修正，但它們無法維持這種清楚的「上下文模型」，更無法從整體架構層面理解一個專案。

LLM 易混亂、缺乏彈性，無法進行有效迭代

Irwin 認為，LLM 在實務操作中常出現幾個問題：

• 它們假設自己產生的程式就是正確的

• 一旦測試失敗，無法判斷錯在哪裡，只能猜測是程式錯還是測試錯

• 碰到瓶頸時，容易「整包砍掉重寫」，但不會帶來更深的理解

這種作法與人類工程師不同。人類在測試失敗時，能回到自己的心智模型思考可能原因，或是主動蒐集更多資料再做決策。即使最後選擇重構，也是在更清楚掌握問題本質的基礎上行動。

問題不只在能力，而是模型本身的設計邏輯

Irwin 認為，就算 LLM 持續演進，若底層模型的架構不改，仍難以跨越目前的瓶頸。真正的挑戰在於：軟體開發需要模型能像人類一樣靈活抽換注意力、建立與切換上下文，並處理多層次資訊。這包含了：

• 察覺缺漏脈絡的能力（context omission）

• 避免過度依賴新輸入的傾向（recency bias）

• 防止編造不實細節的幻覺問題（hallucination）

這些都是現階段生成式模型還無法根本解決的難題。

LLM 可以是好工具，但不能取代架構思維

儘管如此，Irwin 並不全然否定 LLM 的價值。他認為這些模型在快速生成程式碼、草擬需求文件或整合文件資訊上相當有幫助。對於需求明確、範圍單純的任務，它們表現得也很不錯。

但一旦任務稍微複雜、需求有變，LLM 就容易失去掌控。他提醒，開發者仍需為「需求是否合理」、「程式是否真的有效」負起最終責任。

Zed 的願景：人與工具協作，而非取代

Irwin 最後表示，Zed 相信未來的軟體開發應該是人類與智慧代理共同協作的結果。但至少現階段，「人」依然是坐在駕駛座上的主體，LLM 則只是手中的一把工具——好用、但不該過度神化。

• 延伸閱讀：老闆都愛「10倍速天才工程師」？他建議要讓公司長久，團隊協作與「一般工程師」才是軟體開發的核心
• 延伸閱讀：AI寫程式時代真的來臨？Google 工程師解析如何利用 AI 來改進軟體開發
• 延伸閱讀：美國政府呼籲棄用 C/C++，軟體開發界將迎來巨變？