規范驅動開發落地經驗談：為什么 AI 編程的關鍵不在模型，而在協作方式

作者 | Hari Krishnan

譯者 | 明知山

意圖表達的演進：

從指令到對話

過去一年，AI 輔助編程領域迎來了重大變革。我們已不再需要在 IDE 與聊天界面之間來回復制代碼，轉而使用專為 AI 打造的命令行工具與 AI 原生編輯器。

氛圍編程（Vibe Coding）——指令式交互

然而，即便工具持續演進，“氛圍編程”（與 AI 反復迭代直至代碼可運行，而非事先周密規劃）的交互方式本質上仍屬于指令式，一次僅能處理一個提示詞，輸出會作為后續步驟的上下文。

圖 1：氛圍編程工作流

規劃模式（Plan Mode）——更好的準備

規劃模式（AI 在編寫代碼前先起草執行計劃供人工審核）標志著 AI 編程的一次重大演進，能夠及早發現意圖對齊問題。它要求人類與 AI 在實現代碼之前先商議并確定任務清單、相關驗證機制等，拉長了獨立執行的周期，最終交付更完整的結果。這是我們與 AI 的第一次“開工儀式”，它印證了：前期對話質量越高，最終結果越對齊。

然而，人類與 AI 之間的交互仍然是戰術性和指令式的。由于計劃通常不會在執行后保留，代碼實現本身就成了后續迭代與功能新增的主要上下文。

圖 2：規劃模式工作流

規范驅動開發（Spec-Driven Development）——人機對話

隨著 AI 模型開始具備在復雜任務上保持長時間持續專注的能力，規范驅動開發（SDD）應運而生。在連續交互的模式中，人類與 AI 之間的指令式交互并非發揮這一能力的最優方式；同時，讓 AI 長時間獨立運行也存在大幅偏離預期結果的風險。我們需要高效的上下文工程來確保在此場景下的意圖對齊。SDD 通過構建人類與 AI 之間的共同理解來滿足這一需求，規范的作用是促進人機對話，而非充當操作手冊。

圖 3：規范驅動開發工作流

本文探討企業應如何采用 SDD：審視需要填補的即時工具缺口、梳理與現有工作流的集成模式（幫助團隊快速體驗價值），以及推動相關協作模式變革，讓 SDD 能夠規模化、可持續落地。

企業落地：為何至關重要，

且絕非單純的技術部署

SDD 已在多個技術維度展現出明確價值。除了支持更長時間、更專注的獨立執行外，它還有助于解決 Token 用量與上下文窗口管理問題，實現 AI 智能體的高效與低成本使用。

然而，SDD 最重大的影響可能是文化層面的，而非技術層面。

對話優于指令

資深工程師協作時，溝通是對話式的，而非單向指令。我們通過對話達成共識，而這種共識決定了最終要構建的內容。SDD 在人類與 AI 智能體之間建立了同樣的模式：智能體幫助我們思考方案、質疑假設，并在正式實施前細化目標意圖。

圖 4：規范驅動開發詳細工作流

圖 4 展示了 SDD 工具如何幫助構建人與 AI 之間的對話。部分工具采用獨立的探索、設計與任務階段，另一些則采用更細粒度或更靈活的流程。核心在于創造機會，通過規范與 AI 迭代表達意圖。盡管新模型擁有更長的上下文窗口與更強的推理能力，但只有將 AI 視為解決方案的共同創造者，我們才能充分釋放其潛力。

協作上下文優于更智能的模型

從概念層面看，借助規范驅動開發，團隊可將功能拆解為可指導自主執行的組成模塊（圖 4）：

• 什么（發現）：定義我們所服務的用例的業務上下文是什么？

• 如何（設計）：如何將該用例映射到我們的架構？需考慮模塊劃分、實現機制與通信方式。

• 任務：詳細制定智能體可執行的計劃，確保具備清晰的可驗證性與并行執行空間。

但即便采用這種對話式方式，若僅由個人單獨實踐，仍會錯失更大的價值。雖然 AI 可以扮演不同角色（如圖 4 所示）來協助編寫各類規范，但由單個開發者獨立完成全流程并不合理。

