AI 辅助编码普及到现在，一个反差越来越普遍：代码生成的提速以倍数计，需求交付的提速往往只有一两成。原因其实不神秘：写代码从来只是软件交付的一环，AI 恰好只加速了这一环。真正限制交付速度的是两件事：需求里真正决定成败的信息，大半不在那句需求里，也不在 prompt 里（信息缺口）；AI 生成得越快，人检查确认的速度就越跟不上（验证瓶颈）。
一、代码会把每个「到时候再说」变成确定的行为
先看一个例子。产品提了句需求：「用户取消已付款、未发货的订单后自动退款，减少联系客服的等待。」
这句话在产品看来已经说清楚了，但真要写代码，你会发现它什么都没说。退款的钱从哪个账户走、走到哪里算到账？取消和发货同时发生怎么办？渠道没响应，重试还是放弃？怎么保证不会退两笔？每一个问题，代码都必须给出唯一答案。计算机不接收「到时候再说」：需求里每个悬而未决的选择，写进代码的那一刻都变成了确定的行为，至于符不符合真实业务，代码本身不负责。
换句话说，代码是需求的完全指定表述，它由三类信息构成：
第一类是需求写明的；第二类是按惯例就能展开的：语法、框架样板、项目既有写法，不需要谁做决定；第三类最麻烦，是需求没写、实现时却必须拍板的：接口约定、异常处理、旧系统限制、重试要不要防重。前两类 AI 都擅长，卡住交付的是第三类，因为它取决于这个项目的真实情况，而不是常见写法。
把研发生命周期看成一条传话链会更直观：业务意图从一端进，代码从另一端出，中间经过规格、上下文、实现、验证几站。真实目标和约束是有效信号，遗漏造成信号损失，没有依据的补全引入噪声，像传话游戏，错不在传得快慢，而在每一站丢了什么、加了什么。
还是退款那个例子：模型很可能先查订单是否「未发货」，再执行取消和退款。语法没问题，单次测试也能通过；但如果发货流程恰好在查询之后、取消之前推进，系统就会一边发货一边退款。实现能否成立，取决于这个系统怎么保证取消与发货不会同时成功，这项约束靠常见写法猜不出来。
所以 AI 编码的收益取决于任务的信息构成：照惯例展开的部分越多，提速越容易兑现；需要拍板的隐性决策越密集，收益就越取决于收集上下文、核对结果的成本。这解释了为什么同一个工具，在不同业务上体感差距那么大。
二、prompt 是一次有损压缩
大多数人给 AI 提供依据的方式，是在 chat 里打字。这个过程比看上去吃亏得多：你脑中装着领域规则、历史经验、系统细节，发 prompt 时会下意识做两件事：筛选，只说「跟这次有关」的；压缩，把来龙去脉简写成几行。信息在到达模型之前就已经丢了，像把原图转成小尺寸 JPEG 再转发，转完就回不来了。
典型的样子：老开发者知道退款重试「要按老办法处理」，打字时只写了「失败后重试」，防重条件没写。模型只能在缺约束的地方补一个常见实现。模型很擅长补全表达，但补回来的不保证是事实。
这里有个两难：写少了漏约束，后面返工；写足了，准备 prompt 加核对结果的时间又上去了，甚至比自己写还累。传统编码里，防重这类约束是边写边直接落进代码的；委托 AI 之后，这份知识必须先被表达才能被使用。代码的实现成本降了，知识的交付成本反而升了。
多聊几轮能补齐遗漏吗？可以，但前提是人先发现问题。人自己都没意识到的约束，永远不会出现在追问里。「没收到成功响应不代表退款没发生，直接重试可能重复退款」这类教训，只有撞上才知道。所以减少损耗的出路不是把 prompt 写更长，而是改变信息进入模型的方式：让模型直接读接口契约、历史故障记录和运行证据，chat 只讲本次新增的要求和未定的取舍；契约和领域知识跟代码同库同版本管理，别让每次任务都靠人凭记忆重新讲。
三、验证税：生成和检查的带宽不对称
就算上下文给足了，代码还是要被确认。这里有个朴素的度量：验证带宽，即单位时间内能可靠检查多少代码。AI 的生成带宽两年涨了一个数量级不止，人的验证带宽几乎没变。
生成速度超过验证速度之后只有两种结局：坚持逐行认真检查，交付在队列里排队；放宽检查，问题流进集成和线上，之后用缺陷和返工把时间加倍还回来。多轮对话看似构成了「发现问题—反馈—修正」的纠错循环，类似通信里的自动重传，但它的启动条件是人先发现错误。自动测试能分担的前提是判据已经明确，而明确判据本身还是要靠人。
这项新增的人力有个名字，叫验证税：确认 AI 产出所额外付出的人力，区别于原本就有的评审和测试。算净收益时要从生成节省里扣掉它，很多人只算了生成那一侧。
这不是纯理论推演。Faros AI 在 2025 年研究了超过 10,000 名开发者和 1,255 个团队，对比各团队低、高 AI 采纳期：合并 PR 数涨 98%，平均 PR 规模涨 154%，PR 评审时长涨 91%。Sonar 2026 年的调查里，38% 的受访者认为评审 AI 代码比评审同事的代码更费力。
注意口径：这两项都是观察和自报数据，覆盖的是 AI 辅助开发的整体影响，不能当成纯 vibe coding 的因果证据，看趋势比看绝对值更有意义。这个趋势值得注意：评审时长的涨幅低于代码量的涨幅，说明相当一部分变更没经过同等强度的审查就进去了。
四、没确认的假设，会把代码带向腐化
模型不知道重试必须保持是业务上的同一次退款，于是生成了普通的「再次调用」。演示一切正常，这个没确认的选择就留在代码里。暂时没出问题，会让假设看起来像已确认的事实，之后所有相关代码都开始依赖它。等真出了问题，修法通常是对着症状打补丁：退款重复了就在接口外加判断，页面状态不对就在前端补逻辑，回调延迟了再加一条状态更新路径。每个补丁都可能管用，但没有一条回到领域规则本身。
这个过程会自我强化，是它比普通技术债更凶的地方：腐化的代码成为后续生成的上下文，AI 看着现有代码继续写，把早期误判当项目惯例继承、巩固；生成成本又极低，团队倾向继续加代码而不是理解合并已有逻辑。落下来的债主要是三种：没确认过的实现假设、说不出出处的设计决策、本该复用却被反复复制的结构。最终局面是代码越来越多，团队却越来越难判断改哪里才安全。
手写代码同样会腐化，区别在于 AI 把「继续生成」和「打补丁」的成本压到接近于零，加速的不是腐化本身，是通向腐化的每一步。
五、算总账：编码不是全部
就算不谈腐化，只提速编码也有数学上限。阿姆达尔定律用大白话讲就是：你把流水线上最快的那道工序再提速十倍，整条线也不会快十倍，因为其他工序还在。编码占总耗时比例是 p，被加速 k 倍，端到端加速比最大也就 1/((1-p)+p/k)；即使编码瞬间完成，省掉的也只是原来花在编码上的那一份。
下游成本还会在这个上限之外继续加码。按需求范围不变做的示意账（示意结构，非任何团队实测值）：
编码从 30 降到 8，评审和测试却分别涨到 16 和 26，合计只从 100 降到 90。定律说的是「没被加速的部分限制整体收益」，表说的是「下游成本增加进一步抵消收益」，两个机制叠加才接近真实的账。更大的 diff 要求评审者一次理解更多选择，更多变更触及更多回归关系；验证失败后工作回流上游，返工继续占用本就紧张的验证资源。生成越快、错误发现得越晚，返工就越容易和新需求抢同一批人。
六、杠杆在两端：知识显式化，以及重建信任
把账合起来看，结论已经浮出来：AI 接管了中间的代码生成，人的投入会向两端移动：向左，参与需求、约束和规格的形成；向右，承担实现审查、系统验证和运行保障。
向左的动作是知识显式化：把装在个人脑子里的接口约定、业务例外、历史故障、验收标准，提前整理成 AI 可用的上下文、契约和验收条件。这件事有真实成本，只有这些信息被反复复用、切实减少后面的猜测和返工时，成本才摊得薄。
向右的难点是信任的建立方式变了：传统开发里理解和实现同步完成，AI 生成跳过了这个过程，只能靠审查、测试和运行结果重建理解。所以对 AI 产出建议按默认不信任验收：退款接口调用成功，只证明这条请求路径能跑通，不能证明超时重试不会重复退款、取消与发货的竞争被正确处理。有一条纪律特别值得单说：验证证据要独立于生成过程：让模型根据自己的实现反推测试，很可能把同一个误解同时写进代码和断言，测试全绿，误解原样通过。
七、哪些任务真正吃得到红利
判断标准就三条：隐性约束少不多、验收直接不直接、生命周期长不长。
最占便宜的是「日抛型应用」，逻辑简单、用完即丢。比如只做退款需求的交互原型：虚构订单、模拟到账，业务方点一点确认流程符合预期，原型就完成使命。没有历史系统约束、没有长期维护，生成节省的时间几乎不会被后续成本吃掉。
复杂系统是另一番景象：接入真实支付、库存、发货之后，一次取消可能撞上仓库发货，超时重试可能造成两笔退款，延迟回调可能覆盖新状态。「接口调用成功」只能证明一条路径跑通。AI 省下的编码时间会被上下文搜集、集成验证、异常处理和后续维护抵消掉一块。能不能赚到，取决于系统事实能否充分进入上下文、变更能否靠独立证据完成验证。
组织层面的答案是把「离原始信源最近、对结果负责」的人组织起来：让在明确范围内借助 AI 贯通需求、实现和验证的超级个体（或小型交付单元）直接确认用户目标、核对关键规则，减少需求在岗位之间反复转述的损耗。信息论里的数据处理不等式说的就是这件事：二手信息加工不出新信息，复述者省略的，听者靠推断补不回来，只有直接访问原始材料才能打破。
平台层面的答案是把每次变更「依据了哪些事实、通过了哪些检查、产生了什么运行结果」全部可追溯，先扩充证据、再扩充自动执行范围；把流程串起来不等于质量有保证，如果多个 agent 只依赖上一步的摘要，岗位接力只是变成 agent 之间的摘要接力。
写在最后
Vibe coding 改变的是软件开发的成本结构，它没有消除需求确认、系统取舍、独立验证和运行反馈的成本。衡量提效的标准因此很具体：在质量要求不变的前提下，需求能否更快、更稳定地转化为真实可用的结果，而不是代码产量，也不是 agent 数量。任务越明确、证据越充分，生成速度越容易变成交付速度；系统越复杂，越需要靠知识显式化、独立验证和贯通的信息与证据，把局部的编码提速兑换成整体的交付能力。
