規范驅動開發：讓架構變得可執行

作者 | Leigh Griffin

譯者 | 劉雅夢

策劃 | 丁曉昀

第五代抽象

軟件工程歷史上的每一次重大轉變都是由一種一致的力量驅動的：抽象的興起。最早一代的軟件是用原始機器代碼編寫的，后來匯編語言引入了可讀性和控制層。更高級的語言已經跨越多個不同的范式發展，使得像 C、Java 和 Python 這樣的通用語言及其衍生品得以發展。

這些語言使得抽象得以進步，其中像內存管理和特定平臺的怪癖這樣的概念在日常工作流程中被掩蓋，并且由開發者代表進行處理。這種級別的可訪問性允許更廣泛的生態系統發展，因為隨著 每一代語言 的出現，相應的支持工具鏈也在發展。

圖 1：編程語言的世代

第五代，即使用自然語言的第五代，長期以來一直是編程語言的目標演變，其中人類用他們的母語交談，并且以可執行的方式進行解釋。這種演變直到最近才真正成為主流。推動這一點的是人工智能（AI）的代際能力，現在已經成熟到可以接收以人為中心的輸入，并用你選擇的編程語言構建解決方案。幾十年的學術研究記錄了這一進化過程，博客也非正式地對此進行了討論。

這些轉變中的一個共同主題是開發人員角色的演變。每一次抽象提升都允許開發人員更多地關注意圖，而不是機制，我們現在進入了另一個拐點。第五代不僅因為廣泛使用生成式 AI 而加速，而且與行業主導的采用相吻合。這代表了開發者如何從根本上接近他們手藝的新紀元。

隨著前幾代的成熟，支持它的工具鏈也出現了。在前幾代中，工具是在一段時期穩定后出現的；然而，隨著 AI 研究和產出的快速發展，工具鏈現在有望塑造和定義這一代，而不僅僅是支持它。

作為這些進步的一部分，一套關鍵的工具出現了，集中在規范驅動開發（SDD）上。這種趨勢是由 AI 輔助代碼生成的接受所驅動的，它允許開發人員提升自己的抽象，并表達系統應該做什么，而智能工具則實現了它的實際完成方式。

這種轉變重新定義了我們如何接近系統的架構和設計。現在，團隊維護的是活的規范，而不是隨著時間的推移而偏離原始意圖的靜態架構圖。這些定義了系統契約、邊界、不變量和行為。這些規范在設計上是可執行的；它們可以生成代碼、文檔、SDK、模擬甚至服務基礎設施。AI 智能體，通過角色映射的能 力來播種 它們的上下文，其中角色的專業知識被捕捉為智能體的可消費輸入，現在可以作為解釋器、驗證器和特定于領域的協作者行使權威。

在本文中，我們將 SDD 作為一種架構范例進行研究，詳細說明規范如何成為系統的可執行支柱，漂移檢測和持續驗證如何將架構轉變為運行時不變量，AI 和代理工具如何重塑生成和管理，以及這種模型如何代表軟件抽象長期演變中的下一個主要拐點。

SDD 架構

規范驅動開發（SDD）這個名字可能暗示了一種方法論，類似于測試驅動開發。然而，這種框架低估了它的重要性。更準確的理解是，SDD 是一種架構模式，它通過將可執行規范提升到代碼本身之上，從而顛倒了傳統的事實來源。

SDD 代表了軟件系統架構、治理和演變方式的根本轉變。在技術層面上，它引入了一個聲明性的、以契約為中心的控制平面，將規范重新定位為系統的主要可執行工件。相比之下，實現代碼成為了次要的、生成的架構意圖表示。

傳統架構依賴于源代碼作為規范的控制面。在 SDD 中，控制面向上移動到規范控制面。這個控制面正式允許我們定義諸如：

• 接口契約（功能、輸入 / 輸出、行為保證）

• 數據模式和不變量（結構、約束、驗證規則）

• 事件拓撲（允許的流、排序、傳播語義）

• 安全邊界（身份、信任區域、策略實施）

• 兼容性規則（包括向后和向前）

• 版本控制語義（演進、降級、遷移）

• 資源和性能約束（延遲、吞吐量、成本）

這一變化涵蓋了跨行為和治理的經典體系結構表面區域的組合，并具有正確性的時間維度。SDD 不是獨立地在服務和存儲庫之間協調這些領域，而是將它們集中到一個單一的權威模型中。這種模式更接近于語言類型系統或編譯器：它不執行程序本身，而是定義了什么是可表達的，拒絕什么是無效的，并限制演變以保持隨時間的正確性和兼容性。架構不再是咨詢性的；它現在變得可實施和可執行。

