规约驱动开发：AI 编程助手时代从代码走向契约

Spec-Driven Development: From Code to Contract in the Age of AI Coding Assistants

迪帕克·巴布·皮斯卡拉（Deepak Babu Piskala）

美国·西雅图　|　技术报告

arXiv:2602.00180v1 [cs.SE]，2026 年 1 月 30 日

中文专业译稿

翻译说明

本文采用软件工程与智能体领域的专业术语体系。为突出 specification 作为可验证、可执行契约的含义，正文统一译为“规约”；spec-first、spec-anchored、spec-as-source 分别译为“规约优先”“规约锚定”“规约即源”。工具、框架、标准及参考文献名称原则上保留英文原名。

摘要

AI 编程助手的兴起，使一个由来已久的设想重新受到关注：如果软件开发的首要工件不是代码，而是规约，会发生什么？规约驱动开发（Spec-Driven Development，SDD）颠覆了传统工作流：它将规约视为唯一权威依据，而把代码视为由规约生成或依据规约验证的次级工件。本文面向实践者系统介绍 SDD，涵盖其基本原则、工作流模式与支撑工具。本文提出三种规约严谨度层级——规约优先、规约锚定与规约即源，并明确说明各层级的适用条件。通过分析从行为驱动开发框架到 GitHub Spec Kit 等现代 AI 辅助工具，本文展示了规约优先理念如何落实为实际工程方法；同时通过 API 开发、企业系统与嵌入式软件案例，说明不同领域如何应用 SDD。最后，本文给出一套决策框架，帮助实践者判断何时采用 SDD 能够创造价值，何时使用更简单的方法已足够。

**关键词：**规约驱动开发；AI 辅助编程；行为驱动开发；测试驱动开发；API 设计优先；软件规约

Ⅰ　引言

数十年来，代码一直处于软件开发的核心地位。需求文档虽然存在，却会逐渐偏离实际；设计图虽然画过，却会过时失效；测试虽然会编写，却往往是在实现完成之后才补上。最终，系统实际执行的代码成为事实上的权威依据。

这种以代码为中心的现实会带来一系列后果。当新开发人员询问“这个函数应该做什么”时，常见回答是“去读代码”；当利益相关者询问“系统是否满足需求”时，团队必须从实现中反向推断原始意图；当 AI 编程助手被要求新增功能时，它只能根据含糊的提示猜测开发者真正想要什么。

规约驱动开发（SDD）提供了另一种选择：让规约成为唯一权威依据，使代码由规约派生。团队不再先编码、后补文档——甚至永不补文档——而是先清晰描述预期行为，再据此生成、实现或验证代码。规约由此成为人类与机器共同理解、构建和维护系统的权威描述。

A. AI 的催化作用

规约优先并非新思想。测试驱动开发（TDD）与行为驱动开发（BDD）多年来一直倡导先明确预期行为，再完成实现。然而，AI 编程助手的出现使 SDD 获得了新的现实意义。原因很简单：AI 模型擅长模式补全，却不擅长读取人的真实意图。

设想一名开发者向 AI 提示：“为我的应用增加照片分享功能。”AI 必须自行猜测：支持什么格式？采用何种权限模型？文件大小限制是多少？使用云存储还是本地存储？是否压缩？最终生成的代码往往表面合理，却暗含数十个未经声明的假设，其中许多是错误的。

实践者将这种依靠宽松提示、导致大语言模型输出不一致或错误结果的方式称为“氛围编程”（vibe coding）。SDD 通过向 AI 提供明确、可执行的契约，提高编程智能体的可靠性，并为可规模化的软件生产开辟新的路径。

再考虑同一需求被写成规约的情形：“用户可上传不超过 10 MB 的 JPEG 或 PNG 图片；图片存储在 S3 中，对象键以用户 ID 为前缀；只有上传者可以删除自己的图片；上传时将图片最长边缩放至不超过 1024 像素。”此时，AI 已获得足够的信息，可以生成与真实意图一致的代码。

核心洞见

核心原则：在规约驱动开发中，代码是规约的实现细节，而不是规约对代码的事后说明。规约声明意图，代码实现意图。

B. 本文内容

本文是一份面向实践者的规约驱动开发指南。首先，本文界定三种清晰的规约严谨度层级——规约优先、规约锚定与规约即源，并说明各自适用的场景。随后，本文给出实施 SDD 的实践工作流，讨论在使用与不使用 AI 辅助时该方法如何运作；继而综述从传统 BDD 框架到现代 AI 辅助工具包的相关工具与框架；再通过 API 开发、企业系统和嵌入式软件案例展示 SDD 的实际应用；最后说明何时 SDD 能够提供显著价值，以及何时采用更简单的方法即可。

