AI 编程时代，真正稀缺的不是代码，而是可验证的意图

假设你对 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 开发，需要方向盘、护栏和终点线

模型会越来越强，代码会越来越便宜；清晰、可审查、可验证的意图，才会成为最稀缺的工程资产