盡管越來越多的工具被冠以 SDD 的標簽，但從根本上說，它不是一個產品、框架或正式語言。相反，它是一個架構構造，以驚人的一致性作為一個五層執行模型重新出現。

以我們的訂單管理服務為例，在規范層中，我們聲明什么必須為真，而不是如何實現它。這是一個簡單訂單的偽規范可能看起來像：

圖 2：SDD 5 層執行模型

這些層次共同構成了一個封閉的、由規范控制的控制系統，其中意圖不斷塑造執行，而執行不斷地驗證意圖。由此產生的并不是對現有架構的漸進式改進，而是權威、控制和真實性所在位置的根本倒置。

現在讓我們來看看這五個層次。在整個過程中，我們將遵循一個經典的訂單管理服務的簡化示例，以展示各層之間的進展以及它們是如何相互加強的。

規范層

這是系統行為的權威定義。它捕獲了系統的聲明性意圖，而不是如何實現。這一層通常包含 API 模型、消息傳遞契約、領域模式和特定于系統、以策略為中心的約束。從抽象的角度來看，它既是人類可讀的，也是機器可執行的，同時作為設計工件和操作控制面。

以我們的訂單管理服務為例，在規范層，我們聲明什么必須為真，而不是如何實現它。這是一個簡單訂單的偽規范可能的樣子：

    auth: mTLS

這個規范明確聲明了我們的期望：

• 訂單必須是正數

• API 不得引入破壞性變更

• 請求必須經過認證

這里沒有引用任何語言、框架或基礎設施。

生成層

這一層將聲明性系統意圖轉化為可執行的形式。它作為一個多目標系統編譯器，但與發出機器指令的經典編譯器不同，這一層發出系統形狀和跨語言、框架和平臺的可執行運行時界面。在這里，問題空間由規范層聲明，工具將其操作形式具體化。典型的輸出包括類型模型、契約存根、驗證中間件、文檔以及一系列集成和一致性測試。

以我們的訂單示例為例，規范被攝取并發出可執行的系統表面。從概念上講，這看起來像：

   → Contract tests

工具將聲明的意圖轉化為具體的、可執行的形式。

構件層

這一層包含了生成階段的具體輸出：生成的服務、組件、客戶端、數據模型和適配器。關鍵的是，這些工件不被視為主要資產。相反，它們是可再生的、可丟棄的、可替換的，并且可以持續協調。這顛覆了傳統軟件架構的一個基本假設：代碼不再是系統的記錄；規范是。隨著代碼變得無限可復制和按需生成，新出現的術語環境代碼恰如其分地抓住了這種范式轉變。

我們的訂單的形狀現在可以用生成的一次性代碼實現了。這可以看到類似于類型化模型的輸出：

}

這些構件不是真相的來源。如果規范發生變化，它們將被重新生成。如果它們被刪除，什么也不會丟失。

驗證層

這一層強制執行意圖和執行之間的持續一致性。它由契約測試、模式驗證、有效載荷檢查、向后兼容性分析和架構漂移檢測機制組成。它在結構上扮演了編程語言的類型系統和管理程序對虛擬機所扮演的角色：積極防止架構違規傳播到運行時。

我們的生成層創建的工件最終在這里進行管理，其中驗證確保運行時不能偏離意圖：

? Reject requests with quantity <= 0

違規行為在構建時、部署期間以及我們的持續集成系統中被檢測到。架構正確性是持續強制執行的，而不是手動審查的。

運行時層

這是操作系統本身，由典型的一系列構件組成，例如：

• API

• 消息代理和流處理管道

• 函數、方法和等效結構

• 集成服務

至關重要的是，運行時的形狀完全受到上游規范和驗證層的約束。因此，運行時行為在架構上是確定的，而不是涌現性的。

如果我們嘗試在我們的訂單服務使用負數量，如下所示：

}

我們返回了一個 400 ValidationError，并不是因為運行時拒絕了請求，而是因為在系統執行任何請求之前，該行為在規范層中聲明，由生成層具體化，由構件層實例化，并由驗證層持續強制執行。

架構反轉

幾十年來，軟件架構一直在一個基本上未受挑戰的假設下運作，即代碼是最終的權威。架構圖、設計文檔、接口契約和需求規范都是用來指導實現的。然而，運行中的系統總是從最終部署的內容中獲得其真相。當出現不匹配時，標準的反應是“更新文檔”。