團隊通過跨職能協作構建規范與執行上下文遠優于個人埋頭優化提示詞或追求更強大的模型。SDD 能將規范作為轉化層，捕捉各方持續迭代的溝通內容。例如：產品定義“做什么”，架構確定“怎么做”，工程負責落地“具體任務”等。

隨著開發變得更快、成本變得更低，瓶頸已經發生轉移。如果我們仍將精力耗費在校驗 AI 輸出上，需求積壓就會因缺乏新想法而加劇。簡而言之，僅依靠審核的模式，在使用 AI 智能體時無法實現規模化。

正是在這種背景下，團隊需要協同運作，共同構思并解決問題，以此指導可并行構建的智能體集群。掌握這一方法的組織能讓人類將更多時間用于解決戰略性問題，同時由智能體同步處理多個工作流。這種團隊層面的統籌編排，而非單純提升個人效率，正是 SDD 對企業而言不可或缺的核心價值所在。

“規范瀑布”（SpecFall）/ “Markdown 怪獸”的風險

鑒于這種重要的文化屬性，若只是將 SDD 作為技術部署，會造成大量價值流失。SDD 的落地是一項需要長期培養的組織能力，而非一項只需安裝部署的技術實踐。有過企業敏捷轉型經驗的人都會熟悉這一規律：工具與流程很容易落地，但缺少文化轉變就很容易出現“規范瀑布”——也就是敏捷里所謂的“偽敏捷”。

若不改變產品、架構、工程與 QA 各方的實際協作模式，直接推行規范驅動工作流，反而可能催生“Markdown 怪獸”——生成層層疊疊、一誕生便已過時的文檔。關鍵在于要將規范同時作為多方協作的對話媒介與 AI 智能體的上下文引擎。

SDD 規模化落地的挑戰

企業多層級、多利益相關方的現實暴露出當前 SDD 工具存在的諸多短板。主流工具大多存在以下一個或多個問題。

以開發者為中心的工具

目前主流的 SDD 工具大多將使用場景限定在 Git 倉庫、代碼編輯器與命令行界面中。這種定位對個體開發者而言較為合理，卻給跨職能協作帶來了阻礙。當規范存放在代碼倉庫里時，產品經理與業務分析師（本應負責定義“做什么”的角色）會面臨較高的參與門檻。

單倉庫聚焦

當前工具通常將規范與代碼存放在同一倉庫中。這對于簡單的應用來說或許可行，但企業系統極少采用單倉庫架構。現代架構橫跨微服務、公共庫、基礎設施倉庫與平臺組件。當一個功能需要跨六個倉庫修改時，規范應該放在哪里？如何保證這些邊界之間的一致性？工具并未給出明確答案。

缺乏關注點分離

作為以開發者為中心的延伸，現有工具并未根據演進節奏與受眾對象對產出物進行清晰區分。

架構決策（如 Schema 設計）和業務上下文（如驗收標準）更偏戰略層面，涉及不同的受眾與審批流程。而任務列表則具有高度戰術性，通常只需負責執行的工程師審核即可。

然而，大多數工具將所有內容都放在功能專屬的文件夾下，導致難以提取領域級視圖或跨功能跟蹤技術演進。盡管智能體理論上可以匯總出整體視圖，但核心問題依然存在：這些生命周期截然不同的產出物是否本就應該放在一起？

起點不明確

團隊應該從覆蓋整個應用的產品需求文檔開始，還是從現有待辦事項中提取的某個具體功能開始？多數企業在 Jira、Azure DevOps 等工具中已有完善的需求清單，凝聚了數周乃至數月的梳理成果。然而，現有 SDD 工具并未與這些系統打通集成。

團隊能否將現有待辦事項中的功能接入 SDD 工作流？如何讓需求清單與持續迭代的規范保持同步？缺乏清晰的集成方案已成為團隊希望落地 SDD、卻又不愿完全放棄現有工作規劃與投入的主要障礙。

協作模式未定義

并非所有利益相關者都會參與全部階段。產品團隊專注于功能定義，僅需掌握高層技術認知；架構師聚焦系統設計與橫切關注點；平臺工程負責確保符合組織標準。但現有工具并未適配這些不同的參與模式。各方貢獻應從何時開始、何時結束？如何知曉需要審核？由誰負責審批？這些協作機制的模糊之處，都會阻礙 SDD 的可持續落地。

