Spec-Driven Development: 为混乱的 AI 编程增加工程纪律

生成式 AI 最大的问题，就在于不确定性、难以稳定复现性和无法根除的「幻觉」，这样的问题也影响到了 Vibe Coding 的效果，导致开发过程就像抽卡开盲盒，结果时好时坏。

Vibe Coding 对于快速原型验证或许尚可接受，但要构建严肃的、生产级别的软件系统，显然是远远不够的。我们需要一种能将传统软件工程的严谨性与 AI 的强大能力相结合的方法论。

最近，来自 Amazon Kiro 的首席工程师 AL Harris 详细阐述了的解决方案：Spec-Driven Development (SDD)——「规约驱动开发」。

Image

这篇文章将从 Al Harris 的分享出发，探讨 SDD 是如何试图为混乱的 AI 编程注入工程的灵魂，以及它如何通过一套结构化的工作流和工具链，提升 AI 智能体的可控性、代码质量和交付的可靠性。

问题的本质：「Vibe Coding」的脆弱性

当前 AI 辅助编程模式的根本问题在于，开发过程高度依赖于操作者（也就是开发者）的个人能力。用户需要通过提示词引导模型，不断提醒模型不要偏离方向，并对模型生成的代码进行细致的审查和调试。

这个过程不仅效率低下，而且极度依赖个人经验，难以规模化。

更重要的是，AI 编程存在许多问题：

1. 1. 不可复现性： 同样的提示，两次生成的代码可能截然不同。整个开发过程依赖于一段无法被精确记录和复现的对话历史。
2. 2. 隐性假设： AI 为了「完成任务」，会做出大量用户看不到的隐性假设。这些假设在简单场景下无伤大雅，但在复杂的业务逻辑中，就是一颗颗定时炸弹。
3. 3. 验证困难： 如何系统性地验证 AI 生成的代码满足了所有边界条件和约束？大多数时候，只能依赖手动测试几个典型用例，这不符合现代软件工程的测试理念。
4. 4. 维护噩梦： 当需求变更时，是回去修改那段长长的对话历史，还是直接修改 AI 生成的代码？无论哪种，都意味着你正在维护一堆缺乏清晰设计文档和需求来源的「黑箱代码」。

Image

Vibe Coding 把开发者变成了「提示词工程师 + 人肉测试员」，这是工程可靠性的倒退。

我们需要一种方法，将过去二三十年软件行业沉淀下来的宝贵经验——从瀑布模型到敏捷开发，再到极限编程——融入到 AI 开发流程中。

Spec-Driven Development 正是基于这一理念而生。

什么是 Spec-Driven Development？

很多人听到「Spec」或「规约」，第一反应可能是那些冗长、无人阅读的文档。但在 SDD 方法论中，「Spec」远不止于此。

SDD 的核心理念是将传统软件开发生命周期（SDLC）中那些被验证行之有效的实践——需求分析、系统设计、任务分解——进行压缩和自动化，并将其作为 AI 生成代码的强制前置步骤。

Image

在 Kiro 的实践中，SDD 是一个结构化、可落地的流程，这个流程中会产生一系列明确的、可以被版本控制的工程产物（artifacts）：

1. 1. 从模糊到清晰的需求（Requirements）： 流程的第一步，是将开发者输入的模糊提示（Prompt），通过 AI 转化为一份结构化的需求文档。这份文档不仅仅是简单的文字记录，它还包含了明确的验收标准。
2. 2. 从需求到可执行的设计（Design）： 基于这份清晰的需求文档，AI 会生成一份详细的设计文档。这份文档可能包含系统架构、模块划分、API 定义、数据模型，甚至是伪代码。开发者可以在这个阶段介入，与 AI 共同评审和修改设计，确保方向正确。
3. 3. 从设计到具体的任务列表（Task List）： 设计方案一经确认，系统会将其自动分解成一个详细的、可执行的任务列表。每一个任务都对应着设计文档中的一个具体实现点，并且关联着需求文档中的验收标准。
4. 4. 从任务到最终的代码实现（Execution）： 最后，AI Agent 会逐一执行任务列表中的任务，生成并修改代码。

Image

简单来说，SDD 就是将模糊的自然语言想法，通过一个结构化的流程，层层递进地转化为清晰的需求、可行的设计、具体的任务，并最终生成高质量、可验证的代码。

它压缩了传统软件开发生命周期，将需求发现、设计、实现等环节紧密地迭代融合在一起。

从自然语言到形式化验证的桥梁：EARS 与 Property-Based Testing

SDD 的想法不难理解，但要落地并不容易，需要一些具体的工程方法。

EARS: 连接自然语言与机器逻辑的桥梁

在 Kiro 的 SDD 流程中，当用户输入一个初始 Prompt 后，系统会首先生成一系列明确的需求和验收标准。这些验收标准采用了一种名为 EARS (Easy Approach to Requirements Syntax) 的格式。

