規格驅動開發是什麼？先寫 spec 再讓 AI 產碼

2025 年 8 月，GitHub 在自家帳號下開了一個新 repo，叫 spec-kit。裡面沒有模型、沒有雲端服務，主要內容是一支 CLI 加一疊 markdown 模板。

十個月後，這個「模板倉庫」拿到約 11.8 萬顆星、超過 1 萬個 fork——在 GitHub 自家的開源專案裡也是罕見的爆發速度。

它賣的東西只有一個想法：讓 AI 寫程式之前，先把規格寫清楚。這聽起來像軟體工程課第一週的內容，卻在 2025 到 2026 年變成顯學。原因很直接——AI coding agent 把「產碼」變得太便宜，便宜到大家發現真正的瓶頸在「說清楚要做什麼」。

規格驅動開發（spec-driven development，常縮寫 SDD）是一種 AI 協作開發方法：先跟 AI 一起把需求寫成結構化、可審核的規格文件（spec），人確認後，再讓 coding agent 依照規格產生程式、測試與驗收。規格是唯一真相來源——程式要對齊規格，規格由人把關。它被定位成 vibe coding（憑感覺下 prompt、邊聊邊改）的解藥。

用裝潢比喻最快。vibe coding 像站在工地跟師傅說「幫我弄個北歐風」，做出來不對再改，改到預算爆掉。SDD 像先畫設計圖、開材料表、排施工順序，師傅照圖施工，驗收也照圖驗。師傅（agent）手越快，那張圖就越值錢。

起源：Kiro 先出手，Spec Kit 把名字打響

這個詞的走紅有兩個時間點。

2025 年 7 月 14 日，Amazon 推出 agentic IDE Kiro 公開預覽。你用自然語言描述需求，Kiro 會展開成三份文件：需求規格（含驗收條件的 user story）、設計規格（資料流、介面、schema）、任務清單（照依賴排序的實作步驟）。官方定位講得很白：快速 prompt 出原型的 vibe coding 很爽，但要進 production，中間缺的就是這層有意識的規劃與文件。上線第一週需求爆量，Amazon 一度啟用候補名單。

2025 年 9 月 2 日，GitHub 首席產品經理 Den Delimarsky 發文開源 Spec Kit。文章給了這個方法目前最常被引用的定義：spec 是「程式行為的契約，是工具與 AI agent 用來產碼、測試、驗證的真相來源」。跟 Kiro 綁定自家 IDE 的做法相比，Spec Kit 走另一條路——它只是一套 CLI 加模板，README 標明支援 30 多個 coding agent，Claude Code、GitHub Copilot、Gemini CLI、Cursor 都能接。

不綁工具、全開源，SDD 這個詞就跟著 Spec Kit 一起變成通用名詞。為什麼是 2025 年下半年？因為 agent 能力剛好跨過門檻——能自主跑完多步任務——同時「一句 prompt 蓋一個 app」的爛尾殘骸也堆得夠高了。供需兩邊同時到位。

Spec Kit 的工作流長什麼樣

裝好 specify CLI、跑 specify init 之後，你的 coding agent 會多出一組斜線指令，照順序走：

指令	做什麼
/speckit.constitution	定專案憲法：程式品質、測試標準、效能要求等原則
/speckit.specify	描述要做什麼、為什麼做——只談需求，不談技術棧
/speckit.plan	補技術細節：架構、stack、限制條件
/speckit.tasks	把規格與計畫拆成可審核的具體任務
/speckit.implement	agent 照任務清單動工

另外有三個選用指令：/speckit.clarify 逼 agent 先問清楚模糊處、/speckit.analyze 檢查規格與任務的一致性、/speckit.checklist 產驗收清單。

關鍵設計是：每一步的產出都是 markdown 檔。人可以改，下一步吃上一步的輸出。人審規格，agent 寫程式——分工畫在文件那條線上。

跟 vibe coding、prompt engineering 的邊界

三個詞常被混著講，並排看最清楚：

	vibe coding	prompt engineering	規格驅動開發
操作單位	一句一句對話	一段精心調過的 prompt	一份結構化規格文件
真相在哪	散在對話紀錄	在 prompt 模板裡	在 spec 檔案裡，進版本控制
人審什麼	看結果順不順眼	看輸出對不對	先審規格，再驗程式
適合場景	丟掉式原型、探索	單次任務優化	要維護、多人協作的系統

注意這裡沒有優劣序。週末做個原型、試一個 UI 想法，vibe coding 就是比較快，連 Kiro 官方都承認自家工具「很會 vibe coding」。SDD 的代價是前期時間——需求還在探索期就寫細規格，寫完可能整份作廢。

反方：這是瀑布復辟嗎

SDD 走紅後，最有分量的質疑來自行為驅動開發（BDD）社群。

Gojko Adzic——《Specification by Example》作者——2025 年 9 月 29 日發文，標題就問：這是瀑布的復仇，還是 BDD 的升級？他肯定工作流分步驟、檔案可編輯讓人留在迴圈裡，但實測後的批評很具體：工具一次生成太多測試跟程式碼，「多到 human in the loop 根本不可行」；而那些高層次需求文件「其實不算 spec，缺一大堆細節」，真正可執行的規格埋在只有工程師讀得懂的測試裡。

Marmelab 的 François Zaninotto 在 2025 年 11 月 12 日寫得更直接，文章標題就叫「瀑布反擊戰」（The Waterfall Strikes Back）：SDD 產出大量 markdown，審查負擔反而加倍——規格要審一次、程式再審一次——而 agent 還是不保證照規格走。大量前置文件，正是敏捷運動當年要逃離的東西。

支持者的回法是：spec 是活文件，隨迭代更新，跟瀑布那種簽了就鎖死的合約不同。有意思的是交集——兩邊其實同意同一件事：規格沒人維護，就會退化成瀑布最糟的部分。回到裝潢比喻：設計圖畫到最細，拆牆才發現裡面有水管。圖要跟著現場改，不然就是一疊廢紙。

spec 是給 agent 迴圈的輸入

把鏡頭拉遠一點，SDD 跟另一件事直接相關：無人值守的 agent 迴圈。

agent 自己寫碼、跑測試、修錯、再跑——這種迴圈能跑多遠，取決於它有沒有一個可判定的「完成」定義。spec 就是那個定義。驗收條件寫得越明確，agent 越能自己檢查自己，人越晚才需要介入；規格寫得含糊，迴圈第三步就開始飄，你半夜起來看到的是三千行朝錯誤方向狂奔的程式碼。規格的品質，決定你敢讓迴圈跑多久。

你可以不裝任何工具就試最小版：下次丟任務給 coding agent 之前，先要求它把需求寫成一份含驗收條件的 spec.md，你改完、確認過，再叫它動工。光這一步，就能體會 SDD 八成的價值。

至於要不要走完整流程，一個實用的判斷準則：這段程式活得過這個週末嗎？活不過——vibe 下去沒關係；活得過、還要多人碰——規格值得寫。

最後留一個誠實的邊界：SDD 沒有降低「把需求想清楚」這件事本身的難度。它做的是把這個難度往前搬——從寫完程式才發現，搬到 AI 動工之前。這一搬值不值，就看你蓋的是樣品屋，還是要住三年的房子。

資料來源：GitHub Blog、github/spec-kit（GitHub）、Kiro 官方部落格、Gojko Adzic（LinkedIn）、Marmelab Blog

矽基前沿 · 大百科線（編輯：廖玄同），《規格驅動開發是什麼？先寫 spec 再讓 AI 產碼》，矽基前沿 [Si]gnals，2026-07-05。https://signals.tw/articles/what-is-spec-driven-development/