AI Coding 那么快 为什么还需要 SDD

前言

截至 2026 年 7 月，GitHub 上关于 SDD 的库，spec-kit 已经有了 12 万多 Star，OpenSpec 也有 6 万多 Star。能在 GitHub 拿下这么高的 Star，想必是有说法的。AI 写代码已经那么快了，那么强了，为什么我们还需要 SDD？这篇文章就想聊聊这个。

我们平时怎么用 AI 开发的？

我们平时使用 AI 开发的流程，大概是下面这样的：

提个需求↓让 AI 去读项目↓让 AI 开始写代码↓yes、yes、yes，don't ask me again↓运行和测试↓有 bug、需求没理解对↓鞭笞 AI："你这里写的不对，我的意思是 xxxxx"↓AI 继续改↓N 轮之后终于搞定↓不愧是我

比如我们要给一个 Todo App 增加提醒功能，只需要告诉 AI：

AI 很快就能修改数据模型、增加时间选择页面，然后调用系统通知接口。

运行之后，也确实可以收到通知。

但真正开始测试的时候，可能会发现很多没有说清楚的问题：

• 用户拒绝通知权限后怎么办？
• 修改时间，旧的通知要不要取消？
• 删除或者完成任务后，通知还要不要触发？
• 点击通知后，应该进入哪个页面？

于是我们继续补充提示词，AI 继续修改代码。

但是其实并不是 AI 不会写，而是我们在写之前，没有交代清楚我们真正想要的结果，而那些没有说出来的部分，就只能 AI 自己去猜，猜对了，功能就能很快完成，猜错了，我们就得不断修改。

实际开发中，我们当然不一定只有一句需求，一般还会有一份需求文档。需求文档能够让我们知道这个功能是什么，但是不代表每一种情况下应该怎么表现、怎么交互都写得很明确。

测试同学在编写用例时，经常还会想到权限失败、重复操作、状态变化或者异常数据等场景。这部分的思考，应该在代码实现之前完成，不然 AI 可能会没有注意到这些细节。

当然，也不是在这个阶段就把所有测试用例写完。如果预期结果已经明确，只是需要更换设备、系统版本或者数据组合进行验证，那就留到测试阶段处理。

SDD 就是来解决这个问题的。

SDD 是什么？

SDD 全称 Specification-Driven Development，翻译过来就是规格驱动开发。

简单来说，就是在让 AI 写代码之前，先把要做的事情整理成一份明确的规格，然后再根据规格生成技术方案、任务和代码。

它的一个典型的流程是：

提出需求↓Specification：AI 问你想干啥，什么情况才算完成↓Plan：AI 给你描述它打算怎么实现↓Tasks：AI 将它的方案拆分成可以执行的任务↓Implement：AI 根据任务实现代码↓Verify：回到最开始的规格，检查结果是否符合需求

如果你用过 plan 模式，你应该会觉得这套流程似曾相识。

正经点就是：

• Specification：说明要做什么，什么情况算完成
• Plan：说明准备怎么实现
• Tasks：将方案拆成可以执行的任务
• Implement：根据任务实现代码
• Verify：回到最开始的规格，检查结果是否符合要求

为什么需要 SDD？

就是 AI 太快了，写代码太快了，快到你还没有真正的交代好需求，它就已经给你写完了，然后你回头发现，这里写的不对、那里缺了点东西，就得修修补补。

所以它解决的问题是：

它做的事情，就是 把原本在编码之后才发现的问题，尽量提前到编码之前解决。

以前是：

1. 先写代码
2. 运行后发现需求遗漏
3. 修改需求和代码

SDD 是：

1. 先整理需求
2. 发现遗漏并确认
3. 再生成代码

它并不能消除所有的返工，但在只有几段文字的时候修改需求，通常比代码已经散落到多个模块之后再修改简单。

另外，它还顺带解决了一个很重要的问题，就是 上下文的问题。

直接使用 AI 开发的时候，很多决定会散落在你和 AI 的聊天记录里，换一个会话、换一个 Agent，或者过一段时间再回来，或者你不小心关闭了这个会话，可能就会忘记当时为什么要这样实现。

