SDD

SDD 这里采用 Specification-Driven Development 的含义，即规格驱动开发。

1. 什么是 SDD

SDD 的核心思想是：

先把需求、约束、输入输出、边界和验收标准写清楚，再进入实现。

在 AI 协作开发里，这个思路更重要，因为模型非常依赖输入质量。规格不清，生成结果就会漂移。

2. 为什么 AI 时代更需要 SDD

传统开发中，需求写得模糊，资深工程师还能靠经验补洞。

但对 AI 来说：

• 模糊需求会直接变成模糊代码
• 漏掉约束会直接变成错误实现
• 缺少验收标准会导致输出无法判断对错

所以 SDD 本质上是在把“脑补空间”收窄。

3. 一份好规格至少应该包含什么

3.1 目标

这个功能到底要解决什么问题。

3.2 输入

• 输入来源
• 输入格式
• 必填字段
• 非法输入

3.3 输出

• 输出结构
• 成功条件
• 失败条件

3.4 业务规则

• 正常路径
• 异常路径
• 边界条件

3.5 非功能约束

例如：

• 性能
• 安全
• 权限
• 兼容性
• 可观测性

3.6 验收标准

最好写成可以检查的条件，而不是抽象描述。

例如：

• “支持用户登录”太模糊
• “邮箱密码正确时返回 access token，错误时返回 401 和明确错误码”才可验收

4. SDD 在 AI 协作里的典型流程

需求草稿
  -> 规格结构化
  -> AI 根据规格生成方案 / 代码
  -> 根据验收标准验证
  -> 发现缺口后修正规格
  -> 再生成 / 再修改

重点是：先修规格，再修实现。

5. SDD 与 Prompt Engineering 的关系

两者不是一回事。

Prompt Engineering

更关注怎么和模型说话。

SDD

更关注任务本身有没有被定义清楚。

可以理解为：

• SDD 负责“说什么”
• Prompt Engineering 负责“怎么说”

6. SDD 的常见模板

功能名称：
 
背景：
 
目标：
 
输入：
 
输出：
 
业务规则：
 
边界条件：
 
非功能要求：
 
验收标准：

7. 适合 SDD 的场景

• 接口设计
• 后端业务逻辑
• 前后端协作
• Agent 工具定义
• RAG 问答结构设计

尤其适合多人协作和长期维护场景。

8. 常见误区

8.1 只有大项目才需要规格

错。小功能也需要最小规格，否则返工成本更高。

8.2 规格写完就不能改

错。规格是迭代产物，但每次修改都应明确记录变化。

8.3 AI 可以替你补完所有隐含规则

错。AI 可以补建议，但不能替代业务责任。

9. 一个简单例子

模糊需求

“做一个评论功能。”

结构化规格

• 目标：登录用户可对文章发表评论
• 输入：文章 ID、评论内容
• 输出：创建成功后的评论对象
• 规则：评论长度 1 到 500 字；未登录不可提交；敏感词命中则拒绝
• 验收：成功返回 201；未登录返回 401；长度非法返回 400

AI 在第二种输入下生成的结果通常会稳定得多。

10. 一句话总结

SDD 的价值在于：先把问题定义清楚，再让 AI 或工程师去实现，这样系统才更可控。