本篇文章更新時間：2026/03/17
如有資訊過時或語誤之處，歡迎使用 Contact 功能通知或向一介資男的 LINE 社群反應。
如果本站內容對你有幫助，歡迎贊助支持 。
用 LLM 寫程式：不是偷懶，而是重新定義「做東西」的方式
編輯前言：這篇文章來自 How I write software with LLMs，作者分享了他如何用大型語言模型（LLM）構築完整、可維護、能長期運作的軟體系統。我讀完的感覺是：這不是在靠 AI 代寫程式，而是一種全新的工程方法論。
核心觀點 (Key Takeaways)
- 作者從「喜歡寫程式」轉向「喜歡做東西」，而 LLM 解放了他不必親自敲每一行程式碼。
- 真正重要的不再是寫出正確的程式，而是做出正確的架構與決策。
- LLM 寫程式會失控，通常都是因為人類架構不足或對技術不熟導致無法糾偏。
- 多模型、多代理（architect / developer / reviewers）是提升品質的關鍵。
深入解析
這篇長文的核心精神不是「我用 LLM 寫程式」而是：「我如何與 LLM 合作建構大型系統」。作者的方法不是把 LLM 當成代碼生成器，而是把它當成一個工程團隊，分工合作。
以下是文章最值得借鏡的幾個部分。
系統品質取決於人類的架構能力
作者提到，LLM 版本越來越強，他需要逐行檢查的層級從「每行程式」提升到「每個函式」，再到現在只需要檢查「整體架構」。
但這並不代表他可以放手不管。相反地：
當他對某個技術不熟，LLM 就會做出一堆錯誤決策，最後越修越糟，陷入「自我破壞」。
這點我非常認同。LLM 擅長局部修補，但一旦全局方向錯了，它就會陷入「這裡壞了我補一下…欸怎麼又壞了…再補一下」的迴圈。
多模型、多角色是成功關鍵
作者並不靠單一模型，而是：
- architect（通常是最強模型 Opus）
- developer（較便宜、寫程式效率高的模型，例如 Sonnet）
- reviewers（至少三種不同模型：Codex / Gemini / Opus）
這三種角色的分工非常清晰：
- architect：與作者對話、制定計畫、做架構選擇。
- developer：按照 architect 的規格實作，不做主觀決策。
- reviewers：不同模型的「第二雙眼睛」，找出 developer 漏洞。
有趣的是，作者強調：
同一模型扮演不同代理沒有意義，因為那只是同一個「人」戴不同帽子而已。
實作細節像真正的工程團隊合作
文章最精彩的部分是附帶的完整 session，展示他如何與 LLM 一來一往地設計 email 支援功能。
整個過程十足像一個技術 lead 與一個 junior engineer 反覆校準需求：
- architect 提出疑問與可能的 edge cases
- 作者補充需求、調整方向
- architect 逐步細化計畫
- developer 執行
- reviewers 審查
- 作者 QA，提出改進
- 再迭代
例如 wildcard email domain 的支援，在作者提出「我用大量 disposable email」後，LLM 就開始思考 wildcard 會如何與 owner validation、allowlist、安全性（避免 [email protected]@evil.com 的繞過）互動，並逐步優化。
這些互動過程顯示：LLM 的強大不是「它會寫程式」，而是「它可以一起思考」，甚至能在思考中 refine 想法。
筆者心得與啟發
讀完作者的 workflow，我覺得最寶貴的洞察不在技巧，而在心態上的根本轉變：
- 你不是在請 LLM 幫你寫程式，你是在「領導一個 AI 工程團隊」。
- LLM 的失敗通常不是因為 AI 不夠好，而是人類沒有給它足夠的架構與決策方向。
- 要讓 LLM 寫出可維護的系統，人類必須更懂「怎麼設計系統」而不是「怎麼寫程式」。
作者的多代理模式也讓我獲得重要啟發：
「使用多種模型，就像是找不同性格的工程師一起協作。」
有人 pedantic、有人 pragmatic、有人擅長找 bug。讓他們互相 review，自然能提升品質。
最後，文章讓我重新思考：
未來寫程式的能力會不會變成「懂得如何與 AI 合作」？
我認為答案幾乎是肯定的。
不會寫程式不等於不能做產品，但不懂架構與系統設計，就無法駕馭 LLM。
這篇文章展示的正是未來軟體生產模式的一個縮影：人類負責想清楚、AI 負責執行。