# Spec-Driven Development Tools for AI Agents

> 原文链接：https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html
> 作者/来源：Birgitta Böckeler / Thoughtworks (Martin Fowler's blog)
> 阅读日期：2026-04-02

## 一句话总结
Spec-driven development (SDD) 工具（Kiro、Spec-kit、Tessl）试图将规范而非代码作为主要产物来驱动 AI 开发，但当前工具实现可能放大而非解决审查负担和 hallucination 等问题，需要从 Model-Driven Development 的历史教训中学习。

## 核心论点

Birgitta Böckeler 对 spec-driven development（SDD）进行了系统性的工具评估和批判性分析。SDD 的核心理念是"规范——而非代码——是主要产物"，用可测试的语言描述意图。她识别了三个递进的实现层级：**Spec-first**（规范先于代码，但可能在完成后被丢弃）、**Spec-anchored**（规范持续存在，用于后续功能演进和维护）、**Spec-as-source**（规范成为主要可编辑产物，代码自动生成）。

文章评估了三个工具。**Kiro** 采用最简单的线性工作流（Requirements → Design → Tasks），生成三个 markdown 文档指导开发，包含"steering" memory bank，但仅停留在 spec-first 层面。**Spec-kit**（GitHub 的 CLI 工具）有 Constitution（基础规则）、Specify、Plan、Tasks 工作流，大量依赖 markdown 清单和模板，但生成过多重复性文档文件，尽管声称 spec-anchored，实际仍是 spec-first。**Tessl**（私有测试版）是唯一明确追求 spec-anchored 和 spec-as-source 的工具，使用 `@generate` 和 `@test` 标签在规范与代码之间维持双向同步。

Böckeler 的批判性观察尤为重要：Kiro 和 spec-kit 都无法灵活适应不同规模的问题——简单的 bug 修复被迫走过于复杂的工作流；spec-kit 生成大量重复的 markdown 文件导致审查负担超过代码审查本身；AI agent 频繁忽略或过度解读指令，产生重复代码和规范违规。她还指出了与 Model-Driven Development (MDD) 的历史平行——MDD 最终因僵化和开销而失败，而 LLM 虽减少了一些 MDD 的限制，却引入了非确定性，可能结合了两种方法的缺点。

## 关键概念
- **Spec-first / Spec-anchored / Spec-as-source**：SDD 的三个递进层级，从规范作为一次性指导到规范作为可执行的主要产物
- **Steering Memory Bank**：Kiro 中用于存储产品、技术和结构信息的持久化配置，类似 `CLAUDE.md` 的角色
- **Constitution**：Spec-kit 中的基础规则文件，定义项目级别的约束和惯例
- **双向同步（Bidirectional Sync）**：Tessl 在规范和生成代码之间维持的双向映射关系
- **Model-Driven Development (MDD) 的历史教训**：类似的"从规范生成代码"思路曾经失败过，需要警惕重蹈覆辙

## 实践建议
1. SDD 工作流必须能适应不同规模的任务——不应强迫简单 bug 修复走完整的 spec 流程
2. 关注规范审查的体验——如果审查规范比审查代码更费力，工具就适得其反了
3. 明确区分功能性规范和技术实现细节——这是行业长期存在的挑战
4. 采用迭代方式而非大量前置规范——这更适合 AI 的能力特征
5. 从 MDD 的历史失败中学习：不要低估非确定性带来的新挑战
6. 如果选择 SDD 方法，先从 spec-first 开始，验证价值后再逐步向 spec-anchored 演进
7. 不要期望 SDD 工具消除 AI agent 忽略指令的问题——即使有详细规范，hallucination 仍然存在

## 独到观点
文章最有价值的贡献是将 SDD 与 Model-Driven Development 的历史进行类比。这个视角揭示了一个深刻的担忧：LLM 减少了 MDD 的一些限制（如灵活性），但引入了非确定性——可能导致"两个世界最差的组合"。此外，关于"审查负担"的观察指出了 SDD 的一个核心悖论：规范本应简化开发，但当工具生成大量需要审查的 markdown 文件时，实际上增加了认知负担。Böckeler 的结论"spec-first 原则有真正的价值，但当前工具实现可能放大而非解决问题"体现了 Thoughtworks 一贯的务实批判精神。

## 与其他文章的关联
- 与 **Fowler Anchoring to Reference**（#21）互补：参考应用是一种"活的规范"，可以作为 SDD 中 spec-anchored 层级的实现方式
- 与 **Fowler Humans and Agents**（#22）直接相关：SDD 工具本质上是在构建 "harness"——控制 how loop 的规范系统，体现"on the loop"思想
- 与 **Writing a Good CLAUDE.md**（#15）关联：Kiro 的 steering memory bank 和 `CLAUDE.md` 在功能上有重叠，都是为 agent 提供持久化 context
- 与 **Fowler Quality with Agents**（#20）相关：SDD 试图从源头保证代码质量，但 Böckeler 的评估显示当前工具还做不到这一点
- 与 **Claude Code Best Practices**（#23）对比：Claude Code 的方法更接近"迭代+验证"而非"大量前置规范"，这与 Böckeler 的建议一致
- 与 **Writing Tools for Agents**（#18）关联：SDD 工具本身也是需要精心设计的 agent 工具
- 与 **OpenHands Context Condensation**（#14）间接相关：SDD 生成的大量 markdown 文件也会消耗 context，需要考虑压缩策略