02 第一篇 · 先搞懂：为什么、是什么、选什么

SDD 是什么

这一章讲 SDD 是什么、不同方案共享什么骨架、规格交付后怎么维护，以及哪些任务不值得走完整流程。

SDD（Spec-Driven Development，规格驱动开发）是一种先固定意图和验收条件，再让 AI 实现的软件开发方式。它的重点不在于多写文档，而在于让人和 AI 对”要做什么、怎样算完成”有共同依据。

2.1 对 SDD 的两个误解

一提 SDD，最常见的是两个误解。

第一个误解：SDD 就是瀑布开发换了个名字。

不是。瀑布讲的是阶段顺序，总想在进下一阶段前把上一阶段做完做死。SDD 通常只围绕你手头这一次具体改动展开；计划或实现时发现规格理解错了，随时回头改。交付之后规格还维不维护，是另一个要单独选的问题，见下面的三种规格角色。

第二个误解：用了 SDD，改一行代码也要先写一大篇规格。

也不是。有一篇实测记录里，一个很小的缺陷修复，被重型 SDD 工具展开成了远超任务需要的一大堆验收内容。流程太重，本身就是负担。所以本手册按任务分档，不把每个改动都塞进完整 SDD。

SDD 真正要治的，是实现动手前没有共同依据这件事。规格可以很短，但得把这次任务最关键的意图和”算不算完”说清楚。

2.2 共通骨架与本手册的纪律

不同 SDD 方案用的词和产物不完全一样，但都能看到同一条骨架：

写清规格 → 制定计划 → 实现 → 对照规格验证

计划还能再拆成任务；验证可以靠自动化测试、代码审查和人工验收一起完成。它们的共同点是：先立一个能检查的目标，再让实现对着这个目标做。

对应上一章说的三条地基，本手册把这条骨架展开成：

规格与验收条件 → 计划 → 带验收条件的任务 → 按场景建测试安全网 → 实现 → 验证

至于规格交付后还维不维护，不是每种 SDD 方案都一样，得单独选。

2.3 三种规格角色

工程实践里，规格大致可以承担三种角色：

做法规格在当前任务中的角色交付后怎么处理
spec-first开始实现前写清当前任务可以不再维护；后续变更另写新的规格
spec-anchored作为实现与验收的持续锚点跟随功能一起演进
spec-as-source作为代码生成的唯一人工输入人主要修改规格，代码由系统生成

前两种已经能用在日常工程里。spec-as-source 对生成和验证链路的可靠性要求更高，不是本手册讨论的重点。

要注意，spec-kit 没有把这三种角色定成官方分类。它的核心交付链是 specify → plan → tasks → implement → converge；交付后规格怎么维护，它提供 Flow-Forward、Living Spec、Flow-Back 三种模型让团队自己选，官方不设默认。

2.4 可以直接做的任务

多个实践来源都发现，轻量任务套完整 SDD 容易得不偿失。所以本手册专门留出”不写 spec，直接做”这一档。

典型的几种：

要不要升到更完整的流程，看三件事：意图有没有歧义、改动好不好回退、影响面清不清楚。目标明确、容易回退、影响又小的，直接做；不确定性和风险一上来，再逐步加规格、计划和验证。

直接做不等于不检查。哪怕只改一个配置，也得留最基本的差异对比和结果验证。

本章小结

SDD 先固定意图和验收条件，再让 AI 实现。任务越轻，流程也应越轻；不确定性和改动风险上升时，再逐步增加规格、计划与验证。

参考与出处