SDD 完全顛覆了這種關系。規范成為系統現實的權威定義，實現是持續派生、驗證的，并且在必要時重新生成以符合該真實性。這不是一個哲學上的區別；它是軟件系統治理的結構性反轉。

傳統的軟件交付遵循線性、有損失的管道，如圖 3 所示。

圖 3：傳統的軟件交付管道

每一步翻譯都引入了重新解釋、手動適應和隱藏的假設。因此，不能阻止架構漂移；它是在晚期被發現的，通常是通過生產事件、失敗的集成、安全審計或合規性違規。當檢測到不一致時，它是取證而不是糾正。

SDD 從根本上將這種流程重構為一個受控的控制循環：

圖 4：SDD 受控的軟件交付管道

這個控制循環用積極的架構強制執行取代了延遲發現。漂移檢測不會修補運行時行為；它糾正規范權威，并觸發系統的受控再生。傳統架構假設代碼隨時間的推移成為事實；SDD 通過確保規范保持永久的事實來源，并且運行時持續被迫符合它，從而顛覆了這一點。

這種架構反轉可以概括如下幾點：

在 SDD 中，代碼不再是真相出現的地方，而成為真相僅僅被實現的地方。

這種反轉在結構上等同于早期的范式轉變，即從人的責任中移除整個類別的正確性約束，并使其在機械上可執行：

• 從手動內存管理到垃圾收集，內存安全成為運行時不變量

• 從裸機到虛擬機，隔離和資源邊界成為平臺保證

• 從物理服務器到聲明性基礎設施，其中配置漂移和拓撲正確性不斷得到協調

• 從無類型語言到靜態類型系統，在編譯時強制執行結構正確性

• 從非正式的接口協議到模式和契約強制執行的 API，交互正確性被機械地驗證

在每種情況下，正確性都從傳統上由人類強制執行轉變為由平臺結構性強制執行。SDD 將這一原則應用于系統邊界、架構和行為本身。

漂移檢測：使架構自我強制執行

一旦規范成為權威，漂移檢測不再是一種測試便利；它成為一種強制性的架構能力。它是將意圖轉化為不變性的執行機制。在這個模型中，漂移不僅僅是模式不匹配；它是聲明的系統意圖和觀察到的系統行為之間的任何偏差。這種偏差可能是結構性的、行為性的、語義性的、與安全相關的或進化性的。我們在實驗中遇到的一些例子包括：

• 一個 API 返回了規范中未聲明的字段

• 一個服務在重構過程中默默地省略了必需的字段

• 消息負載在沒有協調的模式版本控制的情況下不斷演變

• 錯誤處理偏離了合同保證

• 相對于最初的策略意圖，安全范圍正在退化

沒有漂移檢測，SDD 就會退回到文檔驅動的開發。有了它，系統就變成了自我監管。漂移檢測形成了一個閉環反饋控制系統。它不斷地比較系統聲稱要做的事情和它實際做的事情。這與古典測試相比，后者只提供周期性的、基于樣本的保證，是一種根本不同的操作姿態。

在傳統架構中，意圖的偏差會悄無聲息地傳播，通常數月之后才會以中斷、審計失敗或安全漏洞的形式顯現出來。在 SDD 系統中，漂移變成了機器默認可以檢測到的。規范驗證器可以直接嵌入我們的 CI 管道中，運行時執行層：模式驗證、有效負載檢查、契約驗證和規范差異引擎都成為了一等的架構組件。當輸出違反規范時，系統會快速失敗，并允許進行航向修正。

這種強制要求在一個固有的多模型未來中變得更加重要。軟件系統將越來越多地受到人類驅動開發和機器驅動生成的影響，通常在同一規范表面上并行操作。系統中不再有單一的線性路徑。更改可能來自開發者、AI 代理、自動化重構工具或政策驅動的生成器。這種進化路徑的多樣性極大地放大了漂移問題：分歧不再是邊緣情況；它是必須持續治理的自然狀態。

總體效果是治理方式的深刻轉變。架構不再是設計階段的產物；它變成了一個持續執行的運行時不變量。規范從被動的參考資料轉變為主動的控制表面，漂移檢測作為反饋信號，保持系統與意圖一致。

然而，這并不意味著一個完全自主的系統，機器單方面定義正確性。規范不僅僅是一個機械合同；它是人類對目的、風險容忍度和權衡的表達。漂移檢測可以識別系統已經偏離，但它不能單獨決定這種偏離是可以接受的、偶然的還是可取的。一些漂移代表缺陷，而其他漂移代表進化。在這個邊界上，當自動化執行遇到解釋性判斷時，人類的角色再次變得至關重要。不是作為失敗后被動審查日志的審查者，而是作為治理意義、意圖和受控變更的積極參與者。這就是 Human-in-the-Loop（人在循環中）不再只是一個安全網，而是一個一等的設計原則。

