规范驱动开发，为什么现在值得重看一遍？顺便聊聊 GitHub 的 spec-kit

过去团队的问题，是代码写得太慢。现在AI时代了,团队的问题，是代码写得太快、太多、太乱，以至于错误、歧义和返工。那么你可能需要一套SDD(Spec-DrivenDevelopment)了。

SDD 真正解决的，不是“写不出代码”，而是“写错了还以为自己写对了”

一个需求从提出到上线，往往会经历业务、产品、研发、测试四次翻译。最贵的问题从来不是没人动手，而是每个人都已经动手了，才发现理解根本不是同一件事。

这也是为什么很多项目看起来推进很快，最后却总在返工。不是因为团队不努力，而是因为系统缺少一个足够稳定的约束层。

SDD，也就是 Spec-Driven Development，本质上就是把这个约束层前置。它要求团队先把目标、边界、异常和验收标准说清，再进入实现。重点不是文档本身，而是让 spec 成为后续设计、编码、测试都能共同引用的基准。

没有 spec 的开发，很容易变成一种高速度的误解传递。

GitHub spec-kit 的价值，不在工具感，而在流程感

GitHub 开源的 spec-kit，本质上不是一个帮你自动生成代码的小玩具，而是一套把 SDD 真正落到 AI 编程工作流里的工具链。

它把流程拆成几步很清楚的动作：

• 用 constitution 先定义项目原则。
• 用 specify 先定义做什么，而不是先谈怎么做。
• 用 clarify 把模糊点问清。
• 用 plan 把技术方案落下来。
• 用 tasks 把方案拆成可执行任务。
• 最后再用 implement 进入实现。

这套设计最有价值的地方，是它强迫团队把意图和实现分开。先把需求讲清，再让 AI 和工程师去执行。这听起来像常识，但现实里恰恰最容易被跳过。

对于今天大量依赖 Copilot、Claude Code、Codex 这类工具的团队来说，spec-kit 提供的不是又一个命令集合，而是一种防止 AI 过早冲进实现细节的护栏。

如果你想上手 spec-kit，最小操作路径其实不复杂

根据 GitHub spec-kit 当前公开 README，最常见的起手式大概是这样。

先安装 CLI：

uv tool install specify-cli --from git+https://github.com/github/spec-kit.git@v0.7.0

如果你是在已有项目里初始化，并且想接 GitHub Copilot，可以直接：

specify init . --ai copilot --script ps
specify check

然后进入真正的 SDD 工作流：

/speckit.constitution
/speckit.specify
/speckit.clarify
/speckit.plan
/speckit.tasks
/speckit.analyze
/speckit.implement

这里有两个细节值得特别提。

第一，specify 阶段最好只谈 what 和 why，不要急着把技术栈写死。因为一旦过早进入 how，很多伪约束就会污染规范。

第二，clarify 这一步很关键。很多团队以为 spec 写完就够了，其实真正有价值的不是第一版 spec，而是它被追问之后留下来的那一版。模糊需求最怕的不是没人写，而是写得像已经清楚了。

好的 spec，不是更长，而是更能迫使团队做出关键判断。

怎么测试 spec-kit 和 SDD 有没有真的起作用

很多团队的问题，不是没写 spec，而是没验证 spec 是否产生了效果。所以测试不能只看代码跑没跑通，还要看 spec 有没有真正约束实现。

我建议至少做三层检查。

第一层，流程检查。

• 是否先有 spec，再有 plan，再有 tasks。
• tasks 能不能回溯到 spec 的要求。
• 实现过程中有没有绕过 spec 直接加需求。

第二层，结果检查。

• 每个验收条件是否都能映射到实际测试。
• 边界条件和失败路径是否在 spec 中出现，也在测试里被覆盖。
• 代码实现是否出现明显超出 spec 的顺手扩展。

第三层，团队效能检查。

• 需求评审后返工次数有没有下降。
• 测试阶段的歧义缺陷有没有下降。
• AI 生成代码的可接受率有没有提高。

如果要做一次最小验证，我会建议这样跑：

1. 选一个 1 到 3 天能做完的小功能。
2. 用 spec-kit 走完 constitution 到 tasks。
3. 按 spec 写实现和测试。
4. 在提测时专门记录因需求理解偏差导致的问题数。
5. 再和过去一个类似需求对比返工情况。

这才是判断 SDD 是否值得继续推开的证据。不是觉得流程更高级了，而是返工、歧义和无效实现确实少了。

一个实用的试跑方式

不要一上来拿核心业务做实验。找一个中等复杂度功能，满足三个条件：

• 有清晰输入输出。
• 有几条明确的异常路径。
• 有真实验收人，不只是开发自测。

比如用户资料编辑、订单取消流程、后台审批状态流转这种题目都合适。

用 spec-kit 跑完一轮之后，重点看三件事：

• 需求澄清次数有没有减少。
• 开发中途推翻方案的次数有没有减少。
• 测试阶段新发现的理解偏差有没有减少。

这比讨论 SDD 理论上先进不先进，有用得多。

写在最后

规范驱动开发今天重新重要，不是因为大家突然更爱文档了，而是因为 AI 把实现这件事变便宜了。实现一旦变便宜，约束就会变昂贵。

GitHub 的 spec-kit 有价值，不是因为它神奇，而是因为它把先对齐、再分解、再实现、再验证这件本来应该做的事，变成了一套可重复执行的路径。

如果说 Prompt 决定模型这一次怎么回答，那么 Spec 决定团队接下来几周到底在做什么。后者显然更值钱。

如果你想认真试一次 SDD，不要先问它能不能替代开发流程。先问：它能不能让团队少写一轮本不该写出来的代码。这才是最现实的标准。