最近在討論 Spec-Driven Development（SDD） 時，身邊的朋友提出了不少有意思的看法。工具與情境不同，做法自然也不同。我這邊提供一條自己覺得在生成式開發脈絡下比較順暢的路徑：
用 SDD 釐清規格 → 用 BDD 的例子對齊與具體化 → 最後以 TDD 在程式層落地與驗證。Kiro 這類平台可以協助把前兩步的內容連結到實作，整體會更順。
「先把對的事做對，再把事做快。」放在 AI 協作的年代依然受用。
一、SDD：先把「要做什麼」說清楚（Kiro 的生成起點）
目標：讓人與 AI 都能在同一份可機讀的規格上工作。
以「台灣高鐵早鳥票」為例，先釐清可被計算與驗證的規則與名詞：
- 早鳥可預訂區間：開車日前 5～28 天（含）。
- 優惠層級（例）：10%／20%／35%，名額隨時間與需求調整。
- 連假或指定期間不開放早鳥。
- 旅客變更車次則失去早鳥資格。
在 Kiro 中，這些可以以 YAML/JSON 的規格表述，作為 AI 生出資料模型、API 端點與流程骨架的依據。SDD 的重點不在工程風格，而在語意與規則的清晰。
二、BDD：用「例子」讓規格更貼近真實（服務 SDD 的對齊與解釋）
目標：用情境例子把規格說白，形成跨角色共識與可驗收的語句；必要時再挑選自動化。
- 例子 A：4/1 預訂 4/20 → 顯示早鳥票價與對應折扣。
- 例子 B：4/19 預訂 4/20 → 不顯示早鳥票價。
- 例子 C：已享 20% 早鳥欲改票 → 提示「改票將失去早鳥資格」。
實務上可用 Example Mapping / 小型情境工作坊，讓 PM/RD/QA 一起把「非尖峰」「連假」等易歧義名詞收斂為可計算的定義。
在 Kiro 中，這些例子可轉成驗收測試骨架（API/端對端），為後續程式實作提供準星。
「好的例子會逼出清楚的語言；清楚的語言才有清楚的產品。」
三、TDD：以「類別為單位」落地與保護（class-centric）
目標：在程式層，以類別（class）與公開方法為單位，建立可回歸的保護網，確保邏輯與設計品質。
延續上面的例子，我們會有像 EarlyBirdPolicy 這樣的類別，可能的方法包括：
isEligible(bookingDate, departureDate)：是否符合 5～28 天且非連假applyDiscount(baseFare, tier)：套用 10%/20%/35%losesEligibilityOnChange()：改票是否失去資格
TDD 會先寫紅燈測試，再以最小實作轉綠，最後重構。
和 BDD 的差別在於：BDD 對齊行為（人話與情境），TDD 驗證類別邏輯（程式語境）；兩者互補而非重疊。
為什麼這樣的順序在生成式開發情境下更順？
- SDD 把「要做什麼」講清楚，Kiro 才能有方向生成。
- BDD 以例子補足語意落差，讓規格可討論、可驗收，也更容易挑選哪些情境值得自動化。
- TDD 在程式層面維持正確性與可重構性，確保日後修改不會破壞早鳥規則。
「電腦會照你說的做，不會照你想的做。」— 把想法在前面說清楚，後面就少走冤枉路。
小結
- Kiro × SDD：讀取機讀規格，產出資料模型與服務骨架。
- Kiro × BDD：把情境例子連到驗收測試骨架，形成可執行的規格。
- Kiro × TDD：協助生成單元測試雛形，但由開發者以類別為單位完成紅綠燈循環與重構。
這不是唯一做法，只是我目前覺得這樣在 AI 輔助開發裡還算直覺的一條路：
SDD 定方向 → BDD 舉例對齊 → TDD 類別驗證。
當人與 AI 都在同一份清楚的規格上合作，速度與信心會同時提升。
發表迴響