前言：為什麼要寫這個系列

決定寫這個系列之前，我心裡其實有點猶豫。市面上不缺「AI 幫你寫測試」的教學文，大多停在「叫 AI 生成一段測試程式碼」這個層次——這對一次性的小需求或許夠用，但沒有回答一個更根本的問題：當寫測試這件事的成本被壓到接近零之後，我們原本靠著「寫測試很花時間」這個摩擦力逼自己做的品質判斷，要靠什麼機制找回來？

這個念頭在我自己的日常工作裡越來越具體。過去幾年，我陸續整理過一些關於單元測試、Test Double、覆蓋率誤區的內部教材，零零散散寫在筆記、簡報、code review 留言裡，一直沒有機會系統性地把它們串成一套東西。AI coding agent 開始大量介入日常開發之後，我發現這些散落的經驗突然有了一個共同的敵人：不是「沒有測試」，而是「看起來有測試，但這些測試沒有在保護任何東西」。這個系列，就是藉著鐵人賽的動力，把這些經驗收斂成一套跟 AI 協作時可以照著走的紀律。

第一部回顧：為什麼 AI 時代更需要 TDD

第一部（Day 1-7）從「AI 都能自動生成測試了，還需要 TDD 嗎」這個問題出發，一路拆解 Red-Green-Refactor 三個階段各自在 AI 協作下容易被跳過的環節。這幾天想釐清的核心是一件容易被混淆的事：AI 大幅拉高了「產出測試」的速度，但完全沒有拉高「判斷測試品質」的能力——這是兩條獨立的軸線，前者被自動化，後者如果沒有人主動介入，不會自動跟著提升。

現在回頭看，這一部最重要的不是任何一個具體技巧，而是建立了三個貫穿全系列的判斷句：留不留、夠不夠、做不做。後面 23 天不管講的是命名、Mock、覆蓋率還是任務拆解，骨子裡都是同一組問題的不同外殼。

第二部回顧：AI 寫測試最容易犯的錯

第二部（Day 8-16）走得最細，從 Green 階段的硬編碼陷阱、測試命名的兩種失敗模式、Mock 濫用與過度隔離，一路到邊界情境容易被遺漏。這幾天累積的具體案例，想傳達的是同一件事的不同樣貌：AI 面對「怎麼讓測試通過」這個任務時，會找到技術上成立、但脫離了測試真正目的的捷徑——把期望值直接寫死進實作、把方法簽章翻譯成落落長的測試名稱、把每一個依賴都隔離到連整合行為都測不到。這些捷徑不是 AI 能力不足，而是它被要求解的問題（讓測試變綠）跟我們真正想要的結果（測試能提供保護）並不完全重疊。

第三部回顧：讓 AI 遵守 TDD 循環的具體做法

第三部（Day 17-23）從覆蓋率不是品質的迷思開始，講到 Test Double 的正確選擇、TDD 循環被「一次到位」打斷的成因，最後收在 Pair Programming 的 driver/navigator 分工模式。這一部比較偏向「怎麼做」而不是「哪裡容易錯」——核心工具是把大任務拆成多輪明確的紅綠重構循環，並用 navigator 的角色框架，把「委派」跟「放手不管」清楚地區分開來。這幾天讓我更確定一件事：**紀律不是靠意志力維持的，是靠流程設計逼出來的。**與其期待每次都記得要求 AI 守規矩，不如把檢查點寫進委派的方式本身。

第四部回顧：實戰案例

第四部（Day 24-29）用幾個具體案例，把前面 23 天的原則放回真實情境裡檢驗：測試因為斷言方式有問題掩蓋掉真正的 bug、AI 選擇放寬斷言而不是修好程式碼、遺留系統補測試時特徵測試的取捨、品質把關的三個判斷、AI 時代的分工模型，以及這套方法論本身解決不了什麼。這幾篇合起來想證明一件事：這一路講的原則不是憑空想像出來的方法論，是可以在真實除錯情境裡一條一條驗證的紀律。