Ⅱ　规约谱系

并非所有规约驱动方法都具有同等强度。团队会根据自身需求、工具能力和领域约束采用不同程度的严谨性。图 1 展示了从传统代码优先开发到完全规约即源方法的连续谱。理解团队当前处于何种位置，以及理想状态应处于何种位置，是有效采用 SDD 的第一步。

A. 规约优先：指导初始开发

定义：规约优先

在规约优先开发中，团队在编码之前编写规约，用于指导初次实现。代码形成后，规约可能继续维护，也可能不再维护；其主要价值在于为初始开发提供清晰目标。

规约优先是进入 SDD 的起点。在编写代码之前，开发者或团队先明确代码应该实现什么，常见形式包括带验收标准的用户故事、BDD 场景或详细需求文档。规约指导实现，但当代码完成且测试通过后，规约可能被弃用，也可能逐渐与实现产生偏差。

规约优先的决定性特征，是规约在实现开始之前完成，使开发者在编码前拥有清晰目标。然而，实现完成之后，代码会重新成为主要工件；随着代码在后续迭代中不断演化，规约可能变得陈旧。与更严格的规约方法相比，这种方式的维护负担更低，因此适合无法长期投入规约维护的团队。

当团队使用 AI 编程助手开发新功能时，规约优先尤其有效。前置规约能够避免 AI 猜测需求，显著提高生成代码的质量。对于原型或一次性功能，如果长期同步维护规约与代码的成本不合理，规约优先同样具有价值。但这种方式无法防止长期漂移；若代码库需要持续维护，团队应考虑规约锚定方法。

B. 规约锚定：活文档

定义：规约锚定

在规约锚定开发中，规约在系统整个生命周期内与代码并行维护。任何行为变更都要求同时更新规约与代码，从而使二者保持同步。

规约锚定把规约视为与代码库共同演化的活文档。当功能发生变化时，团队先于代码或与代码同时更新规约。自动化检查——通常表现为由规约派生的测试——确保规约和代码始终一致。一旦二者发生偏离，测试立即失败，提醒团队系统文档已不再反映真实行为。

在这种方法中，规约与代码作为同等重要的工件共同演化。测试负责强制维持二者的一致性，BDD 场景通常会被实现为每次提交时执行的自动化测试。规约因此成为开发者与利益相关者可以信赖的、持续更新的文档。不过，维持这种一致性需要纪律与工具支持：只要系统行为发生变化，团队就必须同步更新规约。

对大多数生产系统而言，规约锚定是最佳平衡点。它既提供清晰文档和可验证需求，又不要求所有代码都必须由规约完全生成。Cucumber 等 BDD 框架就是典型例子：团队可以编写人类可读且可自动执行的场景。对于 API 开发，将 OpenAPI 规约与 Specmatic 等契约测试工具结合，也能实现规约与实现之间的同类一致性。

C. 规约即源：人编辑规约，机器生成代码

定义：规约即源

在规约即源开发中，规约是人类唯一直接编辑的工件。代码完全由规约生成，不应手工修改。任何行为变更都意味着修改规约并重新生成代码。

规约即源是 SDD 最彻底的形态。规约实际上成为源代码，只是以更高抽象层次表达。开发者围绕需求和行为思考，机器负责将这些内容转化为可执行代码。需要改变功能时，开发者修改规约并重新生成，而不直接编辑生成代码。

这种方法源于契约式设计原则，彻底颠倒了规约与代码的传统关系：规约是主要工件，代码完全由规约派生。手工编辑代码要么被禁止，要么仅允许发生在定义明确的扩展点。实施该方法需要成熟且可信的生成工具，开发者必须相信生成代码能够正确实现规约。相应地，漂移会在设计上被消除：代码始终通过重新生成获得，规约与代码因此天然保持一致。

在代码生成机制成熟的领域，规约即源已是标准实践，例如从 OpenAPI 规约生成 API 服务端桩代码，或从 Simulink 模型生成经过认证的嵌入式代码。在汽车行业，工程师通常使用 Simulink 构建控制算法，在模型层通过仿真验证行为，再生成无人手工修改的认证 C 代码。Tessl 等新兴 AI 工具试图把这种方式推广到通用软件开发，代表了一种“规约成为新的源代码”的未来愿景。但规约即源需要团队高度信任生成质量，目前主要适用于这种信任已经建立的领域。

