用Claude Code搭配 spec-kit 開發程序體驗

發表於： 分類於：
字數： 4050 閱讀：≈ 9分鐘

前言

在 AI 輔助開發的浪潮中，如何讓 AI 更好地理解我們的意圖並生成高質量的代碼，一直是開發者關注的焦點。GitHub 推出的 spec-kit 工具為我們提供了一種全新的「規格驅動開發」（Spec-Driven Development, SDD）方法論，讓開發過程更加結構化和可控。

Spec Kit 到底解決了什麼「老大難」？

1. 減少「意圖走樣」

傳統流程裡，「需求→設計→實現」每一環都可能「走樣」。SDD 的思路是：讓規格可執行，由規格派生實現計劃和測試，代碼只是「最後一公里」。遇到偏差，先改規格和計劃，再讓實現「再生一次」去對齊。

2. 把「文檔變廢」為「文檔生碼」

他們把「規格生實現」的節拍拆得很細：

  • /specify 把一句話想法生成結構化規格
  • /plan 把規格翻譯成技術架構與設計文檔
  • /tasks 自動把設計切成可並行執行的任務清單（會標記 [P] 並行）
  • 最後 /implement 按任務和 TDD 節奏去落地

官方甚至用「即時通訊功能」為例，類比傳統要花 ~12 小時的文書工作，通過三條命令在 ~15 分鐘內把規格、計劃、數據模型、合約、測試場景和任務都生成齊全（當然後續還要補充/驗證，但開局就很穩）。

3. 降低「過度設計」的慣性

Spec Kit 不是「放飛自我」的生成，而是用鐵律**（Constitution）+ 模板 Gate** 給 LLM「上護欄」。比如簡單性 Gate、反抽象 Gate、集成優先 Gate，明確限制項目數、反對無謂封裝、強調先做真實環境的契約測試等，從模板層面就把「工程潔癖」遏住。這些「原則」是不可協商的底線，帶來跨時間、跨模型的一致性。

Spec Kit 的核心特性

✅ 一套固定命令，拉齊整個鏈路

從確立團隊原則（/constitution），到「說清楚要做什麼」（/specify），到「把不清楚的先問清」（/clarify），再到「定技術方案」（/plan）、「自動拆任務」（/tasks）、「一致性分析」（/analyze）、「落地實現」（/implement）——這條流水線在 README 的「Get started」與 Quick Start 裡都有演示，CLI 安裝方式也給到了 uv tool 或 uvx 兩種選擇。

✅ 跨 Agent 工作：Claude/Cursor/Copilot/Qwen…

Spec Kit 支持多種 AI Coding Agent（並且針對不同 Agent 生成對應的命令文件/目錄結構），這意味著你可以在熟悉的工具裡跑同一流程，且保持結構一致（AGENTS.md 列了支持矩陣與目錄約定）。README 裡也列了「Supported AI Agents」表格，順帶標註了個別工具的限制（例如部分 CLI 對自定義參數支持有限）。

✅ 模板即「軟規範」：讓 LLM 寫得更像工程師

規格模板會強制標記不確定項 [NEEDS CLARIFICATION]，不允許它「合理想象」；同時明確「規格寫 WHAT/WHY，禁止 HOW（技術細節）」，逼著模型維持正確抽象層級。計劃模板再用一堆 Gate 把工程複雜度「防抖」一次，這些做法在文檔中被總結為「模板驅動質量」。

✅ 把 TDD 寫進流程

任務模板把順序寫死：先寫契約/集成測試並確認失敗，再寫實現（「紅-綠-重構」節奏內化到命令/模板）——這是 Spec Kit 的「工程底線」，而且與「集成優先」的原則一致，鼓勵使用真實依賴而非一味打樁。

✅ 「Clarify/Analyze」把風險暴露在編碼前

Changelog 裡能看到近期新增了 /clarify（自動追問關鍵不確定性並入檔）與 /analyze（跨規格/計劃/任務/鐵律的差異報告）這兩步，把「返工」前置為「提問與體檢」，而不是寫完再返修。

跟「普通的讓 AI 直接生成代碼」相比的優勢

