作者 | Hari Krishnan

譯者 | 明知山

1 意圖表達(dá)的演進(jìn)：從指令到對話

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

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

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

圖 1：氛圍編程工作流

規(guī)劃模式（Plan Mode）——更好的準(zhǔn)備

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

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

圖 2：規(guī)劃模式工作流

規(guī)范驅(qū)動開發(fā)（Spec-Driven Development）——人機對話

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

圖 3：規(guī)范驅(qū)動開發(fā)工作流

本文探討企業(yè)應(yīng)如何采用 SDD：審視需要填補的即時工具缺口、梳理與現(xiàn)有工作流的集成模式（幫助團(tuán)隊快速體驗價值），以及推動相關(guān)協(xié)作模式變革，讓 SDD 能夠規(guī)?；⒖沙掷m(xù)落地。

2 企業(yè)落地：為何至關(guān)重要，且絕非單純的技術(shù)部署

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

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

對話優(yōu)于指令

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

圖 4：規(guī)范驅(qū)動開發(fā)詳細(xì)工作流

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

協(xié)作上下文優(yōu)于更智能的模型

從概念層面看，借助規(guī)范驅(qū)動開發(fā)，團(tuán)隊可將功能拆解為可指導(dǎo)自主執(zhí)行的組成模塊（圖 4）：

• 什么（發(fā)現(xiàn)）：定義我們所服務(wù)的用例的業(yè)務(wù)上下文是什么？

• 如何（設(shè)計）：如何將該用例映射到我們的架構(gòu)？需考慮模塊劃分、實現(xiàn)機制與通信方式。

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

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

團(tuán)隊通過跨職能協(xié)作構(gòu)建規(guī)范與執(zhí)行上下文遠(yuǎn)優(yōu)于個人埋頭優(yōu)化提示詞或追求更強大的模型。SDD 能將規(guī)范作為轉(zhuǎn)化層，捕捉各方持續(xù)迭代的溝通內(nèi)容。例如：產(chǎn)品定義“做什么”，架構(gòu)確定“怎么做”，工程負(fù)責(zé)落地“具體任務(wù)”等。

隨著開發(fā)變得更快、成本變得更低，瓶頸已經(jīng)發(fā)生轉(zhuǎn)移。如果我們?nèi)詫⒕馁M在校驗 AI 輸出上，需求積壓就會因缺乏新想法而加劇。簡而言之，僅依靠審核的模式，在使用 AI 智能體時無法實現(xiàn)規(guī)模化。

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

“規(guī)范瀑布”（SpecFall）/ “Markdown 怪獸”的風(fēng)險

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

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

3 SDD 規(guī)?；涞氐奶魬?zhàn)

企業(yè)多層級、多利益相關(guān)方的現(xiàn)實暴露出當(dāng)前 SDD 工具存在的諸多短板。主流工具大多存在以下一個或多個問題。

以開發(fā)者為中心的工具

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

單倉庫聚焦

當(dāng)前工具通常將規(guī)范與代碼存放在同一倉庫中。這對于簡單的應(yīng)用來說或許可行，但企業(yè)系統(tǒng)極少采用單倉庫架構(gòu)?，F(xiàn)代架構(gòu)橫跨微服務(wù)、公共庫、基礎(chǔ)設(shè)施倉庫與平臺組件。當(dāng)一個功能需要跨六個倉庫修改時，規(guī)范應(yīng)該放在哪里？如何保證這些邊界之間的一致性？工具并未給出明確答案。

缺乏關(guān)注點分離

作為以開發(fā)者為中心的延伸，現(xiàn)有工具并未根據(jù)演進(jìn)節(jié)奏與受眾對象對產(chǎn)出物進(jìn)行清晰區(qū)分。

架構(gòu)決策（如 Schema 設(shè)計）和業(yè)務(wù)上下文（如驗收標(biāo)準(zhǔn)）更偏戰(zhàn)略層面，涉及不同的受眾與審批流程。而任務(wù)列表則具有高度戰(zhàn)術(shù)性，通常只需負(fù)責(zé)執(zhí)行的工程師審核即可。

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

起點不明確

團(tuán)隊?wèi)?yīng)該從覆蓋整個應(yīng)用的產(chǎn)品需求文檔開始，還是從現(xiàn)有待辦事項中提取的某個具體功能開始？多數(shù)企業(yè)在 Jira、Azure DevOps 等工具中已有完善的需求清單，凝聚了數(shù)周乃至數(shù)月的梳理成果。然而，現(xiàn)有 SDD 工具并未與這些系統(tǒng)打通集成。

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

