AI 生成代码如何做验证闭环

业务问题背景

AI 生成代码之后，最容易出现的一句话是“已经完成”。但工程交付不能靠主观描述。尤其是 AI 参与后，代码产出速度变快，验证更不能被弱化。

很多问题并不会在生成阶段暴露：构建能过但页面溢出，单测能过但真实请求失败，接口能通但权限过滤错，功能能跑但缓存没有失效，局部验证通过但旧路径被破坏。

AI 生成代码的验证闭环，就是要把“看起来完成”变成“有证据完成”。

抽象实战场景

一个 AI 辅助任务修复了文件上传问题。它修改了前端请求封装，也调整了后端接收逻辑，单测通过，构建通过。上线前人工试了一下，才发现真实浏览器发出的请求头仍然不对，大文件限制也没有按预期生效。

原因很简单：验证层级不完整。服务层测试证明了逻辑可以跑，构建证明了代码能打包，但没有证明真实交互路径正确。

AI 生成代码最怕“验证错层”。用低层证据证明高层结果，本质上就是没有闭环。

核心架构观点

验证闭环的核心不是跑更多命令，而是让验证覆盖风险所在的层级。

代码层改动，用单元测试和静态检查验证。

接口层改动，用契约测试、接口请求和错误路径验证。

页面层改动，用真实浏览器、不同视口、长文本、空态、错态、权限态验证。

数据层改动，用迁移检查、数据抽检、回滚策略和兼容验证。

配置和缓存改动，用默认值、刷新机制、重启加载和失效路径验证。

验证要和风险对应，而不是用一个“构建通过”覆盖所有问题。

技术方案设计

AI 生成代码的验证闭环可以分成六步。

第一步，变更分类。判断本次改动涉及代码、接口、页面、数据、配置、权限、外部服务还是发布链路。

第二步，验证计划。根据类型选择最小但足够的验证组合。

第三步，自动化执行。优先跑可重复命令，例如单测、集成测试、类型检查、构建、规范检查。

第四步，真实路径验证。对 UI、上传、权限、流程和外部适配类任务，补真实请求或浏览器验证。

第五步，结果记录。记录通过项、未验证项、失败项、非本轮范围项和剩余风险。

第六步，防复发沉淀。对复发问题补测试、脚本、清单或 Review 规则。

底层原理剖析

验证闭环背后的原则是证据链。一个工程结论必须能从证据推导出来。

“单测通过”只能证明被测单元在给定输入下行为正确；“构建通过”只能证明项目可以打包；“接口返回成功”只能证明某条请求路径可用；“浏览器验证通过”才证明用户路径在当前页面状态下可用。

不同证据有不同证明力。AI 交付时如果不区分证明范围，就会把低证明力证据包装成高证明力结论。

架构师要做的是逼近真实风险，而不是追求验证数量。

方案取舍与适用边界

不是每次 AI 改动都要跑全量验证。小范围改动可以跑定向测试和相关构建；跨模块改动要扩大验证范围；涉及公共组件、权限、数据、配置、发布的改动，要更严格。

验证策略要避免两个极端。一个极端是不验证，完全相信 AI；另一个极端是每次都跑全量，导致效率不可接受。正确方式是风险驱动验证。

验证计划也要承认现实：如果某些检查因为历史问题失败，要明确说明失败是否属于本轮范围，不能混淆结论。

生产落地细节

建议团队建立验证矩阵。

矩阵按改动类型列出必选验证和可选验证。例如接口改动至少需要接口测试或请求验证；UI 改动至少需要构建和浏览器检查；数据迁移至少需要重复版本检查和抽检方案；配置改动至少需要默认值和缓存失效验证。

AI 交付说明必须包含验证证据。不要只写“已测试”，要写清楚执行了什么、结果是什么、证明范围是什么。

如果没有验证，也要明确写“未验证”和原因。未验证不是错误，隐瞒未验证才是风险。

踩坑风险总结

第一个坑，是构建通过就宣布完成。构建只是基础门槛，不是业务验收。

第二个坑，是只跑新增测试，不跑受影响路径。AI 可能改到了公共逻辑，局部测试覆盖不到。

第三个坑，是忽略真实交互。文件上传、权限按钮、页面布局、长文本和浏览器行为，经常不在单测里暴露。

第四个坑，是不区分历史失败和本轮失败。交付结论必须清楚边界。

可落地实践建议

给 AI 任务增加固定收尾格式。

收尾至少包括：改动摘要、影响范围、已执行验证、验证结果、未验证项、失败但非本轮范围、剩余风险、需要人工关注点。

同时，把高频验证做成脚本或清单。比如迁移版本检查、接口契约检查、页面多视口检查、上传真实请求检查、配置缓存失效检查。

AI 不是不能生成代码，而是生成之后必须被工程验证接住。

全文升华总结

AI 时代，代码生成会越来越快，验证闭环会越来越重要。

一个成熟团队不会问“AI 有没有写完”，而会问“我们如何证明它写对了”。当验证能够覆盖风险、记录证据、沉淀防复发机制，AI 生成代码才真正进入可交付状态。