TDD、systematic-debugging、verification-before-completion：AI Agent 的三道品質把關

前面談過需求、設計、計畫怎麼排順序。當你真的進入「改程式」這一段，代理可以寫得飛快——快不等於對。Superpowers 裡還有一組流程 skill，專門在實作階段 拉住品質：test-driven-development、systematic-debugging、verification-before-completion。這篇用白話說它們各自守哪一扇門、什麼時候該叫出來，以及新手最常見的錯誤心態。

為什麼 AI Agent 需要品質把關

模型很會「看起來做完」：檔案改了、敘述寫得很有信心，但 行為可能沒對、邊界沒測、環境沒跑過。沒有品質把關時，你得到的是 敘述上的完成感，不是 可驗證的完成。

三道品質把關做的事可以一句話概括：用測試定義「對」、用系統化除錯追到根、用完成前驗證禁止空口交差。它們不保證永不出包，但能把「以為好了其實沒好」的機率壓下去。對初學者來說，先把流程與驗證補齊，往往能在不更換模型的前提下就減少返工；不過模型本身仍會影響理解與產出品質，把關是補強工作方式，不是用來宣稱可以無視模型限制。

TDD 在保護什麼

TDD（這裡指流程裡的 test-driven-development skill） 保護的是：你先說清楚「怎樣算對」，再讓實作去滿足它，而不是反過來用實作結果自己說服自己「應該沒問題」。

它想防的心態包括：

「先寫完再補測試」：常常變成測試遷就程式，而不是程式滿足需求。
「這次改很小不用測」：小改最常踩雷，因為你心裡的假設沒被任何東西打臉。
把 console.log 當驗證：對一次不代表對所有輸入都對。

適用時機：要加行為、修 bug、或重構但怕改壞——只要有「預期輸入／輸出」能寫成測試，TDD 這條跑道就值得上。它不是只給單元測試狂用，而是 強迫你先留下可重跑的證據。

systematic-debugging 在防什麼

systematic-debugging 防的是：看到錯誤就亂改、改到矇對為止、或把症狀當病因。代理（和人）都很容易進入「試試這行、再試試那行」模式，結果 diff 一大包，沒人說得出哪一刀才是真正修到 root cause。

它想推的節奏大概是：先重現、再縮小範圍、再驗證假設，而不是一開始就大改架構或加一堆防禦性程式。常見錯誤心態：

「錯誤訊息很長，直接貼給模型重寫」：可能暫時不爆，但根因沒找到，下次換個輸入又爆。
把運氣當實力：某次跑過就以為好了，沒有最小重現步驟，也沒有回歸檢查。

適用時機：測試失敗、production 怪現象、非決定性 bug——只要你發現自己在「試很多招但說不清為什麼有效」，就該切到系統化除錯這條路。

verification-before-completion 在卡什麼

verification-before-completion 卡的是最後一關：在宣稱「完成」「修好了」「通過了」之前，必須先有跑過的證據。

它想防的心態包括：

「我覺得應該沒問題」：感覺不能當 CI。
「使用者自己會測」：那是 QA 的工作分配，不是完成定義。
只截圖成功畫面、不跑完整指令：成功路徑看了，失敗路徑與邊界沒人負責。

適用時機：每次要結束一個子任務、要 merge、要回報給同事或客戶之前。它的精神很簡單：沒有驗證輸出，就不要寫完成——對代理下指令時，你也可以明講「請跑 X 並貼結果」，等於幫它把這道把關外顯化。

三者如何一起運作

用一條實作線來串：

TDD：先讓「對／錯」變成可自動檢查的東西（紅燈 → 綠燈）。
若紅燈或執行期失敗：systematic-debugging 上場，追到根因再改，避免到處貼膏藥。
要說「這輪做完了」：verification-before-completion 要求你（和代理）用指令、測試或檢查清單 再確認一次，才准關票。

它們不是互斥三選一，而是 同一條品質鏈上的不同關卡：TDD 管「定義與回歸」、除錯管「別瞎修」、驗證管「別空口結案」。和前面 plan 那篇合起來看，就是：計畫寫好怎麼做 → 實作時用測試與除錯守住行為 → 收尾前用驗證守住誠實。

下一步

想回頭補 需求／設計／計畫／實作 的層次與 writing-plans：spec、plan、implementation 有什麼差別？Superpowers 的正確落地流程。
想先把整條路從頭到尾排一次：Superpowers 入門課。

回到系列總覽

這篇負責 三道品質把關的定位與適用時機。若要回到系列的閱讀地圖與建議順序，請開 Superpowers 入門課。