Day 5 講了一份 spec 需要什麼：觸發條件、預期結果、驗收條件。那份 spec 寫的是人話 — 「連續五次失敗帳號鎖定三十分鐘」。
人話需要一個人去讀 code、比對、判斷「對，這段 code 確實在五次之後鎖帳號」。500 行 AI 生成的 code，可能有一個 off-by-one — 鎖的是第六次不是第五次。格式完美、命名合理、看起來全對，但迴圈條件寫反了。
測試做的是同一件事，但它自己會跑：呼叫 login 五次帶錯誤密碼，第六次不管密碼對不對，回應應該是 429。跑一次，紅燈或綠燈，沒有模糊空間。
Spec 告訴 AI 做什麼。測試告訴你它有沒有做對。
2003 年，Kent Beck 出版 "Test-Driven Development: By Example"。核心流程三步：
Red — 先寫一個測試，跑一次，確認它失敗。失敗代表行為還不存在。
Green — 寫最少的 code 讓測試通過。不多不少，剛好讓紅燈變綠。
Refactor — 測試綠了之後整理 code。安全網就是那些測試 — 改完再跑，還是綠就沒改壞。
二十年前，測試先行被不少人當成矯枉過正。「我知道我要寫什麼，幹嘛先寫一個必定失敗的東西？」
二十年後，Kent Beck 觀察到一個現象：AI 不想做 TDD。它的自然傾向是直接寫 code，然後補一組會通過的測試。問題是 — 後補的測試測的是「code 現在的行為」，不是「code 應該有的行為」。測試變成替現狀背書，而不是定義期望。
這正是 TDD 要解決的問題。不管執行者是人還是 AI。
Coding agent 的工作方式就是一個迴圈：讀檔、改 code、在終端機跑測試、讀失敗訊息、根據錯誤改 code、再跑一次。這個 agent loop 的結構本身就是紅綠燈循環 — 跑測試 → 紅燈 → 改 code → 跑測試 → 綠燈 → 重構 → 跑測試確認還是綠的。
差別在速度。人做一輪 red-green 可能十分鐘。Agent 做一輪可能三十秒 — 讀錯誤訊息、定位問題、改 code、再跑，整個迴圈在終端機裡自動完成。
Claude Code 有一個功能把這個迴圈變得更明確：/loop。輸入 /loop "跑 pytest，失敗就修到全過" — 它就會自己反覆跑測試、讀錯誤、改 code，直到全綠或你喊停。不用每次手動看結果再下指令，整個 red-green 循環變成一條指令驅動的自動迴圈。測試就是驅動這個迴圈的燃料。
沒有測試的時候，agent 寫完 code 只能告訴你「我覺得這樣對」。有測試的時候，它能告訴你「測試全過了」。這兩句話的可信度差距不需要解釋。
Exadel 在 2026 年引用 DORA 報告的數據：AI 使用量增加 25% 的團隊，交付穩定性反而下降了 7.2%。結論一句話 — 速度跟交付不是同一件事。
沒有 AI 的時候，工程師一天寫兩百行，review 兩百行是合理的。有 AI 之後一天可能產兩千行，但 AI 生成的 code 格式完美、看起來全對，人眼很難從中找到邏輯錯誤。問題藏在邊界條件、race condition、off-by-one — 不是語法錯，是行為錯。
測試把 review 的焦點翻轉。從逐行讀 code 找邏輯錯，變成先確認行為對不對。兩千行 code 跑一次測試，失敗的那幾條直接告訴你該看哪裡。
Kent Beck 二十年前的洞察是：測試定義行為，實作是次要的。當實作越來越多交給 AI，「行為有沒有對」就是最核心需要人判斷的事。
延伸閱讀
iThome鐵人賽
看影片追技術