AI Coding 時代，SDD（Spec-Driven Development）會成為軟體開發的新趨勢嗎？

日期：
聲明：非專業部落客、非邀請、內文皆為個人感想不代表所有人想法。
本部落格文章版權所有，禁止私自商業用途。

AI Coding 時代，SDD（Spec-Driven Development）會成為軟體開發的新趨勢嗎？

近幾年 AI Coding 快速發展，從 GitHub Copilot、Cursor，到 Claude Code、Codex 等 AI Agent，寫程式的方式正在發生很大的變化。

以前我們可能需要花幾個小時甚至幾天設計架構、撰寫程式碼；現在只要把需求描述給 AI，幾分鐘內就可以產生一大段可以執行的程式碼。

這種方式非常方便，也就是大家現在常講的 Vibe Coding。

但當專案開始變大之後，另一個問題也慢慢浮現：

AI 很會寫 Code，但它真的知道我們「為什麼要這樣做」嗎？

這也是為什麼 SDD（Spec-Driven Development，規格驅動開發） 開始受到越來越多關注。

什麼是 SDD？

SDD，全名是 Spec-Driven Development。

簡單來說，就是：

先定義清楚「系統應該做什麼」，再讓 AI 或開發人員決定「怎麼實作」。

傳統開發流程可能是：

需求
 ↓
分析
 ↓
設計
 ↓
寫 Code
 ↓
測試
 ↓
上線

而在 AI Coding 時代，很多人的流程變成：

需求
 ↓
Prompt 給 AI
 ↓
AI 寫 Code
 ↓
測試
 ↓
發現問題
 ↓
再叫 AI 修改

這種方式在小型功能非常有效率。

例如：

幫我新增一個使用者查詢 API。

AI 很快就可以幫你產生 Controller、Service、Repository、DTO，甚至連前端畫面都可以一起完成。

但是問題在於，AI 很多時候只能根據我們「當下告訴它的資訊」做決定。

如果我們沒有把商業規則、限制條件、權限、資料關聯等資訊講清楚，AI 就只能自己猜。

因此 SDD 的核心概念就是：

Spec
 ↓
Plan
 ↓
Tasks
 ↓
Code
 ↓
Test

也就是：

先規格 → 再規劃 → 拆解工作 → 實作 → 測試

為什麼 AI Coding 讓 SDD 變得更重要？

這是我認為 SDD 真正開始受到重視的原因。

以前我們寫 Code，最大的成本通常是：

「怎麼把這個東西寫出來？」

但 AI Coding 出現之後，這個成本大幅下降。

現在反而變成：

「我到底要 AI 寫什麼？」

這兩個問題其實完全不同。

沒有 Spec 的 AI Coding

例如今天要開發一個「ISO 文件發布申請」。

我們直接跟 AI 說：

幫我新增 ISO 文件發布申請功能。

AI 可能會自己推測：

建立 Controller
建立 Service
建立 Entity
建立 Database Table
建立 Vue 頁面
建立 API

看起來非常完整。

但是 AI 不知道：

  • 誰可以建立申請？

  • 誰可以審核？

  • 誰可以發布？

  • 已發布的文件能不能修改？

  • 同一份文件是否可以重複發布？

  • 文件版本怎麼管理？

  • 是否需要整合 eFlow？

  • 哪些狀態可以轉換？

  • 哪些操作需要留下 Log？

這些資訊如果沒有被明確定義，AI 就只能「合理猜測」。

而 AI 最大的問題往往不是不會寫，而是：

它會很有自信地把錯的東西寫出來。

有 Spec 的 AI Coding

如果改成 SDD，我們會先建立一份規格。

例如：

# ISO 文件發布申請

## Purpose

提供使用者申請 ISO 文件發布。

## Functional Requirements

1. 使用者可以建立發布申請
2. 必須選擇文件
3. 必須輸入發布原因
4. 建立後狀態為「待審核」
5. 審核通過後才可以發布
6. 文件發布後不得直接修改版本內容

## Permission

- 一般使用者：建立申請
- 文件管理者：審核
- ISO 管理者：發布

## Validation

- 文件不可為空
- 發布原因不可為空
- 已發布版本不可再次發布

這時候 AI 拿到的就不是一句模糊的需求，而是一份明確的 Specification。

接著再要求 AI：

請根據這份 Spec：

1. 分析現有系統架構
2. 提出 Implementation Plan
3. 列出需要修改的程式
4. 列出 Database 變更
5. 列出 API 變更
6. 列出前端變更
7. 列出測試項目

先不要寫 Code，等我確認 Plan 後再開始。

這時 AI 的角色就開始從：

「幫我寫程式」

變成：

「根據規格協助我完成軟體開發。」

這是一個很大的差異。

SDD 與 Vibe Coding 的差別

這兩種方式並不是完全互斥。

我反而認為：

Vibe Coding 適合快速產生東西，而 SDD 適合控制 AI 產生的東西。

可以這樣理解：

方式特點
Vibe Coding快速、直覺、適合小型功能
AI CodingAI 協助撰寫程式
SDD用規格控制 AI 如何理解需求
SDD + AI Agent讓 AI 根據規格進行較完整的開發流程

例如：

Vibe Coding

「幫我做一個登入頁面」
        ↓
      AI
        ↓
      Code

而 SDD：

需求
 ↓
Spec
 ↓
Plan
 ↓
Tasks
 ↓
AI Agent
 ↓
Code
 ↓
Test
 ↓
Review

