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

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