图 1　规约谱系。向右移动意味着规约对代码拥有更高权威性，同时也要求更强的工程纪律以保持二者一致

Ⅲ　SDD 工作流

规约驱动开发在实践中如何运作？尽管具体工具各不相同，各类 SDD 方法仍呈现出共同的工作流。图 2 展示了四个核心阶段。关键在于，每个阶段都会产出一个约束并指导下一阶段的工件，由此形成一条从意图到实现的责任链。

图 2　SDD 工作流。每个阶段都会产出指导下一阶段的工件；各检查点由人工审查，以确保实现与意图一致

A. 阶段 1：规约化

规约化阶段回答一个根本问题：软件应该做什么？其产出是描述系统行为、需求与验收标准的功能规约；尤为重要的是，该规约不规定具体实现细节。把“做什么”与“如何做”分开，是 SDD 发挥作用的关键。

在此阶段，团队通过用户故事、场景和验收标准描述面向用户的行为；使用 Given/When/Then（假如／当／那么）格式或输入输出示例界定成功标准；明确记录业务规则与约束；并在实现之前识别边界情况和错误条件，而不是等到开发过程中才被动发现。

规约质量直接决定后续所有产出的质量。优秀规约通常具备以下特征：聚焦行为，描述将发生什么而非如何实现；可测试，每项要求都能够验证；无歧义，不同读者能够得出一致理解；覆盖充分，能够涵盖关键情形，同时避免过度规定。有效规约还强调清晰性、模块化和自检机制，以便在实现过程中约束并引导 AI 智能体。

实践提示

规约的细节程度应以消除歧义为准。如果 AI 或开发者可能对某项要求产生多种解释，就应补充说明；如果只有一种合理解释，则不要过度规定，因为不必要的细节会无谓限制实现空间。

B. 阶段 2：规划

规划阶段回答另一个问题：应该如何构建？在功能规约基础上，该阶段形成技术计划，覆盖架构、数据模型、接口和技术选型。规约声明意图，计划则声明实现必须遵守的约束。

规划工作包括：选择适合问题的技术与框架；定义组件架构及边界；设计数据模型与模式；规定 API、消息和契约等接口；识别性能、安全性与可扩展性等非功能需求。

规划阶段连接“做什么”和“如何做”。它把实现必须遵守的约束编码下来，例如“使用 PostgreSQL 进行持久化”或“所有 API 端点都必须通过身份认证”。使用 AI 编程助手时，计划提供至关重要的上下文：AI 不仅知道要构建什么，还知道系统如何组织以及必须遵循哪些约定。缺少这些上下文，即使功能规约非常完善，生成代码仍可能违背组织标准或既定架构决策。

C. 阶段 3：实现

实现阶段产出能够按照技术计划落实规约的可运行代码。在传统开发中，大部分工作量集中于此；在 SDD 中，特别是在 AI 辅助下，这一阶段可以被大幅自动化，但仍需要人工监督。

实现首先把技术计划拆分为离散、可审查的任务。随后，每项任务由开发人员、AI 助手或二者协同完成。团队同时依据规约与计划审查代码，确认实现保持一致；并通过单元测试把规约要求编码为可执行断言。

SDD 的一项关键原则，是以小步、已验证的增量推进。团队不会一次性实现整个规约，而是把工作分解为多个任务，每项任务交付一块可测试功能。这样就能设置高频检查点，由人工及时验证一致性，在偏差扩大之前尽早发现并纠正。

规约还可充当“超级提示词”：它将复杂问题拆解为与智能体上下文窗口相适配的模块，使 AI 系统能够处理单次提示难以承载的复杂度。

D. 阶段 4：验证

验证阶段回答闭环中的关键问题：代码是否真正满足规约？验证把流程闭合起来，确保最终构建内容正是最初规定的内容。该阶段结合自动化验证与人工判断。

验证包括：执行单元、集成和验收层面的自动化测试；针对实现运行 BDD 场景；审查非功能需求的遵循情况；必要时开展利益相关者验收测试。

如果验证揭示差距——即代码未满足规约——团队必须作出判断：修复代码，还是修正规约。如果原始规约本身错误或不完整，更新规约才是正确选择；如果规约有效而代码未达到要求，则必须修复代码。无论哪种情况，规约始终保持权威地位。

这种纪律确保规约始终可信。团队之所以能够依赖规约，是因为任何违反规约的情形都会被发现并处理，而不是被忽视并不断累积。

Ⅳ　SDD 如何增强 AI 编程智能体

