Spec Kit 教學投影片
Slide 1
SDD 是什麼？
- SDD（Spec-Driven Development）是以規格為核心驅動力的開發方法論
- 在第一行程式碼落地之前，所有成功條件與邊界情境已明確定義
- 規格不是事後補寫的文件，而是整個開發週期的單一事實來源
- 人類開發者與 AI 代理人都在同一份規格約束下協作，目標一致
- Spec Kit 是實踐 SDD 的工具集：CLI 指令 + 結構化文件範本
- 核心流程：Constitution → Specify → Plan → Tasks → Implement → Check
Slide 2
傳統開發的痛點
- 需求以口頭或 Slack 訊息傳遞，各方理解不同，事後爭議不斷
- AI 代理人缺乏足夠上下文，產出方向偏移，需要大量回合修正
- 任務粒度過大，一個 PR 改動數百行，出錯難以精準回滾
- 驗收標準模糊，「完成」的定義因人而異，合併前才發現落差
- 架構決策藏在資深成員腦中，新人與 AI 無從遵守，重複犯相同錯誤
- 缺乏系統性流程，每個功能的開發方式都不一樣，難以複製成功經驗
Slide 3
Spec Kit 核心流程
- Constitution：建立全域架構原則與技術決策，是所有功能開發的護欄
- Specify：從一句需求描述生成結構化的
spec.md，定義成功條件與邊界情境 - Clarify：針對規格盲點提出精準問題，動工前補齊所有模糊地帶
- Plan：依據規格生成設計方案，確認技術路徑後再拆解任務
- Tasks：產出依賴排序的任務清單，每項任務 5～30 分鐘可完成並驗證
- Implement → Check：逐步執行任務，
specify check確保規格與實作始終對齊
Slide 4
撰寫好規格的技巧
- 從使用者情境出發：「身為 X，我希望 Y，以便 Z」
- 成功條件必須可驗證，避免「系統應該很快」這類無法量化的描述
- 主動列出邊界情境：空輸入、超出範圍的值、網路中斷時的行為
- 明確寫出不在範圍內的事項（Out of Scope），防止需求蔓延
- 使用
speckit.clarify自動找出規格中尚未回答的關鍵問題 - 規格要簡潔：每個段落只陳述一個觀念，避免把設計方案混入需求說明
Slide 5
Constitution 的力量
constitution.md是跨功能的全域約束文件，對每個spec.md都有效- 將架構決策制度化：語言版本、框架選擇、錯誤處理規範全部明文記錄
- AI 代理人在生成程式碼時自動遵守 constitution，不需要每次重複說明
- 技術主管可以透過 constitution 設定「護欄」，而非逐行審查 AI 輸出
- Constitution 本身也是版控文件，架構演進的歷程有跡可循
- 建立 constitution 的最佳時機是專案初始化時，越早建立越能降低後期負擔
Slide 6
實戰演示與最佳實踐
- 從一個真實新功能開始：執行完整 SDD 流程一次，建立肌肉記憶
- 每次
speckit.clarify後重新審閱spec.md，確認 AI 回寫的答案符合你的意圖 - 任務清單要在實作前與團隊對齊，避免並行開發時的任務衝突
- 將
specify check加入 CI 守門，讓規格驗證成為合併的強制前提 - 定期回顧 constitution：每個 Sprint 結束後更新一次，納入新的技術決策
- 推廣策略：先從單一功能試點，成功後收集數據，再向團隊展示成效後擴展
Slide 7
導入常見風險與對策
- 風險：規格寫太抽象，AI 無法落地 → 對策：使用 clarify 強制細化，加入具體範例
- 風險：只升級 CLI，忘記更新專案範本 → 對策：升級後執行
specify check確認相容性 - 風險：跳過 plan 直接 implement → 對策：將 plan 輸出列為 PR 的必要附件
- 風險：constitution 從未更新，與實際架構脫節 → 對策：指定專人負責每季審閱
- 風險：任務粒度過大，難以回滾 → 對策：任務超過 30 分鐘估算時強制再拆解
Slide 8
導入行動清單
- 今天：安裝 Spec Kit CLI，執行
specify init初始化一個試點功能分支 - 本週：走完完整 SDD 流程一次，從 specify 到 check，記錄遇到的摩擦點
- 本月：將
specify check加入 CI，讓規格驗證自動化 - 下季：收集試點數據（返工次數、PR 週期、AI 首次成功率），整理成內部分享
- 長期：以試點數據說服團隊，逐步將 SDD 推廣為全團隊的標準交付流程
1 / 8