很多人写代码时习惯「边想边写」：需求在脑子里，手指已经在键盘上敲了。小功能也许没问题，但一旦项目变复杂、多人协作、或者让 AI 来写代码，问题就来了——每个人理解的「需求」都不一样。
规范驱动开发（Specification-Driven Development，简称 SDD）就是来解决这个问题的。
一句话理解 SDD
先写清楚「要做什么」，再动手写代码。规范是唯一的真相来源。
你可以把它想象成盖房子：不会先搬砖砌墙，再画图纸。而是先有设计图、施工规范，工人按图施工，监理按规范验收。
为什么需要 SDD？
传统开发里，需求常常散落在各处：
- 产品经理的口头描述
- 聊天记录里的零散补充
- 开发者自己的理解
- AI 对话里的临时指令
结果就是：
| 常见问题 | 表现 |
|---|---|
| 理解偏差 | 做出来的功能和预期不一致 |
| 反复返工 | 写完了才发现方向错了 |
| AI 输出不稳定 | 同样一句话，每次生成不同结果 |
| 难以维护 | 新人接手，不知道当初为什么这么写 |
SDD 的核心思路是：把需求从「模糊的想法」变成「可执行的规范文档」，让人和 AI 都对着同一份文档工作。
SDD 的三个核心原则
1. 规范先行
在写任何代码之前，先把需求写成结构化文档，包括：
- 功能目标（要解决什么问题）
- 用户场景（谁在什么情况下使用）
- 输入与输出（传什么、返回什么）
- 边界条件（异常情况怎么处理）
- 验收标准（怎样算「做完了」）
2. 规范即契约
规范不是「参考建议」，而是开发者和 AI 之间的合同。
- 代码必须符合规范
- 测试用例从规范推导
- 代码评审对照规范检查
- 规范变更了，代码也要跟着改
3. 规范可执行
好的规范不是空话，而是足够具体，能直接指导实现。比如：
❌ 模糊写法：「用户能登录」
✅ 可执行写法：
- 用户输入邮箱和密码，点击登录
- 邮箱格式不合法时，提示「请输入有效邮箱」
- 密码错误时，提示「账号或密码错误」（不透露是哪一个错了）
- 登录成功后跳转到 /dashboard
- 连续 5 次失败，锁定账号 15 分钟SDD 的工作流程
一个典型的 SDD 流程分四步：
1. 写规范 → 2. 评审规范 → 3. 按规范实现 → 4. 按规范验收第一步：写规范
用 Markdown 或专门模板，把功能描述清楚。可以借助 AI 帮你起草，但你必须审核确认。
第二步：评审规范
团队（或你自己）检查：有没有遗漏？边界情况考虑了吗？验收标准够具体吗？
这一步成本低，但价值极高——改文档比改代码便宜得多。
第三步：按规范实现
把规范交给 AI 或开发者，明确要求：严格按规范实现，不要自行发挥。
在 Cursor 等 AI 编辑器里，常见做法是：
- 把规范文件放在项目里（如
specs/目录） - 让 AI 先读规范，再写代码
- 每次改动都引用对应的规范条目
第四步：按规范验收
逐条对照验收标准检查，而不是凭感觉说「差不多行了」。
和其他开发方式的对比
| 方式 | 核心关注点 | 适合场景 |
|---|---|---|
| 代码驱动 | 先写代码，边写边改 | 个人小实验、原型验证 |
| 测试驱动（TDD） | 先写测试，再写实现 | 逻辑复杂、需要高覆盖率的模块 |
| 行为驱动（BDD） | 用自然语言描述行为 | 需要产品和开发对齐的场景 |
| 规范驱动（SDD） | 先定规范，再实现一切 | AI 辅助开发、团队协作、中大型功能 |
SDD 不是替代 TDD 或 BDD，而是更上游的环节——规范确定了，测试用例和实现方向自然就清晰了。
一个简单例子
假设要做「博客文章删除」功能。
没有 SDD 时，你可能对 AI 说：
帮我加个删除文章的功能。
AI 可能做成硬删除、可能没有确认弹窗、可能忘了刷新列表。
用 SDD 时，你先写规范：
## 功能：删除文章
### 目标
管理员可以删除不需要的文章，删除后前台不再展示。
### 交互流程
1. 文章列表每行有「删除」操作
2. 点击后进入确认页，展示文章标题
3. 确认后执行软删除（状态改为 archived）
4. 返回列表，该文章不再显示
5. 前台 /blog 页面同步更新
### 权限
需要 admin.posts.delete 权限
### 验收标准
- [ ] 删除后后台列表看不到该文章
- [ ] 删除后前台 /blog 看不到该文章
- [ ] 无权限用户看不到删除入口然后让 AI 按这份规范实现——结果会稳定得多。
写好规范的 5 个技巧
- 一条规范只描述一件事，不要又讲登录又讲支付
- 用「当…则…」句式描述行为和结果，清晰可测
- 主动写边界情况：空数据、权限不足、网络失败
- 验收标准用 checklist，做完一项勾一项
- 规范放在代码仓库里，和代码一起版本管理
什么时候特别适合用 SDD？
- 用 AI 生成或修改代码时（给 AI 一份明确的「施工图纸」）
- 多人协作的功能开发（消除口头沟通的歧义）
- 需要长期维护的项目（后人能看懂「当初为什么这么设计」）
- 对接外部系统、API 设计（接口契约本身就是规范）
个人写个 50 行的小脚本，不一定需要完整 SDD。但功能越复杂、参与者越多，SDD 的收益越大。
总结
规范驱动开发（SDD）的本质就三句话：
- 先规范，后代码——不要在模糊的需求上浪费写代码的时间
- 规范是契约——人和 AI 都按同一份文档干活
- 规范要可执行——具体到能验收、能测试、能直接指导实现
在 AI 编程时代，SDD 不是可选项，而是让 AI 真正靠谱的关键习惯。你写给 AI 的规范越清楚，它交给你的代码就越接近你想要的样子。
下次动手写功能前，先问自己一个问题：
如果我现在把键盘交给另一个人（或 AI），他能不能仅凭我的描述，一次就做对？
如果不能，先写规范。
