假设你对 AI 说：“给系统增加一个会员续费功能”
几分钟后，它可能已经完成了数据库、接口、支付回调和前端页面的修改，甚至还补齐了一组全部通过的测试。速度固然令人兴奋，但真正的问题也随之出现：
未到期会员续费，应该从原到期日顺延，还是从付款日重新计算？
同一个支付回调如果到达两次，系统会不会重复增加会员时长？
支付成功后如果权益更新失败，应该如何补偿处理？
优惠券能否与续费折扣叠加使用？
测试通过，证明的是业务逻辑真的正确，还是只证明代码符合 AI 自己默认的假设？
AI 不会读心。需求中留下的每一个空白，都会被它用一个“看起来合理”的答案补上。一个假设可能只是小问题，但十几个相互影响的假设，足以让整个功能返工。
这正是 AI 编程时代最需要警惕的变化：代码生成越快，错误假设被固化和扩散的速度也越快。
从“代码产能”转向“意图治理”
过去，代码是昂贵的。一个模糊需求交给工程师后，工程师通常会一边理解、一边追问、一边实现。沟通未必总是充分，但人的犹豫、经验和代码审查，客观上形成了一层缓冲。
现在，AI 把这层缓冲压缩了。它可以在你还没有完全想清楚时，就迅速交付一个完整而自洽的错误答案。
于是，软件开发的核心瓶颈开始转移：
规约驱动开发（Spec-Driven Development，SDD），本质上就是针对这一新瓶颈给出的一套工程化解决方案。它不是让团队回到堆几十页没人愿意看的文档，而是先把目标、行为、边界、非目标以及验收证据整理成一份可审查、可追踪的规约；随后，无论是人还是 AI，都围绕同一份规约推进设计、拆分、实现和验证。
一条更可靠的开发链路应当是：
这里最关键的不是文档格式，而是“可追溯性”：每项任务能否对应到具体需求，每个测试能否说明自己验证了哪条验收标准，每次额外修改能否解释为什么没有超出范围。
好规约不是写得更多，而是让错误更早暴露
很多人把规约理解成“更详细的 Prompt”，但两者其实有本质区别。
Prompt 通常属于一次对话；规约属于项目。Prompt 会随着会话切换和上下文压缩而丢失，规约则应该进入版本管理，能够被审查、比较和持续维护。聊天适合探索，规约更适合承载团队需要长期相信的事实。
更重要的是，一份好的规约必须具备“可证伪性”。
“系统要稳定”“页面要友好”“尽快完成”都不是真正的约束，因为它们无法被客观检查。相比之下，下面这些表述更接近可执行规约：
同一支付回调重复到达时，会员时长只能增加一次
有效会员购买 30 天续费包后，从原到期时间顺延 30 天
支付成功但权益更新失败时，订单进入待补偿状态
本次不支持优惠券与续费折扣叠加
上述场景必须分别提供自动化测试或可复核的运行证据
规约的价值，不在于让文档显得更专业，而在于把争议和失败提前到代码生成之前。越早发现一句需求无法验收，就越少需要删除几千行“写得很好但方向错误”的代码。
规约的另一个作用：限制 AI 的错误半径
“把会员系统做完”不是一个任务，而是一个愿望。
如果 AI 一次性改动数据库、接口、定时任务、支付回调和页面，等人开始审查时，往往面对的是一份难以理解的大型变更。即便结果不对，也很难判断它从哪一步开始偏离。
更稳妥的方式，是把工作拆成能够独立审查和验证的小任务，例如：
明确会员期限计算规则，并覆盖未过期、已过期和跨月场景
为续费订单建立幂等约束，并验证重复请求
实现支付回调状态流转与失败补偿
增加页面交互与错误提示
完成端到端链路验证
这不是为了做出更漂亮的任务清单，而是在主动限制每次执行的影响半径。任务越小，反馈越快，错误被带到下一阶段的机会就越少。
因此，SDD 并不是瀑布开发的复活。瀑布之所以常被诟病，是因为它试图在很早的时候一次性冻结全部设计；现代规约驱动更像是一条带反馈的装配线：先把下一步所需的信息说清楚，小步实现，小步验证，遇到新事实就同步更新规约和设计。
不要把 SDD 变成新的形式主义
规约也有成本。改一个错别字，如果还要创建需求、设计、任务和验收四份文件，那不是工程化，而是流程表演。
更合理的做法，是按三个变量决定规约深度：
不确定性：需求中还有多少需要猜测的地方
影响半径：改动会跨越多少模块、服务和数据
错误代价：失败是否涉及资金、权限、隐私或不可逆数据
低风险的小改动，一段清晰说明和一项检查可能就够了；跨系统、涉及支付或数据一致性的功能，则值得建立完整的需求、设计、任务和验收链路。
团队还应警惕一种新的“规约债务”：代码已经变化，规约却停留在过去。当团队不知道应该相信代码、文档还是口头说明时，规约不仅失去价值，还会制造误导。
所以，规约必须有明确的生命周期。一次性原型可以在完成后归档；长期维护的业务系统，则至少应持续同步核心业务规则、接口契约和验收标准。不是所有细节都要成为永久真理，但被团队当作依据的内容必须可信。
一份可以马上使用的轻量模板
不必先引入复杂工具。对于一个中等复杂度功能，可以从下面这份最小规约开始：
先让 AI 根据现有代码和业务背景提出问题、识别歧义并生成初稿；再由人来决定目标、取舍和验收标准。AI 可以协助写规约，但不能替团队定义“什么才算正确”。
程序员的价值正在上移，而不是消失
当 AI 越来越擅长把明确方案翻译成代码时，人的价值会更多体现在上游和闭环处：
判断问题是否值得解决
识别真正的业务边界和冲突
在成本、风险与体验之间做取舍
审查 AI 提出的假设
定义能够证明结果正确的证据
对最终交付承担责任
未来优秀的工程师，不只是写出更多代码的人，也会是能够把模糊愿望整理成可执行约束、把复杂工作拆成可验证步骤，并能判断证据是否充分的人。
Vibe Coding 给了我们前所未有的速度，但速度本身不等于生产力。真正可靠的 AI 开发，需要方向盘、护栏和终点线。
模型会越来越强，代码会越来越便宜；清晰、可审查、可验证的意图，才会成为最稀缺的工程资产。
