[探討] 什麼是 SDD

SDD (Spec Driven Development) 這名詞在最近這一年來被屢次頻繁的提到，尤其在台灣這半年來更是火到一個不行。

在最近的 side-project 中，因為想研究全自動化的 ai coding 流程，所以也認真探討一下這名詞背後的核心理念。

過往軟體開發流程

俗話說的好，會動的東西，就不要去碰它。既然傳統的開發流程已經孕育出世界上大大小小的偉大作品，那他必定有其邏輯道理存在。

我的認知裡頭，一個成熟的軟體產品從想法到實踐至少會經過幾個階段。

• 需求想法轉換為文字
• 文字轉換為規格
• 規格轉換為程式碼
• 程式碼轉換為功能
• 功能轉換為使用者體驗

使用者體驗再次回饋成為需求，如此往復，形成一個循環。 每次的循環就是產品的迭代更新。

而通常也可以很粗略的拆分為四種角色。 PM, SA, PG, (QA) User。

PS：通常有一定規模的軟體開發團隊，會有專門的 QA 來負責品質測試，但在此請容許我把它放在 User 的位置。

也因為一個產品拆成四種不同角色的身份去進行開發和（測試）回饋，所以中間的溝通損耗一直以來都是一個不小的問題。很常常演變成 PM 和 PG 之間的世仇關係ＸＤ

在過去也很常透過一些不同的方法導入（e.g. Scrum、敏捷開發、BDD、DDD），來降低不同角色間的溝通損耗，盡可能達成一致的認知水平。

最終產出的內容是必不可少的，會有大大小小的 spec 。

設計與規劃階段 (Design & Planning)

• UI/UX Design Specs (設計規範)：包含 Wireframe（低真原型）與 Mockup（高真視覺稿）。開發者需要這些文件來確認介面元素、間距、顏色與元件行為。
• PRD：User Stories & Acceptance Criteria (AC)，有時會拆解成更細顆粒度的使用者故事，並明確標註驗收標準，作為測試的依據。
• WBS (Work Breakdown Structure)：專案進度表，將開發任務拆解成具體時程（如 Gantt Chart 或 Jira Backlog）。

技術研發階段 (Development)

• SA (System Analysis)：理解業務需求，並將其轉化為系統功能。 SA 是 PRD 與技術實作之間的橋樑。
• SD (System Design)：比 SA 更深入，專注於具體的模組設計、邏輯流程圖。
• API Documentation (Web API)：通常使用 Swagger 或 Postman 撰寫，定義 API 的輸入、輸出、錯誤碼及格式。
• ER Model / Database Schema (資料庫設計)：定義資料庫表結構、欄位類型與關聯圖（Entity-Relationship Diagram）。
• Flowchart / Sequence Diagram (系統互動時序圖)：描述複雜邏輯下的系統互動時序圖。

品質保證階段 (Testing & QA)

• Test Plan (測試計畫)：定義測試範圍、環境、策略與人力分配。
• Test Case (測試案例)：詳細記錄「輸入什麼、預期輸出什麼」，包含正常路徑與異常路徑（Corner Cases）。
• QA Report / Bug Report (品質保證報告/ Bug 報告)：測試完成後的結果彙整，記錄剩餘未解決的 Bug 與風險評估。

上線與維運階段 (Release & Operations)

• Release Notes (版本說明)：記錄此版本新增的功能、修復的 Bug 以及已知的限制。
• User Manual / Help Center (用戶手冊)：對外給客戶使用的教學文件；對內則是客服單位的 FAQ。
• Maintenance Manual (維運手冊)：包含環境配置、故障排除（Troubleshooting）流程與緊急聯絡窗口。

一個標準的軟體開發生命週期（SDLC）通常如下佈局：

那麼來看看因為 vibe coding 而盛行的 SDD，大致上是做些什麼事情。

SDD (Spec Driven Development)

老實說，我第一眼看到 SDD 的時候，我就先一個納悶。規格驅動開發？不是一直以來都是這樣嗎？沒有規格該如何開發呢？

但懷疑歸懷疑，這套方法論會這麼火一定有他的原因在，我們來細細品味一下。

背景：Vibe Coding

在過去一年以來，軟體工程師的門檻被大肆的 vibe coding 所降低。幾乎只要下幾個 prompt ，就可以透過 ai 生成一些符合簡單需求的 prototype 或是 script 出來。

但問題也隨之而來，api key 的暴露、機敏資訊的洩漏、程式碼的不安全、功能疊床架屋在隨意的架構上、甚至不會 debug，各種過往說出來會被罵的糗事，現在都變的司空見慣。因為開發的門檻降低了。

(以下節錄自 AI 回覆)

SDD 的核心覺醒在於認識到：AI 本質上是一個機率性的預測引擎，而非邏輯性的推理引擎（至少在 GPT-4 時代如此）。如果沒有強有力的外部約束（Constraints），AI 會傾向於在巨大的解空間（Solution Space）中隨機遊走，尋找「最可能」而非「最正確」的路徑。

