AI 写代码已不是难题，验证才是新瓶颈

AI 编码助手正在大幅压缩从需求到可用代码的时间，但软件能否被安全交付，取决于另一套尚未同步提速的验证体系。作者在近期文章中提出「验证债务」（verification debt）这一概念：当组织用 AI 把软件产出量从每月 100 个变更提升到 300 个时，如果验证体系仍然只能高效处理 100 个，剩余的 200 个并不会变成已交付价值，而会堆积为待审查与待确认的积压队列。

代码生成提速不等于交付提速

一组常被引用的数据来自 Microsoft Research 的对照实验：使用 GitHub Copilot 的开发者比未使用者完成同一编程任务快 55.8%。然而，从「代码生成」到「可信赖交付」之间，仍需经过自动化测试、静态分析、安全扫描、依赖检查、集成测试、架构评审、业务验证、上线管控与生产监控等环节。第一阶段的提速速度已远超其他阶段。

DORA 2025 年的研究也佐证了这一观察：AI 采用率每提升 25%，软件交付吞吐反而下降约 1.5%，交付稳定性下降约 7.2%。需要指出的是，这是观察性结论而非因果证据；DORA 的解释是，AI 会让变更规模和数量同时变大，从而更难评审、更易引发不稳定。这与作者强调的「系统瓶颈后移」判断方向一致。

「验证」是多层活动的集合

验证并非单一动作，而是若干层相互重叠、却不能彼此替代的检查：

• 技术验证：是否编译通过、单元测试是否通过、静态分析是否发现明显问题。
• 系统验证：组件与数据库、消息队列、API、缓存、支付等服务交互时的行为。
• 安全验证：是否引入授权漏洞、数据泄露、依赖风险或新的攻击面。
• 业务验证：实现的业务规则是否真正是需求所要求的——这恰是多数自动化检查的薄弱区。
• 运维验证：重试、超时、部分故障、流量高峰、发布、回滚场景下的行为。
• 治理验证：能否解释改了什么、为什么改、依据什么证据可以发布。

绿色的测试套件只是证据，并不能证明业务流程正确。

「用 AI 验证 AI 自己的产出」存在结构性风险

文章也提示了一种常见但危险的实践：当同一个智能体既负责解读需求、生成实现，又负责生成测试、运行测试并复审代码时，它可能把同样的「误解」同时编码进实现和测试之中——测试于是确认了那个被错误理解的业务规则。这使工作流看起来完备，却并未真正提高验证的独立性。

更有意义的度量对象

基于以上分析，作者建议把衡量 AI 采用效果的指标从「生成的代码行数」「PR 数量」「开发者吞吐量」转向一个更系统的指标：「单位时间内可被安全交付、经过充分验证的生产变更数」。后者衡量的是整条交付链路，而不是其中最快的那个环节。

对于正在大规模引入 AI 编码助手的团队而言，与其继续追求更高的代码生成速度，不如把工程投入向验证体系倾斜：补齐测试覆盖、自动化安全与合规检查、建立独立于实现者的需求校验机制、并让监控与回滚能力跟上变更数量的增长。这才是把「写代码变快」转化为「业务交付变快」的关键。