SDD、BDD、TDD 是三個層級不是三個選項

「該用 TDD 還是 BDD 還是 SDD」是假議題。三者管的是不同層級的問題，衝突只發生在誤以為要選一個的時候。

	管什麼	一句話
SDD（規格層）	做什麼、什麼叫做對、契約與相依	定義正確性
BDD（審查層）	這份規格寫夠了沒	逼問正確性
TDD（實作層）	有沒有照著做、改壞了會不會紅	守住正確性

各自解不了的事（這才是為什麼要三層）

• TDD 解不了「做的是不是對的事」——需求錯的時候，TDD 會很有效率地把錯的東西做到綠燈。
• BDD 解不了商業決策改變、非功能需求（效能／成本／擴展性）、跨線技術架構相依（共用 schema、套件版本）。它也沒有契約、相依圖那幾章，所以 BDD 不會取代 SDD——它是 SDD 的一個子步驟。
• SDD 解不了「規格不可證偽」——散文式的規格沒有紅燈機制，spec 與 code 漂移時沒人會知道。要靠 規格檢查要機械化進 CI，不能靠紀律 與 consumer-driven contract test 取代 E2E 驗串接 補上。

吸收格式，不引入工具

BDD 的價值在「用具體例子逼問需求」，不在 Cucumber。實務落法是把 Given/When/Then 當驗收準則的表達形式寫進 spec，測試命名對齊場景標題，不做 Gherkin parser、不開第二份檔案——AC id 追溯鏈讓改規格的影響變成一個 grep。

完整流程：規格先行的七步開發流程