規范的風格與粒度多種多樣

不同 SDD 工具對規范的處理方式各不相同。多數采用 Markdown 文件，但格式可能是結構化的用戶故事和驗收標準（GitHub SpecKit），或則 EARS 模式（Amazon Kiro），等等。一些工具會為模式與消息負載生成機器可解析的格式（如 SpecKit 為 HTTP API 生成 OpenAPI），另一些工具則將測試直接嵌入到規范中，用以驗證一致性（如 Tessl）。

規范文件的組織策略也各不相同。有的工具按功能維度組織規范（如 SpecKit、Kiro），有的維護單一可演進的規范，還有的采用混合方式，同時保留頂層規范與歸檔式功能規范（如 OpenSpec）。部分工具會在規范與代碼工件之間建立一一對應的映射關系。不同工具所支持的規范詳細程度也存在差異。

鑒于實現方式與粒度差異巨大，工具與規范風格的選擇可能令人望而生畏。每種工具都自帶一套會影響流程的設計理念，這對剛接觸 SDD 的團隊或許有幫助，但一旦工具的預設邏輯與團隊實際工作方式不匹配，就會變成限制。

規范到實現的對齊

雖然 SDD 的最終目標是實現從意圖到落地的對齊，但整個過程包含兩類不同的轉換：

• 意圖到規范

• 規范到實現

意圖到規范的對齊可通過對話與審核實現，真正顯而易見卻被忽視的關鍵問題是規范到實現的對齊。這種對齊驗證已成為選擇 SDD 工具或方法時的核心考量，因為每種規范風格都有其固有的可驗證性特點。

遺留系統的落地路徑不清晰

無論是企業團隊還是小型團隊都有需要維護或添加新功能的遺留代碼。在這種情況下，第一步應該是讓大模型通讀整個項目來生成規范，還是應該聚焦每個需要關注的領域并逐步構建規范？這其中有兩個方面可能會造成障礙。

如果已有的應用規模很龐大，讓大模型生成規范可能并不現實，因為會超出上下文窗口限制。即便成功生成了規范，也可能因為體量過大而難以審核。雖然通過代碼反向校驗規范能在一定程度上建立信心，但正如我們一直強調的，規范的核心在于捕捉意圖，而意圖必須經過人工審核。體量過于龐大的現有系統規范，會給審核帶來極大困難。

雖然一些工具（如 OpenSpec，它采用增量方法在規范中捕捉現有信息）聲稱面向遺留系統場景，但在大規模環境下——上下文分散在多個倉庫和項目中——這方面的模糊性可能成為采用的障礙。

盡管部分工具（如采用增量方式在規范中記錄現有信息的 OpenSpec）宣稱是面向遺留系統的，但在大規模環境下——上下文分散在多個倉庫與項目中——這方面的模糊性仍會成為落地的障礙。

在不推倒重來的前提下落地 SDD

上述的不足屬于戰術層面的障礙，而非根本性壁壘。企業可以先將相關實踐適配到現有工作流中，待價值顯現后，再逐步向更貼近 AI 原生的模式演進，從而真正體現 SDD 的價值。

從頭開始構建規范驅動開發工具看似誘人，但其推廣成本可能很高。選擇最貼近你理念、且具備擴展性的工具并進行定制會是一條更務實、能從實踐中學習的路徑。

以下是解決當前工具在入門階段若干障礙的實用措施。

對接現有產品需求清單

大多數 SDD 工具誕生于以開發者為中心的環境，因此從工程團隊入手是合理的。但這不應要求產品經理去學習 Git 工作流。MCP 服務器提供了一個實用的集成層。

開發者可直接從 Jira、Linear 或 Azure DevOps 中將需求拉取到 SDD 工作流中，同時進度更新會自動回寫到需求管理工具。

產品待辦清單集成示例

OpenSpec 采用三步式 SDD 工作流，變更通常會經過“提議”、“應用”和“歸檔”三個階段。

圖 5-a：OpenSpec 規范驅動開發工作流

在圖 5-b 所示的改進工作流中，我們通過 MCP 與產品待辦清單集成，采用適當的狀態來對問題進行更新。這與默認通過 CLI 輸入變更提議的方式不同：

