兩本二十年前的軟體書,為什麼在 AI 時代反而更該讀

有種說法是:AI 都能寫程式了,那些講軟體設計的老書可以丟了吧?

我自己讀完《軟體設計的哲學》(John Ousterhout)和《務實的程式設計師》之後,結論剛好相反——這兩本二十年前的書,在 AI 時代反而更該讀。因為 AI 在一個好的程式庫裡表現很好、在一個爛的程式庫裡產出垃圾;而這兩本書講的,正是「怎麼讓程式庫好」。它們等於在教你:怎麼把 AI 的天花板墊高。

《軟體設計的哲學》:複雜度是「難改」,不是「大」

Ousterhout 給了複雜度一個很實用的定義:複雜度 = 任何讓系統難理解、難改的東西,跟行數無關。一個兩千行但沒人會再碰的檔案,其實沒什麼成本;一個三百行、但每次改都怕牽動一片的核心,才貴。

他主張用深模組:一個簡單的介面,後面藏住大量複雜。對 AI 特別有感——介面乾淨,AI 只要從外面用、從外面測就好,不必看懂裡面每一行;反過來,一堆零碎的小模組會讓 AI 迷路、也難測。好的邊界,讓你能把實作放心交給 AI,自己守住介面就好。

《務實的程式設計師》:幾把至今好用的刀

• 軟體熵:每次只想著「這次的改動」、不顧整體設計,系統就會一路爛下去。這正是「只改規格、不看程式碼、反覆重跑」那套做法為什麼會越跑越糟。
• 曳光彈(tracer bullets):與其一層一層做完(先全部資料庫、再全部介面),不如先打一條貫穿所有層的細線,早早看到整條流程通不通。讓 AI 也這樣做,它才會早點拿到回饋、而不是盲做到最後才爆。
• 別開過你的車燈:回饋的速度,就是你的速限。AI 預設愛「一次做太多」,所以要逼它小步走、邊走邊測。

為什麼這些在 AI 時代更重要

把兩本書合起來看,它們其實都在講同一件事:怎麼讓一個系統好改、好測、好驗證。

而「好改、好測、好驗證」,正是 AI 能不能放手去做的前提——它需要乾淨的邊界才不會迷路、需要快的回饋才不會盲做、需要可驗證才信得過。所以這些基本功不但沒過時,反而是你跟 AI 一起把事情做好的地基。工具會換,這些不會。

讀完不是收藏,是把那把刀編進工具

我讀這些書,目標從來不是「讀過」。每一章我要的是最可操作的那把刀——一條公式、一個判準——然後做一件事:把它變成我開發流程裡的一道關卡。

舉我自己的例子:讀《軟體設計的哲學》拿到「複雜度 = 難改」這個定義和那條加權公式,我沒停在筆記——我讓 AI 照著做出一支「該先改哪裡」的重構評分器,接進流程當判斷關卡(就是另一篇〈別憑感覺重構〉)。注意這裡的分工:概念是我研究的、判斷是我定的;把它寫成 script 那段,交給 AI。

這也回答了一個很多人焦慮的問題——當 AI 接手寫 code,工程師還做什麼? 就做這個:往上去讀更重要、更耐久的東西,把學到的概念回頭編進工具。AI 寫得越多,你越該把時間花在「值得編進去的好概念」上。工具會幫你寫;但「該編什麼進去」,永遠是你的。