我一直在尝试理解最新的 AI 编码流行词之一：规格驱动开发（spec-driven development, SDD）。我研究了三个自称为 SDD 工具的工具，并尝试理解它目前的含义。
定义
像许多新兴术语一样，“规格驱动开发”（SDD）的定义仍在不断变化。根据我迄今为止看到的用法，我可以总结如下：规格驱动开发意味着在使用 AI 编写代码之前先编写“规格”（“先文档化”）。规格成为人类和 AI 的事实来源（source of truth）。
GitHub: “在这个新世界里，维护软件意味着演进规格。[…] 开发的通用语言提升到了更高的层次，而代码只是最后一公里的实现。”
Tessl: “一种开发方法，其中 规格 —— 而不是代码 —— 是主要的工件。规格以结构化、可测试的语言描述意图，代理生成与之匹配的代码。”
在查看了该术语的用法以及一些声称实现 SDD 的工具后，我认为实际上，它有多个实现层次：
- 规格先行（Spec-first）：首先编写一个经过深思熟虑的规格，然后在 AI 辅助的开发工作流程中使用它来完成当前任务。
- 基于规格（Spec-anchored）：规格在任务完成后仍然保留，以继续使用它进行相应功能的演进和维护。
- 以规格为源（Spec-as-source）：规格成为主要的源文件，只有规格由人类编辑，人类从不直接修改代码。
所有我找到的 SDD 方法和定义都是规格先行的，但并非所有方法都力求成为基于规格或以规格为源。而且通常对于规格的长期维护策略是模糊的或完全开放的。
什么是规格?
从定义的角度来看，关键的问题当然是：什么是规格？似乎没有一个通用的定义，我见过最一致的定义是将规格与”产品需求文档”进行比较。
该术语目前相当过载，这里是我尝试对规格的定义：
规格是一个结构化的、行为导向的工件 —— 或一组相关工件 —— 用自然语言编写，表达软件功能，并作为 AI 编码代理的指导。规格驱动开发的每个变体都定义了它们对规格结构、细节级别以及这些工件在项目中的组织方式的理解。
我认为有必要区分规格和更一般的代码库上下文文档。这些一般上下文包括规则文件或对产品和代码库的高级描述。有些工具将这种上下文称为记忆库（memory bank），所以这里我就用这个术语。这些文件与代码库中的所有 AI 编码会话都相关，而规格仅与实际创建或改变特定功能的任务相关。
评估 SDD 工具的挑战
事实证明，以接近实际使用的方式评估 SDD 工具和方法是相当耗时的。你需要尝试不同规模的问题，绿地场景（greenfield）、棕地场景（brownfield），并真正花时间审查和修改中间工件，而不仅仅是粗略浏览。正如 GitHub 关于 spec-kit 的博客文章 所说：“关键是，你的角色不仅仅是引导。你还需要验证。在每个阶段，你都要反思和改进。”
对于我尝试的三种工具中的两种，将它们引入现有代码库似乎需要更多的工作，因此更难评估它们在棕地代码库中的实用性。在听到有人在“真实”代码库中使用它们一段时间的使用报告之前，我对它在真实环境中工作的如何仍有很多开放性问题。
话虽如此 —— 让我们来看这三种工具。我将首先分享它们的工作原理（或者更确切地说，我认为它们的工作原理），并将在最后保留我的观察和问题。请注意，这些工具发展非常迅速，因此自我九月份（2025.09）使用它们以来，它们可能已经发生了变化。
Kiro
Kiro 是我尝试的三种工具中最简单（或最轻量级）的一种。它似乎主要是规格先行的，我找到的所有示例都将其用于一个任务或用户故事，没有提到如何在多个任务中以基于规格的方式使用需求文档。
工作流程: 需求 → 设计 → 任务
每个工作流程步骤由一个 Markdown 文档表示，Kiro 会在其基于 VS Code 的分发版中引导你完成这三个工作流程步骤。
需求: 结构化为需求列表，每个需求代表一个“用户故事”（以“作为一个…”格式）并包含验收标准（以“给定… 当… 那么…”格式）
设计: 在我的尝试中，设计文档由下图中看到的各个部分组成。我只保留了其中一次尝试的结果，因此不确定这是否是一个一致的结构，或者是否会根据任务的不同而变化。
任务: 一个任务列表，追溯到需求编号，并获得一些额外的 UI 元素，以便逐个运行任务，并审查每个任务的更改。
Kiro 也有记忆库的概念，他们称之为“steering”。其内容是灵活的，工作流程似乎并不依赖于任何特定的文件（在我完成我的使用尝试之前甚至都没有发现 steering 部分）。当你要求 Kiro 生成 steering 文档时，默认创建的拓扑结构是 product.md、structure.md、tech.md。
Spec-kit
Spec-kit 是 GitHub 的 SDD 版本。它以 CLI 的形式分发，可以为各种常见的编码助手创建工作区设置。一旦设置好结构，你可以通过编码助手中的斜杠命令与 spec-kit 进行交互。由于其所有工件都直接放入你的工作区，这是三种工具中最可定制的一种。
工作流程: 宪法 → 𝄆 规格 → 计划 → 任务 𝄇
Spec-kit 的记忆库概念是规格驱动方法的前提条件。他们称之为宪法（constitution）。宪法应该包含“不可变”的高级原则，并且应始终应用于每个更改。它基本上是一个非常强大的规则文件，在工作流程中被广泛使用。
在每个工作流程步骤（规格、计划、任务）中，spec-kit 使用 bash 脚本和一些模板实例化一组文件和提示词。然后，工作流程大量使用在文件内部的检查表，以跟踪必要的用户澄清、宪法违规、研究任务等。它们就像每个工作流程步骤的“完成定义”（然而由 AI 解释，因此不能保证 100% 遵守）。
下面是一个概览，说明了我在 spec-kit 中看到的文件拓扑结构。请注意，一个规格是由多个文件组成的。
乍一看，GitHub 似乎在追求基于规格的方式（“这就是为什么我们重新思考规格 —— 不是作为静态文档，而是作为随项目演变的、活的、可执行的工件。规格成为共享的事实来源。当某些事情不合理时，你回到规格；当项目变得复杂时，你优化规格；当感觉任务过大时，你拆分规格。”）。然而，spec-kit 为每个新的规格创建一个分支，这似乎表明他们将规格视为变更请求生命周期内的活工件，而不是特性生命周期内的活工件。这个社区讨论 正在讨论这种困惑。这让我认为，spec-kit 仍然只能达到我所说的规格先行层级，而不是随时间推移的基于规格层级。
Tessl 框架
(仍在 beta 测试)
与 spec-kit 类似，Tessl 框架 也是以 CLI 的形式分发的，可以为各种编码助手创建工作区和配置结构。CLI 命令同时也兼作 MCP 服务器。
Tessl 是三个工具中唯一明确追求基于规格方法的工具，甚至在探索 SDD 的以规格为源层级。Tessl 规格可以作为主要工件进行维护和编辑，代码顶部甚至会标注 // GENERATED FROM SPEC - DO NOT EDIT 的注释。目前，这在规格和代码文件之间是 1:1 的映射，即一个规格对应代码库中的一个文件。但 Tessl 仍处于测试阶段，他们正在尝试不同的版本，因此我可以想象，这种方法也可以在一个规格映射到多个文件的代码组件的层面上进行。尚不清楚 alpha 版产品将支持什么。（Tessl 团队自己认为，他们的框架更多是面向未来，而不是当前的公开产品 Tessl Registry。）
这有一个我使用 Tessl CLI 从现有代码库中的 JavaScript 文件反向工程得到的规格示例（tessl document --code ...js）：
@generate 或 @test 等标签似乎告诉 Tessl 要生成什么。规格中 API 部分展示了至少要定义暴露给代码库其他部分的接口的想法，可能是为了确保这些生成组件的更关键的部分完全由维护者控制。对于这个规格，使用这份规格运行 tessl build 会生成相应的 JavaScript 代码文件。
将以规格为源中的规格放在相当低的抽象层级上，每个代码文件一个，可能会减少 LLM 需要执行的步骤和解释的数量，因此减少错误的机会。但即便在这个低抽象层级上，当我多次从同一规格生成代码时，我也看到了非确定性的表现。这是一个有趣的练习，迭代规格并使其越来越具体，以增加代码生成的可重复性。这个过程让我回想起了编写一个明确无误和完整的规格的一些陷阱和挑战。
观察和问题
这三个工具都给自己贴上了规格驱动开发的标签，但它们彼此之间却有很大的不同。所以在谈论 SDD 时，首先要记住的一点是，它并不是单一固定的东西。
一种工作流程能适配所有情况吗？
Kiro 和 spec-kit 各自提供了一种有自己见解的工作流程，但我很确定它们都不适合大多数现实生活中的编码问题。尤其是，它们如何能够适应足够多不同规模的问题，从而具备普遍适用性，对我来讲仍不是很清晰。
当我让 Kiro 修复一个小 bug 时（它是我之前试用 Codex 时使用的同一个 bug），很快就能看出，这种工作流程简直是杀鸡用牛刀。需求文档把这个小 bug 变成了 4 个“用户故事”，总共有 16 个验收标准，其中实例就像 “用户故事：作为一个开发者，我希望转换函数能够优雅地处理边缘情况，以便当引入新的类别格式时系统仍然保持健壮。”
我在使用 spec-kit 时也遇到了类似的挑战，我不太确定应该用它处理多大规模的问题。可用的教程通常是基于从零创建一个应用程序，因为这是教程中最容易的方式。我最终尝试的一个用例是一个在我过去的团队中会被评为 3-5 点的功能故事。该功能依赖于大量已有代码，旨在构建一个概览模态，汇总现有仪表板中的大量数据。考虑到 spec-kit 所需的步骤数量，以及它为我创建的需要评审的 markdown 文件数量，这对于问题的规模来说再次显得过于复杂。这个问题比我在 Kiro 中使用的要大，但工作流程也更加复杂。我甚至没有完成完整的实现，但我认为在运行和审查 spec-kit 结果所花的时间内，我本可以使用“普通”的 AI 辅助编码实现该功能，并且会感觉更有控制力。
一个有效的 SDD 工具至少需要为几种不同的核心工作流提供灵活性，以适应不同规模和不同类型的变更。
比起评审代码，更应评审 markdown 文档？
正如前面提到的，从上面工具的描述中可以看出，spec-kit 为我创建了大量需要审查的 markdown 文件。它们彼此之间以及与已有代码之间有很多重复内容。有些文件已经包含了代码。总体来说，评审它们会非常繁重且乏味。在 Kiro 中情况稍微好一些，因为你只会得到 3 个文件，而且“需求 > 设计 > 任务”的思维模型理解起来更符合直觉。然而，如前所述，对于我要求它修复的小 bug，Kiro 也显得过于冗长。
说实话，比起评审所有这些 markdown 文件，我宁愿审查代码。一个有效的 SDD 工具必须提供非常好的规格评审体验。
虚假的控制感？
即使有所有这些文件、模板、提示词、工作流程和检查表，我也经常看到代理最终没有遵循所有指令。是的，上下文窗口现在更大了，这通常被提到是规格驱动开发的一个推动因素。但仅仅是更大的窗口而已，并不意味着 AI 会正确地捕捉到其中的所有内容。
例如：Spec-kit 在规划阶段有一个研究步骤，它对现有代码以及已有的内容做了大量研究，这很棒，因为我要求它添加一个基于现有代码的功能。但最终这个代理忽略了这些要点是对现有类的描述，它直接将它们视作新的规格，又重新生成了一遍，造成了重复。但我看到的也不只是忽略指令的例子，我还见过代理因为过于急切地遵循指令（例如“宪法”中的某一条款）而做得过火的情况。
过去已经表明，我们能够掌控自己正在构建的内容的最佳方式是采用小型、迭代的步骤，因此我非常怀疑大量预先的规格设计是否是个好主意，尤其是在规格过于冗长的情况下。一个有效的 SDD 工具必须能够适应迭代式的方法，但小型的工作包似乎又与 SDD 的理念背道而驰。
如何有效地将功能规格与技术规格分开？
在 SDD 中，一个常见的理念是有意区分功能规格和技术实现。我猜测其潜在的愿望是，最终我们可以让 AI 填充所有的解决方案和细节，并在相同的规格下切换到不同的技术栈。
实际上，在我试用 spec-kit 时，我经常会困惑于何时保持在功能层面，何时添加技术细节。教程和文档在这个问题上也不太一致，似乎是对“纯功能”的真正含义存在不同的解释。回想一下，我在职业生涯中读过许许多多的用户故事，它们都没有将需求与实现恰当地分离开来，我认为，我们整个行业在这方面的记录并不好。
谁是目标用户？
许多规格驱动开发工具的演示和教程包括定义产品和功能目标，甚至使用“用户故事”等术语。这里的想法可能是利用 AI 作为跨技能的推动者，让开发者更多地参与需求分析？或者让开发者在这个工作流程中与产品人员配对？不过，这些都没有明确说明，而是默认开发者会进行所有这些分析。
在这种情况下，我会再次问自己，SDD 适用于什么问题规模和类型？可能不适用于仍然非常不明确的大型功能，因为这肯定需要更多的专业产品和需求技能，以及许多其他步骤，如研究和利益相关者的参与。
基于规格和以规格为源：我们是否在从过去学习？
虽然许多人将 SDD 与 TDD 或 BDD 类比，但我认为另一个重要的值得平行关注的，特别是对于以规格为源的情况，那就是 MDD（模型驱动开发，model-driven-development）。我在职业生涯初期参与过几个大量使用 MDD 的项目，这让我在尝试 Tessl 框架时，不断想起这些经历。MDD 中的模型基本上就是规格，尽管不是自然语言表达，而是用自定义 UML 或文本 DSL 表达。我们构建了自定义代码生成器，将这些规格转换为代码。
最终，MDD 从未在业务应用领域真正流行起来，它处在一个尴尬的抽象层次，只会带来过多的开销和约束。但 LLM 消除了 MDD 的某些开销和约束，因此我们重新燃起了希望：现在终于可以专注于编写规格，然后直接从规格生成代码。借助 LLM，我们不再受限于预定义且可解析的规格语言，也不必构建复杂的代码生成器。当然，为此付出的代价是 LLM 带来的不确定性。而且，可解析的结构本来也有其优点，而我们现在正在失去这些优点：我们原本可以为规格编写者提供大量的工具支持，帮助他们写出有效、完整且一致的规格。我担心的是，“以规格为源”甚至是“基于规格”，最终可能会同时带来 MDD 和 LLM 的缺点：僵化与不确定性。
需要说明的是，我并不是在怀念过去使用 MDD 的经历，也不是说“我们干脆把它搬回来”。但在今天我们探索规格驱动开发时，确实应该回顾一下过去从规格生成代码的尝试，从中吸取经验教训。
结论
在我个人使用 AI 辅助编码的过程中，我也经常花时间先精心制作某种形式的规格，然后再交给编码代理。因此，规格优先的总体原则在许多情况下确实是有价值的，而如何构建这些规格的不同方法也非常受欢迎。这些问题是我目前在从业者那里听到的最常被问到的问题之一：“我如何构建我的记忆库？”，“我如何为 AI 编写一份好的规格和设计文档？”
但“规格驱动开发”这一术语尚未得到明确定义，而且已经出现了语义扩散的现象。我甚至最近听到有人将“规格”基本上作为“详细提示”的同义词使用。
关于我尝试过的工具，我在这里列出了许多关于它们在实际应用中有用性的问题。我想知道，其中一些工具是否试图过于字面地将我们的现有工作流程输入给 AI 代理，最终放大了现有的挑战，如评审过载和幻觉。尤其是对于那些创建大量文件的更复杂的方法，我不禁想起德语复合词“Verschlimmbesserung”：我们是在试图改进的过程中反而把事情弄得更糟吗？
