# Gemini CLI X Spec Kit 重新定義 AI 協作開發

> 📌 Slido 📌
> https://app.sli.do/event/vXaidSP2HRPvC3MwYvSCgP

## 為什麼是終端機？開發者的「主場」與 AI 新戰場
- 開發者的主場
- 突破 GUI 限制
- AI 革新開發流程

### 為什麼選擇 Gemini CLI？
- 免費額度：使用個人帳戶，每分鐘 60個請求，每天 1000個請求
- 強大的 Gemini 2.5 Pro：可存取百萬個 Token 的 context window
- 內建工具：Google 搜尋、檔案操作、網頁存取
- 可擴充：支援 MCP 以實現自訂整合
- 終端優先：專為習慣使用命令列進行開發的開發者而設計
- 開源：採用 Apache 2.0 授權
- ReAct 推理框架：採用「推理與行動」循環框架，AI 能規劃行動策略、執行任務、觀察結果並動態調整方法

### 進階功能與擴充性
- GEMINI.md 專案設定
- Agent markdown 設定文件
- 定義專案特定的規則、編碼規範與 AI 行為模式
- MCP 協定整合
- 模型上下文協定（MCP）讓您連接外部 API 與專用模型，大幅擴展功能範圍。
- 例如透過 Jira MCP 工具，直接讓 AI 存取專案管理中的各項任務資訊，以避免常常進行視窗切換
- 腳本自動化
- 支援腳本話操作與自動化流程，無縫整合至現有的開發工作流程中。

## 規格驅動開發 SDD

### 傳統開發的痛點：模糊需求與 AI 開發挑戰
- AI 生成困境
- AI 生成的程式碼常常「看似正確卻無法運作」，缺乏明確指令導致反覆修改與時間浪費。
- 規格文件失效
- 傳統**規格文件**經常被忽略或**過時**，造成**團隊溝通不一致**與**理解落差**
- 若直接看卡片解決問題，而不是確認產品規格文件（可能會更動），開發與需求會有落差。
- Vibe Coding 現象
- AI 像搜尋引擎般猜測開發者意圖，無法精準理解真正的需求與商業邏輯。
- Vibe coding 比較適合作為 PoC 工具 [name=講者]

### 什麼是 Spec Driven Development（SDD）
#### 核心概念
- 先撰寫清晰、結構化的規格 (specification)，成為開發過程中的唯一真相來源與決策依據
- 規格不只是靜態文件，而是活得、可執行的工件，隨著專案演進持續更新與調整
- 規格可以版控的優點是可以追蹤規格的變化、更動的歷程 [name=講者]
- 以規格驅動設計、實作、測試與文件，確保整個開發流程的一致性、可追溯性與高品質交付

#### SDD 的三大優勢
- 消除猜測
- 明確的規格讓 AI 不必盲目推測需求細節，大幅減少錯誤與返工次數，提升開發準確度。
- 快速迭代
- 修改規格比直接改程式碼更簡單快速，促進敏捷開發與靈活應變能力。

- 知識集中管理
- 規格成為團隊共用的智慧資產與知識庫，大幅提升跨團隊溝通效率與協作品質。

#### 適用場景與實際效益

- 新專案啟動
- 僅需 30-60 分鐘撰寫初始規格，即可快速產出多種技術方案比較與評估，加速決策流程
- 快速驗證商業概念可行性
- 降低初期投入風險
- 現有系統新增功能
- 明確定義功能整合點與測試要求，降低對現有系統的蟲及風險，確保穩定性。
- 清楚的介面定義與邊界
- 完整的回歸測試計劃
- 遺留系統現代化
- 捕捉核心業務邏輯與規則，制訂分階段重構計畫，降低大規模改造的技術債與業務衝擊。
- 保留業務知識不流失
- 漸進式技術升級策略

#### 產業趨勢與工具生態
- 主流工具崛起
- GitHub Spec Kit、AWS Kirol 等專業工具正在推動 SDD 方法論的普及與標準化，降低採用門檻
- AI 角色轉變
- AI 不再只是簡單的代碼生成器，而是能夠依據規格精準執行的智慧開發夥伴與協作者。
- 全生命週期覆蓋
- 規格成為軟體完整生命週期的核心資產，從需求設計到長期維護階段接能持續受益。

## Spec Kit
> 由 GitHub 推出的 SDD 工具
> https://github.com/github/spec-kit

### Spec Kit 的四大步驟
- `/specify`
- 聚焦使用者需求與成功標準，清楚描述「做什麼」與「為何做」，建立共識基礎
- `/plan`
- 決定技術棧、系統架構與限制條件，行程可以執行的實施計劃
- `/tasks`
- 將規格與計劃分解成可獨立實作與測試的小型任務單元
- `/implement`
- AI 根據任務規格逐步生成程式碼，開發者專注於審查與品質調整。

> SDD 是 Vibe Coding 的進階版 [name=講者]

#### Spec Kit 的指令

- `/speckit.constitution` 建立專案原則: 做憲章
- initial 的時候作一次
- `/speckit.specify` 建建立規格（如三層）
- `/speckit.plan` 建立技術實作計畫
- `/speckit.tasks` 拆解為任務
- `/speckit.implement` 執行實作（在task切好後的虛擬實作）

> 以下三個非流程中必要的指令，有會更好：([link](https://github.com/github/spec-kit?tab=readme-ov-file#2-establish-project-principles))
- `/speckit.clarify` 釐清規格中未明確的區塊（找到遺漏需要補上的並且附上check讓你檢驗）
- `/speckit.checklist` 產生自訂品質檢查清單，驗證需求的完整性、清晰度與一致性：條列式的好處可以迅速理解做了什麼事情。
- 逐步幫你確認每項任務是否完成 (e.g., 完成就打勾)
- `/speckit.analyze` 跨產物一致性與覆蓋度分析

### 補充分享工具：OpenSpec
> 另外一套 SDD 工具
> https://github.com/Fission-AI/OpenSpec

實際情況分享：
- Spec Kit 比較適合從 0 到 1 開發，OpenSpec 比較適合從 1 到 100 開發
- Spec Kit 規則比較多，每一步都要照他的規範走，比較沒辦法讀完既有的專案程式碼，不夠彈性
- OpenSpec 只要一兩個指令就可以實作
- SDD 也不適合一次把需求放太大
- 需求仍然需要小部分地逐步拆解
- speckit 版本還沒到 1.0 版，仍在開發中
- 早期沒有 Spec Kit 時先產文件，另外有版控機制，一樣可以做到規格驅動開發
- 早期還沒有 SDD 工具時，會透過撰寫文件並採用版控來紀錄，可以得知文件前後差異及改動目的
- 規格文件成為開發中心

### SDD 方法論的優缺點

* 今天的分享主題是要跟大家說明優缺點，唯獨在與助手的對話上，要去釐清是否相信，同步也要再給自己放大學習的機會與功力。
* 產出的東西要 review 過，確保程式碼內容
* 仍需要一定的基本功(redis、mq...)，才能駕馭 speckit，開發出良好的系統
* 規格驅動開發一樣要把顆粒度縮小