很多人用 AI 写代码，第一反应是直接把需求丢进去，然后期待它吐出一个能跑的结果。我自己试得越多，越觉得这种方式在小 demo 里很好，在真实项目里却很容易把返工提前透支掉。
这也是我现在更看重 spec-driven development 的原因：它看起来慢，但它其实是在把那些原本会在 review、联调、回归阶段爆出来的问题，提前拉到最前面。
它到底解决了什么问题
AI 写代码最大的问题从来不只是“代码对不对”，而是它太容易在需求还没被说清楚的时候就开始生成实现。于是你会看到一种很常见的情况：代码产出很快，但需求边界、异常分支、接口契约、状态迁移都还是模糊的。
Spec-driven 的价值在这里很直接：先把任务拆成规范、约束、验收条件，再让模型进入实现阶段。它本质上不是文档洁癖，而是把模糊性前置暴露。
为什么它对个人开发者反而有意义
很多人会觉得 spec-driven 更适合大公司流程，不适合个人项目。我反而觉得个人开发者更需要它。因为你没有专门的测试、产品、QA、架构评审来替你兜底，一旦需求写得含糊，最后所有返工都会回到你自己身上。
# task
实现订阅扣费失败后的重试逻辑
# constraints
- 不要重复扣费
- 失败后 5 分钟、30 分钟、24 小时重试
- 用户主动取消后停止重试
- 所有状态迁移必须可审计
# acceptance
- 提供状态图
- 提供测试用例清单
- 提供幂等键设计这一段 spec 写清楚以后，再交给 AI 去生成实现，质量通常会稳很多。因为你不是在让它“猜我要什么”，而是在让它“按约束完成任务”。
它慢在哪里
慢在前面。你得先写清楚边界，先定义好接口，先把验收条件列出来。这个过程没有直接产出功能，也不会给你即时反馈，所以很多人不愿意做。
但如果项目不是一次性脚本，而是要继续维护的产品，这个“慢”往往会在后面变成更少的返工、更少的误解、更小的 diff、更稳的 review。
容易被误解的地方
- 它不是要你先写一份大而全的需求文档；
- 它也不是把瀑布开发重新包装一遍；
- 它更不是为了让流程看起来更正式。
真正有效的 spec-driven 往往很短，但非常具体。它关注的不是背景铺陈，而是约束、失败条件、验收方式、不可做的事。
如果你只有半天时间
- 挑一个会写进数据库的业务场景；
- 先不用 AI 写代码，先让 AI 帮你补全 spec；
- 确认状态、异常、回滚、幂等这四件事是否写清；
- 最后再让它基于 spec 生成实现和测试。
这样试一次，你很快就能感受到差别。它不会让 AI 突然变聪明，但会显著减少“它写得挺多，结果改得也挺多”的无效输出。
我的判断
Spec-driven development 不性感，但很实用。如果你做的是需要维护的产品，而不是一次性 demo，我会建议尽早把“先写约束，再让 AI 实现”变成工作流的一部分。它看起来慢一点，但通常比无约束地让 AI 直接开写更省时间。