很多人一听到 SDD，第一反应是：

“又要写文档了？”

“是不是又多了一套流程？”

“AI 都已经能写代码了，为什么还要回头写 spec？”

这种反应很正常。

因为过去很多团队被“文档驱动开发”折磨过。需求文档写得很厚，评审会开得很长，最后实现还是变形；设计文档放在知识库里，三个月后没人知道它还准不准；接口文档更新不及时，反而变成误导。

所以当 SDD 被翻译成 Spec-Driven Development 时，很多人会本能地把它理解成：

多写文档。

但真正值得在 AI 编程时代重新讨论的 SDD，重点根本不是“多写”。

而是“让 AI 不敢乱来”。

这里的“不敢”，不是指模型真的产生了心理压力。

而是你给它建立了一套协作约束：什么算听懂了，什么算不能做，什么算完成，什么证据才能通过，什么改动必须被 review。

没有这些约束，AI 写代码越快，风险扩散得越快。

有了这些约束，AI 的速度才会变成工程生产力，而不是工程债务的加速器。

一、AI 不缺执行力，缺的是边界感

现在的大模型写代码已经很积极。

你说一句“加个导出功能”，它会立刻开始改组件、加接口、写 helper、补按钮、改样式。

你说一句“这个 bug 修一下”，它会马上加空判断、包 try-catch、塞默认值。

你说一句“优化一下结构”，它甚至可能顺手重构半个模块。

问题在于，这些动作不一定错。

它们更危险的地方是：它们经常在边界还没确认之前就发生了。

导出哪些字段？

权限怎么判断？

数据量多大？

失败怎么处理？

旧逻辑能不能动？

测试覆盖哪些路径？

这些问题如果没有被问出来，AI 会自己补。

而 AI 最擅长的事情之一，就是把空白补成看起来合理的答案。

但工程里的空白，不应该由模型擅自填。

它应该被显式确认，被写成约束，被后续实现、验证和 review 反复对照。

这就是 SDD 在 AI 编程里的第一层价值：不是写一份漂亮文档，而是先把“不能乱猜”的地方固定下来。

二、文档本身拦不住 AI，契约才能

很多团队的问题不是没有文档。

而是文档没有进入工作流。

文档写完以后，AI 还是直接根据一句 prompt 开始写代码。

实现偏离了 spec，没有人检查。

测试没覆盖验收标准，也没人追问。

review 只看代码风格，不看它有没有违背原始意图。

最后文档就变成了一个“曾经认真过”的证据，但不是约束系统行为的契约。

真正的 SDD 必须让 spec 进入后续每一步。

需求阶段，它定义目标、范围、假设、风险和验收标准。

方案阶段，它约束实现选择，避免 AI 自己发明一套架构。

编码阶段，它告诉 AI 先锁住哪个行为，再动哪块代码。

验证阶段，它要求完成声明必须对应真实命令、真实结果、真实覆盖路径。

review 阶段，它提供判断标准：这次 diff 是否符合当初的契约。

所以 SDD 的重点不是“写了 spec”。

而是 spec 有没有成为后续动作的依据。

如果没有，文档再多也只是背景材料。

如果有，一页短 spec 也足够让 AI 收敛。

三、真正的 SDD，是让 AI 的每一步都有对账对象

AI 编程最常见的失控，不是它完全不会做。

恰恰相反，是它太会做。

它会在你没要求时扩展范围。

会在你没确认时选择方案。

会在没复现 bug 时直接修症状。

会在没验证时宣布完成。

会在 commit 前把无关改动一起带进去。

要控制这些问题，不能只靠一句“请谨慎一点”。

你需要对账对象。

它说需求已理解，就对账 spec：目标、范围、out of scope 是否明确？

它说方案可行，就对账 plan：为什么选这个方案，替代方案为什么不选？

它说 bug 已修，就对账 fix artifact：有没有复现、根因、回归测试？

它说任务完成，就对账 verify：跑了什么命令，覆盖了哪些路径？

它说可以提交，就对账 review：有没有无关改动、临时代码、测试缺口、约定冲突？

这才是“让 AI 不敢乱来”的具体含义。

不是靠语气压住它。

而是让每个“我理解了”“我修好了”“我完成了”，都必须拿证据来对账。

四、dev-skills 想解决的就是这个问题

我做 dev-skills，不是想再造一套复杂流程。

它的目标很简单：把 AI 写代码这件事拆成更稳的步骤，让不同场景下的 AI 先做该做的事。

项目地址在这里：

https://github.com/Jason-chen-coder/dev-skills

