作者 | Hari Krishnan

譯者 | 明知山

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

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

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

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

圖 1：氛圍編程工作流

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

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

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

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

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

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

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

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

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

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

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

對(duì)話優(yōu)于指令

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

單倉庫聚焦

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

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

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

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

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

起點(diǎn)不明確

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

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

協(xié)作模式未定義

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

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

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

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

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

規(guī)范到實(shí)現(xiàn)的對(duì)齊

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

• 意圖到規(guī)范

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

多倉庫編排

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

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

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

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

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

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

設(shè)計(jì)階段

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

任務(wù)階段

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

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

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

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

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

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

角色特定貢獻(xiàn)

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

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

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

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

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

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

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

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

頂層引導(dǎo)能力

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

頂層規(guī)范視圖

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

合理的粒度

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

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

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

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

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

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

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

5 長期方向

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

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

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

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

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

框架治理

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

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

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

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

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

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

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

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

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

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

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

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

實(shí)現(xiàn)對(duì)齊的務(wù)實(shí)路徑

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

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

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

6 結(jié)語

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

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

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

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

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

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

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