Spec Kit 是什麼？
Spec Kit 是一套實踐 規格驅動開發（Specification-Driven Development，SDD） 的開源工具包，由 GitHub 與 Microsoft 聯合推廣。它的核心理念很簡單：在寫任何一行程式碼之前，先把「要做什麼」與「成功長什麼樣子」寫清楚。規格文件不只是文字說明，更是驅動 AI 輔助開發、任務拆解、自動化驗證的單一事實來源（Single Source of Truth）。
傳統開發的三大痛點
在引入 SDD 之前，許多團隊都深受以下問題所苦：
- ✗ 需求模糊，一改再改：口頭溝通或粗略的 User Story 導致工程師與 PM 對「完成」的定義各執一詞，驗收時才發現方向跑偏，大量返工在所難免。
- ✗ AI 指令不精準，輸出品質不穩：直接把模糊需求丟給 Copilot 或 Claude，AI 只能靠猜測補全脈絡，產出的程式碼往往需要大幅修改，反而增加認知負擔。
- ✗ 一次大批次改動，風險爆炸：沒有任務拆解步驟，工程師傾向「一口氣做完」，造成 PR 龐大難以審查、問題難以定位、回滾成本高昂。
SDD 核心理念
SDD 建立在三個支柱之上：
- 規格先行：任何功能開始前，先產出
spec.md，明確使用者旅程、成功條件與邊界情境。規格通過審查後，才進入下一階段。 - 小步驗證：透過任務拆解，每個實作單元都對應一個明確的驗收標準。完成一個任務、驗證一個任務，而非「做完所有事再一次測試」。
- 持續迭代：規格並非一成不變的契約，而是隨著對問題的理解加深而不斷精煉。每次迭代都讓規格、計畫、任務三份文件保持同步。
核心四階段流程
Specify — 定義規格
回答「誰在什麼情境下要解決什麼問題，成功長什麼樣子？」。產出 spec.md，包含使用者角色（User Role）、使用者旅程（User Journey）、功能需求、非功能需求（效能、資安、可存取性）以及明確的驗收標準（Acceptance Criteria）。此階段最重要的產物是可量化的成功條件，讓後續所有決策都有依歸。
Plan — 技術規劃
回答「用什麼架構與技術，怎麼滿足效能、資安、維運限制？」。產出 plan.md，涵蓋技術棧選型理由、系統架構圖、資料模型、API 設計、部署策略與風險評估。此階段讓架構決策透明化，避免實作時才發現技術路線不可行而大規模重構。
Tasks — 任務拆解
回答「如何拆成可驗證的小任務，先做哪一塊風險最低？」。產出 tasks.md，將整個功能拆解成 20–60 分鐘可完成的獨立工作單元，每個任務都帶有明確的輸入、輸出與驗收條件，並標注依賴關係與優先序。這份文件也是給 AI 執行器（如 Claude Code）最精準的指令集。
Implement — 逐步實作
回答「每一步怎麼驗證，不通過要回哪一層修正？」。依序執行 tasks.md 中的任務，每完成一個任務立即執行對應的驗證步驟（單元測試、整合測試或手動驗收）。若驗證失敗，根據問題性質決定回到 Tasks 層修正拆解方式，或回到 Plan 層調整架構，而非盲目繼續往前。
SDD 與 TDD 的關係與差異
許多人第一次聽到 SDD 時會問：「這跟測試驅動開發（TDD）有什麼不同？」兩者並不衝突，但層次不同：
- 粒度不同：TDD 的循環是紅燈→綠燈→重構，粒度在函式與模組層；SDD 的循環是規格→計畫→任務→實作，粒度在功能與系統層。
- 目標不同：TDD 預防技術缺陷（程式邏輯錯誤）；SDD 預防方向缺陷（做錯了方向或做了不必要的功能）。
- 可組合：在 SDD 的 Implement 階段，完全可以採用 TDD 的方式撰寫每個任務的實作程式碼，兩者互補而非互斥。
SDD 帶來的具體好處
- ● AI 指令精準度大幅提升：將
spec.md或tasks.md作為 prompt 的上下文，AI 生成的程式碼更貼近真實需求，減少來回修改次數。 - ● 減少返工，縮短交付時間：在規格階段就排除歧義，避免實作一半才發現方向錯誤，整體開發週期可縮短 30–50%。
- ● 提升跨職能溝通效率：PM、設計師、工程師與 QA 圍繞同一份
spec.md對話，減少資訊落差與重複確認。 - ● 降低新成員上手成本：規格文件即是活文件（Living Document），新加入的工程師或 AI 助理都能快速理解功能背景與邊界條件。
- ● 風險可預測，決策有依據：Plan 階段的風險評估讓技術風險在動工前就被量化，避免「做到一半才發現不可行」的驚喜。
適用場景
SDD 並非銀彈，以下場景最能發揮其價值：
- 新功能開發：從零開始的功能最適合走完整的 Specify → Plan → Tasks → Implement 四階段流程。
- 大型重構：重構前先用
spec.md定義重構目標與驗收標準，避免重構成「重寫」後反而引入更多問題。 - AI 輔助開發：以
tasks.md作為 AI 執行器的指令集，是目前讓 Claude Code、Cursor 等工具穩定輸出的最佳實踐之一。 - 分散式團隊協作：非同步溝通時，規格文件取代大量會議，確保不同時區的成員對目標理解一致。
spec.md（半頁即可）來確認方向，其餘流程視需求省略。
三份核心文件介紹
Spec Kit 的一切圍繞著三份 Markdown 文件運作：
spec.md — 功能規格
定義「做什麼」與「為誰做」。包含功能概述、使用者角色、使用者旅程的逐步描述、功能需求清單、非功能需求（效能目標、瀏覽器支援、無障礙標準等）以及詳細的驗收標準。這是整個開發流程中唯一的需求事實來源，所有後續文件都必須對齊此文件。
plan.md — 技術計畫
定義「怎麼做」與「用什麼做」。包含技術棧選型與理由、系統架構說明、元件/模組劃分、資料流與 API 設計、資料庫 Schema 草稿、部署與維運考量，以及技術風險與對應的緩解策略。Plan 的品質直接決定任務拆解的準確性。
tasks.md — 任務清單
定義「誰做什麼、先後順序如何」。每個任務條目包含：任務編號、標題、詳細描述、輸入條件（相依的前置任務或資料）、輸出產物（程式碼、測試、文件）以及驗收步驟。任務粒度以 20–60 分鐘為佳，過大的任務需繼續拆分。這份文件可直接作為 AI 自動化執行的指令集。
總結：為什麼現在是採用 SDD 的最佳時機？
在 AI 輔助開發已成主流的今天，工程師的核心價值正在從「寫程式碼」轉移到「定義清晰的問題與驗收標準」。Spec Kit 提供了一套輕量、可落地的方法論，讓你不論使用哪種 AI 工具，都能以規格驅動 AI 的輸出，而不是被 AI 的隨機輸出所驅動。從下一個功能開始，試著先花 30 分鐘寫一份 spec.md，你會發現後續的實作速度與品質都將顯著提升。