dev-skills 是一套给 Claude Code / Codex 用的 SDD-style 开发工作流规则集。它不是要把所有任务都变成重型流程，而是把常见工程动作拆成 11 个 skill：

需求模糊时，先用 dev-grill-docs 拷问需求、边界和验收标准。

方案复杂时，用 dev-plan 把实现路径、取舍和风险讲清楚。

写功能时，用 dev-tdd 先通过测试锁住行为，再写实现。

修 bug 时，用 dev-fix 先复现问题、确认 root cause，再修复。

声称完成前，用 dev-verify 要求拿出新鲜的验证证据。

准备 commit 前，用 dev-code-review 检查 diff 风险、无关改动和测试缺口。

不知道下一步该做什么时，用 dev-auto 看当前状态，推荐下一步，但它不会偷偷替你自动执行其他 skill。

这条链路可以很轻：

dev-grill-docs -> dev-tdd -> dev-verify -> dev-code-review

也可以更稳：

dev-grill-docs -> dev-plan -> dev-tdd -> dev-verify -> dev-code-review

bug 场景则是另一条路径：

dev-fix -> dev-verify -> dev-code-review

这些步骤的价值不在于“流程感”。

价值在于每一步都能拦住一种常见的 AI 失控。

dev-grill-docs 拦住“没听懂就开始写”。

dev-plan 拦住“没取舍就乱设计”。

dev-tdd 拦住“没锁行为就改代码”。

dev-fix 拦住“没找根因就修症状”。

dev-verify 拦住“没证据就说完成”。

dev-code-review 拦住“没审 diff 就提交”。

这就是我理解的轻量 SDD。

不是让每个小改动都写几十页文档。

而是在 AI 最容易乱来的地方，放上明确的门禁。

五、轻量 SDD 的关键，是不要把流程做重

SDD 也很容易走偏。

一种走偏是完全不写 spec，让 AI 每次从聊天上下文里猜。

另一种走偏是把 spec 变成新的官僚系统：所有改动都必须填模板，所有任务都必须走完整链路，连 typo 都要写验收标准。

这两种都不适合真实工程。

真正可用的 SDD 应该分层。

小任务可以 Spec-first：短 spec，明确目标、范围和验收标准即可。

复杂任务可以 Spec-anchored：spec 和 plan 作为后续实现、验证、review 的长期对齐依据。

但不要默认把 spec 当成代码生成源。

“Spec-as-source” 听起来很吸引人，但它需要严格 schema、生成器、迁移规则、漂移检测和大量工程约束。大多数团队现在真正缺的不是这个。

大多数团队缺的是更基础的东西：

AI 动手前，需求有没有对齐？

AI 改代码前，行为有没有锁住？

AI 修 bug 前，根因有没有确认？

AI 说完成前，证据有没有跑出来？

AI 提交前，diff 有没有被独立检查？

先把这些做好，收益已经很明显。

六、AI 编程的核心问题，不是生成，而是约束

过去我们讨论 AI 编程，太容易把注意力放在模型能力上。

哪个模型更强？

哪个上下文更长？

哪个工具调用更快？

哪个 agent 更自动？

这些当然重要。

但只要你把 AI 放进真实代码库，就会发现另一个问题更基础：

谁来约束它？

没有约束，AI 会把“合理猜测”写进代码。

没有约束，AI 会把“生成完成”包装成“任务完成”。

没有约束，AI 会把“症状消失”当成“问题解决”。

没有约束，AI 会把“能跑一次”当成“可以提交”。

真正的 SDD，不是为了让 AI 写得更慢。

而是为了让 AI 在正确的边界里快起来。

让它知道什么时候该问。

什么时候该停。

什么时候该验证。

什么时候不能越界。

什么时候必须拿证据说话。

如果说 prompt 是你和 AI 的一次性沟通，那么 SDD 就是你和 AI 的长期协作协议。

prompt 让它理解这一次要做什么。

SDD 让它知道每一次都不能怎么乱来。

这才是 AI 编程真正需要补上的工程层。

不是更多文档。

是更硬的约束。

不是让 AI 少写代码。

是让 AI 写出来的每一行，都能回到需求、方案、测试、验证和 review 里找到依据。

当这套协议建立起来，AI 才不只是一个很快的代码生成器。

它才更接近一个能被纳入工程体系的协作者。

如果你也在用 Claude Code 或 Codex 写代码，可以看一下 dev-skills：

https://github.com/Jason-chen-coder/dev-skills

它不承诺让 AI 永远不犯错。

它只做一件更实际的事：

让 AI 每次准备乱来的时候，先撞上一道工程门禁。