1.1 什么是 spec#

关于究竟什么是 spec，目前也并没有一个通用的定义。一个可能被大多数人接受的共识是：spec 类似一个产品需求文档（Product Requirements Document）。

Birgitta 试图给出一个明确的定义。在她看来：

spec 是一个结构化的、面向行为的产物（artifact）——或一组相关的产物——用自然语言编写，表达软件功能并作为 AI 编码代理（AI coding agents）的指导。每种 spec-driven development 的变体都定义了它们对 spec 结构、详细程度以及这些产物如何在项目中组织的方法。

从这个角度来看，spec 与我们的 codebase 中其他更通用的上下文文档之间存在区别。它们的区别在于：

• 通用的上下文文档与代码库中的所有 AI 编码会话都相关；
• 而 specs 只与实际上创建或更改特定功能的任务相关。

2.1 工作流与规模#

Kiro 和 spec-kit 各自提供一个有明确观点的工作流，但 Birgitta 认为，它们并不适合大多数现实的 coding 问题，尤其是面对不同的问题规模，这些工作流是否具有普遍性要打上一个大大的问号。

例如，如果用 Kiro 去修复一个小 bug，一个形象的比喻是“用大锤砸坚果”。Specs 将这个小 bug 变成了 4 个 user stories 与 16 个验收标准。

在使用 spec-kit 时，从 spec-kit 采取的步骤数量，以及为开发者创建的要审查的 markdown 文件数量来看，也明显出现了“过度杀伤”的问题。Spec-kit 是比 Kiro 还要复杂的一个工作流。

2.2 审查 markdown#

正如刚才提到的，正如你在上面的工具描述中看到的那样，spec-kit 为我创建了大量的 markdown 文件来审查。它们是重复的，彼此之间以及与已经存在的代码之间都是如此。有些已经包含了代码。总的来说，它们非常冗长，审查起来很乏味。

老实说，我宁愿审查代码也不愿审查所有这些 markdown 文件。一个有效的 SDD 工具必须提供非常好的 spec 审查体验。

2.3 虚假的控制感#

Birgitta 观察到，即使有我们上面提到的生成的所有这些文件、模板、提示、工作流和检查清单，她也经常看到 Agent 最终没有遵循所有指令。更大的上下文窗口并没有理所应当地带来 AI 理解其中所有内容的正确性。

这不仅仅体现在 Agent 没能遵循所有指令，也体现在它们因为过于热切地遵循指令而做得过火。

在过去，对于保持对所构建内容控制，我们的通常做法是使用小的、迭代的步骤。但小的工作步骤似乎又与 SDD 的理念相违背：

我非常怀疑大量的前期 spec 设计是否是一个好主意，特别是当它过于冗长时。

2.4 有效分离功能与技术#

在 SDD 中，有意分离功能规格（functional spec）和技术实现（technical implementation）是一个常见的想法。一个潜在的追求是，最终我们可以让 AI 填充所有的解决方案和细节，并使用相同的规格切换到不同的技术栈。

但在实践中，一个问题在于我们常常困惑何时应该保持在功能级别，何时应该添加技术细节，尤其是教程与文档在这方面也不完全一致，似乎对 ”纯功能（purely functional）“ 的真正含义有不同的解释。

2.5 目标用户#

许多 spec-driven development 工具的演示和教程包括定义产品和功能目标之类的内容，它们甚至纳入了”用户故事（user story）“等术语。这里的想法可能是将 AI 作为跨技能（cross-skilling）的推动者，让开发人员更多地参与需求分析？或者让开发人员与产品人员配对当他们处理这个工作流时？然而，这些都没有明确说明，它被呈现为理所当然的，即开发人员将完成所有这些分析。

在这种情况下，Birgitta 问道，SDD 旨在解决什么规模和问题类型？可能不是针对仍然非常不明确的大型功能，因为那肯定需要更专业的产品和需求技能，以及许多其他步骤，如研究和利益相关者参与？

2.6 出路#

这篇长文讲述了原作者从踩坑规范驱动工具，到借鉴 Anthropic 多 Agent 协作架构、融合上下文工程与复合工程理念，最终实现边际成本递减、知识持续复利的完整历程。