EARS 是一种半结构化的自然语言。它使用特定的句式模板（例如 When <pre-condition>, the system shall <response>）来描述系统行为。

换句话说，就是描述「当【某个前置条件】发生时，在【某个特定场景】下，系统应当【执行某个动作】，以【实现某个结果】。」

EARS 的价值在于它的可解析性。非结构化的自然语言对于 LLM 来说灵活，但也充满了歧义。而 EARS 这种半结构化的格式，使得系统可以不完全依赖 LLM，而是使用更传统的、更可靠的自动化推理技术来解析、验证和处理这些需求。这为后续的一系列自动化操作奠定了基础。

例如，系统可以扫描 EARS 格式的需求，自动检测是否存在：

• 歧义 (Ambiguity)：某个描述是否不够清晰，可能导致多种解释。
• 冲突 (Conflicting requirements)：两个需求之间是否存在逻辑矛盾。
• 无效约束 (Invalid constraints)：设定的条件是否不合逻辑或无法实现。

当检测到这些问题时，系统可以主动帮助用户解决这些模糊之处，从而在编码开始之前就极大地提升了需求的质量。

Property-Based Testing: 从需求到代码

传统的单元测试通常是基于示例的测试 (Example-Based Testing)。开发者会编写具体的输入和期望的输出，例如 assert add(2, 3) == 5。这种方法的覆盖范围有限，很难发现边界情况下的 bug。

在 SDD 开发中，由于需求是使用 EARS 格式定义的，系统可以将这些结构化的需求，直接翻译成系统的「属性」（Properties）或「不变量」（Invariants）。

这就是属性测试 (Property-Based Testing, PBT)。

例如，对于一个排序函数，它的一个属性是「对于任何一个随机生成的列表，排序后的结果列表长度应与原列表相同」。测试框架（如 Python 的 Hypothesis 或 Node.js 的 fast-check）会自动生成成百上千个测试用例，试图找到一个能够证伪 (falsify) 这个属性的反例。

把 EARS 和 PBT 联系起来。Al 编程的路径就是：

自然语言需求（EARS 格式）-> 系统属性（自动提取）-> 属性测试代码（自动生成）

这意味着，开发者在需求阶段用自然语言描述的「系统应该做什么」，可以被自动转化为 PBT 测试用例，用来验证最终生成的代码是否真的做到了。

依靠这种方式，Kiro 实现了一条从初始需求一直贯穿到最终代码的主线。如果代码通过了所有从需求转化而来的属性测试，那么我们就有很高的置信度认为，交付的软件精确地满足了最初的设想。

这彻底改变了 AI 编程的游戏规则。它不再是「感觉代码好像对了」，而是有了一套机制来系统性地、自动化地验证代码的正确性是否与规约一致。这正是工程化的体现。

SDD 工具箱的三层实践

理论和工程都有了，但在实践中如何灵活运用？

答案就是打磨你的工具箱，并将其分为三个由粗到精的层次，对应着用户对 SDD 流程不同程度的定制和掌控。

第一层：集成外部工具

这是最基础的增强能力。SDD 流程并非一个封闭的系统。通过 MCP，Kiro 可以与外部系统和服务进行交互。

Image

比如，项目管理可能在 Asana 或 Jira 上。与其手动复制粘贴任务描述，你可以直接告诉 Kiro：「去执行我在 Asana 上的这个任务 [URL]」。Kiro 会通过 MCP 调用 Asana 的 API，获取任务的详细信息（标题、描述、子任务等），并以此为基础自动生成 Spec 的需求部分。

这一层打磨的核心在于将 AI 开发流程与现有的工程实践和数据源连接起来，让 Spec 的生成不是凭空想象，而是基于真实的项目上下文。你可以集成 GitHub, Brave Search, AWS 文档等任何提供了 API 的服务。

第二层：定制产物形态

这一层体现了 SDD 的灵活性。Spec 的产物（requirements.md, design.md, tasks.md）本身也是自然语言文档，这意味着你可以像与 AI 对话一样，要求它改变这些文档的内容和形式。

Image

比如：

1. 1. 在设计文档中加入 UI 线框图：在设计一个用户管理界面时，纯文本描述架构可能不够直观。直接对 Kiro 说：「这设计不错，但请为我们要构建的屏幕生成 ASCII 格式的线框图」。Kiro 随即在 design.md 文件中生成了文本化的 UI 布局。这使得团队在编码前就能对最终的视觉呈现有一个更具体的共识，将 UI/UX 的讨论也「左移」到了设计阶段。
2. 2. 在任务列表中包含明确的测试用例：为了避免 LLM 敷衍了事地说「我完成了」，要求 Kiro 在生成每个开发任务时，都明确列出「必须通过的单元测试用例」。这样一来，任务的「完成」标准变得极其清晰和可验证。开发者甚至可以配置 Agent Hooks，确保在任务被标记为完成之前，这些测试用D例必须全部运行通过。

