前言：講了 28 天「怎麼做對」，今天要誠實講「做不到什麼」

這個系列從 Day 01 講到現在，一直在談怎麼讓 AI 遵守 Red-Green-Refactor 的紀律、怎麼防止假陽性測試、怎麼判斷一個測試值不值得留。如果讀到這裡，很容易產生一種錯覺：只要把這套紀律做到位，程式碼品質就有保障了。這個錯覺本身，恰好違反了系列一路強調的立場——AI 可以幫你把測試寫對，但不能替你決定要測試什麼、更不能告訴你這個系統的設計方向對不對。 今天要誠實列出這套方法論真正解決不了的事。

今日目標

• 認識三類 TDD（以及這整套 AI 協作紀律）明確解決不了的問題
• 理解「測試齊全」跟「設計正確」是兩個獨立的維度
• 看清楚「流程紀律」補不了「問題理解」的落差
• 建立一套判斷「這件事該不該指望 TDD 幫你擋下來」的分界

第一類：TDD 沒辦法告訴你「這個需求本身對不對」

TDD 循環的起點是先寫一個會失敗的測試，這件事的前提是你已經知道要驗證什麼行為。如果需求理解本身就是錯的——例如把「滿千折百」誤解成「滿千送百元商品」——那麼照著這個錯誤理解寫出來的測試會很漂亮地紅、綠、重構一輪，最後產出一套完全符合錯誤需求、內部邏輯無懈可擊的程式碼。測試驗證的是「程式碼有沒有做到你以為它該做的事」，不是「你以為它該做的事，是不是真的對」。 這條邊界對 AI 協作特別關鍵：AI 越擅長把一個明確的規格轉成測試跟實作，就越容易把「規格本身可能是錯的」這件事藏起來，因為執行過程完全沒有出錯的跡象。

第二類：TDD 沒辦法取代跟真實使用者對話理解問題

寫測試的過程能幫你把模糊的想法變具體——這確實是 TDD 常被稱讚的附加價值。但這個「變具體」的過程，仍然是在你腦中既有的認知範圍內具體化，不會憑空補上你根本沒想到的使用情境。真正能補上這塊的，是去看真實使用者怎麼用這個系統、聽他們抱怨什麼、觀察他們在什麼地方卡住。這件事沒有捷徑，TDD 循環跑得再嚴謹，也不會自動長出你沒問過的問題的答案。

用一組對照來看這兩類邊界的共同模式：

❌ 誤以為流程紀律能補足問題理解：
「我們的 TDD 紀律做得很扎實，測試覆蓋率高、每個循環都有紅綠重構，
 這個功能上線應該不會有問題。」
→ 沒有意識到：紀律保障的是「程式碼符合測試描述的行為」，
  不保障「測試描述的行為，就是使用者真正需要的行為」

✅ 把流程紀律跟問題理解分開檢查：
「TDD 紀律確保了這段程式碼跟我們理解的需求一致；
 但這個理解本身，有沒有跟真實使用者核對過？
 有沒有可能我們一開始就理解錯了？」
→ 誠實區分「執行有沒有做對」跟「方向有沒有選對」，
  是兩個需要分別把關的問題

第三類：TDD 沒辦法防止「測試齊全但整體設計錯誤」的系統

這是最容易被忽略的一類。一個系統可以每個函式都有測試覆蓋、每條分支都驗證過，卻在整體架構層次是災難——模組間耦合過緊、職責劃分不清、每次改動都牽一髮動全身。單元測試驗證的範圍是「這一小段邏輯對不對」，它天生就不負責回答「這些小段邏輯組合起來的整體結構合不合理」這個更高層次的問題。 這正是為什麼這個系列反覆強調「品質把關不能外包給 AI」——AI 可以在你畫出的每一個小格子裡把測試寫得漂漂亮亮，但格子怎麼畫、格子之間怎麼連，是另一套判斷，TDD 循環本身不會替你做這個判斷。

這三類邊界的共同根源是同一件事：TDD 是一套驗證「執行有沒有做對」的紀律，不是一套判斷「方向有沒有選對」的機制。 執行層面的問題（測試寫得對不對、覆蓋夠不夠、重構要不要做）可以、也應該用這套紀律把關；但方向層面的問題（需求理解對不對、架構設計合不合理、使用者真正需要什麼），需要的是另一種能力——業務脈絡、系統設計判斷力、跟人對話的耐心——這些不是靠更嚴謹地執行 TDD 循環就能長出來的。

今日思考題

回想你手上最近一個「測試都寫得很齊全，但上線後還是出問題」的案例：那個問題出在執行層面（測試哪裡沒驗證到），還是方向層面（需求或設計本身就理解錯了）？如果是後者，再嚴謹的 TDD 紀律，原本就不會幫你擋下這一類問題。

今日重點回顧

• TDD 沒辦法告訴你需求本身對不對——測試驗證的是「照著理解做有沒有做對」，不是「理解本身對不對」
• TDD 沒辦法取代跟真實使用者對話——寫測試只能在既有認知範圍內具體化，補不上沒問過的問題
• TDD 沒辦法防止「測試齊全但整體設計錯誤」——單元測試驗證的是小格子內部，不驗證格子怎麼畫
• 這三類邊界的共同根源：TDD 是驗證「執行對不對」的紀律，不是判斷「方向對不對」的機制

明日預告

明天是這個系列的最後一篇：如果重來一次，這 30 天要教的 AI 時代 TDD 練習法會怎麼被重新設計——完整的回顧與總結。