• 從積壓中選取問題進行"提議"時，將其移至"待辦"狀態；

• 當我們進入"應用"階段實施時，問題移至"進行中"狀態；

• 隨后在"歸檔"時，問題移至"已完成"狀態。

圖 5-b：通過 MCP 與產品待辦清單集成的 OpenSpec 改進版 SDD 工作流

這種簡潔的集成方式充分尊重了產品團隊已在需求管理上投入大量精力的現實。我們無需在新系統中重復工作，而是直接與現有系統打通。

多倉庫編排

將業務上下文與技術實現細節分離，對多倉庫場景下的 SDD 編排至關重要。

以一個同時涉及前端、后端或跨越多個微服務的功能為例，需要明確倉庫職責與集成模式，以便將工作拆解為合適的模塊并進行跨邊界協同。

圖 6：通過 SDD 工作流實現產品負責人、架構師與開發者之間的協作

圖 6 展示了產品負責人、架構師與開發者如何通過 SDD 工作流在三個不同階段開展協作。

發現階段

產品負責人與 AI 協作，明確功能背后的業務意圖（即“做什么”與“為什么做”）。此次對話基于產品待辦清單展開，業務相關方已在此場景下開展工作。

設計階段

架構師與 AI 協作確定技術方案。對于涉及多個代碼倉庫的功能，在該階段會將父任務拆解為各倉庫對應的子問題。每個子問題均限定在單一倉庫內完成，具備清晰的技術邊界與依賴關系。重要的是，這些子問題會保留在待辦清單中，以便產品與研發團隊能夠跟蹤進度。

任務階段

開發者在各自代碼倉庫中處理子問題，并與 AI 協作細化具體實現任務。技術執行細節（如模式定義、模塊拆解等）均在這個階段明確。這些產出物歸屬對應倉庫，因為它們與待修改的代碼庫高度耦合。

通過這種職責分離，業務上下文在產品看板上保持可見，技術實現細節則保留在代碼倉庫中。

重要的是，架構師無需手動分解每個用戶故事。相反，他們可以通過定義倉庫邊界、集成模式與架構約束為智能體搭建執行框架。在上下文的指導下，智能體能夠自動將這些規范應用到新的用戶故事中，為每個受影響的倉庫生成對應的子問題。

當需要進行架構重構時，原始業務故事保持不變，而新的架構拆解會在不同倉庫生成對應的子問題。業務意圖保持不變，但技術實施策略可以持續演進。

下面是一個 Claude Code 實例基于項目級架構分解上下文，根據代碼倉庫職責更新 Linear 待辦清單的示例。

圖 7：基于架構上下文生成的前端和后端子問題

角色特定貢獻

就像架構師提供架構指南一樣，基礎設施專家、性能專家、安全專家等其他角色也可構建各自的上下文框架，每個框架用于捕獲對應領域的特定約束與模式。

關鍵同樣在于配置智能體，將這些角色專屬的指南疊加到傳入的需求場景中，轉化為工作項與任務。專業智能體可自動應用其領域專業知識，而非依賴人工審核，例如：

• 基礎設施智能體添加部署約束

• 性能智能體標記優化需求

• 安全智能體識別合規要求

這為編排多個專業智能體奠定了基礎，各智能體分層應用指導規則，將業務意圖轉化為完整、可落地的執行方案。

規范風格與驗證

這可能是一個主觀性較強的話題。以下從實用性與企業適用性角度，列出需要考慮的方面。

頂層引導能力

架構、代碼組織、技術最佳實踐等關注點屬于跨功能范疇，會影響規范的細化過程，而非僅歸屬某一條具體規范。因此，對這類機制提供原生支持（如 SpecKit 中的 Constitution、Kiro 中的 Steering Docs）或具備實現該目標的可擴展能力至關重要。

頂層規范視圖

能夠提取或隨時查看與當前應用狀態高度一致的規范工件有助于開展驗證工作。

合理的粒度

雖然實現對齊很重要，但生成與實際代碼高度一致的工件的工具可能是一把雙刃劍。從審核負擔角度看，讓規范在規模上保持“可人工審核”至關重要，數量過于龐大將會讓詳細審核變得難以開展。