GPT-4、Claude 等大语言模型作为编程智能体使用时，会因 SDD 提供经过优化、上下文丰富的输入而显著受益。规约作为超级提示词，把复杂问题分解为适配智能体上下文窗口的模块。AI 智能体能够依据规约生成代码，并使用需求符合性检查清单进行自我验证。

尽管相关实证研究仍处于早期阶段，已有研究表明，经人工完善的规约能够显著提高大语言模型生成代码的质量；受控研究报告的错误降幅最高可达 50%。这种增强作用在规模化场景中尤为明显：规约使多个智能体能够对互不重叠的任务并行执行，并通过编排处理依赖关系。团队可以在规约层拆分工作，让多个 AI 智能体同时实现不同组件且互不干扰。

挑战仍然存在，其中包括大语言模型的非确定性：即使规约结构清晰，模型仍可能产生不同输出。基于性质的测试（Property-Based Testing，PBT）可以通过自动验证规约中的不变量是否成立，来应对实现差异。在嵌入式系统及其他安全关键领域，SDD 还可把大语言模型生成与形式化验证相结合，确保符合 ISO 26262 等标准。总体而言，SDD 使 AI 智能体从被动响应工具转变为主动协作方，尤其能提升存量项目中处理遗留约束的效率，因为这些约束可以被明确编码进规约。

一种新兴方法是“自规约”（self-spec）：大语言模型先在生成代码之前自行编写规约。智能体根据高层提示产出初始规约，由人类审查和完善，再由同一智能体或另一个智能体依据该规约完成实现。该方法显式分离规划与执行，使需求误解能够在代码编写前被发现。

Ⅴ　工具与框架

从传统测试框架到现代 AI 辅助工具包，已有多种工具可支撑规约驱动开发。表 1 汇总了主要类别。常见实践包括“规约化—规划—任务拆分—实现”的分阶段工作流，以及 Kiro、GitHub Spec Kit 和 Tessl 等工具：Kiro 面向基于 VS Code 的规约工作流，Spec Kit 面向命令行项目，Tessl 则探索规约即源模型。

表 1　支持规约驱动开发的工具与框架

A. 行为驱动开发（BDD）框架

BDD 框架允许团队使用接近自然语言的形式编写规约，并将其作为测试执行。最典型的格式是 Gherkin，它使用 Given／When／Then 结构化场景：

功能：购物车场景：向空购物车添加商品假如购物车为空当我把商品“Widget”加入购物车那么购物车中应包含 1 件商品并且该商品应为“Widget”

这些场景同时承担两种作用：一方面是利益相关者可阅读的文档，另一方面是验证代码行为的自动化测试。Cucumber（Ruby、Java、JavaScript）、SpecFlow／Reqnroll（.NET）和 Behave（Python）等工具能够针对应用执行这些场景，连接业务需求与技术实现。

实践提示

BDD 场景本质上是规约，而不仅仅是测试。应在实现之前编写场景，让利益相关者参与创建，并把它们作为功能行为的权威描述。当所有场景通过时，团队才有充分依据相信系统符合已记录的需求。

B. API 规约工具

在 API 开发领域，规约驱动方法多年来一直以“设计优先”或“API 优先”的名称存在。OpenAPI（原 Swagger）允许团队完整定义 REST API 端点、请求／响应模式和示例，并据此生成服务端桩代码、客户端 SDK 和文档。GraphQL SDL 允许团队在模式中定义类型、查询与变更操作，使该模式成为前后端之间的契约，从而支持并行开发。

对于事件驱动架构，AsyncAPI 提供了类似的规约能力；Protocol Buffers 与 gRPC 则允许团队定义服务接口和消息类型，并自动生成强类型的客户端和服务端代码。

API 规约工具的价值十分明确：一旦 API 规约达成一致，前后端团队就能有把握地并行工作。规约就是契约，任何符合规约的实现都可被视为有效实现。Pact 和 Specmatic 等契约测试工具则自动验证实现是否真正符合规约。

C. AI 辅助 SDD 工具

新兴工具开始明确围绕规约组织 AI 编程工作流，因为结构化、多阶段提示并产出显式工件，通常比一次性“直接把它写出来”的提示获得更好结果。

GitHub Spec Kit 是一个开源工具包，为规约驱动的 AI 开发提供命令支持。其工作流包含四个明确阶段：/specify 根据提示生成详细规约；/plan 创建技术架构；/tasks 把计划拆分为实现任务；最后按任务逐项生成代码。每个阶段进入下一步之前都由人类审查和完善，从而维持意图与实现的一致。

