透過細部拆解練習，讓 AI 協作 TDD 更穩定
最近在用 AI 協作寫程式的時候，我發現了一個有趣的現象：當我直接要求 AI「用 TDD 寫程式」時，它往往會跳過某些步驟，或是一次寫太多實作。後來我想起之前刻意練習過的「開發流程細部拆解」概念，試著把 TDD 拆解成更具體的指令。經過這幾天的實際測試，效果意外地好。
透過細部拆解的練習，我試著讓 AI 協作 TDD 變得更穩定。這不是什麼完美的解決方案，而是一個持續改善的過程。但我想分享一下這個過程中的一些心得。
把抽象原則變成具體指令
TDD 的核心概念是「紅燈、綠燈、重構」的循環，但這對 AI 來說太抽象了。我想了想，可能是因為這些概念在腦中是「心領神會」的，但 AI 需要更明確的操作指引。
我嘗試把 TDD 拆解成三個獨立的 prompt：
Red Phase 專門負責寫失敗測試。這個階段我會要求 AI 只考慮當前這一個需求，不要預測未來可能要加的功能，並且確保測試會失敗，而且失敗原因清楚。
Green Phase 專門負責最小實作。目標就是讓測試通過，不要寫多餘的程式碼。我會告訴 AI 可以用 hardcode、if-else，甚至直接 throw exception，只要能讓測試變綠就好。
Refactor Phase 專門負責改善程式碼。在這個階段，所有測試都要保持綠燈，然後去找出重複的程式碼，改善命名和結構。
每個階段都有自己的檢查清單和常見錯誤提醒。比如在 Red Phase，我會特別強調 ❌ 不要 peek 未來需求，✅ 專注當前測試。這樣 AI 就比較不會一次做太多事情。
讓不同 AI 都能理解
我主要用 Claude 開發，但也希望能在 Gemini 2.5 Flash 上使用。在測試過程中，我發現兩個模型確實有些差異。
Claude 比較善於理解上下文，即使指令稍微模糊一點也能猜出我的意圖。但 Gemini Flash 需要更明確的指令格式，而且有時候會有一些奇妙的行為。
最明顯的是 refactor 階段。有時候 Flash 會說「這裡應該要改善」，我也覺得要改，但它就是沒有動作。後來我發現要給它更明確的指令：「現在執行 refactor，請實際修改程式碼」，它才會真的動手。
在實際使用時，我不自覺地把整個系統設計成模組化的：
tdd-session.prompt作為主控制器，判斷當前該進入哪個階段red-phase.prompt、green-phase.prompt、refactor-phase.prompt分別處理各階段coding-style.prompt提供一致的程式碼標準
這樣的好處是可以把每個階段的細節都拆解清楚，各自專注在自己該做的事情上。
實際效果如何？
說實話，剛開始我也不確定這樣做值不值得。畢竟 prompt 變多了，token 用量也增加了。但測試了這幾天後，我發現有幾個明顯的改善。
首先是 AI 不再忘記步驟了。改善前，AI 經常會直接跳到實作，或是忘記 refactor。現在每個階段都會讀對應的 prompt，執行變得更有紀律。其次，我對 TDD 的理解更深了。在拆解 prompt 的過程中，我被迫去思考每個階段到底在做什麼。原來我以為自己懂 TDD，但要寫成 AI 能理解的指令時，才發現很多細節其實是模糊的。另外，程式碼品質也變得更一致。因為每個階段都有明確的標準，AI 寫出來的程式碼風格和結構變得比較穩定。雖然不是完美，但至少不會差距太大。
但也有一些限制。Token 用量確實增加了，特別是要在每個階段都讀一次對應的 prompt。而且這套系統需要持續維護，當發現 AI 有新的問題時，就要調整對應的 prompt。不過想想，這動作很像人類拿著小抄，或是處理重要的事項時，拿出 SOP 仔細小心地按圖施工。從這個角度來看，也許這些成本是合理的。
這是一種學習方式
我覺得這個練習最大的價值，不只是讓 AI 協作更穩定，而是讓我重新思考了什麼叫「知道一個概念」。以前對於「懂 TDD」這件事，常常是「腦子懂了手不會做」的狀態。但當你要教 AI 做 TDD 時，你必須把每個步驟都展開得很清楚，每個判斷都要有明確的依據。這個過程讓我對 TDD 有了更深的理解。
而且這種方法不只適用於 TDD。任何你覺得「心領神會」但說不清楚的技術實踐，都可以用類似的方式來練習。透過教 AI，我們也在重新學習。當然，我不會說這是最好的方法。每個人的使用習慣不同，AI 的能力也在快速進步。但如果你也在嘗試 AI 協作開發，也許可以試試這種「細部拆解」的思路。最重要的是，不要期待一次就做到完美。這是一個持續改善的過程，邊用邊調整才是最實際的做法。
JCConf 官網 https://jcconf.tw/2025/
Java TDD Kata 練習 https://github.com/qty-playground/tdd-kata-java