讓 AI 撰寫程式碼的方式正在迅速分化。
一邊是透過對話即興打造的氛圍式編碼；另一邊則是本文主題的規格驅動開發（Spec Driven Development，SDD）。
用一句話總結：SDD 會在要求產生程式碼前，先將規格（spec）以文件確定下來。
這份文件會成為唯一真實來源，讓 AI 依序進行規劃、實作與驗證。
本文整理 SDD 的運作架構、代表工具 spec-kit 與 Kiro，以及和氛圍式編碼的使用分界。工具資訊截至 2026 年 8 月。
先來看看重點摘要。
- SDD 先用 spec 文件確定「要打造什麼」，並將程式碼視為其產出物。
- 流程分為四個階段：spec（需求）→ plan（技術設計）→ tasks（工作拆解）→ 實作。
- GitHub 的 spec-kit 與 AWS 的 Kiro，是將這套流程工具化的代表產品。
- 一般的分界是：原型採用氛圍式編碼，需長期維護的產品程式碼則採用 SDD。
為什麼規格再次受到重視
先寫文件再開發這件事本身並不新。瀑布式時代的需求規格書就是如此，但因為過於沉重而被敏捷開發取代。
然而 AI 代理出現後，情況反轉了。人類開發者即使收到模糊需求，也會透過提問逐步補足脈絡。
相較之下，AI 收到模糊提示時，會用看似合理的猜測填補空白。產出與需求不符，外觀卻似乎正常，形成最棘手的缺陷。
因此出現了「要讓 AI 工作，就必須先消除模糊性」的需求，規格也再次成為答案。這次不同之處在於，文件不是給人閱讀，而是作為 AI 的執行標準。
四階段管線：從 spec 到 tasks
各工具的名稱略有不同，但基本架構一致。
| 階段 | 產出物 | 確定的內容 |
|---|---|---|
| Specify | spec.md | 要做什麼、為什麼做（需求・情境） |
| Plan | plan.md | 如何製作（技術堆疊・架構） |
| Tasks | tasks.md | 依什麼順序製作（拆解工作單位） |
| Implement | 程式碼 | 依序實作每個 task |
核心規則有兩項。
第一，只有在人員審查並核准各階段產出物後，才能進入下一階段。如此可在文件階段過濾模糊性，避免它進入程式碼。
第二，實作中若需求變更，修改的不是程式碼而是 spec，並重新執行後續階段。因為 spec 必須永遠代表最新的真實狀態。
換個角度看，程式碼不再是原始來源，而是將 spec 編譯後的產出物；真正的來源是文件。
兩項工具：spec-kit 與 Kiro
GitHub 的 spec-kit 是不依賴特定代理的開放原始碼工具組。
它在 Claude Code、Copilot、Gemini CLI 等工具上加入 /specify、/plan、/tasks 斜線指令，藉此強制執行上述管線。
另一項特色是使用 constitution 文件記錄專案的不變原則。
AWS 的 Kiro 則是一款以 SDD 為核心設計的代理型 IDE，會建立 requirements.md、design.md、tasks.md 三種文件。
它的優勢在於需求表示法，會使用 EARS（Easy Approach to Requirements Syntax）表示法將需求結構化。
這種方法會將需求整理成「系統在〜情況下必須〜」形式的句子。
如果你已經在使用 Claude Code 這類通用代理，加入 spec-kit 的導入成本較低；如果想要 IDE 整合體驗，Kiro 會更適合。
與氛圍式編碼的分界
SDD 並非永遠正確。建立並審查三種文件確實需要成本，因此套用在週末原型或一次性腳本上，反而會本末倒置。
判斷標準是程式碼的生命週期。如果本週就能丟棄，使用氛圍式編碼快速迭代即可。
如果程式碼需要維護與擴充數個月以上，先用 SDD 消除模糊性，總成本反而更低。
實際運作時還有一點需要注意：spec 與程式碼不一致卻一直被擱置的 drift。
「需求變更一定要先改 spec」這項規則一旦崩潰，spec 就會變成沒人信任的文件，整套 SDD 也會淪為形式流程。
總結
歸根究柢，SDD 主張「AI 時代真正的程式語言是自然語言規格」。它將原本用一行提示帶過的意圖傳達，提升為可供審查的文件。
下次開發功能前，先別急著寫提示，試著先寫一份 spec 文件。一天之內就能判斷這套方法論是否適合自己的工作。