Amazon Kiro 在生成任何代码之前，引导用户依次完成需求、设计和任务创建。Kiro 强调结构化需求获取和迭代完善，确保 AI 在尝试实现前拥有清晰上下文。显式分阶段能够防止 AI 对从未说明的需求进行猜测。

Tessl 采用更彻底的规约即源方法：持续维护的工件是规约，代码则由规约反复生成。Tessl 体现了“规约成为新源代码”的新兴愿景——开发者不直接修改生成代码，而是修改规约并重新生成。

这些工具共享同一核心认识：把规划与实现分离，可以让智能体在边界明确的条件下专注执行，从而减少宽松提示引发的非确定性。

Ⅵ　案例研究

A. 案例 1：API 优先的微服务

案例概况

领域：金融服务微服务模式：基于 OpenAPI 的规约锚定结果：集成周期缩短 75%

某金融服务公司长期受到所谓“集成地狱”的困扰：不同团队对 API 契约作出不兼容假设，导致各微服务在独立开发时看似正常，却在联合部署时频繁失败。问题往往到集成测试阶段才暴露，引发高成本返工。

公司随后强制推行 API 优先开发。任何服务实现开始前，团队都必须先编写 OpenAPI 规约，定义端点、请求／响应模式和错误条件。消费方团队在编码前审查规约并反馈意见，把过去发生得过晚的集成讨论前置到开发之前。

团队使用 Specmatic 根据规约生成模拟服务器，使前端开发能够与后端工作并行。更关键的是，Specmatic 在持续集成流程中验证已实现服务是否符合规约；任何偏离都会导致构建失败，从而防止漂移不断累积。

采用该方法后，集成失败显著减少。团队报告称，API 变更周期缩短了 75%，因为不兼容问题在规约审查阶段就被发现，而不是到生产环境才暴露。规约成为各方共同信赖的契约，消除了此前造成大量返工的歧义。

B. 案例 2：面向企业功能的 BDD

案例概况

领域：企业项目管理软件模式：基于 Cucumber 的规约锚定结果：需求可由利益相关者直接验证，需求歧义减少

某企业软件团队发现，开发人员与产品经理经常对功能“完成”的含义存在分歧。开发人员认为实现已经满足需求，质量保障人员却发现结果与产品预期不符，随后各方又围绕哪一种解释才正确而争论。缺乏共享且权威的预期行为定义，造成了持续摩擦与返工。

团队决定对所有面向用户的功能采用 Cucumber。产品经理用自然语言编写 Gherkin 场景描述预期行为，开发人员实现步骤定义，将这些场景自动化为可执行测试。只有当全部场景通过时，功能才被认定为“完成”，从而形成客观、可验证的完成标准。

Gherkin 场景成为业务与技术利益相关者均可阅读、验证的共同语言。产品经理可以确认场景是否准确表达意图。出现争议时，场景就是权威依据：若场景错误，则在利益相关者明确达成一致后更新；若代码错误，则由开发人员修复。由此，曾经导致大量返工和冲突的歧义被消除。

C. 案例 3：基于模型的嵌入式开发

案例概况

领域：汽车发动机控制模式：基于 Simulink 的规约即源结果：控制逻辑得到验证，代码生成通过认证

某汽车供应商需要开发满足 ISO 26262 功能安全认证要求的发动机控制软件。手工编码容易出错，而认证要求把每一行代码追溯到具体需求；在代码完全手写时，这是一项极其耗时的工作。

团队使用 MathWorks Simulink，将控制算法建模为包含状态机的框图。模型本身就是规约：工程师在模型层仿真并验证行为，在任何代码出现之前发现算法错误。模型通过仿真验证后，再使用经过认证的代码生成器自动生成代码。

模型到代码的生成过程本身已经获得认证，因此生成的 C 代码能够保证与模型规定的行为一致。工程师从不直接编辑生成代码；控制逻辑需要变更时，他们修改模型并重新生成。这样，已验证模型与部署代码在结构上始终保持完全一致。

该方法体现了最严格的规约即源：规约（Simulink 模型）是人类唯一修改的工件，实现（C 代码）则完全由规约生成。嵌入式系统中的 SDD 将生成技术与形式化验证相结合，满足安全关键合规要求，说明在汽车、航空航天等错误可能造成灾难性后果的领域，规约如何保障精确性。

Ⅶ　开发者工作的重新定义

SDD 从根本上重塑了软件开发者的工作含义。随着开发者从手工编写代码转向编排规约、审查 AI 输出并专注高层设计，工作本身正在被重新定义。这一转型可能提高效率，但也带来新的挑战，包括规约维护、工具掌握，以及判断 AI 输出是否正确所需的专业能力。

