变更提案
把模糊需求整理成目标、非目标、验收标准、开放问题和证据要求。
打开模板SDD 文件链路
意图
spec.md在实现前写清目标、非目标、验收标准、边界条件和发布证据。设计
design.md记录架构选择、被拒绝方案、接口、上线顺序和运行约束。执行
tasks.md把工作拆成可评审任务，写明负责人、允许文件、验收链接和测试命令。证明
evidence.md把验收标准连接到测试、截图、日志、指标、手工检查和上线停止信号。为什么 SDD 能改善 AI 辅助交付
| 常见失败模式 | SDD 改变什么 | 评审信号 |
|---|---|---|
| 模糊提示词变成大 diff | 规格先写清非目标和允许行为。 | 规格外代码可以直接要求移除。 |
| 架构在生成过程中被发明 | 设计文档先写清接口、约束和被拒绝方案。 | 生成代码必须符合批准过的形状。 |
| 大 PR 难评审 | 任务按验收标准和文件归属拆开。 | 评审者可以检查更小的可测试切片。 |
| 把批准当成证明 | 证据日志把标准连接到测试、截图、指标和发布门禁。 | 合并评审有具体证据可看。 |
可复制的 SDD 模板
SDD、Spec-First、TDD 和 BDD
| 方法 | 核心问题 | 适合解决什么 |
|---|---|---|
| Spec-First Development | 写代码之前，应该先决定什么行为？ | 在实现前澄清产品和工程决策。 |
| Spec-Driven Development | 哪些仓库文件应该指导计划、编码和证据？ | 用可评审文件协调人工和 AI 代理。 |
| TDD | 哪些测试应该驱动实现？ | 在编码过程中保护单元、契约和回归。 |
| BDD | 哪些示例描述用户可见行为？ | 用业务可读语言写共享示例。 |
当前 SDD 工具带来的启发
OpenSpec 模式
先让变更意图可评审，再进入代码生成。有价值的是显式提案，而不是工具锁定。
Superpowers 模式
给编码代理持久技能和仓库规则，让重复工作遵循同一标准，而不是每次重新开聊天。
Spec Kit 模式
从 specification 到 plan 再到 task execution，让 AI 辅助实现拥有清晰决策轨迹。
FAQ
什么是 spec-driven development？
Spec-driven development 是一种先写可评审规格、约束、实现任务和验证证据，再进入主要代码改动的工作流。
SDD 和 spec-first development 有什么区别？
Spec-first 是先写行为再写代码的原则；SDD 更强调仓库里的文件链路，通常包括 spec、design、tasks 和 evidence。
SDD 会取代 TDD 或 BDD 吗？
不会。SDD 先决定行为和约束，TDD 和 BDD 可以继续用来编写测试和业务示例，证明规格被正确实现。
为什么 SDD 对 AI 编码重要？
AI 编码代理需要明确指令、非目标、允许文件和证据要求。SDD 在改代码之前提供一个可评审的事实来源。
最小可用的 SDD 包是什么？
最小 SDD 包可以是一个包含 spec.md、tasks.md 和 evidence.md 的文件夹；当架构选择需要评审时再加入 design.md。
先把 SDD 模板用在一个真实工单上。让它足够短，方便评审；也要足够具体，能阻止实现漂移。