Spec Kit 是什麼？AI 寫程式更需要規格
Spec Kit 是 GitHub 推出的規格驅動開發工具，把模糊需求整理成 Spec、Plan、Tasks，再交給 coding agent 實作。本文說清楚完整工作流、適用情境，以及它無法替你解決的問題。
目錄+
GitHub 在 2025 年 9 月公開 Spec Kit，第一個瞄準的問題就是 vibe coding：程式碼看起來能跑，卻不一定解決你真正要的問題。
Coding agent 寫得越快，這個問題越明顯。以前需求理解錯了，工程師可能在會議或開發途中發現；現在 AI 可以迅速把錯誤假設擴寫成一整套畫面、API 和資料表。
AI 寫得越快，需求寫錯就越貴。
這篇先說清楚 Spec Kit 是什麼、完整流程怎麼走，以及什麼情況根本不必用它。
Spec Kit 是什麼？
Spec Kit 是 GitHub 開源的規格驅動開發工具。它把人的開發意圖整理成一組可追蹤的 Markdown 產物，再讓 coding agent 依序產生技術計畫、任務與程式碼。
它不是新的 AI 模型，也不負責取代 Codex、Claude Code 或 Copilot。比較準確的說法是：Spec Kit 是放在你和 coding agent 中間的流程層。
一般 prompt 把需求、技術選擇和驗收條件塞在同一段對話裡。Spec Kit 則把「要做什麼」和「準備怎麼做」拆開。需求有問題時改 spec，架構不合理時改 plan，任務切錯時改 tasks，不必等程式碼全部寫完才回頭找原因。
如果你想理解型別、rules 和 skills 如何一起約束 AI，可以先看AI Coding 時代的工程師工具鏈。Spec Kit 處理的是其中更上游的意圖與規格。
Spec Kit 工作流程怎麼走？
官方首頁用四個階段介紹核心流程：
Spec → Plan → Tasks → Implement
但這只是方便理解的短版。2026 年的 Quick Start 已把正式功能的完整流程擴充成九個階段。
constitution 保存專案長期不該隨意變動的原則，例如測試標準、架構限制與安全要求。spec 描述使用者需要什麼，plan 才決定技術棧與實作方式，tasks 再把計畫拆成有依賴順序的工作。
中間的 clarify、checklist 和 analyze 是品質關卡。最後的 converge 會拿程式碼對照 spec、plan 和 tasks；若仍有缺口，就把工作補回任務清單，再跑一輪實作。
這些品質關卡讓你在 AI 動手之前，先檢查它到底理解了什麼。
為什麼 AI 寫程式後更需要規格？
Coding agent 很擅長補完空白。問題是它不知道哪些空白可以自行決定，哪些其實牽涉商業規則。
一句「做會員訂閱」可能藏著取消後何時失效、付款失敗能否登入、舊會員如何遷移等決策。直接叫 AI 實作，它通常會挑一個合理答案繼續走。合理不代表符合你的產品。
Spec Kit 把這些決策留在 repository 裡，而不是只存在某次聊天的 context。換模型、換 agent 或隔週再回來，下一個執行者仍能看到前面的選擇。目前官方文件列出 35 種 integration，包括 Codex、Claude、Gemini、Copilot，也提供 generic integration。
這和用 gstack 把 AI 組成工程團隊、用 Multica 管理多個 coding agent解決的是不同問題。後兩者偏向執行與協作；Spec Kit 先確定大家拿到的是同一份需求。
Spec Kit 無法替你做什麼？
第一，它無法判斷你的需求是不是好需求。錯誤但寫得很完整的 spec，只會得到更一致的錯誤實作。
第二，Markdown 不是形式驗證。Martin Fowler 團隊的分析指出，Spec Kit 的 checklist 仍由 AI 解讀，不能保證每條規則都會被遵守。測試、code review 和實際驗收仍然要做。
第三，規格會漂移。特別是既有專案，程式碼描述「現在真的怎麼運作」，spec 描述「我們希望它怎麼運作」。兩者衝突時，工具不能替團隊決定誰才正確。
最後是流程成本。修一個文案錯字或調整 padding，跑完整九階段沒有意義。官方也提供較短路徑，讓小功能直接從 specify、plan、tasks、implement 走到 converge。
哪些情況適合使用 Spec Kit？
當功能牽涉權限、付款、資料模型、跨服務整合或多人協作時，錯誤理解需求的成本通常高於寫規格的成本。這時 Spec Kit 很合理。
如果你只是在探索介面、做一次性原型，或連產品方向都還不確定，先 vibe coding 反而比較快。等你知道哪些行為必須固定，再把它們整理成 spec。
判斷方式很簡單：如果 AI 做錯後可以十分鐘重來，就先做；如果做錯會牽動五個模組，先寫規格。
Spec Kit 本身免費開源，不需要購買特殊硬體。若你只是想整理長時間開發的桌面環境，可以參考蝦皮開發者桌面選物；這和安裝 Spec Kit 無關。
利益揭露：上方蝦皮連結是聯盟連結，你透過連結購買，我會收到一筆小額回饋，不影響你的價格。這是依文章主題挑選的開發環境商品，不是第一人稱使用推薦。
這個系列接下來會談什麼？
這是「AI 規格驅動開發」系列第一篇。接下來會拆開 Spec、Plan、Tasks 的分工，再實際用 Codex 跑一次 Spec Kit。後續也會比較 OpenSpec、Kiro Specs、Agent OS、BMAD、GSD 與 Superpowers。
我不打算把 SDD 寫成 vibe coding 的反面。兩者更像不同檔位：探索時需要速度，準備把功能留下來時需要約束。
你現在交給 AI 的工作，已經複雜到值得先寫規格了嗎？
常見問題
Spec Kit 是什麼？
Spec Kit 是 GitHub 開源的規格驅動開發工具。它把需求整理成 spec、plan 和 tasks，再讓 coding agent 實作與驗證。
Spec Kit 和 vibe coding 有什麼差別？
Vibe coding 常從自然語言直接進入實作。Spec Kit 先建立可檢查、可修改的規格產物，讓錯誤在產生大量程式碼前被發現。
使用 Spec Kit 一定要 GitHub Copilot 嗎？
不用。官方目前列出 35 種 integration，包括 Codex、Claude、Gemini 與 Copilot；沒有原生支援時也能使用 generic integration。
每個功能都需要跑完整流程嗎？
不用。小改動可以走短流程，正式功能再加入 clarify、checklist、analyze 與 converge。流程應該跟錯誤成本成比例。