在某個熱門的討論區看到 SDD / TDD 討論，有網友說

“TDD 要多寫很多測試，Token 很貴.. Blah Blah…”

我覺得討論不會有結果，就沒參與了，事後整理了一下想法，所以就多了這篇碎碎念，談一下我怎麼看這件事:

—

我覺得這問題是這樣:

其實 AI 很大一部分，就是把過去因為人力跟時間難以實踐的 “軟體工程”，把門檻降低到大家都能輕鬆接受而已。AI 讓時間不再是問題，剩下的是你有沒有想通 “為什麼” 該做這件事而已。SDD 也是 (為何你該寫清楚規格文件?)，TDD 也是 (為何你要先寫測試再寫程式? )

拿一張古典到不行的圖 ( V-Model ) 來說吧! 過去軟體都是 “手工業” 的時候，軟體開發要一路從左邊到谷底，才能爬到右邊，最終才能交到使用者手上。而文件跟測試，都不是 “最終” 要交付的東西，最終交付的是 “CODE”，因此大部分團隊都會省略部分 “過程”，把人力投在真正能交付 (賣錢) 的 CODE 上面…

於是 SPEC 被省掉了，TEST 被省掉了，沒把關好的品質 ( 設計品質，架構設計，測試執行 ) 等交出去了再慢慢改 (咦?)，是過去幾十年來軟體開發的普遍生態。

AI 突然讓 “CODING” 這件事加速了, 你不必走到谷底 (CODING)，就能跨到山谷的另一端了。速度不是問題，但是其他問題就開始浮現出來了。你會碰到 “做出來不是我要的”，所以 SPEC 開始變重要了，TEST 也開始變重要了。我看到的不是 “導入 SPEC-Kits” 就會變厲害，而是要看清楚流程有什麼變化… 並且寫 “對” 的 SPEC 出來才能解決問題..

我把 SPEC 跟 TEST 在圖上標出位置，其實他們應該是 “一對” 的。你設計出 “規格”，就該有對應的 “測試” 來驗證結果符合規格，這就像在山谷的兩側架了一座吊橋，兩端都準備好 (SPEC, TEST)，中間拉起鋼索 (CONTRACT)，橋就可以逐步搭起來 (AI CODING)。當這兩個環節都有做好，底下的 CODING 你才能放心地交給 AI 去負責。

其實在 SPEC 跟 TEST 中間，還有一個關鍵的設計，那就是 Contract. 要符合 Spec 你可能有上千種實作方式可以選擇，你要的是哪個? 講白話就是 SA / SD, 如果講究一點，我會說是設計系統邊界，把邊界的 Interface / Contract 抓出來 (也就是 API)。當這層抓好了，我不用寫 Code 就能先想像這 Contract 該怎麼實現 Spec, 如果 Contract 可行，我就能按照 Contract 寫出一組對應的 Test …

有了明確的 Contract，Test 就會明確了。之後再讓 AI 按照 SPEC 跟 Contract 去產 code, 產的過程中讓 Test 一個一個從紅燈變成綠燈，這就是 SDD 跟 TDD 的精隨了。控制好頭尾跟過程，你會發現 AI 能犯的錯誤很少，因為都被你框好路線了。如果你只給 SPEC，後面很發散，你就得花很多時間去 Code Review 來收斂，並且叫 AI 重寫。有對應的 Test 你就能少掉很多 Review 的功夫，這就是寫 Test 的價值

回過頭來，好像沒有 AI 這些也都說得通啊，這就我說的 “軟體工程” 基本上就是用一套嚴謹的工程方法，讓 “人” 不會犯錯的方法。只是現在 “人” 換成 “AI”，而你有更低的成本產出 SPEC 跟 TEST，如此而已。過去的軟體工程依然有用，但是你要懂得掌握他。

• -

我推薦大家都去研究一下 SDD, SPEC-Kits 也很值得使用。但是這些都是在過去的軟體工程方法中，淬鍊出來 “特別適合” 搭配 AI Coding 的流程跟文件格式。格式的問題你很好用 LLM 做重新整理，真正關鍵的是你該寫出 “正確” 的規格。這方面的 Know How, 其實不必捨近求遠，過去的軟體工程的知識跟文章多到看不完，善用 Chat GPT 幫你整理歸納，好好的學習就夠了。