一句話：少拍腦袋，多有證據。

  • 鏈路可追踪：每個技術選擇都能追溯到規格裡的具體需求，規格/計劃/研究/合約是活文檔，與代碼同分支、同演進
  • 團隊協作友好：規格是團隊共識對象，而不是提示詞的「黑箱藝術」；「Clarifications」有跡可循，方便評審與補齊
  • 抗噪聲：模板把 LLM 容易「過擬合到實現細節」的毛病卡住了（例如明確「禁止 HOW」），降低誤差傳播
  • 可落地：不是 PPT 流程。官方示例從命令到目錄結構再到腳本都給全了，實踐門檻很低

真實開發會是什麼體驗？

想象一下這樣的節奏：

  1. 訂「鐵律」：先用 /constitution 寫定團隊的工程原則（例如「簡單優先、反抽象、集成優先、測試先行」），這會成為之後每個計劃文檔的檢查 Gate（不通過就打回）

  2. 說清楚做什麼：用 /specify 把用戶價值、場景、邊界寫清——不寫技術，只寫 WHAT/WHY（模板會校驗）

  3. 把不清楚的問清楚：/clarify 會生成結構化問題清單並把回答入檔，減少後期「猜」

  4. 定技術方案：用 /plan 把棧、結構、合約、數據模型、Quickstart 測試場景都生成出來，並通過 Gate 校驗一次複雜度與原則一致性

  5. 自動拆任務：/tasks 讀取 plan 與 contracts/data-model，生成帶並行標記的任務清單（先測後碼）

  6. 一致性檢查：/analyze 在實現前再跑一遍「對賬單」，發現衝突先改文檔不是先改碼

  7. 開始實現：/implement 嚴格按任務、按 TDD 順序推進，過程中也會持續回寫狀態文檔，便於復盤與協作

Speckit 全流程使用步驟（完整版）

以下是完整的 8 步 Speckit 工作流程，以「家庭多人 ToDoList 專案」為例：

0. 安裝 Speckit 並初始化

首先，確保你已經安裝了 Speckit。你可以使用以下命令安裝：

1

pip install speckit

進入項目目錄執行以下命令初始化 Speckit：

1

specify init --here

1. /speckit.constitution - 建立項目鐵律

目的：確立團隊工程原則和不可協商的底線 輸出：constitution.md 文件

1

我們要建立一個家庭多人 ToDoList 專案的工程原則

2. /speckit.specify - 創建規格文檔

目的：將想法轉化為結構化規格，只描述 WHAT 和 WHY 輸出：spec.md 文件

1

創建一個家庭多人 ToDoList 應用，讓家庭成員可以共享和管理任務

3. /speckit.clarify - 澄清不確定性

目的：識別並解決規格中的模糊點 輸出：clarifications.md 文件

1

基於當前規格，識別需要澄清的關鍵問題

4. /speckit.plan - 生成技術計劃

目的：將規格轉化為技術架構和實現計劃 輸出：plan.md 文件

1

基於規格和澄清，創建技術實現計劃

5. /speckit.tasks - 自動拆分任務

目的：將計劃分解為可執行的任務清單 輸出：tasks.md 文件

1

基於計劃生成具體的開發任務

6. /speckit.checklist - 生成檢查清單

目的：創建質量保證和驗收標準 輸出：checklist.md 文件

1

為項目創建完整的檢查清單

7. /speckit.analyze - 一致性分析

目的：檢查規格、計劃、任務之間的一致性 輸出：analysis.md 文件

1

分析當前文檔間的一致性和潛在衝突

8. /speckit.implement - 開始實現

目的：按照 TDD 原則執行具體實現 輸出：實際代碼和測試

1

開始實現第一個任務：用戶註冊功能

完整使用順序總結

步驟命令主要輸出核心目的
1/speckit.constitutionconstitution.md建立工程原則
2/speckit.specifyspec.md定義需求規格
3/speckit.clarifyclarifications.md澄清模糊點
4/speckit.planplan.md技術架構設計
5/speckit.taskstasks.md任務分解
6/speckit.checklistchecklist.md質量標準
7/speckit.analyzeanalysis.md一致性檢查
8/speckit.implement代碼實現TDD 實現

上手成本與環境要求

好消息是：上手很輕。你只需要：

  • 一台 macOS / Linux /（或 Windows + PowerShell）環境
  • Python 3.11+、Git、以及用於協作的一個 AI Coding Agent（Claude Code / Copilot / Gemini CLI 等皆可）
  • 使用 uv tool 或 uvx 一行命令初始化即可（可強制選擇腳本類型 sh/ps；也支持「當前目錄初始化」與忽略工具檢查）

