前言：三階段流程都照做了，為什麼還是感覺在趕工？

「我已經照 Day 11 教的方式，把任務拆成『寫測試展示失敗 → 補實作展示通過 → 重構』三個階段，每個階段都要求 AI 交出證據了，為什麼實際做起來，還是感覺 AI 在趕進度？」

如果你認真套用過 Day 11 的三階段流程，可能已經發現一個問題：三階段本身沒有規定「一次要處理多大的範圍」。 AI 完全可以在第一階段一口氣寫出十個測試案例、全部展示失敗，第二階段一口氣把十個都實作完、全部展示通過——三個階段確實都走了，卻依然是「一次到位」，只是換了個包裝。今天要補上 Day 11 沒講清楚的那塊拼圖：怎麼強迫範圍本身也拆小,不只是流程拆小。

今日目標

• 理解「階段拆小」跟「範圍拆小」是兩個獨立的維度，只做到前者還不夠
• 學會具體的做法：把「一次只處理一個測試案例」當成硬性限制
• 看懂範圍太大時,即使照三階段走,測試品質依然會打折的原因
• 建立一套可以直接套用的小步驟溝通模板

階段拆小，不等於範圍拆小

Day 11 講的三階段流程，解決的是「有沒有留下中間證據」這個問題——AI 老實展示了紅燈、老實展示了綠燈,流程上完全合規。但這個流程沒有限制「這一輪紅綠重構,涵蓋的範圍有多大」。如果一個功能有五種輸入情境要處理,AI 完全可以在第一階段就把五個測試案例一次寫完、一次展示五個失敗,第二階段一次把五個實作邏輯全部補齊、一次展示五個通過。

這樣做完全符合「先紅後綠」的字面要求,卻失去了小步驟最重要的價值:每一步都能單獨判斷「這個改動是不是真的只為了讓眼前這一個案例通過」。 當五個案例的實作一次寫完,你沒辦法分辨這段程式碼裡,哪一部分是為了案例一寫的、哪一部分是為了案例三寫的——它們已經混在一起,變成一次到位的變體。

把「一個測試案例」當成不可分割的單位

具體做法是:在拆解階段時,額外加上一條範圍限制——每一輪紅綠循環,只處理一個測試案例,不是一個功能。 一個功能如果需要五種情境,就要走五輪完整的紅綠循環,而不是把五個情境塞進同一輪的紅燈/綠燈裡。

這條限制要在委派任務時明講,而不是預期 AI 自己意識到,例如:

用一組對照來看這個差異:

❌ 沒有限制範圍的三階段:
「請用 TDD 方式實作折扣計算,涵蓋一般會員、
 VIP 會員、優惠券過期、優惠券疊加這四種情境。」
→ AI 一次列出四個測試案例、一次展示四個失敗、
  一次補完四段邏輯、一次展示四個通過——
  三階段都做了,但每一步都在處理四倍大的範圍,
  沒有人能從中間過程分辨哪段實作對應哪個案例

✅ 限制範圍的三階段:
「先只處理『一般會員無優惠券』這一種情境,
 寫一個測試、展示失敗、補最小實作、展示通過。
 這一輪結束後,我們再開始下一個情境:VIP 會員。」
→ 四種情境走四輪獨立的紅綠循環,
  每一輪的實作範圍精確對應一個測試案例,
  重構時也只需要考慮這一輪新增的程式碼

範圍拆小之後,重構階段才有意義——如果一輪紅綠循環涵蓋了四個案例,「這一輪的重構」根本沒有明確邊界;範圍縮小到一個案例,重構要處理的東西就是「這一個案例新增的程式碼,跟既有程式碼之間有沒有重複或不一致」,這是一個具體、可以被驗證做完了沒有的問題。

為什麼要堅持這麼細碎

這聽起來會拖慢速度——把一個功能拆成五輪循環,確實比一次做完要多花幾輪溝通。但這個代價換來的是:每一輪的測試,都是在「只有這一個案例的邏輯存在」的情況下被驗證過有效性(呼應 Day 06、Day 07 講的 Red 階段查證范圍);每一輪的重構,都有明確的邊界可以檢查有沒有做完。

小步驟拖慢的是「看起來完成一個功能」的速度,換來的是「每一步都真的被驗證過」的確定性——這個交換,在建立測試安全網這件事情上,幾乎永遠是划算的。

今日思考題

回想你上一次拆解任務給 AI 的方式:你拆的是「流程階段」,還是「處理範圍」?如果一個功能有多種情境,你是要求 AI 一輪處理完所有情境,還是一輪只處理一種?

今日重點回顧

• 「階段拆小」(紅→綠→重構分開展示證據)跟「範圍拆小」(一輪只處理一個測試案例)是兩個獨立的維度,只做到前者,依然可能是包裝過的一次到位
• 具體做法:委派任務時明講「一輪只處理一個測試案例」,不要預期 AI 自己意識到這條限制
• 範圍拆小之後,重構階段才有明確邊界可以檢查——一輪涵蓋多個案例時,「這一輪的重構」根本無從定義
• 小步驟拖慢的是表面完工速度,換來的是每一步都真的被驗證過的確定性

明日預告

明天用一個具體案例對照:同一個功能,一次做完 vs 拆成多輪 TDD 循環,最後產出的程式碼品質有什麼看得見的差異。