透過規格驅動開發 (SDD) 解決 AI 漂移

在目前的 AI 輔助編碼領域，開發者經常發現自己必須同時應對多種工具——Claude Code、Cursor、GitHub Copilot 和 Windsurf——來構建單一功能。雖然這些工具在技術上令人印象深刻，但一個重複出現的問題也隨之而來：AI 漂移。你可能會要求 Claude 構建一個功能，接著在要求 Cursor 修復錯誤時，它卻與該實作產生矛盾，而 Copilot 在清理程式碼時又會發明第三種解釋。

其根本原因在於缺乏一個共享的真相來源。如果沒有一個中心化的規格說明，每個 AI agent 都會根據自己的假設來填補指令中的空白。為了瞭解這個問題，一個新的 Claude skill 針對規格驅動開發 (SDD) 發布了，旨在強制 AI agent 在編寫任何一行程式碼之前，先針對一組治理文件進行對齊。

核心框架：三個真相來源

SDD 的運作原則是規格必須先於實作。該 skill 會引導 Claude 與開發者進行訪談，並生成三個主要文件，作為專案的「憲法」：

requirements.md：定義系統必須做什麼。它使用正式的「shall」語言和唯一的 ID（例如 REQ-001）來確保每個功能都是可追溯的。
design.md：定義系統將如何被構建，涵蓋架構和數據模型。
tasks.md：一個原子化、有序的實作計畫，其中每個任務都連結回特定的需求。

透過優先建立這些文件，開發者建立了一個硬性門檻。AI 工具被指示在接觸程式碼之前必須完整閱讀這些文件，有效地阻止了因 agent 假設分歧而導致的漂移。

跨 AI 同步

SDD skill 最強大的面向之一是它能夠生成特定工具的配置檔，而這些配置檔都指向同一個通用的指令。

Tool	Config File
Claude Code	`CLAUDE.md`
Cursor	`.cursorrules`
Windsurf	`.windsurfrules`
GitHub Copilot	`.github/copilot-instructions.md`
Aider	`.aider.conf.yml`

這些文件中的每一個都包含一個通用指令區塊 (Universal Instruction Block)。該區塊強制要求 AI 必須在採取任何行動之前閱讀需求、設計和任務文件，並建立了一個「分歧協定 (Divergence Protocol)」：如果實作必須偏離設計，AI 必須立即停止，描述衝突，並等待使用者對更新設計文件獲得批准後才能繼續。

處理現有程式碼庫

SDD 不僅適用於新專案 (greenfield projects)。對於現有的程式碼庫，該 skill 會執行「改造 (retrofit)"。它會對目前的程式碼狀態進行逆向工程，以生成 v0-retrofit 版本的需求和設計文件。至關重要的是，設計文件會在推論的欄位上標記 [TO VERIFY]，強制開發者在添加新功能之前，先驗證 AI 對現有架構的理解。

嚴格的驗證與測試

與許多 AI prompt 或「skill」不同，這個框架由一套完整的測試套件支持。該專案包含三個階段的 130 個斷言 (assertions)：

靜態斷言 (Phase 2A)：64 項檢查以確保生成文件的結構完整性。
行為測試 (Phase 2B)：13 項實時會話測試，以驗證 AI 對 SDD 流程的遵循程度。
生成品質 (Phase 2C)：53 項針對已提交的 fixtures 的檢查，以確保輸出的一致性。

這種測試優先的方法確保了 skill 本身不會引入它試圖解決的不穩定性。

批判性觀點與限制

雖然框架提供了一個穩健的結構，但社群對其擴展性提出了重要的考量。一位評論者指出，隨著 requirements.md 和 tasks.md 的文件的內容增加，它們可能會消耗大量的上下文窗口 (context window) 空間，進而可能導致「上下文腐敗 (context rot)」並增加在大型程式碼庫中產生幻覺的可能性。

此外，該專專案目前處於公開測試階段 (public beta)，正在尋找各種背景的測試者——從完全的初學者到使用多種 AI 工具的團隊領導——來完善該 skill 如何處理自然語言觸發器和複雜的真實世界工作流。

防止的錯誤模式總結

透過強制執行規格優先的工作流，SDD 主動防止了幾種常見的 AI 編碼陷阱：

「直接開始編碼」的陷阱：當使用者試圖跳過規劃階段時，skill 會予以回絕。
模糊性偽造：AI 不被允許猜測模糊的需求，而是被強制要求尋問澄清。
範圍蔓延 (Scope Creep)：未列在 requirements.md 中的功能會被標記為超出範圍，防止 AI 添加不必要的複雜性。