規格驅動開發（Specification-Driven Development, SDD）
權力倒置
幾十年來，程式碼一直是王者。規格說明為程式碼服務——它們是我們搭建然後在「真正的編碼工作」開始後就丟棄的鷹架。我們編寫產品需求文件（PRD）來指導開發，建立設計文件來指導實施，繪製圖表來視覺化架構。但這些總是從屬於程式碼本身。程式碼即真理。其他一切充其量只是良好的意圖。程式碼是真相的源頭，隨著它不斷前進，規格說明很少能跟上步伐。由於資產（程式碼）與實作是一體的，如果不嘗試從程式碼建構，就很難有並行的實作。
規格驅動開發（SDD）顛覆了這種權力結構。規格說明不為程式碼服務——程式碼為規格說明服務。產品需求文件（PRD）不是實作的指南，而是產生實作的源頭。技術計劃不是指導編碼的文件，而是產生程式碼的精確定義。這不是對我們建構軟體方式的漸進式改進，而是對驅動開發的根本性重新思考。
規格說明與實作之間的鴻溝自軟體開發誕生以來就一直困擾著它。我們試圖透過更好的文件、更詳細的需求、更嚴格的流程來彌合這一鴻溝。這些方法都失敗了，因為它們接受鴻溝是不可避免的。它們試圖縮小鴻溝，但從未消除它。SDD 透過使規格說明及其從規格說明中衍生出的具體實施計劃可執行來消除鴻溝。當規格說明和實施計劃產生程式碼時，就沒有鴻溝——只有轉化。
這種轉化現在成為可能，是因為 AI 可以理解和實作複雜的規格說明，並建立詳細的實施計劃。但是沒有結構的原始 AI 產生會造成混亂。SDD 透過足夠精確、完整和明確的規格說明以及後續實施計劃來提供這種結構，從而產生可運作的系統。規格說明成為主要產物。程式碼成為它在特定語言和框架中的表達（作為實施計劃的實作）。
在這個新世界中，維護軟體意味著演化規格說明。開發團隊的意圖用自然語言（「意圖驅動開發」）、設計資產、核心原則和其他指南來表達。開發的通用語言提升到更高層次，程式碼成為最後一哩的方法。
除錯意味著修復產生錯誤程式碼的規格說明及其實施計劃。重構意味著為了清晰性而重新建構。整個開發工作流圍繞規格說明作為核心真相源頭重新組織，實施計劃和程式碼作為持續重新產生的輸出。用新功能更新應用程式或建立新的並行實作（因為我們是有創造力的生命體），意味著重新審視規格說明並建立新的實施計劃。因此，這個過程是 0 -> 1, (1', ..), 2, 3, N。
開發團隊專注於他們的創造力、實驗和批判性思維。
SDD 工作流實踐
工作流從一個想法開始——通常是模糊和不完整的。透過與 AI 的迭代對話，這個想法成為一個全面的 PRD。AI 提出澄清問題，識別邊緣案例，並幫助定義精確的驗收標準。在傳統開發中可能需要數天的會議和文件工作，在專注的規格說明工作中只需幾個小時就能完成。這改變了傳統的軟體開發生命週期（SDLC）——需求和設計成為持續的活動，而不是離散的階段。這支援團隊流程，團隊審查的規格說明被表達和版本控制，在分支中建立並合併。
當產品經理更新驗收標準時，實施計劃會自動標記受影響的技術決策。當架構師發現更好的模式時，PRD 會更新以反映新的可能性。
在整個規格說明過程中，研究代理收集關鍵上下文。它們調查函式庫的相容性、效能基準和安全影響。組織約束被自動發現和應用——你公司的資料庫標準、身分驗證要求和部署策略無縫整合到每個規格說明中。
從 PRD 開始，AI 產生將需求映射到技術決策的實施計劃。每個技術選擇都有記錄的理由。每個架構決策都追溯到特定的需求。在整個過程中，一致性驗證持續提高品質。AI 分析規格說明的歧義、矛盾和差距——不是作為一次性的門控，而是作為持續的改進。
一旦規格說明及其實施計劃足夠穩定，程式碼產生就會開始，但它們不必「完整」。早期產生可能是探索性的——測試規格說明在實踐中是否有意義。領域概念成為資料模型。使用者故事成為 API 端點。驗收場景成為測試。這透過規格說明合併了開發和測試——測試場景不是在程式碼之後編寫的，它們是產生實作和測試的規格說明的一部分。
回饋循環延伸到初始開發之外。生產指標和事件不僅觸發熱修復——它們為下一次重新產生更新規格說明。效能瓶頸成為新的非功能需求。安全漏洞成為影響所有未來產生的約束。規格說明、實作和營運現實之間的這種迭代舞蹈是真正理解出現的地方，也是傳統 SDLC 轉變為持續演化的地方。
為什麼 SDD 現在很重要
三個趨勢使 SDD 不僅成為可能，而且成為必要：
首先，AI 能力已經達到了自然語言規格說明可以可靠產生可運作程式碼的閾值。這不是要取代開發人員——而是透過自動化從規格說明到實作的機械轉換來放大他們的效能。它可以放大探索和創造力，輕鬆支援「重新開始」，並支援新增、刪減和批判性思維。
其次，軟體複雜性繼續呈指數級成長。現代系統整合了數十個服務、框架和相依性。透過手動流程使所有這些部分與原始意圖保持一致變得越來越困難。SDD 透過規格驅動的產生提供系統化的對齊。框架可能會演化以提供 AI 優先支援，而不是人類優先支援，或圍繞可重用元件進行架構設計。
第三，變化的速度在加快。今天的需求變化比以往任何時候都快得多。轉型不再是例外——而是預期。現代產品開發要求基於使用者回饋、市場條件和競爭壓力進行快速迭代。傳統開發將這些變化視為干擾。每次轉型都需要手動將變化傳播到文件、設計和程式碼中。結果要麼是緩慢、謹慎的更新限制了速度，要麼是快速、魯莽的變化累積了技術債務。
SDD 可以支援假設/模擬實驗：「如果我們需要重新實作或更改應用程式以促進銷售更多 T 恤的業務需求，我們將如何實施和實驗？」
SDD 將需求變化從障礙轉變為正常工作流。當規格說明驅動實作時，轉型變成系統化的重新產生，而不是手動重寫。更改 PRD 中的核心需求，受影響的實施計劃會自動更新。修改使用者故事，相應的 API 端點會重新產生。這不僅僅是關於初始開發——而是在不可避免的變化中保持工程速度。
核心原則
規格說明作為通用語言：規格說明成為主要產物。程式碼成為它在特定語言和框架中的表達。維護軟體意味著演化規格說明。
可執行規格說明：規格說明必須足夠精確、完整和明確，以產生可運作的系統。這消除了意圖與實作之間的鴻溝。
持續改進：一致性驗證持續進行，而不是作為一次性門控。AI 分析規格說明的歧義、矛盾和差距作為持續過程。
研究驅動的上下文：研究代理在整個規格說明過程中收集關鍵上下文，調查技術選項、效能影響和組織約束。
雙向回饋：生產現實為規格說明演化提供資訊。指標、事件和營運學習成為規格說明改進的輸入。
分支探索：從同一規格說明產生多個實作方法，以探索不同的最佳化目標——效能、可維護性、使用者體驗、成本。
實施方法
今天，實踐 SDD 需要組裝現有工具並在整個過程中保持紀律。該方法可以透過以下方式實踐：
- 用於迭代規格說明開發的 AI 助手
- 用於收集技術上下文的研究代理
- 用於將規格說明轉換為實作的程式碼產生工具
- 適應規格優先工作流的版本控制系統
- 透過 AI 分析規格說明文件進行一致性檢查
關鍵是將規格說明視為真相的源頭，程式碼作為服務於規格說明的產生輸出，而不是相反。
使用命令簡化 SDD
SDD 方法透過三個強大的命令得到顯著增強，這些命令自動化了規格說明 → 計劃 → 任務的工作流：
/speckit.specify 命令
此命令將簡單的功能描述（使用者提示）轉換為完整、結構化的規格說明，並自動進行倉儲管理：
- 自動功能編號：掃描現有規格以確定下一個功能編號（例如 001、002、003）
- 分支建立：從你的描述產生語義分支名稱並自動建立它
- 基於範本的產生：複製並使用你的需求自訂功能規格說明範本
- 目錄結構：為所有相關文件建立適當的
specs/[branch-name]/結構
/speckit.plan 命令
一旦功能規格說明存在，此命令建立一個全面的實施計劃：
- 規格說明分析：讀取並理解功能需求、使用者故事和驗收標準
- 憲法合規性：確保與專案憲法和架構原則保持一致
- 技術轉換：將業務需求轉換為技術架構和實施細節
- 詳細文件：為資料模型、API 合約和測試場景產生支援文件
- 快速入門驗證：產生捕獲關鍵驗證場景的快速入門指南
/speckit.tasks 命令
建立計劃後，此命令分析計劃和相關設計文件以產生可執行任務清單：
- 輸入：讀取
plan.md（必需）以及（如果存在）data-model.md、contracts/和research.md - 任務派生：將合約、實體和場景轉換為具體任務
- 並行化：標記獨立任務
[P]並概述安全的並行組 - 輸出：在功能目錄中寫入
tasks.md，準備由任務代理執行
示例：建構聊天功能
以下是這些命令如何改變傳統開發工作流：
傳統方法：
1. 在文件中編寫 PRD（2-3 小時）
2. 建立設計文件（2-3 小時）
3. 手動設定專案結構（30 分鐘）
4. 編寫技術規格說明（3-4 小時）
5. 建立測試計劃（2 小時）
總計：約 12 小時的文件工作使用命令的 SDD 方法：
# 步驟 1：建立功能規格說明（5 分鐘）
/speckit.specify 即時聊天系統，包含訊息歷史和使用者線上狀態
# 這會自動：
# - 建立分支 "003-chat-system"
# - 產生 specs/003-chat-system/spec.md
# - 用結構化需求填充它
# 步驟 2：產生實施計劃（5 分鐘）
/speckit.plan WebSocket 用於即時訊息傳遞，PostgreSQL 用於歷史記錄，Redis 用於線上狀態
# 步驟 3：產生可執行任務（5 分鐘）
/speckit.tasks
# 這會自動建立：
# - specs/003-chat-system/plan.md
# - specs/003-chat-system/research.md（WebSocket 函式庫比較）
# - specs/003-chat-system/data-model.md（訊息和使用者模式）
# - specs/003-chat-system/contracts/（WebSocket 事件、REST 端點）
# - specs/003-chat-system/quickstart.md（關鍵驗證場景）
# - specs/003-chat-system/tasks.md（從計劃派生的任務清單）在 15 分鐘內，你擁有：
- 包含使用者故事和驗收標準的完整功能規格說明
- 包含技術選擇和理由的詳細實施計劃
- 準備用於程式碼產生的 API 合約和資料模型
- 自動和手動測試的全面測試場景
- 所有文件都在功能分支中進行了適當的版本控制
結構化自動化的力量
這些命令不僅節省時間——它們還強制執行一致性和完整性：
- 不會遺忘細節：範本確保考慮每個方面，從非功能需求到錯誤處理
- 可追溯的決策：每個技術選擇都連結回特定需求
- 活文件：規格說明與程式碼保持同步，因為它們產生程式碼
- 快速迭代：在幾分鐘而不是幾天內更改需求並重新產生計劃
這些命令體現了 SDD 原則，將規格說明視為可執行的產物，而不僅僅是靜態文件。它們將規格說明過程從必要之惡轉變為開發的驅動力。
範本驅動的品質：結構如何約束 LLM 以獲得更好的結果
這些命令的真正力量不僅在於自動化，還在於範本如何引導 LLM 行為朝向更高品質的規格說明。範本充當複雜的提示，以富有成效的方式約束 LLM 的輸出：
1. 防止過早的實作細節
功能規格說明範本明確指示：
- ✅ 專注於使用者需要什麼和為什麼
- ❌ 避免如何實作（沒有技術堆疊、API、程式碼結構）這種約束迫使 LLM 保持適當的抽象層級。當 LLM 可能自然地跳到「使用 React 和 Redux 實作」時，範本使它專注於「使用者需要其資料的即時更新」。這種分離確保規格說明保持穩定，即使實作技術發生變化。
2. 強制顯式不確定性標記
兩個範本都要求使用 [NEEDS CLARIFICATION] 標記：
從使用者提示建立此規格時：
1. **標記所有歧義**：使用 [NEEDS CLARIFICATION: 具體問題]
2. **不要猜測**：如果提示沒有指定某些內容，請標記它這防止了 LLM 做出看似合理但可能不正確的假設的常見行為。LLM 必須將其標記為 [NEEDS CLARIFICATION: 未指定身分驗證方法 - 電子郵件/密碼、SSO、OAuth？]，而不是猜測「登入系統」使用電子郵件/密碼身分驗證。
3. 透過檢查清單進行結構化思考
範本包括充當規格說明「單元測試」的全面檢查清單：
### 需求完整性
- [ ] 沒有 [NEEDS CLARIFICATION] 標記
- [ ] 需求可測試且明確
- [ ] 成功標準可衡量這些檢查清單強制 LLM 系統地自我審查其輸出，捕獲可能會溜走的差距。這就像給 LLM 一個品質保證框架。
4. 透過門控實現憲法合規性
實施計劃範本透過階段門控強制執行架構原則：
### 階段 -1：實施前門控
#### 簡潔性門控（第七條）
- [ ] 使用 ≤3 個專案？
- [ ] 沒有面向未來的設計？
#### 反抽象門控（第八條）
- [ ] 直接使用框架？
- [ ] 單一模型表示？這些門控透過使 LLM 明確證明任何複雜性來防止過度工程。如果門控失敗，LLM 必須在「複雜性追蹤」部分記錄原因，為架構決策建立問責制。
5. 分層細節管理
範本強制執行適當的資訊架構：
**重要**：此實施計劃應保持高階且可讀性。
任何程式碼範例、詳細演算法或大量技術規格說明
必須放在適當的 `implementation-details/` 檔案中這防止了規格說明變成不可讀的程式碼傾印的常見問題。LLM 學會保持適當的細節層級，將複雜性提取到單獨的檔案中，同時保持主文件的可導覽性。
6. 測試優先思維
實施範本強制執行測試優先開發：
### 檔案建立順序
1. 使用 API 規格說明建立 `contracts/`
2. 按順序建立測試檔案：合約 → 整合 → e2e → 單元
3. 建立原始檔案以使測試通過這種排序約束確保 LLM 在實作之前考慮可測試性和合約，從而產生更健壯和可驗證的規格說明。
7. 防止投機性功能
範本明確反對投機：
- [ ] 沒有投機性或「可能需要」的功能
- [ ] 所有階段都有明確的先決條件和可交付成果這阻止 LLM 新增使實作複雜化的「最好有」功能。每個功能都必須追溯到具有明確驗收標準的具體使用者故事。
複合效應
這些約束共同作用以產生以下規格說明：
- 完整：檢查清單確保不會遺忘任何內容
- 明確：強制澄清標記突出不確定性
- 可測試：測試優先思維融入流程
- 可維護：適當的抽象層級和資訊層次
- 可實作：具有具體可交付成果的明確階段
範本將 LLM 從創意作家轉變為有紀律的規格說明工程師，引導其能力產生始終如一的高品質、可執行的規格說明，真正驅動開發。
憲法基礎：強制執行架構紀律
SDD 的核心是憲法——一套管理規格說明如何成為程式碼的不可變原則。憲法（memory/constitution.md）充當系統的架構 DNA，確保每個產生的實作保持一致性、簡潔性和品質。
開發的九條原則
憲法定義了塑造開發過程每個方面的九條原則：
第一條：函式庫優先原則
每個功能都必須首先作為獨立函式庫——沒有例外。這從一開始就強制模組化設計：
Specify 中的每個功能都必須從獨立函式庫開始其存在。
未經首先抽象為可重用的函式庫元件，任何功能都不得直接
在應用程式程式碼中實作。此原則確保規格說明產生模組化、可重用的程式碼，而不是單體應用程式。當 LLM 產生實施計劃時，它必須將功能建構為具有清晰邊界和最小相依性的函式庫。
第二條：CLI 介面強制
每個函式庫都必須透過命令列介面公開其功能：
所有 CLI 介面必須：
- 接受文字作為輸入（透過 stdin、參數或檔案）
- 產生文字作為輸出（透過 stdout）
- 支援 JSON 格式進行結構化資料交換這強制執行可觀察性和可測試性。LLM 不能將功能隱藏在不透明的類別中——一切都必須透過基於文字的介面可存取和可驗證。
第三條：測試優先命令
最具變革性的條款——程式碼之前先測試：
這是不可協商的：所有實作都必須遵循嚴格的測試驅動開發。
在以下之前不得編寫任何實作程式碼：
1. 編寫單元測試
2. 使用者驗證和核准測試
3. 確認測試失敗（紅色階段）這完全顛覆了傳統的 AI 程式碼產生。LLM 必須首先產生定義行為的全面測試，獲得核准，然後才能產生實作，而不是產生程式碼並希望它有效。
第七和第八條：簡潔性和反抽象
這對配對的條款對抗過度工程：
第 7.3 節：最小專案結構
- 初始實作最多 3 個專案
- 額外專案需要書面理由
第 8.1 節：框架信任
- 直接使用框架功能而不是包裝它們當 LLM 可能自然地建立複雜的抽象時，這些條款強迫它證明每一層複雜性。實施計劃範本的「階段 -1 門控」直接強制執行這些原則。
第九條：整合優先測試
優先考慮現實世界測試而不是孤立的單元測試：
測試必須使用現實環境：
- 優先使用真實資料庫而不是模擬
- 使用實際服務執行個體而不是存根
- 實作前強制合約測試這確保產生的程式碼在實踐中有效，而不僅僅是理論上。
透過範本強制執行憲法
實施計劃範本透過具體檢查點操作化這些條款：
### 階段 -1：實施前門控
#### 簡潔性門控（第七條）
- [ ] 使用 ≤3 個專案？
- [ ] 沒有面向未來的設計？
#### 反抽象門控（第八條）
- [ ] 直接使用框架？
- [ ] 單一模型表示？
#### 整合優先門控（第九條）
- [ ] 合約已定義？
- [ ] 合約測試已編寫？這些門控充當架構原則的編譯時檢查。LLM 不能繼續進行，除非透過門控或在「複雜性追蹤」部分記錄合理的例外。
不可變原則的力量
憲法的力量在於其不可變性。雖然實施細節可以演變，但核心原則保持不變。這提供：
- 跨時間的一致性：今天產生的程式碼遵循與明年產生的程式碼相同的原則
- 跨 LLM 的一致性：不同的 AI 模型產生架構相容的程式碼
- 架構完整性：每個功能都加強而不是破壞系統設計
- 品質保證：測試優先、函式庫優先和簡潔性原則確保可維護的程式碼
憲法演化
雖然原則是不可變的，但它們的應用可以演變：
第 4.2 節：修正流程
對本憲法的修改需要：
- 明確記錄變更理由
- 專案維護者審查和核准
- 向後相容性評估這允許方法論在保持穩定性的同時學習和改進。憲法透過日期修正展示其自身的演變，展示了如何基於現實世界經驗改進原則。
超越規則：開發哲學
憲法不僅僅是規則手冊——它是塑造 LLM 如何思考程式碼產生的哲學：
- 可觀察性優於不透明性：一切都必須透過 CLI 介面可檢查
- 簡潔性優於聰明：從簡單開始，僅在證明必要時新增複雜性
- 整合優於隔離：在真實環境中測試，而不是人工環境
- 模組化優於單體：每個功能都是具有清晰邊界的函式庫
透過將這些原則嵌入規格說明和計劃過程，SDD 確保產生的程式碼不僅是功能性的——而且是可維護的、可測試的和架構健全的。憲法將 AI 從程式碼產生器轉變為尊重和加強系統設計原則的架構合作夥伴。
轉型
這不是要取代開發人員或自動化創造力。而是透過自動化機械轉換來放大人類能力。這是關於建立一個緊密的回饋循環，其中規格說明、研究和程式碼一起演化，每次迭代都帶來更深的理解和意圖與實作之間更好的對齊。
軟體開發需要更好的工具來維護意圖與實作之間的對齊。SDD 提供了透過產生程式碼而不僅僅是指導程式碼的可執行規格說明來實現這種對齊的方法論。