你发布的软件与你所证明安全的部分之间，存在着一个未知的风险地带。

软件交付一直存在一种失衡：修改系统很容易，但要证明这种修改在真实负载、真实依赖和真实故障模式下是安全的却很难。在生成式 AI 出现之前，这种失衡由于一个现实条件的约束而得到了部分缓解，即：人的注意力。人类编写代码、审查代码，自动化测试伴随每次变更运行，有限的灰度发布（Canary Rollout）让新行为在全量推送前先接触真实流量。

在重度依赖 AI 的团队中，这层约束正在松动。当起草变更的边际成本大幅下降，提交审查的代码会变多，需要集成测试的交互也会变多；即便每次改动很小，生产环境面临的变更频率也会上升。此时的风险并非团队变得粗心大意，而是那些“表面看起来正确”的代码变得泛滥，而证明其安全性的证据却依然稀缺。

这至关重要，因为对 AI 的应用已从尝试转向习惯。根据 Stack Overflow 2025 年开发者调查，84% 的受访者正在使用或计划使用 AI 工具，51% 的专业开发者每天都在使用它们。当一种工具成为日常习惯，它就不再仅仅是一个偏好，而成了交付系统的一种属性。它重塑了什么是被审查的、什么是被测试的、什么是被合并的，以及最终什么是被交付的。

什么是验证债务

这种错位积累后的产物，有一个贴切的名字：验证债务（Verification Debt）。它是指你发布的软件与你所证明安全的部分之间的差距，这种证明必须是在接近生产环境的条件下收集到、能够体现安全性和鲁棒性的证据。技术债务是对“未来变更成本”的博弈，而验证债务则是你当下正背负的未知风险。

这里的“验证”并非指严密的定理证明。它指的是来自测试、灰度发布、安全检查和生产环境实时信号的证据，这些证据必须足够有力，能决定是否终止发布或触发回滚。它关注的是真实条件下运行时的不确定性，而非代码整洁度、可维护性，也绝不仅仅是缺失了几个单元测试。

如果你想在不增加新仪表盘的情况下识别验证债务，可以观察一些现有的替代性指标：

• 在金丝雀发布后，你需要多久能检测到回归缺陷？
• 在扩大流量后，触发回滚的频率是多少？
• 有多少次发布是在没有观察到稳定实时信号的情况下就扩大了规模？

你可以明确追踪这些指标：“金丝雀后检测到回归的时间”、“安全回滚的时间”，以及“在没有定义信号看板的情况下进行的流量扩张比例”。这些指标不完美，但能用来判断验证能力是否跟得上代码变更的节奏。

现有证据开始表明...

故障的形态（Texture of failure）也在发生变化。在 AI 辅助的工作流中，产物看起来很干净，解释听起来很自信，但底层行为可能是错误的，且这种错误只有在真实交互时才会暴露。干净的 Diff 记录会降低人们感知到的风险，这意味着细微的回归缺陷可能会传播得更远才被发现。问题往往出现在系统衔接处、非核心（慢速）路径、集成的边缘案例以及超时引发的连锁反应中。

早期证据表明，瓶颈已经从“编写”转移到了“验证”。METR（"模型评估与威胁研究"，一个非营利性的研究组织）对经验丰富的开源开发者进行的一项随机对照试验发现，使用 2025 年初的 AI 工具平均使任务完成时间增加了 19%。在开始任务前，开发者预测 AI 会减少 24% 的时间；但在完成后，他们估计 AI 仅减少了 20%。这个差距印证了一个假设：生成代码变快了，但集成和验证的时间却在增长。

安全领域是“表面正确不代表安全”的典型案例。在 Veracode 对 100 多个大语言模型（涵盖 Java, Python, C#, JavaScript）生成的代码评估中，45% 的代码样本未能通过安全测试，并引入了 OWASP Top 10 漏洞。其中，跨站脚本攻击（CWE 80）在 86% 的相关样本中检测失败。这并不意味着 AI 总是写出不安全的代码，它传达了一个对工程师更有用的信息：产出可以看起来很精致、功能正常，但依然是不安全的。当生成速度超过验证速度，一旦系统遇到真实用户和攻击者，验证债务就会转化为安全债务。

为什么验证无法像生成那样扩展

这时候你可能会问：既然有了生成式 AI，为什么没有同样速度的“验证 AI”来中和这个问题？

因为验证与生成并非同一类问题。

生成产生的是“看起来合理”的产物。而验证需要一个预言机（Oracle），一种用于判定在给定环境下给定输入的输出是否正确的可靠方法。在许多系统中，判定标准是不完整的，因为需求往往是模糊的、依赖上下文的，或者仅在运行时才显现。Barr及其同事对预言机问题进行了详细调查。

换句话说，你可以快速生成测试用例，但如果没有可靠的判定标准，你就无法自动获知在所有关键场景下输出是否正确。验证仍然受限于在代表性环境下的实际运行，以及根据信号变化而改变决策的权威性。

AI 确实能辅助验证，如建议测试用例、提出边缘场景或总结日志，从而提高验证能力。但它无法凭空变出缺失的设计意图，也无法取代“通过运行系统获取证据”的必要性。代码审查（Review）是有益的证据，但它仅能证明代码的可读性和意图，其本身并不能证明系统在高负载、故障频发或受攻击条件下的行为正确性。

减少验证债务的三种控制手段

如何在产出加速的同时，让证据与决策保持同步？以下三种控制手段可以在不改变组织架构的前提下减少验证债务：

1. 以少量实时信号作为流量扩大的门槛

挑选一小组反映用户受损和系统压力的核心指标，将其设为扩大流量前不可逾越的门槛。对于大多数服务，这始于错误率和 P99 响应时间（最慢的 1% 请求），以及崩溃率和回滚率。例如，只有在错误率和 P99 在约定的基准线内保持足够长的时间（足以观察到金丝雀中的典型流量波动）后，才允许扩大规模。

1. 将验证门槛代码化，并设置自动化熔断规则

明确定义从有限发布转向全量流量前必须满足的条件，并将其编码为自动停止规则。不要使用放之四海而皆准的数字，而要使用模板。例如，如果 P99 响应时间在金丝雀期间上升超过 10% 并持续 15 分钟，则自动停止扩张并回滚。将阈值与可靠性目标和错误预算（Error Budget）挂钩，并根据实际情况微调以避免误报。

1. 强制通过复盘改变发布检查清单

在发生真实事故后，要求对发布流程进行至少一项永久性修订，而不仅仅是一个行动项。例如，每次严重事故后必须对检查清单进行一次“增量修订（Diff）”：增加一个新的验证门槛、一个针对该故障模式的集成测试、一个能更早发现问题的监控项，或是一次针对此类变更的强制性回滚演练。

衡量标准的转向

验证债务不是一句口号，它是证据跟不上变化时的必然结果。生成式 AI 并没有创造这种失衡，但它通过提供大量“看起来合理”的变更放大了这一问题。

未来的出路在于改变信任的依据。在代码起草变得廉价的时代，稀缺的资源是“有据可依的信心”（Justified confidence）。请将“证明”视为发布时的硬性要求，并衡量真正重要的指标：从发起变更到获得验证信心所需的时间，而不是每周交付了多少次变更。