Spec Kit 是由 GitHub 所開發的開源工具，旨在推廣和實踐 AI 時代的規格驅動開發（Spec-Driven Development, SDD）方法論。讓比較隨意即興編碼的 Vibe Coding ，轉變成具結構化、有檢查點的 SDD 流程。
Spec Kit 的出現，讓過往沒有好好被整理的專案文件，有了對齊與更新的契機。這套工作方法更能很好地面對高層或客戶所提的改動，比起以往更有機會能接下各種突如其來的需求。
Spec Kit 的出現，為長期困擾團隊的問題提供了系統化的解決方案。
▍規格先行：讓產品開發有跡可循
SDD 與 TDD（Test-Driven Development，測試驅動開發）是採以「規格先行」的方法，透過寫下規格 (Why & What) 、計畫 (How）與測試場景，讓 AI 或工程師可以接著根據規格（Spec）來進行開發。
這份規格就像是一份「可執行的開發合約」。當我們遇到新需求或功能變更時，都可以透過 AI 的輔助來即時更新。如此一來，更新規格不再是麻煩事，而且速度也快超多。
在嚐到 AI 輔助開發的甜頭後，人們自然而然就會想去更新規格，進而讓規格永遠保持在最新狀態，就如同活文件（Living Document）一般。
💡 關於 SDD 與 TDD 的更多介紹，歡迎可以看看「文件復興的時代：SDD 與 TDD 正成為軟體開發的新典範」。
食譜與食譜寫作指南的關係
那麼 SDD 與 TDD，這兩份文件與 Spec Kit 到底有何差異呢？
就猶如你在 Reels 上滑到有人做「酪梨乳酪慕斯」的影片，你發現：「哇！這好健康，是飲控的人也很適合吃的甜點耶！」
於是，你就想將這道甜點分享給有興趣的朋友知道，讓他們也能在家實際做做看。不過發現 Reels 的影片模式就不適合邊看邊做，要以食譜才行。
於是我們的食譜寫作指南（即 Spec Kit）此時就派上用場了！Spec Kit 會教你如何寫出清楚好懂的食譜。從材料、份量、步驟到製作方法，步驟化地教你如何條列與敘述，讓你知道如何寫出清楚好懂的食譜（即 SDD 與 TDD）。
你的朋友們可以輕鬆根據食譜所教的作法，逐步自己實做看看。做完後也能馬上就知道有沒有成功——這就像 TDD 的測試流程一樣。
▍Spec Kit 工作流
好的食譜是可以讓任何人都能重現出美味的甜點，而這正是 Spec Kit 所帶來的標準化效益。
Step 1. 建立 Constitution（專案憲法）
要讓 Spec Kit 順利融入進工作流程，第一步即是為專案建立「憲法」的概念。
專案憲法即是這個專案的最高準則，定義該產品的價值核心、技術與開發準則。這不僅是可以用來指引 AI 的開發方向，更是想透過準則的建立，來確立團隊對於專案的共識。
透過準則的樹立，我們會先建立第一份專案文件——constitution.md，內容如下：
1.價值核心
- 解決使用者什麼痛點
2.技術原則
- 響應式設計優先 (mobile-first)
- 使用者體驗 > 功能複雜度
- 資料隱私最高優先級
3.開發準則
- 每個功能都要有 Spec → Plan → Tasks
- 所有 UI 都要通過 RWD 測試
- 採用 Given-When-Then 格式撰寫場景
4.專案邊界
- 產品不做什麼
Step 2. 制定 Specify（規格）
接著，就可以進到產品細節的制定。輸入 /specify 指令後，描述產品的使用旅程：使用者會在什麼場景下與之互動？能得到什麼結果或解決什麼痛點？
此時，AI 就會根據你的產品規劃，產生第一版 spec.md。接著，我們就可以去審核文件，透過直接修改或是與 AI 來回討論的方式，迭代出符合預期目標的內容。
spec.md 內容包含以下架構：
1.產品概述
- 功能目的
- 目標使用者
2.使用者故事
3.使用場景
- 場景 1
- 場景 2
- 等等
4.驗收標準
- 功能性驗收
- 視覺與互動驗收
- RWD 驗收
Step 3. 制定 Plan（技術規劃）
下一步，即輸入 /plan 指令來規劃產品的技術架構與限制。此時，就可以由工程團隊來進行技術細節的確認與調整，確保符合產品開發的方向。
plan.md 內容包含：
1.技術架構
2.技術棧選擇
3.API 設計
4.資料結構
Step 4. Tasks（任務）生成
在與 AI 討論並規劃好 spec.md 與 plan.md 後，就可以進入自動化環節。輸入 /tasks 指令後，AI 即會讀取 spec.md 與 plan.md 來擬定出成可執行、可審查、小而專一的任務清單。
tasks.md 內容包含:
1.基礎建置
- 專案初始化
- 定義型別與介面
2.元件開發
3.測試
- 單元測試
- RWD 測試
- 使用者場景測試
4.整合與優化
- API 整合
- 效能優化
Step 5. Implement（實作）與 Validate（驗證）
在確認 tasks.md 沒問題後，就可以由 AI 或開發團隊開始實作。
由於 tasks.md 中每個任務就是一個最小開發單位，在生成程式碼、測試、提交的過程中，一有狀況就能立即定位問題。大幅提升了整體產品開發效率。
在最後驗證階段，就可以實際操作看看，對應 spec.md 所寫的使用者故事與場景是否都有實現，同時也能順便檢查是否有遺漏掉的邊界案例（Edge cases）。
▍透過流程的導入，消除對產品的不熟悉與不確定
可能會好奇：怎麼 Spec Kit 產出的文件怎麼沒有 SDD.md 與 TDD.md 呢? 那是因為 Spec Kit 已經將它們拆解重組了：
SDD.md 拆成 spec.md（需求）與 plan.md（技術）
TDD.md 的「測試場景」則是轉化成 tasks.md 的「任務清單」
Spec Kit 是一種效率化的思考方式
透過 Spec Kit，我們可以從產品構想、規劃到開發，整個好好想過一輪，且產品相關內容都有對應的規格文件可以查閱：
產品的定位與功能是？—> 看 spec.md
會用什麼技術來實現？—> 看 plan.md
有哪些 Tickets 要開？—> 看 tasks.md
團隊也分工的很清楚：
產品經理與設計師：負責 spec.md
工程團隊：負責 plan.md
產品開發：看 tasks.md 執行
QA：根據 spec.md 驗收
規格即真相的來源
過往的產品開發流程，很容易遇到文件內容新舊不一且散落在各處的窘境。Spec Kit 的導入可以有效收斂文件，並將產品簡要地劃分成需求（spec.md）、技術（plan.md）與任務（tasks.md）三個文件。
如此，不管是團隊夥伴還是利害關係人，有任何對產品不清楚的地方，看規格文件就能立即了解產品的規劃。讓規格文件不僅成為團隊清楚溝通的媒介，更也成為產品知識的載體。
在可以透過 AI 輔助開發的時代下，規格成為驅動程式碼生成的依據，也決定了產品最終樣貌的來源。
重要的事，我們終於可以不用到處找文件了：）