前言：「複雜度預算不就是事後補救嗎？」

昨天講完複雜度預算，可能有讀者已經在心裡吐槽：這套機制還是「等 AI 寫完，我再去檢查改了幾個檔案」，本質上還是事後補救,只是補救的動作變得更量化而已。等到 PR 已經開出來、11 個檔案已經寫好，就算你抓到「這樣改太多了」，工程師也已經花了時間看過、AI 也已經花了 token 生成，這個成本已經發生了。

今天要處理的是更前面一步的問題：能不能在 AI 動手寫程式碼之前，就先讓它經過一次 Outside-In 的紀律,而不是等它自由發揮完,才回頭用規則去篩檢結果？

今日目標

• 理解「事前引導」跟「事後檢查」在成本結構上的根本差異
• 學會怎麼把 Outside-In TDD 的流程,寫進給 AI 的具體指令順序裡
• 看懂「先給 AI 一句模糊需求」跟「先給 AI 一組驗收測試」會導出完全不同的產出
• 認識這系列案例本身就是這個做法的證據：main 版本正是先有驗收測試、再讓實作被逼出來
• 建立一個可以在日常跟 AI 協作時套用的具體流程順序

事前引導 vs 事後檢查：成本結構完全不同

事後檢查（例如昨天的複雜度預算、Day 19 的架構測試）能做的事，是在 AI 已經產出程式碼之後，用規則去攔截不合理的部分。這件事有它的價值,但成本結構是「先產生、再篩掉」——AI 已經花時間生成一大段程式碼，你也已經花時間去讀、去判斷該留下什麼、砍掉什麼。

事前引導做的是反過來的事：在 AI 動手寫任何一行實作之前，先確立一組會限制它產出範圍的外部約束——這正是驗收測試在 Outside-In TDD 裡扮演的角色。如果 AI 從一開始就被要求「先寫 Given-When-Then 驗收測試，再回頭用最小實作讓測試變綠」，它可以發揮創意的空間,從一開始就被限定在「讓這幾條測試通過」這件事上，而不是「设計一個看起來完整的系統」這個沒有邊界的目標。

這系列案例本身就是證據

回頭看這個系列反覆提到的兩個版本怎麼被做出來的：main 版本是先寫好 10 條 Given-When-Then 驗收測試，再用 Outside-In TDD 的方式逐條逼出實作,最終是 3 個檔案、249 行；over-engineered-demo 版本是拿同一組驗收測試（一行都沒改）,但給 AI 的指示是針對一句模糊需求自由發揮,結果是 745 個檔案、21,727 行。兩個版本的驗收測試完全一樣，差別只在於「實作是被測試逼出來的」還是「實作是自由發揮出來的」——這個順序上的差異，直接對應了 87 倍的行數落差。

這正是這個系列主題句最直接的應用場景：AI 沒有發明過度設計，它只是讓過度設計的速度追上了你按下 Enter 的速度；Review 要跟得上，審的就不能再是程式碼本身，而是產生程式碼的規則。 如果你想讓 Review 真正跟得上，最有效的辦法不是審查更快，而是讓這條規則在 AI 動手之前就先介入，而不是等它按下 Enter 之後才開始追。

常見誤區：以為「先寫測試」等於「先寫任何測試」

這裡有一個容易踩的坑：如果你請 AI「先寫測試，再寫實作」，但沒有具體規定測試要是「外層、對應業務規則的驗收測試」，AI 很可能會生出一堆針對內部方法、內部類別的細碎單元測試——這種測試同樣會讓「先寫測試」這句指示變成空話,因為它沒有真的限制住「該有哪些類別存在」這個問題，反而可能倒過來,先幫已經想像出來的內部類別背書。

❌ 常見但不夠精確的指示：只講「先寫測試」

「幫我實作發佈文章功能，記得先寫測試再寫實作」

結果：AI 可能先幫自己想像中的
      ArticleValidator、ArticleFactory 各寫一組單元測試，
      這些類別本身仍然是自由發揮想出來的，
      測試只是幫它們背書，沒有限制它們是否該存在

✅ 更精確的指示：明確要求先寫「對應業務規則的外層驗收測試」，並限制實作只回應這些測試

「這是這個功能的完整業務規則清單（4 條）。
 請先把每一條寫成一個 Given-When-Then 的驗收測試，
 全部列出來讓我先確認完整、沒有遺漏。
 確認後，請用最小的實作讓這些測試依序變綠，
 不要新增任何這些測試沒有要求的類別或抽象層。」

第二種指示做了兩件事：先把「業務規則有哪些」講清楚（避免 AI 自己腦補隱性需求），再明確限制「只回應這些測試」——這兩件事合起來，才是真正把 Outside-In TDD 的紀律,轉譯成 AI 協作時可以執行的具體流程。

一個實務上的補充：先讓人確認驗收測試清單

流程裡有一個環節值得特別強調：在 AI 開始寫實作之前，先讓驗收測試清單本身經過一次人工確認。這一步的成本很低（讀 10 條 Given-When-Then 敘述，比讀 3 個檔案的實作還快），但價值很高——如果業務規則本身就漏講了或講錯了，越早在測試清單這個階段被抓出來，後面省下的返工成本越大。這也呼應了 Review 分工模型（Day 23 會展開）裡「人定規則」的角色：人的判斷力,最值得花在「這組規則對不對、完不完整」這個問題上，而不是花在事後逐行讀程式碼。

今日思考題

下一次你請 AI 幫忙實作一個功能時，能不能先花五分鐘，自己（或跟 AI 一起）把業務規則列成一組 Given-When-Then 敘述，再讓它動手寫實作？你覺得這五分鐘,能省下多少事後 review 的時間？

今日重點回顧

• 事前引導跟事後檢查的成本結構不同：前者限制產出範圍，後者篩檢已產出的結果
• 這系列案例的兩個版本，差異的根源正是「實作是被測試逼出來的」還是「自由發揮出來的」
• 只講「先寫測試」不夠精確，必須明確要求「外層、對應業務規則的驗收測試」，否則 AI 可能倒過來用測試幫自由發揮的類別背書
• 讓驗收測試清單先經過人工確認，是成本最低、報酬最高的介入點

明日預告

Day 22 會講怎麼把這套流程寫進 CLAUDE.md 或 Skill 裡，讓它變成 AI 每次對話都會自動遵守的預設值，而不是每次都要重新提醒。

老派工程師的心得

我自己剛開始跟 AI coding agent 協作時,常常犯的錯誤,是把它當成一個「很會寫程式的資淺工程師」,用管理資淺工程師的方式——先讓他自己想辦法做,做完再review、再改。這套方法對 AI 完全不管用，因為 AI「自己想辦法做」的速度太快了，快到你根本來不及在它走錯方向前介入。這幾天重新整理這個案例讓我確定一件事：跟 AI 協作,更接近「先把邊界劃好再放手」,而不是「先放手再事後修正」——這聽起來像是管理上的老生常談,但直到看見 21,727 行的具體數字,我才真正把這句話當真。