Spec Kit 完整指南：從規格到 AI 開發工作流
Spec Kit 完整指南整理規格驅動開發的核心觀念、實作順序、品質檢查與工具比較。第一次接觸可從基礎開始，已有經驗則直接選擇教學、舊專案導入或工作流設計。
目錄+
Spec Kit 相關文章增加到 12 篇後，從第一篇照順序讀到底，反而不是最有效率的方式。第一次接觸的人需要先弄懂文件分工；已經在用 coding agent 的人，通常只想解決舊專案、驗收或工具選擇。
這篇是整個主題的入口。你可以依現在遇到的問題挑文章，也可以把它留作日後查找的索引。新的規格驅動開發文章會繼續收進下方目錄。
Spec Kit 是什麼？
Spec Kit 是 GitHub 推出的規格驅動開發 toolkit。它把「想做什麼」逐步整理成 spec、plan 與 tasks，再交給 coding agent 實作。官方目前把核心流程整理為 Spec → Plan → Tasks → Implement，並提供 constitution、clarify、checklist 與 analyze 等能力來補足專案原則、需求歧義和文件一致性。
這套方法不是叫 AI 多寫幾份文件。它要解決的是另一個問題：當需求、技術決策和執行工作都留在對話裡，模型換一個 context，團隊就得重新猜一次。
Spec 是 AI 開工前的共同介面。
如果這個概念還很陌生，先讀Spec Kit 是什麼？AI 寫程式更需要規格。那篇會先把規格驅動開發和一般 prompt coding 的差別說清楚。
Spec Kit 完整指南該怎麼讀？
不用被篇數嚇到。依你的情況選一條路就好。
第一次接觸規格驅動開發
先理解 spec、plan、tasks 各自回答什麼問題，再挑一個小功能實作。這條路的目標不是立刻建立完整制度，而是親眼看見一份 requirement 如何一路走到測試與程式碼。
建議順序：基礎觀念、文件分工、第一個實作。
想直接用 Codex 跑一次
直接進入Spec Kit＋Codex 教學：跑完一個功能。文章會從初始化開始，帶你經過 specify、plan、tasks 和 implement。題目最好選兩三天能完成的真實功能，不要拿待辦清單範例測流程。
跑完後再回頭補 constitution、clarify 與 analyze，會比先背完所有指令容易理解。
已經在用 coding agent，但流程常失控
你需要的可能不是入門教學，而是針對痛點選工具：
- 需求常在實作途中改變，先看 clarify、checklist 與 analyze。
- 測試全綠卻還是漏需求，補上 converge 與人工 review。
- 舊專案背景太多，先做 codebase mapping，再限制第一個 spec 的邊界。
- 團隊同時使用 Rules、Skills 和多套 framework，先把每一層的責任拆開。
最後再讀建立自己的 AI 規格驅動開發系統，依工作風險決定哪些關卡要保留。完整流程應該服務交付，不該變成每次都得走完的儀式。
這個主題分成哪幾塊？
系列文章大致處理五個層次。
第一層是需求。Spec 要說清楚使用者、行為、邊界和驗收條件，暫時不急著指定檔案與框架。
第二層是技術決策。Plan 把需求映射到現有架構，記錄資料流、介面、測試與風險。Tasks 再把 plan 切成可以依序完成的小批次。
第三層是專案治理。Constitution、Rules 和 Skills 保存跨功能的原則與工作程序，避免每份 spec 重複解釋同一套慣例。
第四層是品質。Clarify 找出會改變設計的歧義，checklist 檢查規格寫得能不能驗收，analyze 對照 artifacts，converge 則在實作後追查是否做漏。
第五層是工具選擇。Spec Kit、OpenSpec、Kiro Specs、Agent OS、BMAD、GSD 與 Superpowers 處理的範圍並不相同。先找出缺口，再選一套補上，通常比把所有框架疊在一起有效。
Spec Kit 系列完整文章目錄
下方目錄會依 seriesOrder 自動排序。未來新增文章只要沿用 ai-spec-driven-development 系列名稱，就會出現在這裡，不必手動維護連結清單。
Living index
Spec Kit 與規格驅動開發
目前收錄 1 篇如何把這個入口用在日常工作？
遇到新功能時，先判斷它卡在哪一層。需求不清楚就讀 specify 與 clarify；技術方案散亂就回到 plan；實作做不完就檢查 tasks 是否太大；驗收沒有把握，再補 analyze、測試與 converge。
工具比較文章則留到你真的要換流程時再看。只因為另一套 framework 功能更多就遷移，常會把熟悉的問題換成新的設定成本。
這個入口會保留為常青文章。當 Spec Kit 增加新的 workflow、extension，或系列新增案例與教學時，內容和目錄都會繼續更新。
Spec Kit 本身免費開源。若你會長時間對照規格、終端與程式 diff，可參考蝦皮開發者桌面選物整理閱讀空間；這不是使用 Spec Kit 的必要條件。
聯盟揭露：上方連結為蝦皮聯盟連結，若透過連結購買，我可能取得少量分潤，不影響你的價格與本文內容。
常見問題
Spec Kit 是什麼？
Spec Kit 是 GitHub 推出的規格驅動開發 toolkit。它用 spec、plan、tasks 等 Markdown artifacts 保存需求、技術決策與執行工作，再由 coding agent 實作。
Spec Kit 完整流程一定要全部執行嗎？
不一定。小修改可以只保留 acceptance criteria 與測試；跨模組或高風險功能才值得使用完整品質關卡。流程重量應該和錯誤代價成比例。
第一次學 Spec Kit 應該從哪篇開始？
先讀基礎介紹，再理解 spec、plan、tasks 的分工，接著跟著 Codex 教學完成一項小功能。
之後新增的 Spec Kit 文章會放在哪裡？
新文章只要設定 series: 'ai-spec-driven-development' 與下一個 seriesOrder，就會自動加入本頁目錄。