協(xié)作模式未定義

并非所有利益相關(guān)者都會參與全部階段。產(chǎn)品團(tuán)隊專注于功能定義，僅需掌握高層技術(shù)認(rèn)知；架構(gòu)師聚焦系統(tǒng)設(shè)計與橫切關(guān)注點；平臺工程負(fù)責(zé)確保符合組織標(biāo)準(zhǔn)。但現(xiàn)有工具并未適配這些不同的參與模式。各方貢獻(xiàn)應(yīng)從何時開始、何時結(jié)束？如何知曉需要審核？由誰負(fù)責(zé)審批？這些協(xié)作機制的模糊之處，都會阻礙 SDD 的可持續(xù)落地。

規(guī)范的風(fēng)格與粒度多種多樣

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

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

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

規(guī)范到實現(xiàn)的對齊

雖然 SDD 的最終目標(biāo)是實現(xiàn)從意圖到落地的對齊，但整個過程包含兩類不同的轉(zhuǎn)換：

• 意圖到規(guī)范

• 規(guī)范到實現(xiàn)

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

遺留系統(tǒng)的落地路徑不清晰

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

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

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

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

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

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

從頭開始構(gòu)建規(guī)范驅(qū)動開發(fā)工具看似誘人，但其推廣成本可能很高。選擇最貼近你理念、且具備擴(kuò)展性的工具并進(jìn)行定制會是一條更務(wù)實、能從實踐中學(xué)習(xí)的路徑。

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

對接現(xiàn)有產(chǎn)品需求清單

大多數(shù) SDD 工具誕生于以開發(fā)者為中心的環(huán)境，因此從工程團(tuán)隊入手是合理的。但這不應(yīng)要求產(chǎn)品經(jīng)理去學(xué)習(xí) Git 工作流。MCP 服務(wù)器提供了一個實用的集成層。

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

產(chǎn)品待辦清單集成示例

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

圖 5-a：OpenSpec 規(guī)范驅(qū)動開發(fā) 工作流

在圖 5-b 所示的改進(jìn)工作流中，我們通過 MCP 與產(chǎn)品待辦清單集成，采用適當(dāng)?shù)臓顟B(tài)來對問題進(jìn)行更新。這與默認(rèn)通過 CLI 輸入變更提議的方式不同：

• 從積壓中選取問題進(jìn)行"提議"時，將其移至"待辦"狀態(tài)；

• 當(dāng)我們進(jìn)入"應(yīng)用"階段實施時，問題移至"進(jìn)行中"狀態(tài)；

• 隨后在"歸檔"時，問題移至"已完成"狀態(tài)。

圖 5-b：通過 MCP 與產(chǎn)品待辦清單集成的 OpenSpec 改進(jìn)版 SDD 工作流

這種簡潔的集成方式充分尊重了產(chǎn)品團(tuán)隊已在需求管理上投入大量精力的現(xiàn)實。我們無需在新系統(tǒng)中重復(fù)工作，而是直接與現(xiàn)有系統(tǒng)打通。

多倉庫編排

將業(yè)務(wù)上下文與技術(shù)實現(xiàn)細(xì)節(jié)分離，對多倉庫場景下的 SDD 編排至關(guān)重要。

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

圖 6：通過 SDD 工作流實現(xiàn)產(chǎn)品負(fù)責(zé)人、架構(gòu)師與開發(fā)者之間的協(xié)作

圖 6 展示了產(chǎn)品負(fù)責(zé)人、架構(gòu)師與開發(fā)者如何通過 SDD 工作流在三個不同階段開展協(xié)作。

發(fā)現(xiàn)階段

產(chǎn)品負(fù)責(zé)人與 AI 協(xié)作，明確功能背后的業(yè)務(wù)意圖（即“做什么”與“為什么做”）。此次對話基于產(chǎn)品待辦清單展開，業(yè)務(wù)相關(guān)方已在此場景下開展工作。

設(shè)計階段

架構(gòu)師與 AI 協(xié)作確定技術(shù)方案。對于涉及多個代碼倉庫的功能，在該階段會將父任務(wù)拆解為各倉庫對應(yīng)的子問題。每個子問題均限定在單一倉庫內(nèi)完成，具備清晰的技術(shù)邊界與依賴關(guān)系。重要的是，這些子問題會保留在待辦清單中，以便產(chǎn)品與研發(fā)團(tuán)隊能夠跟蹤進(jìn)度。

