✓ 效益 1：AI 輸出可預測
AI 不再基於模糊的聊天歷史生成程式碼，而是根據清晰的規格實現。減少 40% 的返工和修改，大幅提升開發效率。
✓ 效益 2：需求明確化
在寫程式前，通過結構化規格明確定義系統應該做什麼，消除團隊間的歧義和誤解。規格迭代比程式碼迭代快 10 倍。
✓ 效益 3：多工具無縫協作
適用於 Claude Code、Cursor、CodeBuddy、Cline 等 15+ 種 AI 程式設計工具。團隊成員使用不同工具，但共享同一規格庫。
✓ 效益 4：既有系統也能用
專為棕地專案設計。無需重構既有程式碼，只需逐步為新功能建立規格，既有規格持續累積成為知識沉澱。
✓ 效益 5：輕量級無依賴
5 分鐘完成初始化，無需 API 金鑰或訂閱費。完全開源（MIT 授權），所有規格檔案存儲在本地 Git 倉庫。
基礎概念
Q1. OpenSpec 和傳統 Markdown 文件有什麼區別？
傳統文件：靜態敘述，與程式碼分離，容易過時。
OpenSpec：結構化規格，與 Git 版本控制整合，規格變更和程式碼變更同步，能自動驗證格式，支持 AI 工具直接解析和操作。
Q2. OpenSpec 適合小型團隊還是大型組織？
兩者都適合。小型團隊（1-5人）用 OpenSpec 可消除對話歧義；大型組織（50+人）用 OpenSpec 可規範跨團隊協作。OpenSpec 的輕量級特性讓它在任何規模都有價值。
Q3. 我已有既有系統，可以用 OpenSpec 嗎？
完全可以。OpenSpec 專為棕地專案設計。你無需重構既有程式碼，只需：(1) 執行 openspec init (2) 逐步為新功能建立規格 (3) 既有規格持續累積。
Q4. OpenSpec 需要持續付費或訂閱嗎？
完全免費。OpenSpec 是開源專案（MIT 授權），不需要 API 金鑰、訂閱費或雲服務費用。所有規格檔案存儲在本地 Git 倉庫。
Q5. 哪些 AI 工具原生支援 OpenSpec？
15+ 種工具原生支援：Claude Code、Cursor、CodeBuddy、Cline、Crush、Factory Droid、OpenCode、Kilo Code、Qoder、Windsurf、Codex、GitHub Copilot、Amazon Q Developer、Auggie、Qwen Code。其他工具通過 AGENTS.md 相容。
規格設計
Q6. 規格應該寫多詳細？
關鍵原則：足以讓 AI 理解需求，但無需完全規範。通常包括：需求敘述、3-5 個場景（Given-When-Then 格式）。不需要每個邊界條件都寫，AI 會根據規格推導實現細節。
Q7. 如何區分 ADDED、MODIFIED、REMOVED 規格增量？
ADDED：新功能（如「兩步驟驗證」）。
MODIFIED：改變既有行為，需寫完整的更新後文本。
REMOVED：廢除功能。
例：新增郵件通知功能 → ADDED；改變登入流程 → MODIFIED。
Q8. 規格和設計文件是什麼關係？
規格定義「應該做什麼」，設計定義「怎麼做」。OpenSpec 的 design.md 是可選的，用於記錄架構決策。規格優先級更高，設計是補充。例如規格說「支援 OAuth」，設計可說「使用 Auth0 服務」。
工作流程
Q9. 標準的 OpenSpec 工作流有幾步？
5 步：
1. 起草提案（proposal.md）
2. 審查和對齊（反覆編輯規格）
3. 實現任務（AI 根據 tasks.md 寫程式碼）
4. 歸檔變更（自動合併規格）
5. 持續維護（規格成為源頭真值）
Q10. 能否同時進行多個變更？
可以，但要小心衝突。OpenSpec 的 changes/ 目錄可同時包含多個變更（如 add-2fa、fix-login-bug、optimize-database）。建議：
• 獨立的功能可平行進行
• 如果涉及同一規格，應序列化（一個完成後再開始下一個）
• 歸檔前驗證沒有規格衝突
Q11. 規格審查應該關注哪些重點？
審查清單：
• 需求是否清晰明確？
• 場景是否涵蓋主流程和邊界情況？
• 是否有衝突或重複？
• 是否遺漏非功能性需求（效能、安全性）？
• AI 能否理解並實現這個規格？
Q12. 如何避免規格和程式碼不同步？
核心機制：歸檔時自動合併。當運行 openspec archive change-name 時，OpenSpec 自動將 changes/change-name/specs/* 合併回 specs/*。這確保規格始終反映已實現的功能。
技術細節
Q13. OpenSpec 檔案結構是什麼？
典型結構：
Q14. 如何在不同 AI 工具間共享規格？
OpenSpec 設計支援多工具協作。AGENTS.md 是標準手冊，所有工具都能讀取。若某工具有原生支援（如 Claude Code 的 /openspec:proposal），會自動啟用斜杠指令。若無原生支援（如 GitHub Copilot），可用自然語言要求 Copilot「建立 OpenSpec 提案」。
Q15. OpenSpec 能和其他 CI/CD 系統整合嗎？
可以。OpenSpec 的結構基於 Git，所以能整合到任何 Git 流程：
• GitHub Actions：驗證規格格式
• Pre-commit hooks：檢查規格和程式碼同步
• Code review：規格 PR 應與程式碼 PR 同時進行
團隊和企業應用
Q16. 大型團隊應如何組織 OpenSpec？
建議分層管理：
• 全公司共用 specs/（核心系統規格）
• 團隊級 specs/ 子目錄（domain-driven）
• 個人 AI 工具配置各自保存
例：openspec/specs/payment/spec.md（支付團隊）、openspec/specs/auth/spec.md（身份驗證團隊）
Q17. 新加入團隊成員如何快速上手？
流程：
1. Clone 倉庫，執行 openspec update
2. 閱讀 openspec/project.md（項目背景和約定）
3. 閱讀相關 specs/（理解系統設計）
4. 查看 archive/（學習過往變更決策）
Q18. 規格評審流程應該正式到什麼程度？
靈活調整：
• 小型團隊：Slack 審查 + 快速迭代
• 中型團隊：Pull Request 審查 + 兩人簽核
• 大型團隊：正式審查會 + 利益相關者簽核
核心原則：規格必須經過「人類審查」，不能直接 AI 生成後就實現。
進階和最佳實踐
Q19. 如何處理跨規格的複雜變更？
OpenSpec 的優勢所在。例如「整合支付系統」可能涉及 payment/spec.md、auth/spec.md、user/spec.md：
1. 單一變更資料夾 openspec/changes/integrate-payment/
2. 其 specs/ 子目錄包含所有受影響的規格增量
3. 單個 tasks.md 列出全部任務
4. 歸檔時自動合併所有規格，無遺漏
Q20. OpenSpec 該如何與持續迭代和敏捷相結合？
完全相容。OpenSpec 能適應任何開發模式：
• Sprint：每週的用戶故事轉換為 OpenSpec 提案
• Kanban：變更在 proposal → implementation → archive 中流轉
• 連續部署：規格驗證後即可快速實現和發布
規格成為 Backlog 的結構化版本，提升可追蹤性。