如果你已經有偏愛的 Agent，不用換工作方式——Spec Kit 也考慮了跨 Agent 的目錄/命令適配（AGENTS.md 詳細寫了各自約定與工具檢測）。

適合誰？

  • 中小團隊/個人開發者：需要快速起盤、又不想犧牲工程質量
  • 大中型組織/平台團隊：希望在多項目、多技術棧下保持統一工程治理與「可再生」的實現方式
  • 內容/效率愛好者：你要做 Demo、做對比評測或想嘗試「並行解法」，這套「生成多個實現以做決策」的思路也被官方當成實驗目標之一

個人使用建議

  1. 把「鐵律」當第一生產力：先定好工程底線，再談技術棧，真的能少走彎路（Gate 會幫你擋很多「未來可期式」的複雜度）

  2. 習慣先 Clarify，再 Plan：這一步是把「返工」變「補題面」的關鍵，尤其多人協作時更必要

  3. 把「研究（research.md）」當可執行備忘錄：遇到版本/依賴不確定，就讓 Agent 生成研究任務逐條攻克，別放任「模糊棧」進實現

  4. 嚴格按 TDD 順序：契約和集成測試先紅再綠，這是 Spec Kit 最硬的護欄之一

  5. 實現前跑一遍 /analyze：讓系統幫你找「規格/計劃/任務/鐵律」的矛盾，寧可前置 10 分鐘，也別後置 3 天

一分鐘開始你的第一個項目

方式一：一次安裝，處處可用（推薦） 

1
2
3

uv tool install specify-cli --from git+https://github.com/github/spec-kit.git
specify init my-first-spec-kit
specify check

方式二：臨時使用 

1

uvx --from git+https://github.com/github/spec-kit.git specify init my-first-spec-kit

初始化後，進到你的 Agent 裡，先跑一發 /constitution，再 /specify、/clarify、/plan、/tasks、/analyze、/implement，就能完整體驗從「意圖→實現」的全鏈路。

安裝 uv 的方法

你可以選擇下面最適合你的一種方法進行安裝。

方法一：官方推薦腳本 (macOS, Linux, Windows)

這是最直接和推薦的安裝方式。

對於 macOS 和 Linux：

1

curl -LsSf https://astral.sh/uv/install.sh | sh

對於 Windows：

1

irm https://astral.sh/uv/install.ps1 | iex

方法二：使用 pip

如果你已經安裝了 Python 和 pip，可以直接使用 pip 來安裝 uv。

1

pip install uv

為了獲得最佳性能，建議使用 Python 3.8 或更高版本。

方法三：使用包管理器

如果你習慣使用系統或語言的包管理器，也可以用它們來安裝。

Homebrew (macOS/Linux):

1

brew install uv

Scoop (Windows):

1

scoop install uv

Cargo (如果你安裝了 Rust 工具鏈):

1

cargo install uv

驗證安裝

安裝完成後，你可以通過運行以下命令來驗證 uv 是否成功安裝並查看其版本：

1

uv --version

如果能看到版本號輸出，就說明安裝成功了！✅

執行你的命令

在你成功安裝 uv 之後，你就可以直接運行你提到的命令了：

1

uv tool install specify-cli --from git+https://github.com/github/spec-kit.git

這個命令的作用是：

  • uv tool install: 類似於 pipx install，它會將 specify-cli 這個工具安裝到一個獨立的虛擬環境中，避免污染你的全局 Python 環境，同時將其可執行文件路徑添加到系統的 PATH 中，讓你可以在任何地方直接調用它
  • --from git+...: 指定從一個 Git 倉庫來安裝這個包

總的來說，你先用上述任意一種方法把 uv 本身安裝好，然後就可以使用 uv 來安裝其他 Python 工具了。

結語

Spec Kit 的價值不在於「它能不能一鍵出代碼」，而在於它把團隊的「意圖」變成有約束、有證據鏈、可再生的資產。當規格成為「唯一真相」，當測試把「真相」守住，代碼就不再是「手工翻譯」，而是可再生成的「表達」。

如果你也在找一種高質高效、又不放棄工程紀律的 AI 開發方式，Spec Kit 非常值得一試。正如 Linus 所說的「好品味」——有時你可以從不同角度看問題，重寫它讓特殊情況消失，變成正常情況。Spec Kit 正是這樣一個工具，它讓複雜的開發流程變得簡潔而優雅。