用規範驅動開發（SDD）阻止 AI 毀掉你的程式碼庫

AI 程式設計助手正在改變開發方式，但它們也帶來了新的問題：輸出不穩定、範圍蔓延、規則遺忘。當團隊依賴 AI 進行多迭代、多開發者協作時，這些問題會被放大。規範驅動開發（Spec-Driven Development，SDD）提供了一種解決方案：將人類從逐行審查者轉變為規則定義者，讓 AI 在清晰的約束下執行。

SDD 的核心思想是前置規範工作。在編寫程式碼之前，團隊需要建立三種文件：Spec 文件定義構建什麼和不碰什麼，Design 文件鎖定技術方案，Tasks 檔案將工作分解為可驗證的小塊。AI 在這些護欄內執行，而不是即興發揮。這種方法減少了 AI 幻覺和範圍蔓延，使輸出更加可預測。

OpenSpec 是一個輕量級工具，透過 /opsx 命令集（propose, apply, sync, archive）實現 SDD 工作流。它生成和管理規範、設計和任務文件，並支援 MCP（模型上下文協議）伺服器。MCP 協議讓 AI 程式設計工具直接連線到 Figma、Yapi 和內部維基等外部資料來源，從而在生成初始 Spec 時自動獲取相關上下文，避免了手動複製貼上的錯誤。

在程式碼生成後，還有三層約束系統來捕獲剩餘的偏差：Skills（技能）編碼團隊的編碼習慣，分為底層（通用規則如“先思考再編碼”）和頂層（專案特定架構和命名習慣）；AGENTS.md 檔案作為 AI 工具的入門手冊，包含穩定的專案級規則，如目錄結構和禁止觸碰的區域；Hooks（鉤子）則在生命週期事件中強制執行硬約束，例如 PostToolUse 鉤子可以拒絕包含硬編碼中文字串的檔案。

歸檔完成變更是 SDD 中最被低估的步驟。透過 /opsx:archive，團隊可以儲存已確認的邊界、放棄的設計路徑和發現的陷阱，形成專案知識庫。這樣，下一次 AI 會話就能繼承之前的積累，邊際協作成本逐漸降低。經驗法則是：任何預計超過兩天的工作都值得編寫 Spec，而簡單的樣式調整或一次性指令碼則不需要。

總的來說，SDD 的核心轉變不是工具，而是將人類從程式碼審查者轉變為規範作者。AI 成為執行者而非協作者。只有 Hooks 能阻止不合規輸出，使規則真正生效。歸檔是打破重複錯誤的關鍵。MCP 整合使 SDD 在規模上實用，而兩天啟發式法則是判斷是否編寫 Spec 的有用標尺。