前言：技術上都對，但不代表可以放手

「AI 寫的測試邏輯沒錯、覆蓋率也達標、重構建議也合理，這樣還不能放心交給它嗎？」

這個系列走到第 27 天，講過很多 AI 在 TDD 各個階段容易犯的技術性錯誤——假陽性測試、過度 mock、循環被打斷、測試改鬆讓 CI 通過。但今天要講一件更根本的事：就算 AI 把每一個技術動作都做對了，還是有三個判斷不能交給它自己決定。 這三個判斷的共同點是：它們問的不是「這樣做對不對」，而是「這樣做值不值得」——後面這種問題，答案取決於團隊的時間、風險胃納、專案階段，不是程式碼本身能回答的。

今日目標

• 收斂前面 26 天的內容，抓出三個具體的「不能外包」判斷
• 理解這三個判斷為什麼本質上是取捨問題，不是技術正確性問題
• 看清楚「AI 做得很好」跟「AI 有資格自己決定」是兩件不同的事
• 建立一套簡單的自我檢查：這個決定屬於哪一類

判斷一：這個測試，留不留？

Day 16 講過測試品質的判斷標準——真的紅過、斷言驗證了結果本身、涵蓋邊界情境。但就算一個測試通過了這些檢查，還有一個問題技術標準回答不了：這個測試值得長期維護嗎？

每一個留下來的測試都是未來的維護成本——重構時要跟著改、CI 跑起來要花時間、新人讀程式碼時要多理解一個案例。一個測試技術上寫得很紮實，但如果驗證的是一個團隊已經決定要棄用的舊功能，或者是一個發生機率極低、就算真的出錯也影響很小的邊界情境，留不留就變成一個「投入產出比划不划算」的問題——這需要知道專案的優先序、團隊的維護容量，AI 手上沒有這些資訊。

判斷二：覆蓋夠不夠？

Day 17、18 講過覆蓋率不是品質——覆蓋率高不代表測試有驗證到東西。但反過來也要問：就算每一行都是「有意義的覆蓋」，覆蓋到什麼程度才算「夠了」？

這同樣是個取捨問題。一個核心結算邏輯，可能需要窮舉到幾十種邊界組合才算夠；一個內部工具的輔助函式，覆蓋到主要情境可能就足夠，繼續往下投入邊際效益很低。「夠不夠」取決於這段程式碼出錯的代價有多高、團隊剩下多少時間——這是一個風險胃納的問題，AI 可以幫忙列出還沒覆蓋到的情境清單，但「要不要繼續補下去」的停損點，得由知道代價與時程的人決定。

判斷三：這一步 Refactor，做不做？

Day 10 講過 TDD 的 Refactor 階段，AI 容易「順手」做一些沒被要求的額外調整。但這裡要問一個更根本的問題：就算 AI 誠實地只提出重構建議、不擅自動手，這個建議該不該現在就做？

一個技術上合理的重構——抽出重複邏輯、換一個更清楚的命名、拆分過長的方法——可能會跟當下的交付時程衝突，可能會踩到一個團隊還沒決定要不要換的架構方向,也可能單純是「現在改動風險太高、之後再處理比較安全」。AI 判斷「這樣重構在技術上是對的」沒問題,但「現在做不做」牽涉到時程壓力、風險評估、甚至團隊共識這些程式碼本身看不出來的因素。

三個判斷的共同結構

用一組對照來看這三個判斷共同的模式：

❌ AI 自己拍板：
「這個測試技術上沒問題，我留著了。」
「覆蓋率我覺得夠了，我停在這裡。」
「這裡可以重構得更好，我已經改了。」
→ 三種情況的共同問題：AI 用「技術上合理」
  取代了「值不值得」這個需要團隊脈絡的判斷

✅ AI 呈現選項，人拍板：
「這個測試留著會有維護成本，但驗證的情境發生機率很低，
 要不要留，你們怎麼看？」
「還有這幾種邊界情境沒覆蓋到，代價評估是這樣，
 要繼續補到什麼程度？」
「這裡可以重構，但時程上可能要延，
 現在做還是先記錄下來？」
→ 呈現查證過的事實跟選項，決定權留給人

這三個判斷共同的結構，跟這個系列從第一天就在講的道理是同一件事：AI 擅長回答「這樣做技術上對不對」，但「值不值得」永遠需要脈絡——而脈絡是 AI 手上沒有、也不該自己假設的東西。

今日思考題

回想你上一次接受 AI 對測試/覆蓋率/重構的建議：那個決定屬於「技術上對不對」，還是「值不值得」？如果是後者，你當時有意識到自己其實在幫 AI 做一個它不該自己做的決定嗎？

今日重點回顧

• 三個不能外包給 AI 的判斷：這個測試留不留、覆蓋夠不夠、這一步 Refactor 做不做
• 三者的共同結構：問的是「值不值得」，不是「對不對」——前者需要團隊脈絡，AI 手上沒有這些資訊
• AI 做得再好的技術判斷，也不等於它有資格替團隊做取捨決定
• 正確的分工是 AI 呈現選項跟依據，人做最終取捨

明日預告

明天要把這三個判斷收進一個更完整的分工模型：AI 時代 TDD 的分工模型——AI 產生候選方案，人做品質判斷。