人在循環中：在自動化架構中保留意圖

當我們最初探索這種系統設計模式時，我們以一種天真的“氛圍編碼”心態來接受生成的變化，最小化阻力，并信任 SDD 工具鏈為我們處理邊緣情況。那個假設很快就失敗了。取而代之的是一個更強大的認識：SDD 并沒有將人類從循環中移除；它將人類判斷重新定位到更高的控制層面。問題不再是人類如何實現系統，而是如何以及在哪里治理系統。

SDD 并沒有消除人類在軟件設計中的參與。它重新分配了人類認知的應用領域。傳統上，一旦功能實現，開發人員就會花費大量的精力來解決不匹配、調試集成故障、協調分散的服務以及修復更改的意外副作用。隨著時間的推移，這被錯誤地等同于軟件工程本身的手藝。實際上，這是維護大型、長期、面向生產的系統的負擔。SDD 將這個負擔轉移到機器上，同時故意保留人類對意圖、策略和意義的權威。

這引入了一種新型的人機界面。人類仍然是領域語義、風險容忍度、安全范圍和系統進化方向的最終守護者。這種權威也擴展到隱含地塑造工程決策的法律、倫理和道德框架中。這些維度不能僅從執行跟蹤或行為觀察中推斷出來。它們存在于機器無法完全擁有的抽象層次上。

相反，人類將這些約束明確編碼到規范層中，機器承擔起執行、生成和持續一致性的責任。這反映了我們技術的歷史演變：就像我們曾經將手動內存管理交給垃圾收集一樣，我們現在正在將結構性執行和機械一致性委托給 SDD。取代這種委托的不是盲目的自動化，而是明確的審批邊界：

• 破壞模式更改需要人工批準

• 策略轉變需要人工授權

• AI 提出的重構需要人工確認

• 兼容性降級需要人工解釋

因此，SDD 實現了有限的自主性，而不是完全自動化，并且在這些限制內，長期架構意圖可以得以保留。

通過強制漂移檢測和人工意圖監督，SDD 在人和機器之間建立了新的責任分工。執行變得自動化。意義仍然是人類的。這種分離不是哲學上的；它是架構上的，正是這種分工產生了一類新的基礎設施能力。一個的規范原生系統現在必須將執行、演化、驗證和治理直接編碼到其核心原語中。我們接下來探討這些能力，以及它們為什么在結構上與經典軟件架構中的能力不同。

規范原生系統的核心能力

SDD 不是由單一工具、框架或平臺啟用的。它源于一組緊密耦合的架構能力，這些能力共同允許規范變得可執行、可強制和可擴展。當這些能力中的任何一個缺失時，SDD 就會退回到文檔驅動開發或臨時代碼生成。要從理論進入操作范式，系統必須內化五個核心能力：

1. 規范編寫作為一等工程表面

2. 正式驗證和類型強制

3. 確定性生成和組合

4. 持續的一致性和漂移執行

5. 受控演化和兼容性控制

我們將這種操作規程稱為 SpecOps，即規范操作。從 SpecOps 的角度來看，規范被視為一等的、可執行的系統資產，這些能力并沒有定義一個產品類別；它們代表了軟件意圖的控制平面。在規范原生系統中，規范編寫不是在實現之前進行的活動；它就是實現活動。因此，系統必須支持多模型規范，其中結構、行為和策略定義共存于統一的模式空間內。這需要可組合的領域建模，使得分層規范成為一種可行的架構策略，而不是文檔便利。

隨著規范成為主要的系統構件，它們必須像源代碼一樣被嚴格地處理：版本控制、同行評審、分支和受控合并策略都要是強制性的。此時，規范不再是描述性的，而是成為系統本身的可編程模型。

一旦規范是可執行的，它還必須是機器可驗證的，就像編譯器前端或類型系統一樣嚴格。這種執行涵蓋了結構驗證、語義一致性和領域不變性執行。條件約束、引用完整性和跨規范一致性必須是可證明的。效果不僅僅是提高了正確性，而是從可以表示的所有內容的空間中消除了整個類別的系統故障，就像靜態類型限制非法程序一樣。

在這個范式中，生成不是腳手架的一種形式。它是聲明的系統真理的具體化。這需要嚴格確定性行為。一個生產級別的規范原生系統必須保證輸入的確定性：相同的規范總是產生相同的構件。它必須是目標無關的，跨語言、平臺和運行時環境產生一致的輸出。最關鍵的是，生成必須是邏輯可逆的。系統必須始終能夠回答一個簡單但基礎的問題：哪個規范狀態產生了這種行為？這種決策的譜系可追溯性是將生成從生產力輔助提升到架構權威的關鍵。

