规范驱动开发SDD详解

去年底我开始用 Claude Code 写业务代码。一开始确实爽跟 AI 用中文聊着天，哗哗出代码，一个下午就能搞出一个管理后台的雏形。感觉自己像个乐队指挥，AI 就是那个指哪打哪的乐手。

然后问题来了。

大概是第三周左右，我往项目里加一个新功能的时候，发现 AI 生成的代码风格跟之前完全不一样了。变量命名忽左忽右，有的地方用 snake_case，有的地方用 camelCase。更吓人的是它"忘记"了我们之前约定好的错误码规范，自顾自地返回了一堆 HTTP 500。

我当时心想：这 AI 怕不是得了失忆症。

后来才知道，圈子里管这个叫"上下文漂移"。说白了就是你跟 AI 聊的轮次越多，它对最初需求的理解就越偏。等你发现不对劲的时候，它已经离题三千里了。

这就是我入坑 SDD 的起点。

后来翻自己的笔记本，发现左边记"Vibe Coding"那段全是问号和叉叉，右边记 SDD 的时候明显清爽多了。人果然还是得先想清楚再动手。

SDD 不是啥高深的玩意

SDD，全称 Specification-Driven Development，规范驱动开发。名字听着挺唬人，其实道理简单得不行：

让 AI 写代码之前，先把"要做什么"写清楚。

就这一句话。不是什么银弹，不是啥方法论革命，就是一个很朴素的习惯——把需求写成一份结构化的文档，然后再让 AI 照着文档干活。

我一开始也觉得，这不就是写 PRD 吗？有啥新鲜的。但区别还挺大的。传统的 PRD 写完了就扔那儿了，代码一改，PRD 立马过时。SDD 里的规范不一样——它是"活"的。代码要改，先改规范；规范一改，AI 自动帮你重新生成代码。

知乎上有位腾讯技术大佬说过一句很到位的话："代码终将老去，规范永远年轻。" 规范承载的是系统为什么存在的本质意图，代码只是意图的某一次具体表达。

四步走，比我预想的简单

SDD 的工作流拆成四个阶段，而且这四个阶段不是那种"必须先做 A 才能做 B"的死板流程，你想回头改随时可以改。

1. Specify（写规范）。用中文把功能描述清楚。不用写得多专业，但要具体。比如"用户登录功能"就不够——你得写上手机号格式校验、密码最低长度、登录失败几次锁定、token 有效期多长。越具体越好，AI 不会嫌你啰嗦。

2. Plan（做方案）。这一步决定技术选型和架构。用 Spring Boot 还是 Go？数据库用 MySQL 还是 PG？接口是 RESTful 还是 GraphQL？这些决策一旦定下来，AI 后续就不会瞎改了。

3. Tasks（拆任务）。把方案拆成一个一个能独立执行的小任务。每个任务带产出路径和验收标准。这个的好处是你可以让多个 AI 同时干活——后端写接口，前端写页面，互不干扰。

4. Implement（实现）。AI 照着规范和任务清单写代码。写完了跑测试，不通过就回到规范阶段修正，再重新生成。

我第一次完整跑完这套流程，最大的感受是：慢在前期，快在后期。 写规范花了将近一个小时，但后面写代码和调 bug 的时间加起来不到以前的三分之一。

选啥工具？我踩过的坑

目前社区主流的 SDD 工具有三个：Spec Kit（GitHub 出品，28K+ Star）、OpenSpec（Fission AI，22K+ Star）、Superpowers（开源社区）。前两个我都用过，第三个还没来得及试。

说实话，网上很多对比文章写得都太"官方"了。我来讲讲真实感受。

Spec Kit 确实严谨，但也确实重。 它有 Constitution（宪章）→ Specify → Clarify → Plan → Tasks → Analyze → Implement 一共七个阶段。光 clarify 这一步，AI 能给你抛出二十几个问题，逐一回答完我头都大了。而且它要求一次性加载完整规范，你搞个稍大点的项目，上下文窗口分分钟爆满。

我看到腾讯后端团队的技术负责人 rickyshou 公开说过，他用 Spec Kit 三个月后选择放弃。原话是：

"Speckit 的规范流程在企业需求的'千层套路'、海量代码面前显得理想化，上下文窗口频繁爆满让复杂任务半途而废，每次做类似需求还是要花同样的时间，因为知识全在人脑里。"

这段话我当时看了真是感同身受。

OpenSpec 要灵活得多。 它的设计出发点就是"你大部分时间是在已有代码上改东西，不是从零开始"。它用 Delta 机制只记录每次改了什么，不存全量状态。命令也更自由，/opsx:ff 一口气生成全部产物，/opsx:continue 一步一步来，你按需选。

我现在的做法是：新项目启动阶段用 Spec Kit 把架构和核心规范敲死，进入日常迭代以后切到 OpenSpec 做增量变更。两个工具搭配着用，效果比单用任何一个都好。

不是所有场景都适合 SDD

说实话，SDD 不是万能的。有些时候用了反而更慢。

比如你只是想写个一次性脚本处理几百条数据，花了半小时写规范，脚本本身五分钟写完，这就有点本末倒置了。再比如 UI 层面的快速试错，你连自己要什么效果都没想清楚，写啥规范？先让 AI 生成几个版本看看再说。

SDD 真正发光的地方是这些场景：

1.多人协作的项目，前后端分离开发，用一份 API_CONTRACT.yaml 做锚点，后端写真实接口，前端自己 Mock 数据，两边同时开工，互不阻塞。

2.需求会频繁变更的长期项目，别直接改代码，先改 Spec。改一行 Spec 的成本远低于改一百行代码。而且 Spec 上留着变更记录，半年后你还能追溯"当初为什么这么做"。

3.对代码质量有硬性要求的场景，比如金融、权限系统这种容错率极低的模块。SDD 提供的验证机制可以减少很多低级错误。

最后说几句

这三个月用下来，SDD 给我最大的启发其实不是技术层面的。

是思维方式变了。以前拿到需求，第一反应是"怎么写代码"。现在第一反应是"先写清楚要什么"。听起来像废话，但真正养成这个习惯以后，返工少了一大半。

AI 编程工具越来越强，写代码本身已经不是瓶颈了。瓶颈变成了"写对代码"。而"写对"的前提，就是你先想清楚、写清楚。SDD 本质上就是逼你把这件事做在前面。

如果你也在用 AI 写代码但总觉得哪里不对，用AI写代码是快了，但质量忽高忽低，改到后面越改越乱，不妨试试先停下来，花半小时写一份像样的 Spec。比你在聊天框里反复纠正 AI 省时间得多。