AI 帮助开发团队生成代码的速度已经大幅提升。然而，Sonatype CEO Bhagwat Swaroop 在 2026 年 10 月发表的分析指出，速度本身正在制造一个新问题：当软件生产量远超人工审查能力，企业如何确认那些机器生成的代码是可以信任的？这篇文章拆解这个问题背后的决策逻辑，以及衡量 AI 真实价值的四个关键指标。
结果：代码产量暴增，但安全漏洞同步累积
根据 Sonatype 覆盖 2024 年 1 月至 2026 年 5 月的研究数据，企业每月创建的应用程序数量增长了近五倍。与此同时，每个应用平均包含的高危安全漏洞也增加了四倍以上。
安全团队确实在加快修复速度——同一研究显示，漏洞从被发现到解决的中位时间缩短了 59%。但修复速度的提升，追不上软件生产量和潜在风险的扩张速度。这是一个典型的 AI 时代悖论：能力在进步，但需要应对的体量增长得更快。
问题：用错误的指标衡量 AI，制造了看不见的债务
传统的软件开发指标——代码行数、完成任务数、提交请求量——让 AI 工具看起来效果显著。GitHub 的一项受控研究显示，使用 GitHub Copilot 的开发者通过基础单元测试的可能性高出约 53%。
但这些指标只衡量了软件生命周期的一个环节：代码是否被写出来了。它们没有回答更重要的问题：这些代码能否通过安全审查？能否稳定运行在生产环境？出问题后需要多少人工介入？
Swaroop 将这种现象命名为”验证债务”（verification debt）。当 AI 生成一个表面上正常运行的功能时，它可能同时引入了一个版本过旧的外部依赖，或者更改了某个敏感数据的访问权限。Sonatype 的研究发现，在被选用的有漏洞依赖项中，大多数情况下其实已经存在风险更低的可替代版本——但开发者或 AI 系统当时缺乏足够的上下文去做出更安全的选择。
如果 AI 帮开发者节省了 20 分钟写代码，却增加了一小时的审查、修复和解释工作，企业只是把工作量转移到了一个更不显眼的地方，整体生产效率并没有提升。
决定：把衡量重心从”生产了多少”移到”可信任多少”
Swaroop 的判断是：企业 AI 采用的下一阶段，需要一套新的价值衡量框架。问题不应该是”AI 帮我们写了多少代码”，而应该是”AI 帮我们交付了多少可信任、可上线的软件”。
他将这个框架称为”信心调整后的生产力”（confidence-adjusted productivity）。核心逻辑是：速度必须与可信度一起计算，否则只是在以机器速度积累技术债。
执行：四个真正有价值的衡量维度
Swaroop 提出了四个具体的衡量指标，用于替代传统的代码产量指标：
- 上线成功率（Production yield）：AI 辅助产生的变更，有多大比例真正成功上线并保持稳定运行？
- 返工量（Rework）：AI 生成的代码需要经历多少次额外的审查循环、漏洞修复、拒绝合并或回滚操作？
- 引入的风险（Risk introduced）：AI 辅助的变更中，有多少比例带入了有漏洞的依赖项、不安全配置或其他本可避免的问题？
- 人工监督成本（Human oversight）：将机器生成的输出转化为组织可以信任的软件，平均需要多少人工注意力和时间？
这四个维度组合在一起，才能给出 AI 工具真实价值的完整图像。单独看任何一个，都容易产生误判。
在执行层面，Swaroop 的建议是：企业需要明确划定哪些变更 AI 可以自主完成，哪些需要额外的自动化检查，哪些必须由人工审阅和批准。这不是限制 AI 的使用，而是为 AI 的输出建立可信任的路径。
成果：瓶颈从”生产速度”转移到了”信任速度”
供应链层面的数据已经说明了方向。Sonatype 的研究显示，企业确实在提升风险清理能力，但软件体量、依赖项数量和需要人工判断的决策点，正在以更快的速度扩张。安全团队不是在变慢，而是面对的目标在以更快的速度增多。
这意味着，下一个 AI 瓶颈不是算力，也不是模型能力，而是组织将 AI 生成内容转化为可信任软件的速度。谁能更快地完成这个转化，谁就掌握了下一阶段的竞争优势。
Lesson：速度是战术，信任才是战略
这个案例的核心教训不限于软件开发，它揭示了一个更普遍的 AI 采用规律：当一项工具大幅压低了某个环节的成本，下一个瓶颈必然出现在它的下游。
用错误的指标衡量 AI，会产生一种”进步的幻觉”——产量数字看起来漂亮，但真正的工作只是换了一个地方堆积。企业在引入 AI 工具时，需要同时设计一套与之匹配的信任验证机制，而不是等问题积累到生产环境才开始补救。
值得持续关注的问题是：随着 AI Agent 开始独立执行更复杂的工程任务，”人工监督成本”这一指标将如何变化？如果验证本身也交给 AI 来完成，谁来验证验证者？这个问题，目前还没有标准答案。
