GitHub Spec Kit 是什麼？用規格驅動開發約束 AI 編程

Mon, 25 May 2026 00:19:14 +0800

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 給出的入門流程大致是這樣：

1
2
3

uv tool install specify-cli --from git+https://github.com/github/spec-kit.git@vX.Y.Z
specify init my-project --integration copilot
cd my-project

初始化後，項目裡會生成 .specify 目錄、模板、腳本和與 Agent 整合的命令。隨後在支援的 AI coding agent 中使用 /speckit.* 命令推進開發。

典型順序是：

/speckit.constitution
/speckit.specify
/speckit.clarify
/speckit.plan
/speckit.tasks
/speckit.implement

其中 /speckit.constitution 用來建立項目原則，/speckit.specify 描述產品需求，/speckit.clarify 補齊模糊點，/speckit.plan 生成技術計劃，/speckit.tasks 拆任務，最後由 /speckit.implement 執行實作。

這和直接對 Agent 說「幫我做一個應用」差別很大。Spec Kit 要求你把「做什麼」和「怎麼驗收」先說清楚，再讓 Agent 動手。

它改變了 AI 編程的入口

傳統 AI 編程經常從代碼開始：

`1`	`我想做一個任務管理應用，幫我寫出來。`

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 幫你把需求寫成規格，再讓它寫代碼。

這一步看似變慢，實際是在減少後面「代碼寫完了，但不是我想要的」的返工。

參考連結

github/spec-kit

Spec Kit on KnightLi的博客