SDD 的出現，是為了將軟體開發的重心從「撰寫實作細節」上移至「定義系統邊界」。在這種模式下，規格文件（Spec）不再是陳舊的文檔，而是具備執行力的資產（Executable Asset）。開發者發現，透過維護一份高清晰度的規格文件，並強制 AI 遵循該規格進行編碼，可以有效地「鎖定」AI 的行為，消除其隨機性帶來的風險。這標誌著開發範式從「人寫代碼」向「人寫規格，AI 寫代碼」的根本轉變。

作法：明確詳細的規格文件（？）

有了粗略了解以後，我們來參考一下 GitHub Spec Kit 的作法。

主要圍繞以下檔案：

• constitution.md：你的憲法記錄了現有的建築模式和限制。
• spec.md：功能特色規範考量現有的基礎設施與整合點。
• plan.md：計畫展示了新功能如何整合現有架構，而非提出孤立的實作方案。

最後，產生 tasks.md 來推動開發。

認真看完了以後，發現到這終究無法避免程式碼產出的隨機性。

本質上仍然是透過 prompt engineering ，去約束 LLM 的行為。但無法確定每次的產出程式碼都會是一致的。你仍然是在玩抽卡遊戲只是機率高了些。

SDD 的不同層級（Spec-first, Spec-anchored, Spec-as-source）這三種等級強弱的差距，即使以現在的技術，仍然無法做到 Spec-as-source，尤其是在 spec.md 和 plan.md 如果是停留在在一個對實作細節仍有很大留白的自然語言 markdown 這種階段上。現在大多只在第二階段 Spec-anchored。

不過整體的流程仍然是好的，他確實解決了 vibe coding 的問題，讓程式碼能有個參照的規格文件、以及其餘的迭代機制。

但既然這樣，為何不直接使用 AI 來協作產生更穩固的文件呢？

既然 AI 有著數十年的訓練資料量，那麼 AI 應該也很懂什麼是 PRD, SA Spec, SD, API Doc, Database Schema, Flowchart, Sequence Diagram… 吧？

調整一下 SDD 的作法

既然 Spec 沒有著明確的規定內容格式，那我用傳統的 PRD, SA Spec 來替代 constitution.md, spec.md, plan.md 應該也是可行的。更甚者，我可以在 SA spec 裡頭去定義更詳細的規格文件格式（e.g. 呼叫外部 API 的串接方式…等等）。

依照現在的 AI 模型開始把能力值點到推理上，我認為足夠詳細的文件仍然會是一個好的選擇。

所以而對我來說，PRD 和 SA spec 只要有這兩個文件且也足夠詳細，我想對大多數的軟體開發者來說已經足夠產生出程式碼。

AI 最終還是要學著人類去思考，而不是人類去教 AI 如何思考。

我認為，當我們為了讓 AI 方便做事，而又去設計出一套又一套的規範或是名詞時，或許根本上就本末倒置了。

說來說去，其實最終還是回到傳統的那一套，寫 spec -> 實作 -> 回饋 的產品循環。

現在 SDD 最大的賣點就是在於過往的產品開發流程會仰賴一推人，但現在只需要**開發者和AI **就可以完成。溝通損耗為零。

而開發者也可以善用 AI 作為槓桿工具，去撬動原本不懂、不熟悉的領域知識，帶來豐富的成果產出。

那麼回過頭來看，SDD 的 spec 到底得要遵循著 constitution.md, spec.md, plan.md 去寫嗎？似乎也就未必了。

或許換成你原本就已經熟悉的名詞、過去曾學過的技能去實作，效果也不差。

咦！我手邊竟然剛好有一份我自己搞的 SDD 實作細節ＸＤ 有興趣可以看看～ https://github.com/Tai-ch0802/arc-like-chrome-extension/blob/main/.github/i18n/zh_TW/README.md#-contributing

我期望可以達到的效果正是 將模糊的需求轉化為可實作的程式碼 ，當這流程整成 SOP ，社群上想參與開發貢獻的門檻就會降低。 當參與貢獻就像在對著自動販賣機點餐一樣簡單，那我想應該可以提高大家想法實踐的動力。

就如同 AI 的出現，帶來了 vibe coding 這這股創造的浪潮。

結語

其實原本只是想了解一下 SDD 和傳統開發流程 (PRD + SA spec) 的差異，一開始壓根也沒想過要用 SDD。只是看完以後發現，原來 SDD 只要是曾待過 SI (System Integrator，系統整合商)的人，應該都懂其中概念。

只是今天的起源背景是由於 vibe coding，所以讓這些過往既有的知識有了新的名詞去包裝。

規格優先（Spec‑first）、可驗證的需求描述、規格錨定（Spec‑anchored）、思考可版控，這些特點都早在 SDD 出現前就存在，只是現在透過 SDD 這方法論將這些知識串聯在同一份 repo 中。

要說有什麼不同，那就是 SDD 的參與者只有一個。所以不會有共識落差的問題要去處理。

就結論而言，大膽猜想 SDD 可能在一兩年後就會退燒了。 因為 AI 會越來越強，強到即使模糊的想法，也能產出品質很好且穩定的程式碼，更遑論中間過程的所有 spec 也是由 AI 自產，你只需要從中檢查和些微介入即可。

從模糊的概念直接昇華出產品，也許規格即程式碼（Spec-as-Code）也不夠酷了。

未來是屬於想法即程式碼（Idea-as-Code）的，只要會許願就好。