前言：把 27 天的技巧收攏成一張分工圖

昨天列出三個不能外包的判斷（留不留、夠不夠、做不做），今天要把這件事講得更完整：不是零散地在幾個時間點介入,而是有一個貫穿整個 TDD 循環的分工模型——AI 負責產生候選方案跟機械執行，人負責在每個候選方案出現的地方做品質判斷。 這個模型不是這個系列臨時發明的框架,而是把前面 27 天累積的具體做法,收攏成一張可以重複套用的分工圖。

今日目標

• 理解「候選方案」跟「最終決定」這兩個角色分別對應 TDD 循環的哪些環節
• 看懂一張具體的分工對照表：每個階段誰產生候選、誰做判斷
• 認識這個模型跟「一次性委派、看結果就接受」的根本差異
• 學會用這個模型檢查自己目前的協作方式,漏了哪個判斷點

分工模型：三個階段，各自的候選與判斷

把 Red-Green-Refactor 三個階段攤開來看，每個階段都有一個「AI 產生什麼」跟「人判斷什麼」的對應關係：

Red 階段——AI 產生的候選是「測試案例的斷言內容」；人判斷的是「這個斷言驗證的是不是真正該驗證的業務規則」（Day04、Day05 講過的假陽性辨識）。AI 可以很快寫出語法正確的斷言，但斷言驗證的對不對，需要人對業務規則的理解才能判斷。

Green 階段——AI 產生的候選是「讓測試通過的實作」；人判斷的是「這個實作是真正符合規則的邏輯，還是投機取巧的硬編碼」（Day09 講過的硬編碼案例）。AI 的目標函式是「讓測試變綠」，這跟「寫出正確邏輯」在多數情況下重疊，但不保證每次都重疊。

Refactor 階段——AI 產生的候選是「重構後的程式碼結構」；人判斷的是「這個重構有沒有被測試覆蓋保護、現在是不是動手的時機」（Day10、Day27 講過的順手重構風險）。

跨階段的候選——除了每個階段內部，還有一類候選是「這個測試值不值得留、覆蓋夠不夠」（Day16、Day27 講過），這個判斷不屬於單一階段，而是貫穿整個循環的品質把關。

這個模型跟「一次性委派」的根本差異

用一組對照來看這個分工模型實際運作起來是什麼樣子：

❌ 沒有分工模型，一次性委派：
「幫我用 TDD 實作這個折扣計算功能。」
（等待）
AI：「完成了，測試都綠燈，覆蓋率 92%。」
→ 三個階段的候選方案在同一次回應裡全部產生完畢，
  人只看到一個打包好的最終結果，
  沒有在任何一個階段的候選出現時介入判斷

✅ 有分工模型，逐階段確認候選：
「先寫第一個測試案例，向我展示它會失敗。」
（AI 展示 Red，人確認：這個斷言驗證的是不是我要的規則？）
「現在寫最小實作讓它通過。」
（AI 展示 Green，人確認：這是真邏輯還是硬編碼？）
「這裡有沒有需要重構的地方？」
（AI 提出候選，人確認：測試覆蓋夠嗎？現在該動嗎？）
→ 每個候選方案出現的當下就被判斷過，
  最終結果是一連串小決定的累積，不是一次性的黑箱產出

這個模型的核心價值不是「讓 AI 做得更好」，而是「讓人的判斷力介入的時間點,對齊候選方案實際產生的時間點」。 一次性委派讓判斷延後到看到最終結果才發生，中間所有的候選方案都在人沒看到的地方被 AI 自己決定過一輪；分工模型把判斷點往前移，跟候選方案的產生同步。

這個模型不要求每次都走完整流程

值得澄清一點：這個分工模型不是說每一行程式碼都要照著三階段走一遍問答。對於低風險、範圍明確的小改動（例如加一個簡單的 getter），逐階段確認的成本可能高於它帶來的保護。 這個模型該套用的地方，是 Day22 講過的「規則交互複雜、bug 密度高風險」的情境——分工模型是一個工具，不是一套宗教儀式，該不該用、用到多細，本身也是「做不做」這個判斷的一部分。

今日思考題

回想你手上正在進行的一個協作任務：三個階段（Red/Green/Refactor）裡，你的判斷是跟著候選方案同步發生，還是延後到看到最終結果才一次補上？如果是後者，中間有多少候選方案是你根本沒看過就被接受的？

今日重點回顧

• 分工模型的核心：AI 產生候選方案（斷言內容、實作邏輯、重構結構），人在每個候選出現時做品質判斷
• Red/Green/Refactor 三階段各自對應不同的候選與判斷內容，另外還有跨階段的「留不留、夠不夠」判斷
• 這個模型的價值在於讓判斷點對齊候選產生的時間點，而不是延後到看到最終結果才介入
• 分工模型不是每次都要走完整流程，該不該套用本身也是一個「做不做」的判斷

明日預告

明天要誠實面對這套方法論的邊界：講了 28 天「怎麼做」，明天要講「TDD 解決不了什麼問題」。