工作這幾年發現專案開發經常會有業務與執行的爭執，對執行團隊（工程師 / 設計 / 開發團隊）來說，以下是常見情境：
1.「只是多加一個按鈕而已，應該很快吧？」→ 開發成本的認知差異
2.「下週要 demo，一定要有這功能。」→ 交付速度 vs 系統穩定度，要犧牲哪一個?
3. 「希望購物體驗跟蝦皮一樣順暢」→ 完美體驗 vs 工時/預算限制
4. 「希望提前上線，以便更快得到市場反饋。」→ 搶快驗證市場 vs 風險控管及維持開發人力

尤其是中小企業，業務團隊需要「求快」來爭取市場，執行團隊在人力不足下需要控管開發資源。
雙方長期在「價值取向」上各自為政，或許導入SDD是降低這些爭執的方向；讓需求方聚焦於「要什麼」，讓執行方聚焦於「怎麼做」，在持續更新的規格中達成共識。

什麼是SDD?

SDD，全名為 Specification-Driven Development（規格驅動開發），是一種軟體開發方法論,核心理念是：寫程式之前必須將需求轉換成「清晰且可驗證的規格」，並以此作為開發的依據。
與傳統「邊討論邊寫程式」的做法相比，SDD 提供更嚴謹的流程，避免因需求模糊或理解落差導致的資源浪費。

SDD 的典型流程

1. 需求分析
   • 深入理解要解決的問題
   • 明確使用者需求與可能的挑戰
2. 設計階段
   • 將需求轉化為完整的設計文件
   • 產出「可執行或可驗證的規格」：例如 API 文件、資料結構定義、設計規範
3. 實作階段
   • 工程師根據規格進行開發
   • 測試與驗收也以規格為依據，確保系統行為與設計一致

這種模式可以說是大家理想中的開發流程，但在現實中往往礙於「工時與資源不足」，團隊通常難以徹底落實。然而，隨著 AI 工具的興起，過去最大的痛點似乎不再是無法跨越的障礙。

以往熟悉的開發流程類型

1. 測試驅動開發 (Test-Driven Development, TDD)
   先寫測試再寫程式，規格通常隱含在測試裡。
2. 行為驅動開發 (Behavior-Driven Development, BDD)
   通常用 Given / When / Then 的格式來描述系統應該有的行為，並讓這些描述能直接轉換成自動化測試。
3. 規格驅動開發 (Specification-Driven Development, SDD)
   其實和傳統開發模式幾乎相同，都需要「定義規格及需求」再進行開發實作；不過SDD 強調「規格必須是可執行或可驗證的契約」，過去的做法往往是「業務寫文件 → 技術執行」，缺乏可驗證的共識，容易因解讀不同造成時程延宕或人力錯估。若沒有足以平衡需求與執行的 PM，把關成本就又更高了。

輕量版的SDD

透過規格及文件來確保所有專案人員取得共識，另外，得到清晰規格後也助於AI 產出更正確的結果。

不過這篇範疇聚焦於「無動態資料的個人網站」，不延伸到後端及資料處理，在後續篇章目標設定達成以下：

1. 以 Figma Variables / Tokens Studio 定義設計規格 → 輸出為 CSS Variables 或 Design Tokens
2. 測試案例源自規格定義（例如內容 schema、SEO 規範）→ 規格更新後，測試自動對應更新，降低人工遺漏
3. 在 CI/CD 流程中自動驗證網站是否符合規格（內容格式、無障礙、SEO、效能）

另外也想偷渡對於後續邁入40歲的職涯想法。

參考文章

• 規格驅動開發：重新定義軟體開發的未來
• Claude Code 通過 Claude Code PM 實現規格驅動開發
• Claude Code 通過 Spec Workflow 實現規格驅動開發
• AI-DLC Sprint × Spec-Driven Development：規格驅動的敏捷 AI 開發實踐