什么是规范驱动开发？

随着 AI 工具和编码助手（如 Microsoft 的 GitHub Copilot、Anthropic 的 Claude Code 或 IBM 的 Bob）的普及，代码生成的入门门槛已经降低。由 LLM 驱动的 AI 智能体使用复杂的 AI 模型，可以随时实时运行一系列迭代任务，所有这些都只需用户的自然语言提示即可。

对于软件开发而言，这意味着我们可以优化和自动化开发工作流程，以构建原型、新功能、单元测试等等。生成代码从未如此简单。然而，氛围程序员们应该意识到一个危险的趋势：AI 的优劣取决于它接收到的指令。

您可能在现实中见过技术债务，只是自己没有意识到。技术债务早于氛围编程出现，几十年来一直是软件开发的一部分，当人们为了追求速度而走捷径时，技术债务就会不断累积。然而，氛围编程加速了技术债务的累积，因为它使得在不完全理解或验证代码的情况下生成大量代码变得容易。也许存在快速交付的压力，或者氛围程序员根本不具备技术背景，无法阻止技术债务的产生。

在 AI 辅助开发中，技术债务可能表现为以下几种形式： 

• 当一个区域的错误修复无意中破坏了另一个区域的功能时，就会发生上下文漂移，这是在不完全了解更广泛系统的情况下生成的代码。
• 碎片化是另一种常见表现，即新生成的功能未能与现有架构惯例保持一致，逐渐侵蚀代码库的一致性和可维护性。
• 还有运营成本需要考虑。如果没有明确的规格来指导生成过程，开发人员可能会发现自己陷入了漫长的提示周期。这种方法会消耗数千个词元来解决定义明确的规范本来可以完全避免的错误。

想象一个行业内许多开发者都熟悉的情景。您已经为一项新功能开发了数天或数周，眼看就要上线了。然后，在临近截止日期的压力下，您通过一系列 AI 提示的更改匆忙完成最后的调整。

无论使用 Python 还是其他语言编写，从用户的角度来看，生成的代码的功能可能看起来都不错。然而，在此过程中，暴露了多个漏洞，引入了依赖冲突，边缘案例处理和测试完全被遗忘。

预先建立的正式规范为团队提供了一个共享的可信信息源，用于管理软件开发生命周期 (SDLC) 的每个阶段，无论谁编写代码。

规范驱动开发有多种方法和模板，它们的规范维护水平和权衡取舍各不相同。与其说存在一种严格的“更优”开发进程，不如说正确的选择取决于您的代码库、团队和问题领域。选择之前，请考虑团队的需求和限制。

在规范先行式开发中，规范在生成任何代码前就已编写，形式包括用户故事、验收标准或正式需求文档。当提供最初的明确性并生成了代码后，规范不一定会得到维护。随着软件的不断发展，该规范可能会过时。 规范的主要目的是提供初始明确性，无需继续进行维护。这一方面被认为是“SDD 的切入点”。¹

在以规范为导向的开发中，规范与软件同步演进。随着需求的变化和功能的添加，规范也会更新，以反映系统的当前状态。这对于服务于更大计划的项目尤其有用。

自动化测试作为文档和实施之间的桥梁，通常集成到 CI/CD 管道中，以确保两者在整个开发生命周期中保持同步和可执行。这种结构与灵活性的平衡使得以规范为导向的开发成为大多数工程团队实用且可扩展的方法。¹

连续谱的另一端是“规范即源”式开发，这是最以 AI 为先的形式。在“规范即源”式开发中，规范中的更改会自动触发代码更改。从来没有人直接重构代码。

这种级别的规范权威性要求对 AI 代码生成管道的质量和一致性有高度信心，而 AI 代码生成管道现在其本质上仍然是不确定的。实际上，这意味着如果没有强有力的人工监督，它的严谨性可能会降低。在采用此方法之前，团队应仔细评估其技术栈和规格套件的成熟度、相关系统的关键性以及他们验证 AI 生成的输出的能力。¹

在实践中，许多团队会采用混合方法：