一旦生成自動化，執行就必然變得連續。運行時系統不能再悄悄地偏離聲明的意圖。實現不能引入未記錄的行為。消費者不能依賴于未定義的屬性。因此，架構從設計時斷言轉變為運行時不變性，由系統本身積極維護。

SDD 中最困難的能力不是生成或驗證，而是不斷裂的更改。規范原生系統必須自動將更改分類為添加性、兼容性、破壞性或模糊性，并執行明確的兼容性策略。這引入了受控演化的正式概念：需要并行版本表面、已知的兼容性窗口、受控的棄用曲線和用于破壞性更改的顯式批準門。沒有這個，SDD 在架構上就會變得脆弱。有了它，系統可以在不違反自己的正確性保證的情況下進行演化。

這五個能力引入的最深刻的轉變不是技術上的；它是結構上的。

交付的單元不再是服務或代碼庫。交付的單元變成了規范本身。這將結果與產出重新對齊：聲明的是什么，交付的就是什么。這與以氛圍驅動、生成性編碼方法形成鮮明對比，在這些方法中，偏差是創造力（或幻覺）的涌現屬性，而不是設計中受控的行為。

結論：存在的工程權衡和挑戰

軟件工程中每一次重大的抽象飛躍都帶來了非凡的生產力提升，同時引入了全新的系統性風險類別。垃圾收集消除了大量內存錯誤，同時引入了暫停時間行為和新的故障模式。虛擬機簡化了部署，同時增加了業務編排的復雜性。云平臺消除了基礎設施負擔，同時引入了深層操作耦合。規范驅動開發也不例外。

通過將系統的真實來源提升到規范和生成器中，SDD 并沒有消除復雜性；它只是簡單地重新定位了復雜性。下面的權衡定義了我們在大規模采用這種范式時所經歷的真實工程成本。

規范成為主要的復雜性表面

在 SDD 中，規范不再是文檔構件，而是成為長期存在的可執行基礎設施。因此，它們獲得了傳統上與源代碼相關的屬性。它們繼承了通常與源代碼相關的所有屬性：技術債、跨團隊耦合、兼容性慣性和架構引力。因此，模式工程成為了與數據建模和分布式系統設計同等重要的一級架構學科。

生成器信任成為供應鏈問題

在 SDD 中，AI 代碼生成器不再是開發者的便利工具。它們成為系統可信計算基礎的結構組件。確定性、可重復性、可審計性、沙箱執行和可驗證的出處不再是可選屬性；它們是強制性的。代碼生成從工具提升為關鍵基礎設施。

運行時執行有實際成本

SDD 將執行從社會過程轉移到技術控制。這種轉變是強大的，但不是免費的。運行時契約驗證引入了實際的計算開銷。在小規模上，這個成本是微不足道的。在大規模上，我們需要考慮系統的目的，無論是高頻 API、實時流還是對延遲敏感的系統。這成為了一個明確的架構預算項目。正確性成為了計量資源，而不是默認的免費屬性。

認知轉變非同小可

SDD 用契約優先推理取代了實現優先的思維。這要求工程師采用新的心智模型：

• 用不變量而不是行為來思考

• 關于兼容性而不是功能的推理

• 用聲明式而不是過程式表達意圖

• 將模式視為可執行程序

歷史上每一次抽象的轉變都擴大了人類的影響力，同時引入了不熟悉的失敗模式，需要多年才能掌握。SDD 現在正進入相同的成熟曲線。

架構權威的價格

雖然新的范式轉變通常令人興奮，但最終是否采用這一轉變歸結于平衡所涉及的實際權衡。

一方面，SDD 提供了：

• 架構確定性

• 持續的正確性執行

• 系統性減少漂移

• 多語言平價

• 可復制的系統邊界

但它以以下代價：

• 模式復雜性

• 生成器信任要求

• 運行時驗證成本

• 長期兼容性負擔

• 工程角色的認知轉變

這不是避免 SDD 的理由。這是一個有意識地采用它的理由，要有明確的治理、有紀律的規范實踐，以及對其成本的清醒認識。每一次抽象的飛躍都需要新的嚴謹形式。

SDD 只是將這種嚴謹重新定位到它一直屬于的地方：系統真理本身的定義。

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

聲明：本文為 InfoQ 翻譯，未經許可禁止轉載。