SDD是什么东西？一文看懂SDD的定义与作用

时间：2026-08-21 | 作者：宇宙开黑者 | 阅读：0

事情是这样的。

上个月我用 Claude Code 写一个优惠券核销的后端接口。

需求不复杂：用户下单时用券，扣减库存，记录流水，处理并发。

我心想，这点活 AI 不是分分钟搞定？于是打开终端，随口描述了一下需求，让它干活。

半小时后，代码确实写出来了。

该有的接口有了，数据库操作有了，甚至还贴心地加了单元测试。

我一看，挺好，跑一下——

崩了。

不是编译错误，不是空指针，而是逻辑层面的问题。

同一个订单号重复调用接口，券被扣了两次。幂等性没做。

我让它改。它确实改了，加了个 Redis 锁。

但锁的粒度不对，把整个用户的所有订单都锁住了。

再改，锁对了，但又忘了处理退款时券要不要退还的问题。

继续改，代码开始出现一些奇怪的判断逻辑。

很明显，这是前面几轮改动留下来的残余。

到第五轮的时候，我盯着那个接口文件里 400 多行代码，心里只有一个念头：

这代码我要是自己写，100 行就够了，而且不会出这些幺蛾子。

问题不在 AI，而在没有“谱”

问题出在哪？不是 AI 不行，是我没给它一个"谱"。

我让它"凭感觉写"，它当然只能凭感觉写。

这个感觉有时候对，有时候错，而且越改越偏。

这就是所谓的 Vibe Coding——氛围到了代码就出来了，但氛围这东西，它不靠谱。

这也是为什么SDD（Specification-Driven Development，规格驱动开发）最近突然火起来的原因。

SDD 不是新东西，但在 AI 时代有了新意义

先说清楚一个事：SDD 不是 AI 时代的发明。

早在 2000 年代就有人提过"以规格为中心的开发"。

甚至可以说，瀑布模型时代那些厚厚的需求文档，本质上就是一种 SDD。

只不过那时候是人写文档、人写代码，中间隔了十万八千里，文档写完就没人看了。

那为什么现在又火了？因为中间变了。

以前是人写 Spec，人写代码，Spec 是给人看的。

人看 Spec 的时候会走神、会理解偏差、会跳过不想看的章节。

所以那套玩法在敏捷时代被抛弃了。

大家发现，与其写一堆没人看的文档，不如直接面对面聊。

但现在不一样了。

现在是人写 Spec，AI 写代码。

AI 不会走神，不会理解偏差（前提是 Spec 写得够精确），也不会跳过任何一行。

这个变化很关键。

它意味着 Spec 不再是"仅供参考"的文档，而是变成了给 AI 的指令集。

你写得越精确，AI 生成的代码越靠谱。

你写得模糊，AI 就给你"自由发挥"——然后你就得像我一样，跟它来回拉扯五轮。

所以 SDD 的核心理念其实就一句话：

把"你想要什么"想清楚、写清楚，然后让 AI 去执行，而不是跟 AI 边聊边改。

用 SDD 的术语来说，就是：

SDD 的四步工作流

目前社区里比较主流的 SDD 工具——GitHub 的 Spec-Kit、Kiro、Tessl 等等——基本上都遵循一个类似的四步流程：

Spec → Design → Tasks → Code

我们一步步拆开来看。

Step 1: Spec（规格说明书）

Spec 解决的是"要做什么、不能做什么"。

它会写清楚用户场景、功能边界、异常情况和验收标准。

以一个"优惠券核销"功能为例，Spec 大概长这样：

# 优惠券核销功能规格## 用户场景用户下单时选择一张优惠券，系统核销该券并抵扣相应金额。## 核心规则- 一个订单只能使用一张优惠券- 核销时检查券的有效期、使用门槛、库存- 同一订单号重复调用接口，返回相同结果（幂等）- 订单全额退款时，优惠券退还- 订单部分退款时，优惠券不退还## 异常处理- 券已过期 → 返回错误码 COUPON_EXPIRED- 券已用完 → 返回错误码 COUPON_DEPLETED- 订单金额不满足门槛 → 返回错误码 THRESHOLD_NOT_MET- 并发核销同一张券 → 仅一次生效，其余返回 COUPON_ALREADY_USED## 验收标准- 并发 100 QPS 下，同一张券不会被重复核销- 核销记录写入数据库，支持审计追溯- 接口响应时间 P99 ≤ 200ms

值得玩味的是，这段规范里甚至没有一行代码，却把“功能该做什么”界定得清清楚楚。

一旦把这些细节前置，AI 自然无法遗漏幂等性要求。