而 Spec、Plan 和 Tasks 可以和代码一起保存在项目中，后面的 AI 可以直接读取，不需要我们每次都重新解释一遍。

用了之后会怎么样？

还是以 Todo App 的提醒功能来举例。

这次我们不让 AI 立即写代码，而是先告诉它：

经过几轮的确认之后，我们可能得到一份简单的规格：

## 目标用户可以为未完成的任务设置一个提醒时间。## 验收条件- 用户可以创建不包含提醒的任务；- 修改提醒时间后，只保留新的通知；- 完成或者删除任务后，取消对应通知；- 用户拒绝通知权限后，页面需要给出提示；- 点击通知后，打开对应任务。## 不包含- 不支持重复提醒；- 不支持服务端推送。

规格确认后，再让 AI 根据项目生成技术方案：

方案确认后，再拆成任务：

最后才进入代码实现，并在完成后根据规格逐条验收。

所以在使用 SDD 后，开发过程并没有发生什么神奇的变化，仍然要写代码、运行测试、检查结果。

真正发生变化的是，AI 不再只依赖一句临时提示词，而是根据一组经过确认的内容去干活。

所以，聊天驱动代码变成了，规格驱动代码。

怎么用？

它并不需要你去安装什么工具，它只是一套规则，最简单的，在项目中自己加几个文件就能用起来：

docs/└── specs/└── task-reminder/├── spec.md├── plan.md└── tasks.md

然后给自己定几条规则：

1. Spec 没有确认之前，不开始设计和实现
2. Plan 没有确认之前，不开始拆任务
3. 每个任务都需要说明怎么验证
4. 实现中发现新需求，先更新 Spec
5. 完成后根据 Spec 逐条验收

另外也不需要每个任务都走完整流程。

• 小任务直接实现
• 有一些边界条件的：Spec -> Tasks -> Implement -> Verify
• 影响多个模块：Spec -> Plan -> Tasks -> Implement -> Verify

SDD 的重点不在于生成多少份文档，而是根据任务复杂度，决定需要提前说清楚多少内容。

GitHub 上那些 SDD 库

Spec Kit

spec-kit 提供的完整能力大致如下。这里为了方便理解是列了完整的流程，但并不是每个需求都必须依次执行所有步骤：

Constitution（项目级）↓Specify↓Clarify（可选）↓Plan↓Checklist（可选）↓Tasks↓Analyze（可选）↓Implement↓Converge

其中，Constitution 主要用于定义项目长期遵守的原则，一般不需要为每个需求重复执行。

Clarify、Checklist 和 Analyze 都是按需使用的可选命令。

看看每一步都在做什么。

• Constitution（项目级）：定义整个项目需要遵守的原则

  • 使用什么架构和技术栈
  • 代码需要符合什么质量标准
  • 哪些内容必须经过测试
  • 是否允许添加第三方依赖

• Specify：将原始需求整理成 spec.md

  • 要解决什么问题
  • 用户可以做什么
  • 系统应该表现出什么行为
  • 什么情况才算完成

• Clarify（可选）：找出规格中没有说清楚的地方

  • 是否存在多种理解
  • 有没有遗漏边界情况
  • 哪些内容是 AI 自己做出的假设
  • 将确认后的答案写回 spec.md

• Plan：根据规格生成技术方案

  • 使用什么系统 API
  • 需要修改哪些模块
  • 数据如何流转
  • 使用什么方式进行测试

• Checklist（可选）：检查规格本身的质量

  • 需求是否完整
  • 表达是否明确
  • 不同需求之间是否冲突
  • 每一项是否可以验证

• Tasks：将技术方案拆成任务

  • 每个任务需要修改什么
  • 需要修改哪些文件
  • 任务之间有什么依赖
  • 完成之后如何验证

• Analyze（可选）：检查 Spec、Plan 和 Tasks 是否一致

  • 规格中的行为是否都有对应方案
  • 方案中的内容是否都被拆成任务
  • 是否存在遗漏或者冲突

• Implement：根据 tasks.md 实现代码

  • 按照依赖顺序执行任务
  • 运行对应测试
  • 更新任务完成状态

• Converge：根据原始规格检查最终结果

  • 哪些要求已经实现
  • 哪些要求还没有实现
  • 发现遗漏后补充任务并继续实现

