被忽视的现实：代码审查并非为AI时代而生
瓶颈不再是写代码，而是信任代码。
AI生成代码的速度，已经正式超出了人类审查它的能力。几十年来，软件工程的瓶颈一直是编写代码。如今，瓶颈完全转移到了信任上——信任代码能在生产环境中有效运行，真正解决业务问题。
但实话实说：人类从来就没有真正把代码审查这件事做好过。
在我的职业生涯中，我曾多次目睹开发人员批准那些包含严重Bug的PR（Pull Request，拉取请求）或MR（Merge Request，合并请求）。即便他们投入了审查过程，关注的也常常是代码风格之类的问题。为什么会出现这种情况？因为审查者自己手头的任务已经堆积如山，他们往往选择阻力最小的路径，丢下一句"看起来没问题"了事。
而现在，我们试图用AI来解决这个问题？这就很讽刺了。
被忽视的现实：代码审查并非为AI时代而生
无论是人类审查还是LLM（大语言模型）审查，传统的代码审查机制都不是为这个自主编码时代设计的。代码审查实际上并没有验证代码是否完成了最初的要求，也没有确认代码是否符合预期的规格说明，更没有去证明AI代理声称的"任务完成"是否绝对为真。即便是遵循五维度最佳实践（正确性、架构、安全性、可读性、性能）的优质审查，也远远不够。几乎没有代码审查会去核实原始的验收标准是否被满足，或者AI代理是否为了完成PR而偏离了任务范围。大语言模型尤其擅长回避困难、多步骤、有依赖的任务，这意味着意图本身就发生了偏离。此外，审查人员也很少去验证测试覆盖率是否保持不变，或者检查AI代理是否为了通过PR而悄悄削弱了测试。
这就引出了一个关键问题：即便人类审查者或LLM能够有效处理所有这些新的检查项，在AI代码生成速度激增的情况下，他们真的能现实地、确定性地做到吗？
解决方案何在？我们必须从基于意见的审查，转向基于证据的验证。
这意味着要构建护栏（我称之为“断言检查器”），把原始意图和确定性证据绑定在一起：验收条件（ACs，即意图）检查、构建、测试、五维度代码审查、扫描、代码变更的影响范围、文档覆盖率、需求完整性（且互不矛盾）、以及代码中的监控覆盖率。
AI 可以给出建议，但只有证据才能决定是否合入代码！
这个转变我们可能早在几年前就该完成。但在 AI 代理以机器速度编写代码的当下，这已是唯一的前进方向。