GitHub 的 Spec Kit 是一個面向 AI 編程的新工具包，目標是幫助開發者實踐 Spec-Driven Development，也就是規格驅動開發。
它解決的問題很直接：現在很多 AI 編程工作流太像「邊聊邊寫」。人類給一個大概想法，Agent 立刻開始改代碼，短期看很快，但需求邊界、驗收標準、技術取捨和任務拆分往往沒有沉澱下來。項目稍微複雜一點，就容易變成一次性的 vibe coding。
Spec Kit 的思路是反過來：先把規格寫清楚，再進入計劃、任務和實作。代碼不再是第一步，規格才是第一步。
Spec Kit 是什麼？
Spec Kit 是 GitHub 開源的規格驅動開發工具包。它提供 specify CLI、模板、腳本和面向 AI coding agent 的命令，讓團隊可以圍繞同一套結構化產物推進開發。
它強調的不是「讓 AI 少問問題」，而是讓 AI 在寫代碼前先生成並完善這些內容：
- 項目原則：團隊對品質、測試、體驗、性能等方面的約束；
- 功能規格：要做什麼、為什麼做、使用者故事和功能需求；
- 技術計劃：使用什麼技術棧、如何落地、有哪些架構決策；
- 任務清單：把計劃拆成可執行步驟；
- 實作過程：按任務逐步修改代碼，而不是一次性亂改。
這套流程讓 AI 編程更像工程協作，而不是一次提示詞表演。
基本使用流程
官方 README 給出的入門流程大致是這樣：
|
|
初始化後，項目裡會生成 .specify 目錄、模板、腳本和與 Agent 整合的命令。隨後在支援的 AI coding agent 中使用 /speckit.* 命令推進開發。
典型順序是：
|
|
其中 /speckit.constitution 用來建立項目原則，/speckit.specify 描述產品需求，/speckit.clarify 補齊模糊點，/speckit.plan 生成技術計劃，/speckit.tasks 拆任務，最後由 /speckit.implement 執行實作。
這和直接對 Agent 說「幫我做一個應用」差別很大。Spec Kit 要求你把「做什麼」和「怎麼驗收」先說清楚，再讓 Agent 動手。
它改變了 AI 編程的入口
傳統 AI 編程經常從代碼開始：
|
|
Spec Kit 更像這樣：
|
|
這個變化很重要。因為 AI 最擅長根據上下文執行，但如果上下文本身是鬆散的，執行速度越快，偏離方向也可能越快。Spec Kit 把上下文變成文件和模板，讓需求、計劃和任務都能被 review、修改和版本管理。
換句話說，它不是讓 AI 更「自由」，而是讓 AI 在更清晰的工程軌道上自由發揮。
核心命令怎麼理解？
/speckit.constitution
這是項目的「憲法」。它會生成或更新 .specify/memory/constitution.md，用於記錄項目長期遵守的原則，例如代碼品質、測試標準、使用者體驗一致性、性能要求和技術決策規則。
這一步適合寫團隊共識，而不是單個功能需求。
/speckit.specify
這是功能規格階段。你需要描述要構建什麼、使用者是誰、解決什麼問題、有哪些核心流程。
官方特別強調：這一階段不要過早關注技術棧。先把 what 和 why 寫清楚，再討論 how。
/speckit.clarify
這是補問題的階段。很多需求第一次寫出來都會有空洞：權限怎麼處理？異常狀態是什麼？數據是否持久化？邊界條件如何驗收？
/speckit.clarify 的價值，是讓 Agent 主動發現規格中的不確定點，並把回答記錄回規格文件，減少後面返工。
/speckit.plan
這是技術計劃階段。到了這裡，才開始明確框架、數據庫、架構、API、測試策略和約束。
如果說 /speckit.specify 是產品語言，/speckit.plan 就是工程語言。
/speckit.tasks
這一步把計劃拆成可執行任務。好的任務清單應該能讓 Agent 逐步推進，也能讓人類看懂每一步的目的。
/speckit.implement
最後才進入實作。Agent 根據前面沉澱的規格、計劃和任務修改代碼。這時它不再是憑一段大 prompt 猜需求，而是在一組結構化文件裡執行。
為什麼它適合 AI 編程？
Spec Kit 的價值不在於某個神奇命令，而在於它把 AI 編程中最容易缺失的東西補了回來：
- 需求可審查；
- 計劃可討論；
- 任務可追蹤；
- 決策有上下文；
- 產物可以進入 Git 歷史；
- 團隊可以複用模板和原則；
- Agent 的實作不再只依賴一次性聊天記錄。
這對複雜項目尤其有用。越是多人協作、長期維護、品質要求高的項目，越不能只靠臨時 prompt 驅動開發。
擴展和 Preset
Spec Kit 還提供了兩類自訂能力：
- Extensions：增加新命令、新模板或外部工具整合；
- Presets：改變現有規格、計劃、任務模板的格式和術語。
簡單理解：如果要新增能力，用 Extension；如果要改造工作流風格，用 Preset。
例如，團隊可以透過 Preset 強制加入安全審查、合規追蹤、領域術語或測試優先規則；也可以透過 Extension 增加 Jira 整合、代碼審查、項目健康檢查等新階段。
這說明 Spec Kit 並不想把所有團隊鎖進同一種流程，而是提供一個可擴展的規格驅動骨架。
適合誰用？
Spec Kit 適合這些場景：
- 用 AI coding agent 做新項目原型；
- 想把 vibe coding 變成可複盤流程；
- 團隊希望統一 AI 生成代碼前的需求和計劃格式；
- 項目需要明確驗收標準和測試要求；
- 希望把需求、計劃、任務和實作過程都納入版本管理；
- 正在探索 GitHub Copilot、Claude Code、Codex CLI 等工具的團隊化用法。
它不一定適合非常小的一次性腳本。對於幾行代碼能解決的問題，完整規格流程可能顯得重。但只要任務開始涉及多個頁面、多個模組、狀態管理、權限、數據模型或長期維護，Spec Kit 的結構化收益就會變明顯。
我的理解
Spec Kit 代表的是 AI 編程工具的一種重要轉向：從「讓 Agent 更快寫代碼」，轉向「讓 Agent 更可靠地參與軟件工程」。
過去的 AI 編程關注提示詞和模型能力，Spec Kit 更關注流程、產物和約束。它提醒我們：AI 寫代碼越快，規格、計劃和驗收就越不能省。
如果你已經習慣讓 AI 直接實作功能，可以嘗試用 Spec Kit 改變起手式：
先讓 AI 幫你把需求寫成規格，再讓它寫代碼。
這一步看似變慢，實際是在減少後面「代碼寫完了，但不是我想要的」的返工。