SDD，到底是个什么东西？

事情是这样的。

上个月我用 Claude Code 写一个优惠券核销的后端接口，需求不复杂：用户下单时用券，扣减库存，记录流水，处理并发。我心想这点活 AI 不是分分钟搞定？于是打开终端，随口描述了一下需求，让它干活。

半小时后，代码确实写出来了。该有的接口有了，数据库操作有了，甚至贴心地给我加了单元测试。我一看，挺好，跑一下------

崩了。

不是编译错误，不是空指针，而是逻辑层面的问题：同一个订单号重复调用接口，券被扣了两次。幂等性没做。

我让它改。它确实改了，加了个 Redis 锁。但锁的粒度不对，把整个用户的所有订单都锁住了。再改，锁对了，但又忘了处理退款时券要不要退还的问题。再改，代码开始出现一些奇怪的判断逻辑，明显是之前几轮改动的残余。

到第五轮的时候，我盯着那个接口文件里 400 多行代码，心里只有一个念头：这代码我要是自己写，100 行就够了，而且不会出这些幺蛾子。

问题出在哪？不是 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 的术语来说，就是：

Spec 是唯一真相源（Single Source of Truth），代码只是 Spec 的"最后一公里"。

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 里白纸黑字写着。

而且 Spec 写完之后，你自己读一遍，经常会发现一些之前没想清楚的问题。比如退款时券退不退？退多少？这些在"边聊边写"的模式下很容易被忽略。

Step 2: Design（技术设计）

Design 解决的是"应该怎么做"------技术方案、模块影响范围、数据流、接口依赖、兼容性要求。

说实话，对于小功能来说，Design 这一步经常显得多余。有时候 Spec 写清楚了，AI 直接就能生成靠谱的代码。但如果是涉及多个模块的改动，或者有架构层面的决策，Design 就有用了。

比如你需要在 Redis 和数据库之间做分布式锁的选择，或者决定用消息队列还是同步调用------这些决策放到 Design 里讨论，比让 AI 在写代码时瞎猜要靠谱得多。

Step 3: Tasks（任务拆解）

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

1. 创建优惠券核销数据库表
2. 实现核销接口（含幂等逻辑）
3. 实现退款时券退还逻辑
4. 编写单元测试（覆盖正常流程 + 异常场景）
5. 编写集成测试（并发场景）

这步的价值在于控制 AI 的"步子"。如果你让 AI 一次写完所有代码，它容易失控。拆成小任务，一个一个来，每一步都验证，整体质量会高很多。

Step 4: Code（生成代码）

最后一步就是让 AI 根据 Spec、Design、Tasks 来生成代码。因为前面三步已经把能想清楚的都想清楚了，这步通常比较顺利。

但这里有一个重要前提：AI 确实会按照 Spec 来写。实践中，AI 有时会"自作主张"偏离 Spec------比如你让它写单元测试，它可能跳过去直接写集成测试，然后标记"已完成"。所以 Code 这一步的产物，你还是得看。

一个完整的 SDD 实践案例

光说不练假把式。拿刚才的优惠券核销来完整走一遍。

我用的是 GitHub 的 Spec-Kit1，当然你也可以用 Kiro 或者自己手写 Markdown 然后丢给 Claude Code。工具不重要，思路才重要。

首先写 Spec。上面已经展示过了，不再重复。写完 Spec 之后，我花了大概 10 分钟读了一遍，发现漏了一个场景：如果用户下单后立即取消，券要不要退？答案是退。我补上了这条规则。

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

接下来是 Tasks，AI 自动生成了 6 个任务。我调整了一下顺序，把"数据库迁移脚本"放在最前面。

最后让 AI 逐个执行任务。整个过程大概 40 分钟，代码生成之后我检查了一遍，逻辑基本正确。跑了一遍测试，并发场景下确实没有重复核销。

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

但这不是重点。重点是：这段代码我敢上线了。因为 Spec 里明确写了幂等性、并发控制、退款逻辑，每个边界条件都有对应的测试用例。我不需要靠"感觉"来判断代码对不对。

关键收获 SDD 最大的价值不是"写得更快"，而是"写得更稳"。当 Spec 把边界条件都列清楚之后，AI 的代码质量会有一个质的提升。这就是从"Vibe Coding"到"Engineering"的转变。

SDD 的槽点：它不是银弹

说实话，SDD 不是没毛病。InfoQ 上 François Zaninotto 写了一篇很犀利的文章2，把 SDD 骂得挺狠。我挑几个我觉得说得很对的点：

1. 文档太多了。即使是一个小功能，SDD 也能给你生成上千行 Markdown。Spec 写一遍，Design 又是一遍，Tasks 再一遍------里面大量内容是重复的。读这些文档本身就很花时间，有时候你读完发现，还不如自己直接写。

2. 三步流程经常过度。不是所有功能都需要 Spec + Design + Tasks。一个改个文案的小需求，你也走一遍完整流程？那是给自己找事。但 SDD 工具目前没有提供"轻量模式"，你只能全量或者不用。

3. 对已有代码库不友好。SDD 在从零开始的项目上表现很好，但如果你在一个已经跑了两年的项目里加功能，AI 生成的 Spec 经常遗漏上下文------它不知道某个功能已经存在，或者某个模块之前已经重构过。

4. 双重审查。Spec 里可能包含伪代码，你得审一遍。最后生成的代码，你还得审一遍。等于审了两遍。

5. 边际效益递减。项目初期，SDD 帮助很大。但随着项目规模增长，维护 Spec 本身的成本也在涨。Spec 写的跟不上代码改的，那就又回到了"文档滞后于代码"的老问题。

这些槽点总结起来就是一句话：SDD 把"写代码"的时间省下来了，但把时间花在了"写文档"和"审文档"上。到底划不划算，取决于你的场景。

---

我的看法：什么时候用，什么时候别用

写了这么多，说说我自己的判断。

适合用 SDD 的场景：

• 从零开始的新项目。没有历史包袱，Spec 就是你的"设计稿"。
• 业务逻辑复杂、边界条件多的功能。比如支付、优惠券、权限系统------这些场景下，提前想清楚比事后修 bug 划算得多。
• 需要多人协作的功能。Spec 作为一种"共识文档"，让产品、开发、测试对需求的理解对齐。
• 你想让 AI 独立完成一个完整功能模块。没有 Spec，AI 容易跑偏；有了 Spec，AI 就像有了详细的任务清单。

不太适合用 SDD 的场景：

• 小修小改。改个文案、调个样式、修个简单的 bug------直接让 AI 干就行，不用大费周章写 Spec。
• 探索性开发。你还不确定功能长什么样，需要快速试错------这时候 Vibe Coding 反而更高效。
• 在大型已有项目里加简单功能。SDD 的上下文发现机制不够成熟，很多时候你写 Spec 的时间比 AI 写代码的时间还长。

最后说一个我觉得很重要的点：SDD 不是要取代你的判断力。它只是一个工具，帮你把"想"和"做"分开------先想清楚，再让 AI 去执行。但如果你自己都没想清楚，Spec 写得再详细也没用，AI 只会忠实执行你的错误。

所以，SDD 到底好不好用？

我的答案是：对的东西，用在对的场景，它就是好用的。别把它当成万能药，也别因为它有毛病就全盘否定。它就是一个让你和 AI 之间少一些"鸡同鸭讲"的方法论，仅此而已。

如果你还在"边聊边改"的 Vibe Coding 里挣扎，不妨试试。先拿一个小功能走一遍完整流程，感受一下。也许你会发现，写 Spec 的那 15 分钟，其实是最值得花的 15 分钟。