用規範驅動開發（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 的有用標尺。