• 将规范视为可堆叠的版本化工件，如架构决策记录 (ADR)，而非始终保持最新。
• 使用外部系统（例如问题跟踪器）作为可信信息源来引入有意的分隔。
• 避免在高度复杂或社区驱动的项目中实现高度自动化，在这些项目中，严格控制变更至关重要。

每种方法各有优势和局限性；语境比严格遵守任何一种模型更为重要。

根据您喜欢的规范权威性级别，有效的规范可能看起来各不相同。但是，假设您的用户处于连续谱的中间位置，并选择“以规范为导向的开发”，那么规范就应以清晰、可测试的术语描述系统需要做什么。此种规范可避免让您过早地锁定其实现方式。

规范应足够详细，以包括输入和输出定义、数据模式、边缘情况和成功标准。但是，它应该足够轻量级，以便随着问题理解的深入而不断发展。最重要的是，好的规范应该能加快开发速度：如果它不能帮助您更快地编写更好的代码或减少误解，那么可能就过于详细了。

为了说明有效的规范在实践中是什么样子，请考虑以下用户身份验证功能的示例：

您正在为 Web 应用程序实现用户登录功能。
使用以下规范作为您的单一可信信息源。
请勿对此处未列出的任何要求做出假设。

功能：用户登录 
 
概述： 
允许注册用户使用电子邮件  
地址和密码安全地执行身份认证。 
 
验收标准： 
1. 登录表单必须接受电子邮件地址和密码 
2. 如果凭据有效，则将用户重定向到仪表板 
3. 如果凭据无效，则显示一般错误消息，  
  而不指定哪个字段不正确 
4. 连续 5 次登录尝试失败后，  
  锁定帐户 15 分钟 
5. 仅通过 HTTPS 传输密码 — 绝不以明文形式存储 
 
范围外： 
- 社交登录 (OAuth) 
- 双重身份验证 
- 密码重置流程 
 
边缘案例： 
- 提交前在客户端捕获空字段 
- 将过期会话重定向至登录页面并显示一条信息性消息 
- 若禁用 JavaScript，表单必须保持有效 
 
在确认理解验收标准之前，  
请勿开始实施。

这些规范与产品经理编写的功能规格类似，但范围严格限于实施必须包括的内容、验收标准以及如何妥善地处理边缘案例。

通常情况下，该规范会作为 Markdown 文件保存在 GitHub 上的项目存储库中，例如SPEC.md 或/docs/auth-login.md ，并通过 Git 与代码库一同进行版本控制。AI 编程智能体可以通过用户将其粘贴到提示符中来访问该规范，或者更推荐的方式是，通过 CLI 引用该文件，由智能体从项目目录中读取该文件。例如，“实现 /docs/auth-login.md 中描述的功能”。

在更自动化的流程中，规范文件会在任务开始时作为系统提示或上下文窗口的一部分传递，从而在智能体开始执行任务之前向其提供指令。

虽然规范驱动开发可以节省大量时间和减少技术债务，但也要记住，过度设计也可能导致花费过多时间。如果你花了三周时间讨论一个 JSON 键的名称或某个功能的特定 API 端点，而该功能可能在一个月内就会被删除，这就违背了规范驱动开发的目的。

不要过分专注于为每种可能的未来建模。青睐轻量级的、不断发展的规范，而不是详尽无遗的“最终”规范。编写行动所需的内容，在代码中快速验证，并随着现实的变化进行迭代。一般原则是，完善规范的成本应始终低于实施中纠正误解的成本。当这种趋势发生逆转时，这就是一个停止打磨并开始建设的信号。

随着 AI 编程辅助的出现，测试驱动开发 (TDD) 和行为驱动开发 (BDD) 激发了一场新浪潮：规范驱动开发。TDD 要求开发人员通过测试定义预期结果，BDD 要求他们通过协作定义行为，而规范驱动开发首先问了一个更基本的问题：我们是否已经明确定义了要构建什么，以及为谁而建？^2,3

随着 AI 智能体承担越来越多的执行工作，其工作质量与它们接收到的指令质量成正比。一份撰写得当的规范不会限制开发过程，而是会在加速现代软件系统中的开发进程。