線上課程
技術文章
平台介紹

Mike

22 Sept, 2025

Spec Kit 指令快速打造 SDD 規格驅動開發文件使用指南 !

在 Vibe Coding 開發的時代，我們經常遇到一個問題是給 AI 一個模糊的描述，它卻產生了完全不符合期望的程式碼，然而 GitHub 推出的 Spec Kit 透過規格驅動開發（Spec-Driven Development, SDD），徹底解決了這個問題。

今天我要跟大家分享 Spec Kit 的其中常用到的指令：/constitution、/specify、/plan、/tasks、/implement，以及如何運用它們建立一套完整的開發流程。

什麼是 Spec Kit 指令？

Spec Kit 將傳統「丟一句話給 AI 然後祈禱」的模式，轉變為結構化的幾個階段流程：

為什麼需要分階段？

傳統 Vibe Coding 開發流程的問題：

 

Spec Kit 的開發流程：

 

核心概念

/constitution 建立開發約束的憲法

/constitution 制定以程式碼品質、使用者體驗一致性和效能要求為重點的原則，並納入如何指導這些原則的技術決策和實施選擇的治理機制，以及參照該技術的最佳實踐進行開發，使用 JavScript ES6+ 的版本，所有專案文件、註解、README 檔案必須使用正體中文撰寫；程式碼變數和函數命名使用英文，但註解必須使用正體中文；錯誤訊息和使用者介面文字使用正體中文；API 文件和技術規格使用正體中文說明。

# [專案名稱] 專案憲章

## 核心原則

### I. 程式碼品質優先
所有程式碼必須遵循最佳實踐和編碼標準；使用 ESLint 和 Prettier 進行程式碼規範檢查；所有功能必須有對應的單元測試；程式碼審查是必要的，不得跳過；重構優於新增技術債務。

**理由**: 高品質的程式碼確保專案的長期維護性和擴展性，減少錯誤和開發成本。

### II. 使用者體驗一致性
所有使用者介面元件必須遵循統一的設計系統；互動模式在整個應用程式中保持一致；響應式設計確保在所有裝置上的最佳體驗；無障礙設計遵循 WCAG 2.1 AA 標準；使用者回饋和載入狀態必須清晰可見。

**理由**: 一致的使用者體驗提升使用者滿意度，降低學習成本，增強品牌認知。

### III. 效能要求 (不可協商)
頁面首次載入時間必須在 3 秒內完成；互動響應時間不得超過 100 毫秒；Lighthouse 效能評分必須達到 90 分以上；實施程式碼分割和懶載入優化；圖片和靜態資源必須經過最佳化處理。

**理由**: 優秀的效能直接影響使用者體驗和 SEO 排名，是商業成功的關鍵因素。

### IV. 技術標準
使用 JavaScript ES6+ 語法；模組化架構，每個功能獨立可測試；API 設計遵循 RESTful 原則；使用現代化的建構工具 (Vite)。

**理由**: 統一的技術標準確保團隊協作效率和程式碼一致性。

### V. 文件與註解規範
所有專案文件、README 檔案必須使用正體中文撰寫；程式碼變數和函數命名使用英文；程式碼註解必須使用正體中文；錯誤訊息和使用者介面文字使用正體中文；API 文件和技術規格使用正體中文說明。

**理由**: 統一的語言規範確保團隊溝通效率和文件可讀性。

## 技術決策治理

### 架構決策記錄
重大技術決策必須記錄在 `docs/architecture/` 目錄中；每個決策記錄包含背景、選項評估、決定和後果；決策變更需要新的記錄文件，不得直接修改舊記錄。

### 依賴管理
新增外部依賴必須經過安全性和效能評估；優先選擇活躍維護且社群支援良好的套件；定期更新依賴版本並進行安全性掃描；避免引入不必要的大型依賴庫。

### 效能監控
實施效能監控和指標追蹤；建立效能回歸測試；定期進行效能分析和最佳化；設定效能預算和警報機制。

## 開發流程與品質保證

### 程式碼審查流程
所有程式碼變更必須經過 Pull Request 審查；審查重點包含功能正確性、程式碼品質、效能影響和安全性；至少需要一位團隊成員的批准；自動化測試必須通過才能合併。

## 治理

憲章優先於所有其他開發實踐；憲章修改需要團隊討論、批准和遷移計畫；所有 Pull Request 和程式碼審查必須驗證憲章合規性；複雜性增加必須有充分理由；使用 `AGENTS.md` 檔案提供執行期間的開發指導。
  • /constitution 重要性
  1. 約束 AI 行為：防止 AI 偏離專案標準
  2. 確保一致性：所有功能都遵循相同原則
  3. 提高品質：建立不可妥協的品質標準
  4. 團隊協作：統一開發標準和期望

/specify 的目標是完全避免技術細節，專注於使用者需求和商業價值。

舉例來說，如果你想建立一個「 個人記帳 APP 」 為例：

/specify 建立個人記帳 APP

## 目標使用者：個人用戶，想要簡單追蹤日常支出

## 核心問題：現有記帳工具太複雜，使用者需要一個更簡單的解決方案