更務實的做法是優先采用能促進有效溝通的規范風格，以便在與 AI 協作時更好地交流思路、探討方案。驗證固然重要，但不應以引發抵觸的方式影響規范風格，進而阻礙這一核心目標。

在遺留系統環境中采用 SDD

與其追溯性地為整個系統編寫規范，不如采用增量式探索，這種方式更為實用。采用 SDD 的核心原因之一是通過向編碼智能體精準提供其在特定工作領域所需的信息來降低上下文負擔。規范只需在變更區域附近保持最細粒度，這種粒度同樣能減輕前面章節中強調的審核負擔。

這種方法與我們在測試驅動開發中重構遺留代碼時所用的技術并無區別。我們會盡可能覆蓋變更區域周邊的現有邏輯，一旦具備足夠信心，便對該區域進行有效隔離，幫助編碼智能體專注于目標區域，而不是用過多細節污染上下文窗口。

隨著時間推移，規范覆蓋范圍會在每次修改中逐步完善。錯誤修復、功能新增、重構工作，都可以成為為相關代碼補充規范的契機。這種漸進式的方式能自然形成規模合理、便于人工審核的上下文，聚焦于活躍開發區域，避免了對整個遺留系統全面“編寫規范”的不切實際做法，也減輕了由此帶來的審核負擔。

至此，我們已探討了如何將 SDD 適配到現有組織模式，且不破壞已驗證的工作流。一旦團隊看到價值，問題就會轉變為：組織應如何向更 AI 原生的交付模式演進？答案在于，將規范視為非靜態工件，通過反饋循環持續優化的動態指南。

長期方向

SDD 早期落地階段的一個常見問題是：對于微小變更或錯誤修復，我們是否還需要遵循規范流程？難道不能直接修改代碼嗎？隨著組織向規范原生開發轉型，這個問題會變得愈發關鍵。

答案決定了規范是作為次要文檔存在，還是作為一等工程界面。在成熟的 SDD 實踐中，每一次變更——無論是主要功能還是微小錯誤修復——都必須經過規范。這與其說是遵守流程，不如說是認識到規范是指導智能體執行的核心界面。這也是我們向 AI 原生 SDLC 轉型時流程層面的一個重大轉變。

以往，我們會禁止直接修改服務器上的代碼，因為這類直接變更會在下次部署發布時被覆蓋。通過關閉服務器直接修改權限，團隊必須在唯一可信源（版本控制中的代碼）中進行修復，并通過規范的發布流程重新部署。這種限制確保了修復內容能在后續版本中持續生效。

同理，對于 AI 生成的代碼，代碼問題本質是規范缺口導致的結果。直接在代碼層面修改反而會進一步擴大這一缺口。受 AI 生成的非確定性影響，每次基于該規范重新生成代碼時，這類缺口都會以不同形式反復出現。持續手動修補代碼難以規模化，尤其在 AI 短時間內生成大量代碼的情況下更是如此。相比之下，將問題反饋至規范層面、閉合缺口，才是更可持續的方式。

因此，我們需要讓“做正確的事”變得簡單，即在規范層面而非代碼層面開展工作。例如，盡管代碼依然是我們進行版本控制和審核的產物，但編寫代碼的工作可僅限于 AI 編碼智能體。

框架治理

在 InfoQ 文章“規范驅動開發：當架構變得可執行”中，Leigh 和 Ray 引入了 SpecOps 概念，確立了規范編寫作為一等工程界面的地位。

當規范成為需求進入系統的主要途徑時，理應對它們采用與生產代碼相同的質量規范、版本控制、審核流程和持續改進機制。

這一轉變具有深遠影響。如果智能體依據規范執行，那么規范的質量將直接決定最終實現的質量。缺陷不再只是代碼問題，更是優化生成該代碼的規范與框架的機會。這正是反饋循環發揮關鍵作用的地方。

當錯誤出現時，理解其根源至關重要。

規范到實現的缺口

規范本身清晰，但實現出現了偏差。這類問題需要強化任務完成驗證機制，避免類似缺口再次出現；框架也需要更完善的驗證智能體或更明確的實現約束。

意圖到規范的缺口