在全新项目中，开发者逐渐成为通过规约设计系统的架构师，而不再只是代码生产者。他们重点处理需求获取、约束定义和验收标准，也就是“做什么”，而不是“如何逐行编码”。AI 智能体负责把规约转换为实现，但人类仍须对规约是否准确表达真实需求负责。

在存量项目和遗留系统中，SDD 支持另一类工作：在修改之前，先把既有行为编码为规约。团队可从遗留代码中提取规约，验证现代化改造是否保留必要功能，同时清除未经记录的偶然行为。规约由此成为旧实现与新实现之间的桥梁。

SDD 的应用贯穿整个开发谱系：在全新项目中，规约指导初次开发；在遗留系统新增功能时，规约先记录现有行为再支持修改；在嵌入式软件中，规约保障安全关键领域的精确性。无论何种情形，开发者的角色都从代码生产者转向规约作者与 AI 编排者。

Ⅷ　何时使用 SDD

规约驱动开发并非适用于所有情形。与任何工程实践一样，它既有成本——前期规约投入、工具投资和纪律要求——也有收益——清晰性、质量与可维护性。图 3 的决策框架可帮助实践者判断 SDD 是否能够增加价值。

图 3　选择 SDD 方法的决策框架。应从与实际需要相匹配的最低严谨度开始

在使用 AI 编程助手时，SDD 具有明确价值，因为规约消除了迫使 AI 猜测的歧义，可显著提高输出质量。复杂需求也适合采用 SDD，因为利益相关者能够在代码编写前验证系统是否符合真实需要。由多人维护的系统可通过规约获得能够跨越人员更替的可信文档；集成密集型系统可借助 API 规约支持并行开发并预防集成失败；受监管领域往往要求需求到实现的可追溯性，而 SDD 能够自然提供这种能力；遗留系统现代化也会受益，因为从现有行为中提取规约，有助于在重新实现时保持信心。

然而，在某些场景中，SDD 可能属于过度投入。一次性原型不值得为即将被丢弃的成果投入完整规约；单人、短周期项目中，若没有长期维护需求，规约开销可能大于收益；探索式编程在团队尚不知道要构建什么时，会因过早规约而限制学习；需求显而易见的简单 CRUD 应用只需要最低程度的规约，因为复杂规约会增加成本，却不产生相应价值。

核心洞见

黄金法则：采用能够消除当前情境歧义的最低规约严谨度。AI 辅助的初始开发采用规约优先；长期维护的生产系统采用规约锚定；只有在生成工具成熟且值得信赖时，才采用规约即源。

Ⅸ　常见陷阱

团队采用 SDD 时经常遇到一些可预见的问题；如果不加处理，这些问题会削弱该方法的收益。

过度规约，是指团队把规约写得过于详细，甚至接近伪代码。这违背了 SDD 将“做什么”与“如何做”分离的初衷。如果规约读起来像代码，就说明已经走得太远：实现空间被不必要地限制，规约原本提供的抽象价值也随之丧失。

规约腐化常发生于规约锚定方法中：代码变化后，团队未同步更新规约，导致规约逐渐脱离现实，失去文档价值并侵蚀信任。解决办法是通过自动化测试强制一致；当规约与代码分离时测试必须失败，使漂移变得可见且必须处理，而不能静默累积。

规约官僚化，是指规约沦为需要填写的表单，而不是澄清问题的工具。如果规约流程只增加工作量，却没有提升理解或质量，团队就会设法应付流程甚至放弃它。规约应保持在消除歧义所需的最低程度，而不是变成面面俱到的文档工程。

工具复杂性也可能压垮团队，尤其是能够生成大量工件的 AI 辅助工具。团队可能被自动生成的计划、任务清单和中间文档淹没。正确做法是从简单方式开始，只有当新增工具复杂性确实带来收益时才逐步增加；不要照搬华而不实的复杂工作流，以免引入没有价值的流程。

虚假信心或许是最隐蔽的陷阱。规约测试通过，并不等于软件本身正确；它只证明软件符合规约。如果规约错误，代码会忠实地实现错误内容。规约需要像代码一样接受认真审查，它并不是消除人类需求判断的万能方案。

Ⅹ　SDD 与传统设计文档

一个自然问题是：SDD 与软件工程长期使用的概要设计（HLD）和详细设计（LLD）文档有何不同？HLD 描述架构，LLD 规定实现细节，需求文档说明功能；这些难道不都是规约吗？

答案并非简单的“是”或“否”。传统设计文档本身确实属于规约；真正的差异不在于写了什么，而在于这些内容如何被使用，以及它们能否持续与代码保持一致。