它的整个过程可以概括为：

1. 先确定项目规则
2. 把需求说清楚
3. 找出需求中的歧义
4. 设计实现方案
5. 拆成可以执行的任务
6. 实现代码
7. 回到原始需求验收

OpenSpec

OpenSpec 和 Spec Kit 不同的是，OpenSpec 不强调必须依次经过多个阶段，而是把每个需求当成项目的一次变更。

项目中会同时保存两种规格：

openspec/specs/

记录系统当前已经确认的行为。

openspec/changes/

记录当前正在开发的变更。

OpenSpec 默认提供 Explore、Propose、Apply、Update、Sync 和 Archive 六个核心 Workflow。

Verify 不在默认的 Core Profile 中，但可以按需启用。它们的使用方式大致如下：

具体流程可以参考 OpenSpec OPSX 文档。

我们看看每一步都在做什么：

Explore

在正式创建变更前探索需求：

• 读取现有项目
• 理解当前实现
• 比较不同方案
• 找出没有说清楚的问题
• 不创建正式变更，也不修改代码

如果需求已经明确，可以直接跳过。

Propose

为需求创建一个独立的变更目录：

openspec/└── changes/└── change-name/├── proposal.md├── specs/├── design.md└── tasks.md

其中：

• proposal.md：为什么要做，会影响什么
• specs/：系统行为发生了什么变化
• design.md：准备如何实现
• tasks.md：需要完成哪些任务

规格会通过下面几种方式描述变化：

• ADDED：新增要求
• MODIFIED：修改已有要求
• REMOVED：删除要求
• RENAMED：只修改名称

design.md 不是所有需求都必须生成。如果变更涉及多个模块、数据模型、外部依赖或者重要技术选择，就需要先写 Design，简单修改可以省略。

Apply

根据变更中的文档实现代码：

• 读取 Proposal、Specs、Design 和 Tasks
• 按照任务列表修改代码
• 完成后更新任务状态
• 实现中发现需求或者方案发生变化时，先使用 Update 更新已有产物

这也是 OpenSpec 和固定阶段流程不同的地方：实现过程中如果需求或者方案发生变化，可以使用 Update 回到前面的产物，再继续 Apply。

Update

如果需求、技术方案或者任务发生变化，使用 Update 更新已经存在的变更产物：

• 修改已有的 Proposal、Specs、Design 或 Tasks
• 检查其他产物是否需要一起调整
• 保持需求、设计和任务之间的一致
• 不创建缺失的产物，也不修改代码

Update 不是 Apply 之后必须执行的固定步骤，而是在需求或者方案发生变化时按需使用。

如果代码已经按照旧方案实现，更新产物之后，还需要再次 Apply，让代码和新的方案保持一致。

Verify

检查代码是否符合变更内容：

• 所有任务是否完成
• 每条要求是否已经实现
• 边界情况是否处理
• 实现是否符合 Design

Verify 默认不在 Core Profile 中，需要手动启用：

openspec config profileopenspec update

在配置中勾选 verify 后，具体入口取决于所使用的 Agent 和 Delivery。

如果使用 Commands Delivery，通常是：

/opsx:verify

如果使用 Codex 的 Skills Delivery，则是：

$openspec-verify-change

复杂功能或者跨模块修改适合执行 Verify，简单并且已经充分测试的修改可以跳过。具体配置方式可以参考 OpenSpec Commands。

Sync

将当前变更中的规格合并到项目主规格：

openspec/changes/change-name/specs/ -> openspec/specs/

Sync 可以在开发过程中主动执行，让其他变更提前读取最新规格。

如果功能实现后马上归档，也可以不单独执行，等 Archive 时一起同步。

Archive

结束并归档本次变更：

• 检查文档和任务状态
• 提示同步尚未合并的规格
• 将变更移动到 archive/
• 保留 Proposal、Design、Tasks 和 Spec 的完整历史

归档后的结构大概是：

openspec/├── specs/│ └── 当前有效的规格└── changes/└── archive/└── 已经完成的变更

所以 OpenSpec 的整个过程可以概括为：

