两年前，AI 辅助编程最难的部分，是让模型写出看起来正确的代码。对很多团队来说，这个坎已经迈过去了：编程 Agent 提交 PR 的速度，超过了评审流程能消化的上限。取而代之的是一个更隐蔽、也更头疼的问题——代码生成出来的那一刻，就得有人决定要不要信任它。
Checksum 联合创始人兼 CEO Gal Vered 天天琢磨的就是这件事：生成的代码丢进真实数据库、被限流的第三方 API、一套没人写文档的权限系统里，还能不能站得住？用他的话说，代码写出来之后会发生什么，才是真正没人解决的部分。
这个缺口有多大？Checksum 的调研数据摆在那：过去 90 天里，61% 的受访工程负责人报告过由 AI 生成代码导致的生产事故，74.3% 回滚过单元测试没拦住的 AI 变更。要注意，这些团队并不是完全没设防：测试写了，代码评审做了，也拿 AI 工具查过 AI 生成的代码。问题不在执行的人不够认真，而在验证循环本身的设计。
AI 代码债：能过你所有检查
他口中的 AI 代码债，不是写得烂的代码，而是那种看起来完全正确、能通过你所有检查、却从没在真实运行条件下验证过的代码。模型写代码时，没见过生产数据库，没见过第三方接口的限流，也不知道那些只存在资深工程师脑子里的业务逻辑。所以它能轻松通过现有检查，却照样会在决定系统成败的地方翻车。
根因数据也支持这个判断。Checksum 问受访者最近一次 AI 相关事故栽在哪儿，结果没有任何一个原因占主导——大规模下的性能问题、逻辑错误、模型无法预见的集成失败，全都挤在 10% 到 20% 出头 这一段。
在 Vered 看来，这个平坦的分布本身就是结论：它指向的是盲区，而不是某种具体的 bug 类型。他的说法是，盲区不是靠多写几个单元测试就能修好的，要在代码发布之前让 Agent 看见运行环境，而不是发布之后。CrowdStrike 和 Cloudflare 的事故就是现成的例子：每个组件单独测都没问题，可它们在运行时一交互，照样会出大事。
想把这件事落地的负责人，可以先改一个动作：调整事故的事后归类方式。别再只按 bug 类型分类，改按失败条件在合并前的环境里能不能被观察到来分。这一分，团队缺的到底是多一个测试，还是一个更真实的验证环境，立刻一目了然。
评审时间吃掉了 AI 的提速
几年前，工作流是写代码、评审、发布，一气呵成；现在变成了提示、生成、评审、重新提示、再评审，来回拉扯。评审没有消失，它只是悄悄吞掉了原本花在写代码上的时间，还顺手吃掉一部分从来没人预算过的时间。
Checksum 的数据把这笔账算得很清楚：64.8% 的负责人表示，评审 AI 生成的代码比评审人写的代码更耗时；一半人表示，引入 AI 编程工具后，评审周期拉长了 25% 以上。Vered 引用的 Faros AI 遥测数据同样扎心：AI 采用率高的团队，合并的 PR 多了 98%，而这些 PR 的评审时间涨了 91%。
Vered 的总结一针见血：写作端赚到的量，在评审端连本带利还了回去。
加评审人手是最容易想到的对策，但多数负责人并不买账：只有 28.6% 的人相信评审负担能靠招人解决，更多人认为这是个结构性问题，加人没用。道理也不复杂——评审 AI 代码和评审同事的 PR 完全是两回事：工程师要在一堆局部看起来都说得通的代码里，把藏得很深的错误翻出来。
真正有效的不是加人，而是调顺序。Vered 描述的目标状态，用过 AI 编程产品的人都不陌生：他预计 氛围编程(vibe coding) 应用里那套提示、生成、验证的循环，会在未来 12 个月内进入企业级软件。到那时，验证会变成一层 仿真，在发布之前用接近真实的条件把应用跑一遍。
做对了的团队，会把验证挪到人前面：工程师打开 diff 时，自动化检查已经把机械性问题扫完了，评审只需要盯设计和意图。落到执行上，就是一条顺序规则——自动化验证没有跑完并给出结论之前，PR 不允许进入人工评审。
编程 Agent 看不见运行时
代码债和评审税，根子上是同一个可见性缺口，Vered 管它叫 上下文空洞(Context Void)。专门起这个名字不是玩概念——它决定了负责人会把这件事当成哪一类问题来解。
编程 Agent 看得见代码，却看不见数据库状态、API 在压力下的行为、权限系统、特性开关，也看不见生产流量的真实形状。凡是决定运行时行为的东西，全在 Agent 的视野之外。Vered 说得很明白：这是结构性问题，不是等更强的模型出来就能补上的临时短板——模型再强，也没法对一个自己从没见过的系统做推理。
也正因如此，他拿自动驾驶打比方就不是随口一说了。没人敢把一辆没有 世界模型 的自动驾驶汽车放上路；让驾驶模型变安全的办法，不是把它关起来练得更聪明，而是先给它几百万英里的仿真里程。各种天气、车流、行人行为、传感器噪声，都得在碰真实道路之前先排练一遍。
Vered 认为，软件面对的是更难的那个版本：生产系统的 状态空间——配置、数据、时序的每一种组合——比汽车在街区里能遇到的情况还要大得多，而且根本没法穷举。穷举不了，就只能仿真有代表性的条件。这就是他判断未来几年软件开发会越来越像自动驾驶开发、而不是继续堆评审流程的原因。
验证是基础设施，不是流水线末尾
Vered 给工程负责人的核心建议，是 把验证重新归类为基础设施。这个归类一变，它的运行位置和预算来源都会跟着变：验证要像 CI 流水线一样常驻、自动。现在多数团队的状态是什么？AI 在前面写代码，一群人和一堆单点工具在后面收拾残局——这套打补丁式的组合，撑不住代码生成量的持续增长。
具体从哪儿开始？先做一次盘点：现有每一道检查处在哪个环节，能看到什么环境。单元测试、代码评审、安全扫描，各有价值；但 Checksum 的调研还发现一个反直觉的现象——AI 单元测试生成，这个 Vered 眼中对 AI 写代码最直接的制衡手段，在主要验证手段里的采用率反而垫底，只有 48.6%。采用率还只是问题的一半：这些检查没有一层能看到生产环境里的真实状态，就算把每层的覆盖率都拉满，照样可能够不着真正的盲区。
Vered 建议负责人拿一条大家早就在无意识执行的标准来要求自己：像信任编译器一样信任代码。你不会逐行检查编译器的输出，你信任的是它背后的体系。AI 代码也一样——要敢不逐行读，前提是底下的验证体系确实值得信任。够到这个标准，才撑得住生成代码的量；现在就按这个标准建设的团队，会在生成速度甩开人工评审能力之前先到位。
从手动 QA 到仿真验证的三步
对今天还在靠手动 QA、目标却是 仿真驱动验证 的团队，Vered 给的是一个序列，而不是一步登天。好在每个阶段单独看都有收益。
第一阶段，把验证塞进 AI 已经在用的写码循环里：每个 PR 自动生成并执行测试，测试只针对真正改动的部分，不允许任何 PR 只靠人工评审就合并。哪怕只走完这一步，也能干掉一类典型失败——合并了一个压根没人真正运行过的 diff。
第二阶段，从孤立地测代码，变成 在类生产条件下测代码：真实的数据形状、真实的 API 行为、真实的负载，而不是 mock。Checksum 的调研显示，69.5% 的团队已经在做某种形式的类生产验证，但这些检查往往还外挂在一个看不清系统间交互的流程上——而最贵的失败，恰恰就出在这些交互里。
第三阶段，把循环闭上：Agent 拿到的不再只是通过或失败，而是什么东西坏了、为什么坏，而且是它能照着行动的描述。于是它可以自己修、自己复验，不用每个循环都夹一个人。走到这一步，收益就不只是事故数下降了——更大的回报，是团队最贵的那部分工程工时，不再花在填缺口上。
收录于 FunTester 原创专题：AI ，测试有点东西
相关阅读：AI 生成越快，人审核越累 · Agentic Coding 的监督机制 · 传统测试不够用了 · AI 代码草稿化，质量护栏不能少 · 让测试速度真正跟上 AI 生成速度