传统软件工程会产生多种类似规约的工件：软件需求规格说明书（SRS）描述功能与非功能需求；概要设计文档描述架构和组件；详细设计文档描述类图与算法；接口规约则定义 API 契约和接口描述语言。

问题不是缺少规约，而是规约会漂移。到第三个迭代时，概要设计可能已经过时；到第二个版本时，SRS 可能不再符合产品现状。代码重新成为事实上的权威依据，而文档则沦为无人信任、无人更新的历史材料。

核心洞见

核心差异：传统设计文档通常只是指导性材料——开发者阅读后编写一份“希望能够符合文档”的代码；SDD 规约则具有强制力——代码一旦偏离规约，测试就会失败；在规约即源方法中，代码甚至不会被手工修改，而是根据规约重新生成。

SDD 真正增加了三项能力。第一，可执行规约：传统规约由人阅读，而 SDD 规约会作为 BDD 场景、API 契约测试或模型仿真执行；代码不符合规约时，构建即失败。第二，CI/CD 集成：现代 SDD 把规约验证嵌入持续集成流程，对每次提交进行检查，使漂移能够立即暴露，而不是等到季度审查才发现。第三，AI 可消费性：传统设计文档主要面向人类读者，而 SDD 规约经过结构化处理，可由 AI 编程助手直接消费，让其根据规约生成代码和测试，而不是根据含糊提示进行猜测。

SDD 并非革命，而是一种演进。“先写规约，再让代码由规约派生”的核心思想，数十年来一直存在于敏捷开发智慧中。真正的新变化包括：更好的工具使可执行规约成为可行实践；成熟的 CI/CD 使自动强制一致成为可能；AI 成为规约的直接消费者，导致规约质量直接决定输出质量。正如 Bryan Finster 所言：“SDD 不是革命……它只是重新包装的 BDD。”但这种重新命名具有现实作用：它提醒实践者，规约应当具有权威性，而不只是建议性；现代工具能够把过去依赖人工纪律的要求转化为可执行约束。

Ⅺ　与既有实践的关系

SDD 并不取代既有开发实践，而是在 AI 辅助开发背景下建立于这些实践之上，并进一步扩展它们。

**测试驱动开发（TDD）：**TDD 可以视为单元层面的 SDD。先写测试，就是在实现之前编写一个定义预期行为的微型规约。SDD 将同样的“先规约”纪律扩展到更高层级，包括功能、系统和架构。

**行为驱动开发（BDD）：**BDD 是现代 SDD 最直接的前身。Gherkin 场景是连接业务需求与技术实现的可执行规约。AI 辅助 SDD 工具进一步增加了依据这些规约生成代码的能力，从而加速从场景到可运行软件的过程。

**领域驱动设计（DDD）：**DDD 强调通用语言，与 SDD 高度契合：规约使用开发人员和利益相关者共同理解的领域术语表达。DDD 所倡导的共享词汇，正是构建对各方都有意义的规约基础。

**敏捷方法：**敏捷方法与 SDD 兼容。带验收标准的用户故事就是规约，“完成定义”也是规约的一种。差异在于强调程度：SDD 将这些工件视为权威依据，而非指导性材料，并通过自动化强制一致，而不是仅依赖人工纪律。

Ⅻ　结论

规约驱动开发颠倒了规约与代码的传统关系。它不再让代码成为权威依据、文档沦为事后补充，而是赋予规约权威地位，并使代码成为由规约派生的实现。随着 AI 编程助手能力不断增强，这种颠倒变得愈发重要：当 AI 能够依据规约生成代码，速度甚至超过人类键入代码的速度时，瓶颈将转移到规约质量。

规约能够同时消除人类开发者和 AI 助手面对的歧义，避免猜测与误解导致昂贵返工。规约优先、规约锚定和规约即源三个严谨度层级，为不同项目需求提供了选择——从轻量的初始清晰性，到严格的代码生成。贯穿整个谱系的成熟工具已经存在，包括 BDD 框架、API 规约工具与 AI 辅助 SDD 工具包，使规约优先工作流今天即可落地。团队应根据需要选择严谨度，在自身情境下采用能够消除歧义的最低规约纪律，而不是过度设计流程。

SDD 建立在数十年来 TDD 与 BDD 的经验之上，并针对 AI 时代重新调整这些实践。思想本身并不新；新的，是让规约比以往更具力量的工具与 AI 能力。随着开发者从手工编码转向编排规约、审查 AI 输出并专注高层设计，开发工作正在被重新定义。