一個誠實的失敗經驗

寫到這裡，如果只講「照著這套紀律做就萬事順利」，那就違背了這個系列一直在強調的立場——AI 給出的、或者我自己給出的任何結論，都該誠實標注它的邊界。

我自己也不是每次都守住這套紀律。有一次接到一個時程壓得很緊的功能，我明知道正確的做法是先讓 AI 針對這個功能拆出三、四輪小步驟的紅綠重構，但當下判斷「這個功能邏輯簡單，應該不會出問題」，直接讓 AI 一次生成了完整實作跟一整批測試，全部綠燈，我掃過一眼覺得沒問題就合併了。

結果上線後兩天，一個邊界情境（輸入剛好卡在某個數值門檻上）出了問題。回頭查那批測試，果然沒有涵蓋這個門檻值本身，只測了門檻值前後比較遠的兩個數字。事後花在除錯、寫修復、補測試上的時間，遠遠超過當初「省下」的那三、四輪 TDD 循環所需要的時間。

這件事讓我更確定：「這次應該沒問題」這句話，是整套紀律裡最危險的例外——不是因為判斷一定是錯的，而是因為一旦允許自己在「感覺沒問題」的時候跳過紀律，這個例外會慢慢變成常態。這套流程能不能落地，考驗的往往不是知不知道原則，而是在時程壓力下還願不願意照著走。

回到系列主題句

系列一開始立下的主題句是：AI 可以加速 Red-Green-Refactor 循環的每一步，但「這個測試值不值得留、覆蓋夠不夠、重構要不要做」這些品質判斷，不能交給 AI 自己決定。

30 天寫完，我更確定這句話，但也更確定它背後真正的意涵不是「不信任 AI」，而是分清楚「能被自動化的」跟「需要理解業務意圖才能判斷的」這兩類工作，把兩者混在一起處理,是所有陷阱共同的根源。測試骨架、邊界案例的產生、程式碼片段的重寫，這些是可以交給 AI 大幅加速的；但「這個測試在保護什麼、值不值得留下來」，需要對系統實際該做什麼有理解，這個理解沒辦法外包。

給讀者的實用建議

如果你也想開始把這套紀律套進自己跟 AI 協作的流程，幾個立即可行的第一步：

• 每次 AI 產出測試後，問一句「如果我故意把這段邏輯改錯，這個測試會不會變紅」。這是整個系列成本最低、效益最高的單一習慣，Day 07 講過的判斷法可以直接套用。
• 從命名開始練：下次 review AI 生成的測試時，先只看名稱，問自己「這個名稱有沒有告訴我它在驗證什麼業務規則」，這個練習比想像中更快能訓練出判斷力。
• 把「先紅後綠」當成一個明確的委派指令，而不是默認的期待：與其期待 AI 自己記得，不如在每次要求它實作功能時，明確拆成「先寫一個會失敗的測試」「展示失敗」「再寫最小實作」這幾個步驟。

漸進式的技能發展路徑：先練會判斷「這個測試留不留」，這是最基礎、也最常用的判斷；再練「邊界夠不夠」，開始主動列出 happy path 之外的情境清單；最後才是「重構做不做」，這個判斷需要對系統未來變動方向有一定的理解，通常要累積一定的專案經驗才會越來越準。

結語

回到 Day 01 那句話：AI 可以加速 Red-Green-Refactor 循環的每一步，但品質判斷不能交給 AI 自己決定。寫完這 30 天，我最大的體會是——這不是一句要你提防 AI 的警語,而是一句提醒你「你的判斷力在哪個環節最有價值」的定位句。AI 越擅長把測試「產出」這件事做得又快又多，人在「判斷這些產出值不值得留下」這件事上的角色，就越不能少。

這套紀律還在持續演化，我自己也還在練習怎麼在時程壓力下不跳過它。如果你在自己的專案裡也踩過類似的坑，或是找到了更好的做法，很樂意聽聽你的版本長什麼樣。謝謝你陪我走完這 30 天。