本篇文章更新時間：2026/04/13
如有資訊過時或語誤之處，歡迎使用 Contact 功能通知或向一介資男的 LINE 社群反應。
如果本站內容對你有幫助，歡迎贊助支持 。
內容目錄
程式設計真正的美德：為什麼我們正在失去「懶惰」這門技藝？
從《The peril of laziness lost》談 LLM 時代的工程美學失落
編輯前言：這篇文章來自 Brian Cantrill 的深度反思（來源：The peril of laziness lost），他從 Perl 之父 Larry Wall 提出的三大美德談起，討論 LLM 如何正在侵蝕工程師「懶惰」的能力。對正在大量使用 AI 工具寫程式的人來說，這篇文章值得仔細讀。
核心觀點 (Key Takeaways)
- 程式設計的「懶惰」其實是追求更好的抽象，讓未來的自己與他人節省時間。
- LLM 雖然能生產大量程式碼，但不具備「懶惰」的美德，也不懂得追求更簡潔或更佳的設計。
- 缺乏懶惰的 LLM 會傾向生成「更多」而非「更好」的系統，使工程品質下降。
深入解析
作者從 Larry Wall 在《Programming Perl》中的名言切入：
"If we’re going to talk about good software design, we have to talk about Laziness, Impatience, and Hubris…"
這三個看似玩笑的「美德」其實暗示了程式設計的核心精神：用抽象化來減少未來的麻煩。而作者最推崇的，是「懶惰」。
懶惰不是不努力，而是為了未來更省力而先付出更多心力。 這是一種工程美學：讓系統變得更簡潔、更可理解，讓後人能在你的抽象上繼續搭建。
但作者指出，隨著程式設計民主化，越來越多人不把自己稱為「程式設計師」，自然也無法理解「懶惰」背後的深意。現代軟體文化反而被「brogrammer」式的炫技淹沒，例如誇耀一天寫三萬七千行 AI 生成的程式碼。
問題當然不是程式碼量，而是這種心態導致的結果。作者引用另一位工程師的分析，指出那位炫耀者生成的系統竟然包含：
- 多個測試框架的重複版本
- Hello World Rails 專案
- 一個不知從哪來的文字編輯器
- 八個版本的 logo，其中還有容量為零的檔案
這不是工程，而是垃圾堆。作者點出的核心是：
LLMs inherently lack the virtue of laziness. Work costs nothing to an LLM.
因為 LLM 沒有「時間成本」，它不會刻意追求更好的抽象，也不會避免重複、冗餘或複雜性。「多寫一些」對它們毫無代價，但對人類維護者卻代價巨大。
換言之：LLM 的存在放大了不懂懶惰的工程師的壞習慣。
作者強調，真正好的工程來自限制，尤其是「時間」與「認知負荷」的限制。人會追求更好的抽象，是因為我們不想浪費生命在維護糟糕的設計上。但 LLM 不受這些限制，因此很難自動產生真正優雅的系統。
筆者心得與啟發
讀完這篇文章，我最深的感觸是：我們正在失去「花時間思考」這門技藝。
AI 工具讓我們更容易產生程式碼，但不會自動讓我們寫出更好的系統。相反的，它更容易讓人沉迷於短期快感──像是看到專案快速膨脹、功能迅速堆疊、看似成果豐碩。
但軟體工程的本質從來不是「產量」，而是「結構」。真正重要的永遠是：
- 這個抽象是否減少了未來的心智負擔？
- 這段設計是否讓後來者能夠理解並沿用？
- 這是否是「值得維護」的系統？
AI 不是不能用，而是要讓它服務於「好的懶惰」——也就是作者所說的 virtuous laziness。讓 LLM 幫我們處理罐頭式的繁瑣工作、清理技術負債、加強嚴謹度……但「抽象何時應存在、應如何存在」這些決定，仍然是人類工程師的職責。
我會把這篇文章視為一個提醒：在 AI 時代，工程師不能只會寫程式，還得更會「不寫程式」。更懂得設計、更重視抽象、更珍惜時間。
真正的懶惰，是一種深度的美德。