前言：「這根本是 AI 才有的新問題吧？」

看完前兩天用 ai-news-test 示範的 21,727 行怪物，很容易得到一個結論：這是 AI 時代才有的新現象，以前工程師手動寫程式碼,誰會沒事幫自己找麻煩,多包八層架構？

事實是,軟體工程界吵「過度設計」這件事,吵了幾十年，比 AI coding agent 出現早得多。今天想把時間拉遠一點,說明白這不是一個新病,而是一個老毛病被放大了速度。

今日目標

• 認識「過度設計」在軟體工程史上不是新概念，至少可以追溯到幾十年前的討論
• 理解 YAGNI 這個原則為什麼會在 1990 年代的 Extreme Programming 脈絡裡出現
• 認識「意外複雜度」這個詞的來源脈絡，以及它為什麼跟過度設計是同一件事的兩種講法
• 理解 GOOS（Growing Object-Oriented Software, Guided by Tests）這本書在這段歷史裡扮演的角色
• 建立一個判斷框架：AI 到底改變了「過度設計會不會發生」，還是改變了「過度設計發生的速度」

這不是新病：從「意外複雜度」講起

軟體工程領域很早就有人在討論「程式碼的複雜度,有多少是問題本身必須的，有多少是我們自己加上去的」。Fred Brooks 在他 1986 年的文章〈No Silver Bullet〉裡，把複雜度分成「本質複雜度」（essential complexity，問題本身固有的困難）跟「意外複雜度」（accidental complexity，工具、流程、選擇不當帶來的額外困難）。Brooks 這篇文章的原始論點其實比較悲觀：他認為工具與方法論的進步早已大幅削減了意外複雜度，過去那種「換個更好的工具就能讓生產力大躍進」的年代已經過去，剩下的本質複雜度才是難處理的部分，沒有單一的「銀彈」能再解決它。我這裡借用的不是他的悲觀結論,而是他劃出的這條分界線本身——分清楚「這段複雜度是問題本身逼出來的，還是我們自己疊上去的」，這個框架放到過度設計的討論上一樣好用。

過度設計，本質上就是一種自己製造出來的意外複雜度。 業務規則沒有變複雜，但因為預先假設了各種未來需求，程式碼的複雜度被人為推高了——這件事在 1986 年就已經被點名,不需要等到 AI 出現。

YAGNI：對抗過度設計的老原則

1990 年代末，Kent Beck 等人推動 Extreme Programming（XP）這套開發方法論時，提出了一個後來廣為流傳的原則：YAGNI（You Aren't Gonna Need It）——不要為了「以後可能會用到」而現在就寫。這個原則存在的理由，就是在對抗工程師（不分資深資淺）都有的一種傾向：預先幫未來的需求鋪路，結果鋪出來的路九成從來沒人走過。

ai-news-test 過度設計版本裡那 92% 從未被任何測試呼叫過的程式碼——50 種假設性的未來功能、25 個沒有業務規則用到的欄位、5 種多餘的快取／日誌後端——如果放進 1990 年代的 XP 討論脈絡裡，會被直接點名是 YAGNI 原則要防的那種東西。只是當年這種東西是人類工程師花好幾天、好幾週寫出來的，現在 AI 幾分鐘就能生出一整套。

ATDD／GOOS：用測試逼出「真正需要」的設計

再往後推到 2009 年，Steve Freeman 跟 Nat Pryce 出版了《Growing Object-Oriented Software, Guided by Tests》（業界通稱 GOOS）。這本書的核心方法論之一，是用 Outside-In 的驗收測試作為設計的驅動力——先寫一個從系統邊界（使用者角度）出發的驗收測試，讓這個測試逼你一步步往內建立「真正需要」的類別與協作關係，而不是先憑經驗或直覺畫出一整套架構藍圖，再回頭補測試。

這套方法論背後的假設,跟 YAGNI 是同一件事的不同表達方式：如果一段程式碼不是被某個測試逼出來的，它存在的理由就值得懷疑。 ai-news-test 的乾淨版本正是照這個精神寫出來的——只有 10 個驗收測試逼出的類別會存在，沒有一個是「以防萬一」先建好的。

AI 到底改變了什麼

如果過度設計、YAGNI、Outside-In 這些概念都已經存在幾十年，那 AI 到底帶來了什麼新東西？答案不是「新的錯誤類型」，而是錯誤累積的速度。

❌ 過去的過度設計：一個工程師花一週時間，手動把一個簡單系統包裝成有五層抽象的架構，中間至少會有幾次「這樣寫是不是太多了」的猶豫,或者被同事在 PR 討論時攔下來。

✅／❌ 現在的過度設計：AI coding agent 在幾分鐘內生出 21,727 行、745 個檔案，中間沒有猶豫、沒有天然的「寫累了想偷懶少寫一點」煞車機制——只要你沒有明確告訴它「不要」，它就會把所有沒問清楚的地方用一整套完整架構填滿。

為什麼重要

理解「過度設計是老問題」這件事很重要,因為它決定了我們該往哪裡找解法。如果過度設計是 AI 才有的新病，我們該研究的是怎麼「馴服 AI」；但如果它是老病被放大，我們該做的是把幾十年前就存在、被驗證有效的紀律（YAGNI、Outside-In TDD／ATDD）重新拿出來，用可執行的方式套在 AI 的產出流程上。 這正是本系列後半段（第三部）要具體示範的內容。也呼應本系列的主題句：AI 沒有發明過度設計，它只是讓過度設計的速度追上了你按下 Enter 的速度；Review 要跟得上，審的就不能再是程式碼本身，而是產生程式碼的規則。

今日思考題

在 AI 出現之前，你的團隊有沒有遇過人類工程師「預先幫未來鋪路」結果從沒被用到的程式碼？那時候你們是怎麼發現、怎麼處理的？這套處理方式，放到 AI 產出速度下還撐得住嗎？

今日重點回顧

• 過度設計不是 AI 時代的新概念，「意外複雜度」這個詞至少可以追溯到 Fred Brooks 1986 年的討論
• YAGNI 原則誕生於 1990 年代的 Extreme Programming 脈絡，正是為了對抗「預先鋪路」的傾向
• GOOS（2009）用 Outside-In 驗收測試逼出「真正需要」的設計，是同一個問題的另一種解法
• AI 沒有發明新的錯誤類型，它改變的是錯誤累積的速度——過去要幾週的過度設計，現在幾分鐘就能生出來
• 解法方向應該是把已驗證有效的老紀律，重新套用在 AI 的產出流程上

明日預告

Day 5 要更精確地拆解「複雜度」這個詞——意外複雜度跟本質複雜度到底怎麼分辨？拿到一段程式碼時，該怎麼判斷它的複雜度長在哪裡。

老派工程師的心得

寫這篇的時候，我重新翻了一次 YAGNI 跟 GOOS 相關的討論，有一種很微妙的感觸：這些道理我十幾年前就聽過、也認同,但真正讓我把它們當回事，是這一兩年帶著 AI 一起寫程式碼、親眼看著一個過度設計版本在短短時間內長到 21,727 行之後。知道一個原則存在,跟真正被它救過一次,是兩種不同層次的相信。 AI 加速的不只是寫程式碼的速度，也意外地加速了我對這些老原則的信任程度。