LLM 沒有「懶惰」，所以它寫的 code 很危險
有篇文章提到一個概念讓我想了很久：LLM 缺乏「laziness」。
這裡的 laziness 不是偷懶，是那種「這段邏輯重複三次了，我真的受不了，必須抽成一個 abstraction」的衝動。是促使工程師做簡化、建立模型、砍掉複雜度的心理壓力。
LLM 沒有這個壓力。它生成 code 的邊際成本是零，所以它不會去想「這可以共用嗎？這個 interface 設計得合理嗎？三個月後有人能看懂嗎？」
我看到的真實情況
帶 team 以來，我開始注意到一個新的 code review pattern：整體看起來可以動，但結構讓人頭痛。
同一個邏輯出現在三個地方，稍微改了一下但不完全一樣。Function 命名語義模糊。Error handling 特別詳細但放在奇怪的位置。問工程師：「這段是自己寫的還是 AI 出的？」答案大概猜得到。
更麻煩的是，這種 code 不會立刻出問題。它會跑。它會過 unit test。但六個月後你要改需求，你才發現這個東西到底有多脆。
LOC 是最爛的 KPI
如果你的工程師在用 LLM 之後產出行數大幅增加，然後你覺得「哇生產力提升了」，先停一下。
更少的 code 但更穩的系統，才是真的效率。 一個好的 abstraction 可以讓你砍掉 300 行換成 40 行，同時讓整個模組變得可測試、可替換。
LLM 很擅長「幫你快速產出一個可以動的方案」，但它不會主動跟你說「其實你現在的架構有根本性的問題，這個方向繼續走下去會很痛」。
我的用法
把 LLM 反過來用：不是用來加 code，是用來減 code。
- 「幫我看這段邏輯有沒有可以合併的地方」
- 「這個 module 現在有幾個責任？幫我拆開」
- 「這個 interface 設計有什麼 edge case 我沒考慮到」
這樣用，它才是真的在幫你提升 engineering rigor，而不是幫你堆複雜度。
作者：鍵盤工人