事情是这样的。

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

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

崩了。

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

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

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

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

我让它“凭感觉写”，它当然只能凭感觉写。这个感觉有时候对，有时候错，而且越改越偏。这就是简单讲的 Vibe Coding——氛围到了代码就出来了但氛围这东西，它不靠谱。

这也是为什么 SDD最近突然火起来的原因。

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

先说清楚一个事：SDD 不是 AI 时代的发明。早在年代就有人提过“以规格为中心的开发”，甚至瀑布模型时代那些厚厚的需求文档。本质上就是一种 SDD——只但是那时候是人写文档、人写代码，中间隔了十万八千里文档写完就没人看了。

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

• 以前是人写 Spec。人写代码，Spec 是给人看的。人看 Spec 的时候会走神、会理解偏差、会跳过不想看的章节。那套玩法在敏捷时代被抛弃——大家发现与其写一堆没人看的文档，不如直接面对面聊。

• 但现在不一样了。现在是人写 Spec，AI 写代码。AI 不会走神，不会理解偏差，不会跳过任何一行。

这个变化很关键。它代表着 Spec 不再是“仅供参考”的文档，而是变成了给 AI 的指令集。你写得越精确，AI 生成的代码越靠谱。你写得模糊，AI 就给你“自由发挥”——接下来你就得像我一样跟它来回拉扯五轮。

SDD 的主要理念其实就一句话：把“你想要什么”想清楚、写清楚。接下来让 AI 去执行，而不是跟 AI 边聊边改。

SDD 的四步工作流

• SdD 工具如 GitHub 的 Spec-Kit、Kiro、Tessl 等等基本上遵循一个差不多四步流程：Spec → Design → Tasks → Code

Step : Spec

痛点这方面。如果只靠自然语言描述，很容易遗漏边界条件导致后期反复调试。例如同一订单号重复调用接口导致券被扣两次就是因为没有明确幂等性要求。

Spec 解决的是“要做什么、不能做什么”。其实，它会写清楚使用者场景、功能边界、异常情况和验收标准。在优惠券核销功能中，一个典型 Spec 如下：

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

Step : Design

• Design 解决的是“应该怎么做”——技术方法、模块影响范围、数据流、接口依赖还有兼容性要求。在小功能中可能显得多余，但在涉及多模块或架构决策时必不可少。例如决定使用 Redis 分布式锁 + 数据库唯一索引双重保障，就放在 Design 阶段讨论而不是让 AI 随意猜测。

Step : Tasks

• Tasks 把 Design 拆成可执行步骤。例如：

- 实现核销接口
- 实现退款时券退还逻辑
- 编写单元测试
- 编写集成测试

• 拆解任务能控制 AI 步子，让每一步都可验证，从而明显提高整体质量和可维护性。

Step : Code

• 根据已完成的 Spec、Design 与 Tasks，让 AI 按顺序生成对应实现。当前面三步已经把能想清楚的都想清楚后这一步通常比较顺利。但仍需人工复审，因为 AI 有时可能自作主张偏离原始规范。例如直接跳到集成测试而忽略单元测试需求。

一个完整的 SDD 实践案例

• 先从实际痛点开始。我用了约30分钟读完刚才编制好的 Spec，并补充漏掉的关键场景，如订单取消后是否退还优惠券；随后让 AI 根据 Spec 自动生成 Design，我确认建议使用 Redis 分布式锁+数据库唯一索引双重保障。并标记为代码经过一次快速审核后即可上线，因为所有关键边界都已落到位，没有需要手动判断的问题；相比之前五轮修改导致两个小时以上时间浪费且频繁出现 bug。这种方式节省至少70%的工期，并明显提高稳定性与可维护度。

SDD 的槽点：它不是银弹

1. 三步流程经常过度。对于小修小改，一遍完整流程显然是冤枉自己。如果项目已有成熟规范则可以省略或简化此流程。其实，目前主流工具缺少轻量模式。需要全量或放弃 SD.
2. 对已有代码库不友好。在已有两年运行项目中添加新功能时新产生 Specs 往往无法捕捉上下文—例如某个模块已经重构或存在隐藏依赖。这使得 AI 输出往往与实际环境冲突，需要大量手工修正.
3. 双重审查成本高。怎么说呢，有些 Specs 包含伪代码，需要先审，再审最终生成代码，相当于 “两遍审核”。尤其对团队新人而言学习成本提高明显.
4. 边际效益递减。话说回来，一旦项目规模扩大并持续演进，在维护 Specs 与实现同步方面投入也随之增长，如果 Specs 没同步更新。则容易 陷入 “文档滞后于代码” 的老问题.

再看我的看法，什么时候用？什么时候别用，

• 适合用 SDD 场景：
  1. 从零起步的新项目，没有历史包袱；Specs 就是设计稿，
  2. 业务逻辑复杂、有大量边界条件，例如支付/优惠/权限程序;
  3. 多人协作。需要统一共识，使产品/研发/测试对需求保持一致;
  希望让 AI 完全承担实现工作，一个完整功能块可以由其独立完成;老实说，
• 不太适合 SDD 场景：
  小修小改。比如文本替换或样式微调，只需直接让 AI 即可; 探索性开发。对功能形态仍未确定，需要快速迭代实验; 大型已有项目中增添简单特性，由于上下文缺失导致 Specs 编排效率低于直接编码;

Caution：SdD 并非万能药，它只是把思考和实现分离的一种方法论。如果你自身没有先理清需求细节，即便 Specs 再详尽也无法防止错误；AI 会忠实执行你的错误指令。在使用之前先评估是否真的需要把业务细节抽象成正式 Docs，以免浪费时间。

如果你仍处于 “Vibe Coding” 阶段，不妨选取一个较小但业务关键度高的功能尝试完整 SD 流程。你会发现，“花费几分钟完善 Specs” 比 “无厘头多次修改” 更值得投资，也更能提高团队整体交付质量与信任度。