生成式 AI 的出現，徹底改變了軟體開發方式。
從 GitHub Copilot、Cursor、Gemini、Claude Code 到 OpenAI Codex，現在的工程師只需要輸入自然語言，就能在幾分鐘內產生大量程式碼。
於是近兩年開始流行一個詞：
Vibe Coding
簡單來說，就是想到什麼需求，就直接交給 AI 實作。
流程看起來非常簡單：
想法
↓
AI
↓
程式碼
↓
上線
這種方式讓開發效率大幅提升，也讓許多非工程背景的人第一次能夠獨立完成產品原型（MVP）。
但當專案開始成長、功能開始增加、團隊開始協作時，問題也逐漸浮現。
而且問題往往不在程式碼本身。
Vibe Coding 最大的問題不是程式碼品質
許多人認為 AI 開發最大的風險是：
程式碼品質不佳
重複程式碼過多
架構混亂
AI 幻覺（Hallucination）
這些問題確實存在。
但我認為它們都只是結果。
真正的根本原因其實是：
AI 沒有商業邊界（Business Boundary）。
AI 可以理解需求文字。
但它不理解：
哪些功能現在需要做
哪些功能未來再做
哪些功能根本不需要做
例如你告訴 AI：
我要一個 CMS 系統。
AI 很可能開始建立：
使用者管理
權限管理
文章系統
分類系統
標籤系統
SEO 系統
API
Dashboard
Activity Log
最後產生數百個檔案。
但實際商業需求可能只是：
希望飯店官網首頁內容可以透過後台修改。
這時候問題不是 AI 寫錯程式。
而是 AI 做了太多不需要的事情。
結果變成：
真正需求：3 天
AI 實作範圍：3 週
這種現象其實就是：
商業需求錯位（Business Misalignment）
而這也是許多 AI 專案後期開始失控的原因。
為什麼傳統軟體開發需要規格書？
很多人認為規格書是傳統軟體開發留下來的包袱。
但規格書存在的真正目的從來不是為了寫給主管看。
而是為了建立邊界。
成熟的軟體開發流程通常長這樣：
需求分析
↓
規格定義
↓
系統設計
↓
開發實作
↓
Code Review
↓
測試驗證
↓
部署上線
這個流程的價值在於：
有明確需求範圍
有設計依據
有驗證標準
有維護文件
然而在 AI 時代，許多團隊逐漸變成：
想法
↓
AI
↓
上線
中間所有工程管理環節全部消失。
短期看起來很快。
長期卻容易造成：
技術債累積
功能重疊
文件缺失
團隊無法接手
維護成本上升
SDD 是什麼？
SDD（Spec-Driven Development）中文通常翻譯為：
規格驅動開發
它的核心概念非常簡單：
先定義規格，再讓 AI 實作。
流程變成：
需求
↓
Spec
↓
設計
↓
實作
↓
驗證
很多人看到這裡會問：
這不就是以前的規格書嗎？
其實不完全一樣。
傳統規格書與 SDD 的差異
過去的規格書主要是給人類閱讀。
而 SDD 的規格，則同時服務人類與 AI。
| 傳統規格書 | SDD |
|---|---|
| 人類閱讀 | 人類 + AI 閱讀 |
| 偏文件管理 | 偏執行驅動 |
| 更新成本高 | 可持續同步 |
| 容易過期 | 持續演化 |
| 開發參考 | 開發依據 |
如果用一句話來形容：
PRD 是給工程師看的，而 Spec 是給 AI 執行的。
這也是 AI 時代最大的改變。
規格不再只是文件。
而是直接驅動開發。
OpenSpec：AI 與人類之間的契約層
目前常見的 SDD 工具有：
Spec Kit
OpenSpec
PRD First Workflow
AI Contract First
其中我認為最容易上手的是 OpenSpec。
很多人以為 OpenSpec 是文件工具。
其實更精確地說：
OpenSpec 是 AI 與人類之間的契約層（Contract Layer）。
在傳統開發中：
Product Owner
↓
工程師
↓
程式碼
而在 AI 開發中：
Product Owner
↓
Spec
↓
AI
↓
程式碼
Spec 成為了人與 AI 溝通的介面。
因此 OpenSpec 的真正價值不是產生文件。
而是幫 AI 建立需求邊界。
OpenSpec 的基本流程
OpenSpec 的工作流程非常接近真實軟體開發。
1. Explore
探索需求與問題。
/opsx-explore
例如：
/opsx-explore 認證系統越來越複雜，想重構
AI 先協助分析問題，而不是直接修改程式。
2. Propose
建立提案。
/opsx-propose add-user-auth
產生：
changes/
└── add-user-auth/
├── proposal.md
├── design.md
└── tasks.md
此時需求被正式定義。
3. Apply
開始實作。
/opsx-apply
AI 根據規格逐步完成工作。
而不是自由發揮。
4. Verify
驗證結果。
/opsx-verify
確認：
是否符合需求
是否存在風險
是否遺漏規格
5. Archive
完成後歸檔。
/opsx-archive
同步更新規格與專案知識。
AI 的角色正在改變
這也是我認為 SDD 最重要的一點。
過去大家把 AI 當成：
Code Generator
需求進去。
程式碼出來。
但這種模式很容易造成失控。
未來 AI 更適合扮演：
Spec Executor
規格進去。
程式碼出來。
看似只有一個字的差異。
但本質完全不同。
因為：
Code Generator
→ AI 自己決定怎麼做
Spec Executor
→ AI 根據規格執行
而這正是 SDD 的核心價值。
SDD 不只提升 AI 品質，也提升團隊協作能力
很多人認為 SDD 只是為了提升 AI 生成品質。
其實更大的價值在團隊協作。
當每個功能都有：
proposal
design
tasks
archive
半年後接手專案的人可以清楚知道：
為什麼要做這個功能
當初的設計理由
修改過哪些規格
哪些方案被否決
而不是只能透過：
git blame
git log
猜測歷史決策。
這對團隊維護與知識傳承非常重要。
不只後端，前端更需要需求邊界
很多人以為這種問題只存在於後端。
其實前端更常發生。
例如：
需求：
建立一個產品介紹頁。
Vibe Coding：
建立 Design System
建立 CMS
建立 Dashboard
建立 API Layer
建立 Auth
建立 i18n
結果：
200 個檔案
只用到 3 個元件
而真正需求可能只是：
一個 Landing Page
這種過度設計在 React、Next.js、Vue、Astro 生態系中非常常見。
因此需求邊界其實是所有技術棧共同面對的問題。
未來工程師最重要的能力可能不是寫程式
AI 正在快速降低程式碼生產成本。
未來工程師的價值，可能不再是：
寫更多程式
而是：
定義需求
+
建立規格
+
架構設計
+
AI 協作
程式碼本身會越來越容易產生。
但商業邏輯、領域知識與系統邊界仍然需要人類決策。
因此未來的工程師角色可能變成：
Junior
→ 撰寫程式
AI
→ 執行規格
Senior
→ 定義規格與架構
結語
Vibe Coding 並沒有錯。
它讓更多人能夠快速將想法變成產品。
但當專案規模開始成長時，
真正重要的已經不是：
如何讓 AI 寫更多程式。
而是：
如何讓 AI 在正確的邊界內寫程式。
這也是 SDD（Spec-Driven Development）存在的價值。
AI 不缺寫程式能力。
缺的是需求邊界。
而未來工程師最重要的能力，也許不再是程式碼產生者，而是規格定義者。