任務(wù)階段

開發(fā)者在各自代碼倉庫中處理子問題，并與 AI 協(xié)作細(xì)化具體實現(xiàn)任務(wù)。技術(shù)執(zhí)行細(xì)節(jié)（如模式定義、模塊拆解等）均在這個階段明確。這些產(chǎn)出物歸屬對應(yīng)倉庫，因為它們與待修改的代碼庫高度耦合。

通過這種職責(zé)分離，業(yè)務(wù)上下文在產(chǎn)品看板上保持可見，技術(shù)實現(xiàn)細(xì)節(jié)則保留在代碼倉庫中。

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

當(dāng)需要進(jìn)行架構(gòu)重構(gòu)時，原始業(yè)務(wù)故事保持不變，而新的架構(gòu)拆解會在不同倉庫生成對應(yīng)的子問題。業(yè)務(wù)意圖保持不變，但技術(shù)實施策略可以持續(xù)演進(jìn)。

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

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

角色特定貢獻(xiàn)

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

關(guān)鍵同樣在于配置智能體，將這些角色專屬的指南疊加到傳入的需求場景中，轉(zhuǎn)化為工作項與任務(wù)。專業(yè)智能體可自動應(yīng)用其領(lǐng)域?qū)I(yè)知識，而非依賴人工審核，例如：

• 基礎(chǔ)設(shè)施智能體添加部署約束

• 性能智能體標(biāo)記優(yōu)化需求

• 安全智能體識別合規(guī)要求

這為編排多個專業(yè)智能體奠定了基礎(chǔ)，各智能體分層應(yīng)用指導(dǎo)規(guī)則，將業(yè)務(wù)意圖轉(zhuǎn)化為完整、可落地的執(zhí)行方案。

規(guī)范風(fēng)格與驗證

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

頂層引導(dǎo)能力

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

頂層規(guī)范視圖

能夠提取或隨時查看與當(dāng)前應(yīng)用狀態(tài)高度一致的規(guī)范工件有助于開展驗證工作。

合理的粒度

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

更務(wù)實的做法是優(yōu)先采用能促進(jìn)有效溝通的規(guī)范風(fēng)格，以便在與 AI 協(xié)作時更好地交流思路、探討方案。驗證固然重要，但不應(yīng)以引發(fā)抵觸的方式影響規(guī)范風(fēng)格，進(jìn)而阻礙這一核心目標(biāo)。

在遺留系統(tǒng)環(huán)境中采用 SDD

與其追溯性地為整個系統(tǒng)編寫規(guī)范，不如采用增量式探索，這種方式更為實用。采用 SDD 的核心原因之一是通過向編碼智能體精準(zhǔn)提供其在特定工作領(lǐng)域所需的信息來降低上下文負(fù)擔(dān)。規(guī)范只需在變更區(qū)域附近保持最細(xì)粒度，這種粒度同樣能減輕前面章節(jié)中強調(diào)的審核負(fù)擔(dān)。

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

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

至此，我們已探討了如何將 SDD 適配到現(xiàn)有組織模式，且不破壞已驗證的工作流。一旦團(tuán)隊看到價值，問題就會轉(zhuǎn)變?yōu)椋航M織應(yīng)如何向更 AI 原生的交付模式演進(jìn)？答案在于，將規(guī)范視為非靜態(tài)工件，通過反饋循環(huán)持續(xù)優(yōu)化的動態(tài)指南。

5 長期方向

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

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

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

同理，對于 AI 生成的代碼，代碼問題本質(zhì)是規(guī)范缺口導(dǎo)致的結(jié)果。直接在代碼層面修改反而會進(jìn)一步擴(kuò)大這一缺口。受 AI 生成的非確定性影響，每次基于該規(guī)范重新生成代碼時，這類缺口都會以不同形式反復(fù)出現(xiàn)。持續(xù)手動修補代碼難以規(guī)?；?，尤其在 AI 短時間內(nèi)生成大量代碼的情況下更是如此。相比之下，將問題反饋至規(guī)范層面、閉合缺口，才是更可持續(xù)的方式。

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

框架治理

在 InfoQ 文章“規(guī)范驅(qū)動開發(fā)：當(dāng)架構(gòu)變得可執(zhí)行”中，Leigh 和 Ray 引入了 SpecOps 概念，確立了規(guī)范編寫作為一等工程界面的地位。

