什么是 SDD

SDD 通常指 Spec-Driven Development，规范驱动开发。

大白话说：先把“要解决什么、什么算完成、有哪些约束”写成可以审查的规范，再让人和 Agent 围绕同一份规范设计、实现和验证，而不是只靠聊天记录往前冲。

为什么需要它

普通提示词开发容易出现这些问题：

• 需求只存在于某次会话，换一个 Agent 就丢了；
• “差不多做好了”没有客观验收标准；
• 设计、实现和测试互相脱节；
• 大任务做一半后，没人说得清剩余范围；
• 多人或多 Agent 并行时，各自理解不同。

SDD 把关键事实放进版本控制中的文档，让它们能 review、diff、追踪和复用。

一份典型规范包含什么

• 背景、目标和非目标；
• 用户场景与需求；
• 验收标准；
• 技术设计和约束；
• 任务拆分；
• 验证方式；
• 决策与变更记录。

不同框架的文件名不同，但核心都是把意图从临时对话变成仓库工件。

SDD 不等于自动交付

写了 spec.md 和 tasks.md，只代表“事情说清楚了一部分”。它不自动证明：

• 每个任务的依赖正确；
• 多个任务可以安全并行；
• Agent 使用了全新上下文；
• 代码真的通过测试；
• 测试绑定的是最新代码；
• 中断后不会重复执行；
• checkbox 对应的改动已经合入目标分支。

这正是 Spec Autonomous 补上的部分：保留 SDD 的事实源，再增加确定性的执行账本和验证交付协议。

规范和账本为什么要分开

规范回答“应该是什么”；运行账本回答“这一次发生了什么”。

把两者混在一起会导致：

• 运行失败污染产品规范；
• checkbox 被误当作测试证据；
• 数据库状态反过来取代团队可 review 的文档；
• 重新规划时历史 attempt 无处可查。

因此本项目坚持：

• OpenSpec / Spec Kit Markdown 拥有需求权威；
• SQLite 账本拥有 attempt、回执、证据和恢复状态；
• Git revision 和 hash 把两者绑定在某个精确快照上。