## 主要功能：
1. 快速記錄收入和支出
2. 按類別分類（食物、交通、娛樂等）
3. 查看每月支出統計
4. 設定預算提醒

## 使用者操作：
1. 開啟應用 → 看到主畫面
2. 點擊「新增」→ 選擇收入/支出
3. 輸入金額和類別 → 快速儲存
4. 查看統計圖表 → 了解消費習慣

## 成功標準：
- 記錄一筆支出在 30 秒內完成
- 支援離線使用

## 範圍外：
- 不做投資理財功能
- 不支援多人協作
- 不包含銀行帳戶連結
  • /specify 寫作技巧
  1. 使用具體數字：例如說 記錄一筆支出在 30 秒內完成 而非 要很快給我完成
  2. 明確定義使用者：個人用戶，想要簡單追蹤日常支出 而非 給所有人使用
  3. 說明商業價值：解釋為什麼需要這個功能
  4. 設定可測量標準：用數字和時間量化成功標準

/plan 指令：制定「如何」實作

/plan 指令根據 /specify 階段的需求，制定具體的技術方案和架構設計。

/plan 個人記帳應用技術實作方案

## 技術架構：
- 前端：Vue.js 3 + Vite 單頁應用
- 資料儲存：本地 IndexedDB
- 圖表：Chart.js 視覺化統計
- PWA：支援離線使用和安裝

## 介面設計原則：
- 極簡風格：主畫面只顯示「新增」按鈕和當月總計
- 一鍵操作：常用分類放在首頁快速按鈕
- 視覺化優先：用圓餅圖和柱狀圖顯示統計

## 安全考量：
- 本地資料加密儲存
- 雲端同步使用 JWT 認證
- 敏感資料不記錄在日誌

**部署策略**：
- 靜態網站部署 Zeabur
- PWA 自動更新機制
- 錯誤監控和分析
  • /plan 寫作重點
  1. 技術要有詳細：例如說 圖表 : Chart.js 視覺化統計 而非 圖表 : 使用第三方圖表套件
  2. 考慮非功能需求：效能、安全、擴展性
  3. 具體的技術規格：資料模型、API 設計、架構圖

/tasks ：分解為可執行步驟

/tasks 指令將規格和計劃分解為獨立的、可測試的小任務，每個任務在 2-4 小時內完成。

/tasks 將上述規格和計劃分解為具體開發任務

## 每個任務應該：
- 有明確的驗收標準  
- 可以獨立測試
- 標記並行任務 [P]
  • /tasks 分解原則
  1. 時間控制：每個任務 2-4 小時完成
  2. 獨立性：任務可以單獨開始和測試
  3. 依賴明確：清楚標示任務間的依賴關係
  4. 並行標記：用 [P] 標記可並行執行的任務
  5. 驗收明確：每個任務都有具體的完成標準

每個指令使用流程

  1. 專案初始化
    specify init my-project --ai claude
  2. 建立新功能，在 AI 工具中執行每個階段的指令
    /constitution  →  /specify  →  /plan  →  /tasks
  3. 按照任務清單開始實作
    /implement specs/001-expense-tracker/plan.md

 

常見錯誤與避免方法

Specify 階段常見錯誤

// bad
過於技術化：「使用 Vue.js 建立 SPA 應用」
// good
專注需求：「讓使用者快速記錄日常支出」

// bad
模糊描述：「要有好的使用者體驗」
// good
具體標準：「記錄一筆支出在 30 秒內完成」

Plan 階段常見錯誤

// bad
忽略非功能需求：只考慮功能實作
// good
全面考慮：效能、安全、可維護性、擴展性

Tasks 階段常見錯誤

// bad
任務太大：「實作完整的前端功能」（需要20小時）
// good
適當切割任務：「實作交易記錄新增功能」（3小時）

// bad
指向不清楚：請按照任務執行
// good
明確指示：「請按照 specs/001-expense-tracker/plan.md 執行任務 」

支援的 AI 工具

這三個指令不僅限於特定的 AI 工具，可以在多種 AI 輔助開發工具中使用：

  • Cursor
  • Claude Code
  • GitHub Copilot
  • ChatGPT
  • 其他 AI 工具：只要支援對話或指令功能的 AI 工具都可以採用這套方法

重點是指令的結構化思維，而不是特定的工具。即使在不直接支援這些指令的 AI 工具中，你也可以用相同的格式來組織你的需求描述。

總結！

Spec Kit 的三階段指令不只是工具，更是一種思維模式的轉變。透過 /constitution、/specify、/plan、/tasks、/implement 的結構化流程，我們可以：

  • 確保 AI 理解真正的需求：而不是基於猜測寫 Code
  • 建立可維護的系統架構：而不是隨意拼湊功能
  • 控制專案複雜度：將大問題分解為小任務

下次當你要開始一個新專案或新功能時，試試用這三個指令來規劃吧！你會發現開發過程變得更有條理，結果也更符合期望。

記住：好的規格是成功專案的一半，而 Spec Kit 就是幫助我們寫出好規格的最佳工具。