当软件系统日益复杂、AI 能力持续增强时，核心问题会从“我应该写什么代码”转变为“我应该提供什么规约”。掌握规约驱动开发的团队，能够从 AI 工具中获得更大价值，同时保持复杂系统所需的清晰性与可追溯性。SDD 为系统性回答这一问题提供了框架：让规约而非代码成为软件开发的首要工件。

参考文献

[1] GitHub, “Spec-Driven Development with AI: Get Started with a New Open Source Toolkit,” GitHub Blog, 2025. [Online]. Available: https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit/

[2] Thoughtworks, “Spec-Driven Development,” Technology Radar, Vol. 32, 2025. [Online]. Available: https://www.thoughtworks.com/radar/techniques/spec-driven-development

[3] B. Finster, “5-Minute DevOps: Spec-Driven Development Isn’t New,” Medium, Nov. 2025. [Online]. Available: https://bdfinst.medium.com/5-minute-devops-spec-driven-development-isnt-new-3a5c552efc95

[4] M. Fowler, “Exploring Gen AI: Spec-Driven Development,” martinfowler.com, 2025. [Online]. Available: https://martinfowler.com/articles/exploring-gen-ai.html

[5] L. Griffin and R. Carroll, “Spec Driven Development: When Architecture Becomes Executable,” InfoQ, Jan. 2026. [Online]. Available: https://www.infoq.com/articles/spec-driven-development/

[6] R. Naszcyniec, “How Spec-Driven Development Improves AI Coding Quality,” Red Hat Developer, 2025. [Online]. Available: https://developers.redhat.com/articles/2025/10/22/how-spec-driven-development-improves-ai-coding-quality

[7] Cucumber, “Cucumber Documentation,” cucumber.io, 2024. [Online]. Available: https://cucumber.io/docs/

[8] OpenAPI Initiative, “OpenAPI Specification v3.1.0,” 2024. [Online]. Available: https://spec.openapis.org/oas/v3.1.0

[9] Specmatic, “Contract-Driven Development with Specmatic,” 2025. [Online]. Available: https://specmatic.io/

[10] MathWorks, “Simulink: Simulation and Model-Based Design,” 2024. [Online]. Available: https://www.mathworks.com/products/simulink.html

[11] K. Beck, Test Driven Development: By Example, Addison-Wesley, 2002.

[12] D. North, “Introducing BDD,” dannorth.net, Mar. 2006. [Online]. Available: https://dannorth.net/introducing-bdd/

[13] Amazon Web Services, “Kiro: Agentic AI Development from Prototype to Production,” 2025. [Online]. Available: https://kiro.dev/

[14] Tessl, “Tessl: Make Agents Work in Real Codebases,” 2025. [Online]. Available: https://tessl.io/

[15] GitHub, “GitHub Copilot Documentation,” 2024. [Online]. Available: https://docs.github.com/en/copilot

[16] Cucumber, “Gherkin Reference,” 2024. [Online]. Available: https://cucumber.io/docs/gherkin/reference/

[17] GraphQL Foundation, “GraphQL Specification,” 2024. [Online]. Available: https://spec.graphql.org/

[18] Google, “Protocol Buffers Documentation,” 2024. [Online]. Available: https://protobuf.dev/

[19] gRPC Authors, “gRPC Documentation,” 2024. [Online]. Available: https://grpc.io/docs/

[20] Pact Foundation, “Pact Documentation,” 2024. [Online]. Available: https://docs.pact.io/

[21] Reqnroll Contributors (formerly SpecFlow), “Reqnroll Documentation,” 2024. [Online]. Available: https://docs.reqnroll.net/

[22] Behave, “Behave: BDD for Python,” 2024. [Online]. Available: https://behave.readthedocs.io/

[23] SmartBear, “What Is API-First Development?,” Swagger.io, 2024. [Online]. Available: https://swagger.io/resources/articles/adopting-an-api-first-approach/

[24] B. Meyer, “Applying Design by Contract,” IEEE Computer, vol. 25, no. 10, pp. 40–51, 1992.

[25] ISO, “ISO 26262: Road vehicles – Functional safety,” International Organization for Standardization, 2018.

[26] S. J. Mellor and M. J. Balcer, Executable UML: A Foundation for Model-Driven Architecture, Addison-Wesley, 2002.

[27] AsyncAPI Initiative, “AsyncAPI Specification,” 2024. [Online]. Available: https://www.asyncapi.com/

[28] M. Chen et al., “Evaluating Large Language Models Trained on Code,” arXiv:2107.03374, 2021.