前言
截至2026年7月，GitHub上关于SDD（规格驱动开发）的仓库中，spec-kit已获得超过12万Star，OpenSpec也拥有6万多Star。能在GitHub上收获如此高的关注度，背后必然有充分理由。AI写代码的速度已经如此之快、能力如此之强，为什么我们仍然需要SDD？本文旨在探讨这一问题。
我们平时怎么用AI开发的？
日常使用AI编写代码，流程大致如下：
提出需求↓让AI阅读项目↓让AI开始编写代码↓yes、yes、yes，don't ask me again↓运行与测试↓出现bug、需求理解有偏差↓督促AI："你这里写错了，我的意思是xxxxx"↓AI继续调整↓经过N轮迭代后终于完成↓不愧是我举个例子，想给一个Todo应用增加提醒功能，直接告诉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太快了。写代码速度太快，快到你还来不及把需求真正交代清楚，它就已经把代码写完了。等你回头一看，才发现这里不对、那里缺了东西，又得修修补补。
因此，它要解决的核心问题十分明确：
把原本在编码之后才发现的问题，尽量提前到编码之前解决。
以前是：
- 先写代码
- 运行后发现需求遗漏
- 修改需求和代码
SDD则是：
- 先整理需求
- 发现遗漏并确认
- 再生成代码
它当然不能消除所有返工，但只在几段文字的阶段修改需求，通常比代码已经散落到多个模块之后再修改要简单得多。
另外，它还顺带解决了一个重要问题——上下文问题。
直接使用AI开发时，很多决策会散落在你和AI的聊天记录中。换一个会话、换一个Agent，或者过一段时间再回来，甚至不小心关掉了这个会话，可能就忘了当时为什么这么实现。
而Spec、Plan和Tasks可以和代码一起保存在项目中，后续的AI可以直接读取，不需要每次都重新解释一遍。
用了之后会怎么样？
还是用Todo App的提醒功能来举例。
这次我们不急着让AI写代码，而是先告诉它：
经过几轮确认之后，最终，我们可能会得到一份像下面这样的规格：
## 目标用户可以为未完成的任务设置一个提醒时间。## 验收条件- 用户可以创建不包含提醒的任务；- 修改提醒时间后，只保留新的通知；- 完成或者删除任务后，取消对应通知；- 用户拒绝通知权限后，页面需要给出提示；- 点击通知后，打开对应任务。## 不包含- 不支持重复提醒；- 不支持服务端推送。规格确认后，再让AI根据项目生成技术方案：
方案确认后，再拆成任务：
最后才进入代码实现，并在完成后根据规格逐条验收。
所以，使用SDD后，开发过程并没有发生什么神奇的变化，仍然要写代码、运行测试、检查结果。
真正发生变化的是，AI不再只依赖一句临时提示词，而是根据一组经过确认的内容去干活。
聊天驱动代码，变成了规格驱动代码。
怎么用？
SDD并不需要你安装什么额外的工具，它本质上是一套规则。最简单的做法，在项目中自己加几个文件就能用起来：
docs/└── specs/└── task-reminder/├── spec.md├── plan.md└── tasks.md然后给自己定几条规则：
- Spec没有确认之前，不开始设计和实现
- Plan没有确认之前，不开始拆任务
- 每个任务都需要说明如何验证
- 实现中发现新需求，先更新Spec
- 完成后根据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：根据原始规格检查最终结果
- 哪些要求已经实现
- 哪些要求还没有实现
- 发现遗漏后补充任务并继续实现
整个过程可以概括为：
- 先确定项目规则
- 把需求说清楚
- 找出需求中的歧义
- 设计实现方案
- 拆成可以执行的任务
- 实现代码
- 回到原始需求验收
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 profile
openspec 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的整个过程可以概括为：
- 理解需求
- 建立一次独立变更
- 描述系统行为发生了什么变化
- 根据变更实现代码
- 需求或者方案变化时，更新已有产物
- 按需检查代码是否符合变更内容
- 把变化合并到当前规格
- 归档完整的开发历史
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-implcc-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的整个流程可以概括为：
- 先判断需不需要Spec
- 将需求拆成可以独立交付的范围
- 明确模块边界和依赖
- 拆成一个个独立任务
- 由不同Agent实现和审查
- 最后验证任务之间是否能够正确协作
它们有什么区别？
看完前面噼里啪啦的一堆流程，会发现它们都在做同一件事：先把需求变成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才开始发挥作用：
- 先写一个测试：完成任务后，应该调用取消提醒的方法
- 运行测试，因为代码还没有实现，所以测试失败
- 编写取消提醒的代码，让测试通过
- 整理代码，然后继续实现下一个行为
因此：
- SDD发现并确认 "完成任务后应该取消提醒"
- TDD确保这条行为被代码正确实现
TDD不会替你决定完成任务后究竟要不要取消提醒。如果需求没有提到权限失败，TDD也不会凭空替你补出这个场景。它只能在预期结果已经确定后，将这个结果变成测试，再推动代码实现。
此外，SDD并不要求必须使用TDD。在刚刚几个库中，cc-sdd明确将TDD放进了实现流程；Spec Kit可以按需生成测试先行的任务；OpenSpec则不限制具体的实现方式。TDD是SDD进入代码实现阶段后，可以采用的一种开发方式。
需要打造自己的SDD吗？
看完这些，你可能会发现，它们都很强，但未必和你平时的开发流程完全契合。不过没关系，我们可以自己打造专属于自己的SDD。
关键点在于，你在意的是什么，你希望AI帮你做到哪些东西，并把这个流程规范下来。
举个例子，如果是我自己，我关注的是：
- 需求上有什么遗漏或者不合理的地方吗？
- 代码准备怎么实现，大概会做哪些改动，为什么要选择这个方案？
- 会改哪里，影响的范围是哪些？
- 需要测试哪些场景，怎么样算测试通过？
- 这次改动如何长期记录和归档？
但列完之后，我发现OpenSpec其实就很符合我的需求。所以，打造自己SDD的这个大业就暂时搁置了。抛砖引玉，只是做一个思路的分享。后续可能我会将TDD的流程也引入进来，再说吧。