後者雖然前面多了一些工作，但對大型系統而言，通常更容易控制。

SDD 最重要的觀念：Intent 才是核心

過去軟體開發有一個很重要的概念：

Code is the Source of Truth

也就是：

Code 就是系統真正的答案。

但是 AI Coding 出現後，這個觀念可能逐漸發生變化。

因為未來我們可能不會只關心：

現在的 Code 是什麼？

而會更關心：

為什麼 Code 要這樣寫？

因此 SDD 強調的是：

Intent，也就是「開發這個功能的目的與規則」。

例如：

Business Requirement
        ↓
      Spec
        ↓
      Plan
        ↓
      Code

Code 是 Spec 的實現結果。

如果未來 Code 被 AI 重構，只要 Spec 沒有改變，AI 理論上仍然可以重新產生符合需求的實作。

這其實是一個很值得注意的變化。

SDD 不是叫你寫一堆文件

這也是很多人第一次接觸 SDD 容易誤會的地方。

SDD 並不是：

「以前文件太少，所以現在再寫 100 頁文件。」

如果 Spec 最後變成：

需求文件 30 頁
架構文件 50 頁
設計文件 80 頁
測試文件 50 頁

然後 AI 還是看不懂，那其實沒有太大的意義。

比較實際的做法反而是：

Small + Structured + Machine-readable

也就是：

小型、結構化，而且 AI 容易理解。

例如：

/docs
    system.sdd

    /document
        document.sdd

    /approval
        approval.sdd

    /publish
        publish.sdd

每個 Spec 專注在一個功能或模組。

實際導入可以非常簡單

如果公司還沒有 SDD，不需要一開始就建立非常複雜的制度。

可以先從最簡單的方式開始。

例如每個新功能建立：

/spec
    spec.md
    plan.md
    tasks.md

spec.md

定義：

這個功能要做什麼？
誰可以使用？
有哪些商業規則？
有哪些限制？

plan.md

定義：

要修改哪些程式？
要修改哪些資料表？
需要哪些 API？
前端需要修改什麼？

tasks.md

再把工作拆成：

[ ] 建立 Entity
[ ] 建立 Service
[ ] 建立 API
[ ] 建立 Vue 頁面
[ ] 加入權限驗證
[ ] 加入 Unit Test
[ ] 加入 Integration Test

最後才交給 AI Agent 執行。

對企業內部系統而言，我認為特別有價值

如果是單純做：

  • Todo List

  • 計算機

  • 小型工具

  • Demo

  • 個人網站

其實不一定需要 SDD。

但如果是企業系統，例如：

  • ERP

  • ISO 系統

  • CRM

  • HR 系統

  • 財務系統

  • SAP 整合

  • API 整合

  • Workflow

  • 文件管理系統

SDD 的價值就會非常明顯。

因為企業系統通常有大量：

Business Rules
Permission
Workflow
Data Relationship
Legacy System
API Integration
Audit Log
Compliance

這些東西不是單純「把 Code 寫出來」就能解決的。

AI 可以很快幫你寫：

Controller
Service
Repository
Vue
SQL
API

但它不一定知道：

為什麼這個公司的流程必須這樣走。

而這正是 Spec 最適合描述的東西。

我認為未來可能會變成這樣

AI Coding 的發展，可能會從：

人 → 寫 Code

逐漸變成：

人
 ↓
定義需求與規則
 ↓
Spec
 ↓
AI Agent
 ↓
Plan
 ↓
Tasks
 ↓
Code
 ↓
Test
 ↓
CI/CD
 ↓
Production

人類的角色也會慢慢從：

Code Writer

轉變成：

System Designer + Reviewer + AI Orchestrator

也就是說，未來一個優秀的開發者，不一定是「寫 Code 最快的人」。

而可能是：

最知道系統要做什麼、能把需求描述清楚，而且能有效控制 AI Agent 的人。

那 SDD 會成為未來主流嗎？

我的看法是：

很有可能。

SDD 並不是要取代 Agile、Scrum、TDD 或 CI/CD，而比較像是 AI Native Development 時代增加的一層。

可以把它想成：

Agile
 └── 開發管理方法

TDD
 └── 測試與開發方法

CI/CD
 └── 建置與部署流程

SDD
 └── AI 時代的需求與規格控制

而未來很可能會變成：

        Human
          │
       Requirement
          │
         SDD
          │
      AI Agent
          │
     ┌────┴────┐
     │         │
    Code      Test
     │         │
     └────┬────┘
          │
        CI/CD
          │
      Production

結語：AI 讓「寫 Code」變容易，也讓「定義需求」變得更重要

我認為 SDD 真正重要的地方，不是多了一種文件格式，也不是多了一個開發流程。

而是它解決了 AI Coding 時代的一個核心問題：

AI 很會寫程式，但誰來告訴 AI 這個系統真正應該是什麼？

過去我們花很多時間寫 Code。

未來 AI 可能幫我們寫掉大量 Code。

因此開發者真正需要掌握的能力，可能會逐漸從：

How to Code

轉向：

What to Build
Why to Build
How to Specify
How to Verify

而 SDD（Spec-Driven Development），正好站在這個轉變的核心。

所以如果你現在正在學習 Copilot、Claude Code、Codex、Cursor 或其他 AI Coding Agent，我認為 現在開始接觸 SDD 是很值得的。

因為下一階段的 AI Coding，很可能不只是：

「AI 幫我寫 Code。」

而是：

「AI 根據我的 Spec，幫我完成整個功能。」

留言

張貼留言