这一层打磨的核心是提升 Spec 制品本身的信息密度和可操作性，使其更贴合团队的具体需求，让「完成」的定义不再模糊。

第三层：迭代流程本身

这是最高级的应用，也是最能体现人与 AI 协作价值的地方。它意味着你不仅可以定制 Spec 的内容，还可以挑战和迭代 Spec 生成的流程和决策本身。

Image

比如，Harris 最初要求 Kiro 为一个 Agent 应用增加会话持久化功能，并随口提了一句「将会话转储到 S3 文件中」。Kiro 忠实地按照这个指示生成了基于 S3 的完整设计方案。

但他马上意识到，自己可能引入了偏见。S3 只是他熟悉的方案，但不一定是最优解。于是，他向 Kiro 发出了挑战：「这是实现会话持久化的惯用方法吗？有没有更好的选择？」

Image

Kiro 接收到这个指令后，立即调用了相关的 MCP 工具（如 AWS 文档查询），进行了一番研究，然后回来提出建议：对于 LangChain（他们使用的 Agent 框架），使用其内置的 Agent Core Memory 机制可能更加原生和面向未来，当然，使用 S3 也是一个可行的选项。

这个过程的优势在于，SDD 并不要求你一开始就拥有完美的计划。相反，它鼓励你利用 AI 的信息检索和分析能力，来审视和优化你自己的初始想法。开发过程变成了一场动态的、有信息增益的对话，最终的设计决策是人类经验和 AI 研究能力的共同产物。

实践中的考量：大型项目、上下文管理与多人协作

在分享的 Q&A 环节，Al 也回应了一些关于 SDD 在现实世界中应用的尖锐问题。

• 如何应用于大型、已有的项目？ Harris 认为：这取决于代码库本身的质量。如果项目遵循了良好的软件设计原则，如高内聚、低耦合，模块划分清晰，那么 AI Agent 就能更好地理解代码并进行修改。反之，如果代码是一团乱麻，AI 同样会举步维艰，就像一个新人开发者一样。Kiro 会通过后台索引（如语义搜索）来帮助 Agent 理解大型代码库，但代码质量始终是关键。
• 如何管理 Spec 的生命周期？ 一个项目中会有很多 Spec。每个 Spec 通常对应一个功能或一个待解决的问题领域。Spec 是活的文档。当有新的需求时，AI Agent 在进行研究后，理想情况下会发现已有的相关 Spec，并对其进行修订，而不是每次都创建一个全新的。例如，为一个已有的聊天 UI 增加遥测功能，Agent 会找到之前关于 UI 的 Spec，并在其中增加新的需求和任务。这样，Spec 就成为了项目演进的真实记录。
• 什么是 Steering？ Steering 是一种给 Agent 提供持久化指令的机制，类似于 Custom Instructions。你可以创建一个 steering.md 文件，在里面定义你对代码风格、提交信息格式（例如，要求 AI 生成的提交信息署名为 Kiro agent）、架构偏好、性能要求等的偏好。这些指令会在每次交互中影响 Agent 的行为，确保输出符合团队规范。

总结：从「提示」到「规约」的范式转移

不同的 Vibe Coding 工具在探索不同的发展方向，Amazon Kiro 就是想把AI 辅助软件开发从手工作坊式走向工业化生产。

Spec-Driven Development 的核心思想，就是要通过引入结构、规约和可验证性，来驯服 AI 这匹强大的野马。

总结一下其核心价值：

1. 1. 提升可控性与可靠性：通过结构化的工作流，将模糊的想法转化为精确的、可执行的计划，减少 AI 输出的随机性。
2. 2. 建立从需求到代码的验证闭环：利用 EARS 和 Property-Based Testing，实现了需求和代码正确性之间的自动化验证，这是对软件质量的根本性保障。
3. 3. 兼具结构与灵活性：既有明确的流程阶段，又允许用户通过对话深度定制产物和流程本身，实现了人机协作的最佳实践。
4. 4. 沉淀可维护的工程资产：生成的 Spec 文件本身就是高质量的、活的系统文档，随着项目的迭代而更新，解决了传统软件开发中代码与文档脱节的顽疾。

总而言之，Spec-Driven Development 代表了一种范式转移：从单纯地向 AI「提示 (Prompting)」，转向与 AI 共同「规约 (Specifying)」。

这不仅仅是工具层面的变化，更是开发哲学层面的演进。它要求开发者更多地像一个架构师或产品经理一样思考，将重点放在定义「做什么」和「为什么做」上，而将「如何做」的繁重任务更大程度地交给可靠的 AI 智能体去完成。