商議過程中遺漏了用例細節，導致規范本身并不完整。這類問題需要通過向框架補充問題模式、調研步驟或分析框架來優化規范引導流程，確保后續需求在前期就能捕捉到這些細節。

這些問題不只是簡單的錯誤分類，更是上下文框架的質量指標。每一個缺口都揭示了框架需要完善的地方。質量工程的角色也從驗證實現結果演變為驗證并改進指導智能體執行的框架。

圖 8：框架反饋循環

圖 8 展示了這一持續改進循環。當驗證智能體發現規范與實現之間的缺口時，這些洞察會反饋到框架的優化中。隨著時間推移，框架會沉淀更多領域知識、預見更多邊界場景，并生成更完整的規范。系統并非通過修補實現來從錯誤中學習，而是通過完善指導未來實現的上下文來實現自我進化。

通過將規范編寫視作一套包含反饋循環、質量指標與持續改進的運營體系，單個功能所需的人工細化工作會大幅減少，框架也能將積累的經驗持續傳承下去。

實現對齊的務實路徑

有人質疑，在意圖、規范與實現無法完全對齊的情況下，SDD 是否仍有價值，這種質疑是合理的。雖然我們可以設計驗證機制，基于規范獨立測試實現，但可達到的對齊程度會隨規范類型而變化。如果從一開始就追求完美對齊，可能會導致規范過于細碎，進而引發審核疲勞，阻礙落地推廣。

從實踐層面來看，即使在人類團隊成員之間也同樣需要面臨對齊問題。在人工協作場景中，我們會通過機制修復問題，減少后續誤解。同理，回顧式反饋循環有助于逐步提升對齊效果。每一個被發現的缺口都會強化框架，讓后續的規范更完整、實現更一致。

這一轉變標志著智能體編排開發中質量工作的根本性轉變。質量專家不再審核最終實現，而是驗證上下文框架、框架所承載的約束，以及這些驗證機制能否及早發現偏差。其工作重心也從實現質量轉向框架質量。

結 語

隨著 AI 智能體具備持續自主執行能力，軟件交付的瓶頸已經發生轉移。核心不再是我們能多快編寫代碼，而是我們能多高效地表達意圖。正如 Adrian Cockcroft 在舊金山 QCon 大會上所闡述的，我們正在學習指揮智能體集群。這種構建方式是一種與傳統人員管理截然不同的組織能力。

SDD 為這一轉變提供了可能，但前提是我們要認清其背后真正的變革是什么。產品團隊需以足夠清晰的方式闡明業務上下文，確保智能體能夠理解用戶價值與驗收標準；架構師則必須將技術約束和集成模式編碼為可復用的框架。工程師的角色將從編寫實現，轉變為驗證智能體生成的代碼是否與規范對齊；而質量專家也不再測試已完成的實現，轉而保障上下文框架本身的健壯性。

有了 SDD，對話不再僅僅發生在人與人之間。規范成為產品、架構、工程與質量團隊的協作界面，他們共同構建執行上下文，并由 AI 智能體轉化為具體行動。而規范編寫中的反饋循環，正是這類協作落地的核心環節。

將 SDD 作為技術進行推廣的人將獲得技術方面的收益，如更好的 Token 利用率、更持久的智能體運行時長、更少的幻覺現象。而將其視為組織變革的人將真正具備高效指揮智能體集群的能力，釋放人類創造力用于解決戰略性問題，同時由智能體完成多工作流的落地實現。

對于已經準備好轉型的組織而言，這一轉變并非遙不可及的未來，而是當下即可實現的能力。

https://www.infoq.com/articles/enterprise-spec-driven-development/

會議推薦

2026，AI 正在以更工程化的方式深度融入軟件生產，Agentic AI 的探索也將從局部試點邁向體系化工程建設！

QCon 北京 2026 已正式啟動，本屆大會以“Agentic AI 時代的軟件工程重塑”為核心主線，推動技術探索從「AI For What」真正落地到可持續的「Value From AI」。從前沿技術雷達、架構設計與數據底座、效能與成本、產品與交互、可信落地、研發組織進化六大維度，系統性展開深度探索。開往 2026 的 Agentic AI 專列即將啟程！匯聚頂尖專家實戰分享，把 AI 能力一次夯到位！

今日薦文

你也「在看」嗎？