如果你最近刷技术圈，会发现 “SDD”（Spec-Driven Development，规范驱动开发）这个词突然变得很火，经常和 “TDD”（Test-Driven Development，测试驱动开发）放在一起讨论，甚至有人说 “SDD 要取代 TDD 了”。

但你作为刚入门的新手，看到这种讨论很容易懵：TDD 我还没搞明白呢，怎么又来了一个 SDD？它们是竞争关系吗，我该学哪个？

那现在这篇文章将带你了解这两者究竟是什么。

一个场景：做一个"登录功能"

假设产品经理给你提了个需求：“做一个用户登录功能”。

如果什么都不想，直接打开编辑器开始写代码——边写边想字段、边想校验逻辑、边想报错提示——这种写法俗称"跟着感觉走"（在 AI 编程里也叫"vibe coding"）。写到一半发现漏了"密码错误 3 次要锁定账号"，又得回头改。

TDD 和 SDD，本质上都是"别一上来就乱写，先做点准备工作"的方法，只是它们准备的东西不一样。

TDD：先写"考卷"，再写"答案"

TDD 的核心套路是一个三步循环，俗称"红-绿-重构"：

1. 红：先写一个会失败的测试，比如"输入正确的用户名密码，应该返回登录成功"
2. 绿：写最少的代码，让这个测试跑通（变绿）
3. 重构：在测试保护下，把代码改得更整洁

用登录功能举例，TDD 的做法是：

先写测试：
- test_正确密码登录成功()
- test_错误密码返回提示()
- test_密码错误3次后账号锁定()

然后才去写 login() 函数的具体实现，
直到上面这些测试全部跑通。

TDD 回答的问题是：“这段代码写对了吗？” 它能保证你写的函数行为符合预期，但有个前提——你得先知道"应该有哪些行为"。如果你压根没想到"密码错误 3 次要锁定"这个需求，TDD 也帮不了你，它不会主动提醒你漏了什么。

SDD：先写"说明书"，再开始做

SDD 解决的恰恰是 TDD 没解决的那一层：“我们到底要做什么”。

它的做法是，在写任何代码之前，先写一份"规范文档"（Spec），里面写清楚：

• 这个功能要做什么、给谁用
• 输入输出是什么、有哪些边界情况
• 出错了应该怎么处理
• 怎么算"做对了"（验收标准）

还是登录功能，SDD 的做法可能是先写这样一份 spec：

## 功能：用户登录

### 输入
- 用户名（邮箱格式）
- 密码（6-20 位）

### 行为
- 用户名密码正确 → 登录成功，返回 token
- 密码错误 → 提示"用户名或密码错误"，不暴露具体哪个错了
- 同一账号密码连续错误 3 次 → 锁定 15 分钟，并提示剩余锁定时间

### 验收标准
- [ ] 正确凭证可以登录
- [ ] 错误凭证有统一提示
- [ ] 锁定逻辑生效，15 分钟后自动解锁

写完这份 spec 之后，测试、代码、文档都是从这份 spec "长出来"的——无论是你自己写，还是让 AI 编程工具（比如 Claude Code）按这份 spec 去生成代码和测试。

SDD 回答的问题是：“我们要做的这个东西，本身是对的吗？” 它发生在写代码之前，关注的是需求和边界，而不是某段代码的正确性。

它们是竞争关系吗？一张表说清楚

	TDD	SDD
关注层级	代码 / 函数层	需求 / 功能层
回答的问题	这段代码写对了吗？	我们要做的东西本身对吗？
起点	先写测试	先写规范（spec）
测试的角色	测试是"起点"，驱动代码编写	测试是"产物"，由 spec 派生出来
发生时机	写代码的过程中	写代码之前

看这张表就会发现：TDD 和 SDD 根本不是同一个层级的东西，不存在"谁取代谁"。一个关心"代码本身写得对不对"，一个关心"我们理解的需求对不对"。完全可以先用 SDD 想清楚要做什么，再在实现的时候继续用 TDD 的红绿循环来保证代码质量——SDD 里产出的验收标准，本身就可以变成 TDD 里的测试用例。

为什么最近大家突然开始聊 SDD？

核心原因和 AI 编程工具的普及有关。

人写代码的时候，如果需求有点模糊，最多是自己纠结半小时，或者去找产品经理确认一下，损失的是"几十分钟"。

但现在很多代码是 AI agent（比如 Claude Code）一次性生成几百行的。如果给它的需求是模糊的，它不会停下来问你"你说的这个边界情况具体是怎样的？“——它会直接基于自己的"猜测”，生成一大段看起来很合理、但实际上猜错了的代码。这种错误规模一旦放大到整个项目，排查和返工的成本会远超"提前把需求写清楚"的成本。

所以 SDD 在 AI 编程语境下，本质上是给 AI 立一份"说明书"，让它在动手之前，没有"猜"的空间。

新手该怎么入手？

不用一开始就追求"严格按照某个框架做 SDD"或者"100% 测试覆盖率"，可以从两个小习惯开始：

1. 写代码前，先写 2-3 句"这个功能应该怎么表现"，哪怕只是写在注释或者一个简单的 Markdown 文件里——这就是 SDD 思维的入门版。
2. 写完一个函数后，给它配一两个测试用例，验证关键的输入输出——这就是 TDD 思维的入门版，不用一开始就追求"测试先写"。

等这两个习惯都养成了，再去看 GitHub Spec Kit、Claude Code 里和 spec 相关的工作流，会发现它们做的事情，无非就是把这两个习惯"工具化、自动化"了而已。

总结

一句话概括：TDD 管的是"怎么把一件确定的事做对"，SDD 管的是"先把这件事到底是什么想清楚"。对新手来说，不用纠结"该学哪个"，它们解决的是软件开发里两个不同阶段的问题——而在 AI 帮你写代码的今天，"先把事情想清楚"这一步，正在变得比以前更重要。