1. 理解需求
2. 建立一次独立变更
3. 描述系统行为发生了什么变化
4. 根据变更实现代码
5. 需求或者方案变化时，更新已有产物
6. 按需检查代码是否符合变更内容
7. 把变化合并到当前规格
8. 归档完整的开发历史

cc-sdd

cc-sdd 最关注两件事：

• 通过 Spec 明确模块边界和依赖关系
• 规格确认后，让 Agent 长时间、逐任务完成实现

cc-sdd 的整体流程如下：

具体流程可以参考 cc-sdd Workflow。

也来看看它的每一步在做什么：

Steering

记录整个项目的长期上下文：

• 使用什么架构和技术栈
• 代码目录如何组织
• 项目有哪些开发规范
• 模块之间有什么依赖
• 使用什么测试和验证方式

Steering 主要用于已有项目。如果 Agent 已经可以从其他文件获取完整项目规则，可以按需使用。

Discovery

判断当前需求应该采用什么开发方式：

• 直接实现，不创建 Spec
• 修改一个已有 Spec
• 创建一个新 Spec
• 将大需求拆成多个 Spec
• 将不同部分混合处理

Discovery 会保存 brief.md，让后面的 Agent 不需要重新理解需求。如果需要拆成多个 Spec，还会生成 roadmap.md。

所以 Discovery 不只是澄清需求，还负责判断这次工作到底需不需要进入完整 SDD。

Spec Init

为功能创建独立工作区：

.kiro/└── specs/└── feature-name/

后面的 Requirements、Design 和 Tasks 都会保存在这个目录中。

Design

生成技术设计：

• 调查当前项目实现
• 设计模块、接口和数据流
• 说明需要修改哪些文件
• 明确每个模块负责什么
• 记录模块之间允许的依赖

design.md 中会包含一份 File Structure Plan，用来划分后面任务可以修改的文件范围。

cc-sdd 将这一步称为 Boundary-First，也就是先确定边界，再让多个 Agent 独立工作。

Tasks

将 Design 拆成任务：

• 每个任务只负责一块明确工作
• 标记任务之间的依赖
• 说明允许修改的文件和模块
• 记录完成条件和验证方式

任务中会出现类似的标记：

_Boundary: 这个任务可以修改什么_Depends: 这个任务依赖什么

这样 Agent 执行任务时，不会随意修改范围之外的模块。

Spec Batch

如果 Discovery 判断需求过大，可以使用：

/kiro-spec-batch

它会：

• 根据 Roadmap 创建多个 Spec
• 并行生成不同 Spec
• 检查多个 Spec 之间是否存在冲突
• 检查接口和职责是否重复
• 确保每个 Spec 可以独立交付

Implementation

规格经过确认后，使用：

/kiro-impl

cc-sdd 支持两种实现方式。

自动模式：

• 每次只执行一个任务
• 为任务创建一个新的实现 Agent
• 使用 TDD 完成代码
• 再由独立的 Reviewer Agent 检查结果
• 失败时使用新的调试 Agent 分析原因
• 将经验写回 tasks.md，供后续任务读取

手动模式：

• 指定需要执行的任务
• 在当前会话中完成实现
• 同样按照测试、实现和验证的方式执行

具体执行方式可以参考 cc-sdd Skill Reference。

Validation

检查多个任务组合后的最终结果：

• 各任务是否都已经完成
• 实现是否违反模块边界
• 不同任务之间是否保持一致
• 测试、构建和静态检查是否通过
• 上游修改是否要求重新验证下游任务

单个任务的正确性主要由 Reviewer Agent 检查，Validation 更关注多个任务组合之后是否仍然能够正常工作。

cc-sdd 的核心

cc-sdd 不把 Spec 看成控制所有实现细节的总文档。

它更倾向于把 Spec 看成模块之间的合同：

• 这个模块负责什么
• 不负责什么
• 可以依赖什么
• 修改后需要重新验证什么

具体实现仍然可以由 Agent 自由决定，但不能越过已经确认的边界。cc-sdd 的设计说明 也明确提出，代码仍然是最终运行的真实结果，Spec 负责让责任和边界变得清楚。

所以 cc-sdd 的整个流程可以概括为：