毕竟，白纸黑字的规则面前，任何模糊都无处遁形。

而且 Spec 写完之后，你自己读一遍，经常会发现一些之前没想清楚的问题。

比如退款时券退不退？退多少？

这些在"边聊边写"的模式下很容易被忽略。

Step 2: Design（技术设计）

Design 解决的是"应该怎么做"。

包括技术方案、模块影响范围、数据流、接口依赖、兼容性要求。

说实话，对于小功能来说，Design 这一步经常显得多余。

有时候 Spec 写清楚了，AI 直接就能生成靠谱的代码。

但如果涉及多个模块的改动，或者有架构层面的决策，Design 就有用了。

比如你需要在 Redis 和数据库之间做分布式锁的选择，或者决定用消息队列还是同步调用。

这些决策放到 Design 里讨论，比让 AI 在写代码时瞎猜要靠谱得多。

Step 3: Tasks（任务拆解）

Tasks 把 Design 拆成可执行的步骤。

比如：

先处理数据库迁移脚本
再实现优惠券核销接口
补充并发控制逻辑
增加退款处理逻辑
编写测试并验证验收标准

拆解任务的核心逻辑，在于有效驾驭 AI 的工作节奏。

如果试图让 AI 一次性输出全部代码，往往会导致输出失控或逻辑混乱。

将复杂需求拆解为独立的小任务，逐个击破并实时验证，是保障最终交付质量的关键路径。

Step 4: Code（生成代码）

最后一步就是让 AI 根据 Spec、Design、Tasks 来生成代码。

因为前面三步已经把能想清楚的都想清楚了，这步通常比较顺利。

但这里有一个重要前提：AI 确实会按照 Spec 来写。

实践中，AI 有时会"自作主张"偏离 Spec。

比如你让它写单元测试，它可能跳过去直接写集成测试，然后标记"已完成"。

所以 Code 这一步的产物，你还是得看。

一个完整的 SDD 实践案例

光说不练假把式。

拿刚才的优惠券核销来完整走一遍。

我用的是 GitHub 的 Spec-Kit[1]，当然你也可以用 Kiro 或者自己手写 Markdown 然后丢给 Claude Code。

工具不重要，思路才重要。

首先写 Spec。

上面已经展示过了，不再重复。

写完 Spec 之后，我花了大概 10 分钟读了一遍，发现漏了一个场景：

如果用户下单后立即取消，券要不要退？答案是退。我补上了这条规则。

然后我让 AI 根据 Spec 生成 Design。

Design 里它建议用 Redis 分布式锁 + 数据库唯一索引做双重保障，我觉得合理，确认了。

接下来是 Tasks。

AI 自动生成了 6 个任务。

我调整了一下顺序，把"数据库迁移脚本"放在最前面。

最后让 AI 逐个执行任务。

整个过程大概 40 分钟，代码生成之后我检查了一遍，逻辑基本正确。

跑了一遍测试，并发场景下确实没有重复核销。

和我之前"边聊边改"花了将近两小时还改出 bug 的经历相比，效率提升明显。

但这不是重点。

重点是：这段代码我敢上线了。

因为 Spec 里明确写了幂等性、并发控制、退款逻辑，每个边界条件都有对应的测试用例。

我不需要靠"感觉"来判断代码对不对。

SDD 的槽点：它不是银弹

说实话，SDD 不是没毛病。

InfoQ 上 Franois Zaninotto 写了一篇很犀利的文章[2]，把 SDD 骂得挺狠。

我挑几个我觉得说得很对的点：

文档太多了。

即使是一个小功能，SDD 也能给你生成上千行 Markdown。

Spec 写一遍，Design 又是一遍，Tasks 再一遍——里面大量内容是重复的。

读这些文档本身就很花时间，有时候你读完发现，还不如自己直接写。
三步流程经常过度。

不是所有功能都需要 Spec + Design + Tasks。

一个改个文案的小需求，你也走一遍完整流程？那是给自己找事。

但 SDD 工具目前没有提供"轻量模式"，你只能全量或者不用。
对已有代码库不友好。

SDD 在从零开始的项目上表现很好。

但如果你在一个已经跑了两年的项目里加功能，AI 生成的 Spec 经常遗漏上下文。

它不知道某个功能已经存在，或者某个模块之前已经重构过。
双重审查。

Spec 里可能包含伪代码，你得审一遍。

最后生成的代码，你还得审一遍。

等于审了两遍。
边际效益递减。

项目初期，SDD 帮助很大。

但随着项目规模增长，维护 Spec 本身的成本也在涨。

Spec 写的跟不上代码改的，那就又回到了"文档滞后于代码"的老问题。