當(dāng)規(guī)范成為需求進(jìn)入系統(tǒng)的主要途徑時，理應(yīng)對它們采用與生產(chǎn)代碼相同的質(zhì)量規(guī)范、版本控制、審核流程和持續(xù)改進(jìn)機制。

這一轉(zhuǎn)變具有深遠(yuǎn)影響。如果智能體依據(jù)規(guī)范執(zhí)行，那么規(guī)范的質(zhì)量將直接決定最終實現(xiàn)的質(zhì)量。缺陷不再只是代碼問題，更是優(yōu)化生成該代碼的規(guī)范與框架的機會。這正是反饋循環(huán)發(fā)揮關(guān)鍵作用的地方。

當(dāng)錯誤出現(xiàn)時，理解其根源至關(guān)重要。

規(guī)范到實現(xiàn)的缺口

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

意圖到規(guī)范的缺口

商議過程中遺漏了用例細(xì)節(jié)，導(dǎo)致規(guī)范本身并不完整。這類問題需要通過向框架補充問題模式、調(diào)研步驟或分析框架來優(yōu)化規(guī)范引導(dǎo)流程，確保后續(xù)需求在前期就能捕捉到這些細(xì)節(jié)。

這些問題不只是簡單的錯誤分類，更是上下文框架的質(zhì)量指標(biāo)。每一個缺口都揭示了框架需要完善的地方。質(zhì)量工程的角色也從驗證實現(xiàn)結(jié)果演變?yōu)轵炞C并改進(jìn)指導(dǎo)智能體執(zhí)行的框架。

圖 8：框架反饋循環(huán)

圖 8 展示了這一持續(xù)改進(jìn)循環(huán)。當(dāng)驗證智能體發(fā)現(xiàn)規(guī)范與實現(xiàn)之間的缺口時，這些洞察會反饋到框架的優(yōu)化中。隨著時間推移，框架會沉淀更多領(lǐng)域知識、預(yù)見更多邊界場景，并生成更完整的規(guī)范。系統(tǒng)并非通過修補實現(xiàn)來從錯誤中學(xué)習(xí)，而是通過完善指導(dǎo)未來實現(xiàn)的上下文來實現(xiàn)自我進(jìn)化。

通過將規(guī)范編寫視作一套包含反饋循環(huán)、質(zhì)量指標(biāo)與持續(xù)改進(jìn)的運營體系，單個功能所需的人工細(xì)化工作會大幅減少，框架也能將積累的經(jīng)驗持續(xù)傳承下去。

實現(xiàn)對齊的務(wù)實路徑

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

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

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

6 結(jié)語

隨著 AI 智能體具備持續(xù)自主執(zhí)行能力，軟件交付的瓶頸已經(jīng)發(fā)生轉(zhuǎn)移。核心不再是我們能多快編寫代碼，而是我們能多高效地表達(dá)意圖。正如 Adrian Cockcroft 在舊金山 QCon 大會上所闡述的，我們正在學(xué)習(xí)指揮智能體集群。這種構(gòu)建方式是一種與傳統(tǒng)人員管理截然不同的組織能力。

SDD 為這一轉(zhuǎn)變提供了可能，但前提是我們要認(rèn)清其背后真正的變革是什么。產(chǎn)品團(tuán)隊需以足夠清晰的方式闡明業(yè)務(wù)上下文，確保智能體能夠理解用戶價值與驗收標(biāo)準(zhǔn)；架構(gòu)師則必須將技術(shù)約束和集成模式編碼為可復(fù)用的框架。工程師的角色將從編寫實現(xiàn)，轉(zhuǎn)變?yōu)轵炞C智能體生成的代碼是否與規(guī)范對齊；而質(zhì)量專家也不再測試已完成的實現(xiàn)，轉(zhuǎn)而保障上下文框架本身的健壯性。

有了 SDD，對話不再僅僅發(fā)生在人與人之間。規(guī)范成為產(chǎn)品、架構(gòu)、工程與質(zhì)量團(tuán)隊的協(xié)作界面，他們共同構(gòu)建執(zhí)行上下文，并由 AI 智能體轉(zhuǎn)化為具體行動。而規(guī)范編寫中的反饋循環(huán)，正是這類協(xié)作落地的核心環(huán)節(jié)。

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

對于已經(jīng)準(zhǔn)備好轉(zhuǎn)型的組織而言，這一轉(zhuǎn)變并非遙不可及的未來，而是當(dāng)下即可實現(xiàn)的能力。

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

聲明：本文為 InfoQ 翻譯，未經(jīng)許可禁止轉(zhuǎn)載。