1. 先判断需不需要 Spec
2. 将需求拆成可以独立交付的范围
3. 明确模块边界和依赖
4. 拆成一个个独立任务
5. 由不同 Agent 实现和审查
6. 最后验证任务之间是否能够正确协作

它们有什么区别？

看完前面噼里啪啦的一堆流程，会发现它们都在做同一件事：先把需求变成 Spec，再生成设计、任务和代码。

区别在于，它们关注的问题不同。

Spec Kit 更关注需求、方案和任务是否完整、一致。

它围绕需求、设计和任务提供一套完整能力，并根据任务复杂度按需使用 Clarify、Checklist 和 Analyze。

它是在问：

OpenSpec 更关注项目发生了什么变化。

它把每次需求记录成一次独立的变更，完成后再合并到项目当前的规格中，并保留完整的变更历史。

它是在问：

cc-sdd 更关注任务应该怎么拆，以及 Agent 应该怎样执行。

它会先明确模块边界和任务依赖，再让不同 Agent 分别负责实现、审查和验证。

它是在问：

所以简单来说：

• Spec Kit：强调让需求、方案和任务保持完整、一致
• OpenSpec：强调管理持续发生的变更
• cc-sdd：强调划分边界并让 Agent 持续执行

TDD 是什么？

说完 SDD，再说一下 TDD。

TDD 全称 Test-Driven Development，也就是测试驱动开发。它并不是代码写完以后再补测试，而是按照下面的流程反复开发：

先写一个测试，并确认它会失败（Red）↓写刚好能让测试通过的代码（Green）↓在测试仍然通过的前提喜爱整理代码（Refactor）↓继续实现下一行为

例如 SDD 先规定：

到了 TDD 阶段，就会先为这个行为编写测试，再实现取消提醒的代码，直到测试通过。

它和 SDD 并不是二选一的关系，它们解决的问题并不一样：

它们不在同一个层级里。可以把 TDD 理解成 SDD 的 Implement 阶段里，一种可选的开发方式：

SDD 工具负责外层流程规格↓设计↓任务↓实现↓验证在“实现”这一步里可以选择使用 TDD

还是用 Todo 提醒功能举例。

最开始我们发现一个问题：

这个问题应该由 SDD 处理，因为此时连正确结果是什么都不知道。经过确认，规格中写明：

接下来进入实现阶段，TDD 才开始发挥作用：

1. 先写一个测试：完成任务后，应该调用取消提醒的方法
2. 运行测试，因为代码还没有实现，所以测试失败
3. 编写取消提醒的代码，让测试通过
4. 整理代码，然后继续实现下一个行为

因此：

• SDD 发现并确认 "完成任务后应该取消提醒"
• TDD 确保这条行为被代码正确实现

TDD 不会替你决定完成任务后究竟要不要取消提醒。如果需求没有提到权限失败，TDD 也不会凭空替你补出这个场景。它只能在预期结果已经确定后，将这个结果变成测试，再推动代码实现。

还有，SDD 并不要求必须使用 TDD。在刚刚的几个库中，cc-sdd 明确将 TDD 放进了实现流程；Spec Kit 可以按需生成测试先行的任务；OpenSpec 则不限制具体的实现方式。TDD 是 SDD 进入到代码实现阶段后，可以采用的一种开发方式。

需要打造自己的 SDD 吗？

其实看完你可能会发现，它们都很强，但是它们不一定和你平时的开发流程很契合。不过好在，我们可以自己打造专属于自己的 SDD。

这里的关键是，你在意的是什么，你希望 AI 帮你做到哪些东西，并把这个流程给规范下来。

以我自己为例，我关注的是：

• 需求上有什么遗漏或者不合理的地方吗？
• 代码准备怎么实现，大概会做哪些改动，为什么要选择这个方案？
• 会改哪里，影响的范围是哪些？
• 需要测试哪些场景，怎么样算测试通过？
• 这次改动如何长期记录和归档？

但是列完之后我发现好像 OpenSpec 就很符合我的需求，所以打造自己的 SDD 这个大业就暂时搁置了，抛砖引玉，只是做一个思路的分享，后续可能我会将 TDD 的流程也引入进来，再说吧。