SDD 研究

最近在啃《Spec by Example》這本書，接下來會連載關於 SDD（Spec-Driven Development）的內容，盡量寫得淺顯易懂。

目前就我所接觸到的資訊，SDD 有很多解讀，不同背景的人對這個詞的定義跟想像可能也不同。

對沒有程式背景的人來說，會接觸到 SDD，應該是因為 AI 爆發後，發現若沒有提早規劃好需求，結果會難以控制，甚至 Vibe 出來的東西根本跑不動。所以事前的 Planning 變得非常重要，Plan Mode 也應運而生。但光是 Plan Mode 好像還是有其侷限，毫無章法、遺失細節的需求描述，只會讓 AI 自己腦補剩下 90% 沒被定義的內容。這對需要精準控制結果的人來說是無法接受的，所以出現了 Spec Kit，這是在相同 Model 下，Context Engineering 的一種極致展現。

對有程式背景的人來說，SDD 其實偏向一個 Buzzword。因為原本的 BDD（Behavior-Driven Development）其實就已經涵蓋了 SDD 的精神，而且更為實際。它規範了如何描述需求，以及描述需求的文件要如何可執行化，因此也涵蓋了 TDD（Test-Driven Development）的內容。如果說這裡的 SDD 真的有額外含義，應該是指 AI 與 BDD 的結合吧。這其中多出了跟 AI 協作的流程：需要先準備好怎樣的素材，才能讓 AI 產出符合規格的程式碼；以及在需求變動之下如何快速迭代。若要追求更自動化的產出，就必須有相應的方法論及工具輔助。

從本質而言，為什麼需要 Spec？因為它是用自然語言描述系統需求，讓不同職能的人可以在 Day 1 就對齊需求。職能不同就會導致使用的術語不同，或是理解認知不同。例如一個首頁，PM 想的是畫面如何擺放才能提高轉換率；行銷想的是 SEO 排名；工程師想的是搞懂未來可能有什麼功能、要如何設計架構；QA 想的是我的驗收標準是什麼；設計師想的是如何設計出符合品牌價值的形象以及使用者體驗。大家關注的面向不同，代表背後的基礎知識也就不同。在設計師看來理所當然的東西，QA 可能不在乎，工程師可能沒想過，行銷可能覺得不重要。這就是為什麼需要一個載體，能夠在一開始就把不同職能的人的想像給具象化，盡量減少理解差異。

更甚者，軟體是因應市場需求而變動，市場的需求一直在變，那軟體開發勢必要有辦法快速迭代。而傳統的瀑布式流程（Waterfall）難以應付這種需求，因為瀑布把不同職能做的事在時間上切開，要嘛來回確認需求浪費時間，要嘛造成對於需求的規格各自解讀，只要有新的需求或是變動發生，成本就很高。

為了解決上述問題，答案其實呼之欲出了：直接把不同職能的人在一開始就用一套共同語言來共同編纂需求文件，確保大家的專注點都有被涵蓋到後，才開始開發。而且描述的方式是以行爲導向設計，在什麼情況下（Given）做了什麼操作（When），會得出什麼結果（Then）。這樣的描述至少完善了需求以及驗收標準，所以整個文件就會是這樣格式的一堆範例，因為是自然語言，所以所有人都看得懂。

這就是所謂的「活的文件」（Living Documentation）。它不再是寫完就丟的死板規章，而是隨著產品一同演進的真理來源（Source of Truth）。

當我們掌握了這套描述邏輯，其實也就等於掌握了指揮 AI 的精準咒語。如果接觸過 BDD 就會發現 Spec Kit 還遠遠不夠，因為能服務的對象不只是開發軟體，而是所有需要規劃的 AI 工作的場景。接下來幾天，我會帶大家看看具體該怎麼寫出高品質的 Spec，以及會遇到哪些問題。