AI 生成代码的 Review 证据层
AI 生成代码不能只看 Diff。Reviewer 需要一组证据来判断它是否改对位置、影响范围是否可控、验证是否充分。
传统 Review 依赖人的经验和局部阅读。AI 时代，代码生成速度更快，Review 更需要系统化证据。证据层的作用是把代码图谱、影响面分析、测试覆盖、运行时数据和架构规则组织成可检查的报告。
为什么自然语言解释不够
AI 可以解释自己做了什么，但解释不等于证据。一个流畅的解释可能遗漏关键调用方，也可能没有检查测试覆盖。
Reviewer 需要看到可验证材料：
哪些文件和方法被修改。
这些方法被哪些入口调用。
哪些测试覆盖了受影响路径。
哪些路径没有覆盖。
是否触碰核心业务或高频路径。
是否违反架构依赖。
是否引入新的安全数据流。
自然语言总结可以作为辅助，但不能替代结构化证据。
改动范围证据
第一层证据是改动范围。
它应该说明：
修改了哪些文件。
修改了哪些类、方法、配置和资源。
哪些是功能改动。
哪些是测试改动。
哪些是格式化或重构改动。
是否修改了任务范围之外的文件。
改动范围证据可以帮助 Reviewer 快速判断 AI 是否过度修改。对于 Agent 来说，常见风险是为了完成局部任务而顺手重构无关代码。证据层应该把这类扩散显式暴露出来。
影响面证据
第二层证据是影响面。
影响面证据来自调用图、依赖图、资源关系和运行时路径。它应该展示从变更实体到业务入口、测试和服务的关键路径。
例如：
这样的路径比“修改了订单取消逻辑”更可验证。
测试覆盖证据
测试证据应该回答：
哪些测试和改动相关。
哪些测试已运行。
哪些测试失败或未运行。
Coverage 是否覆盖变更路径。
是否存在高风险未覆盖路径。
如果 AI 生成了测试，还需要检查测试是否验证了真实行为，而不是只验证实现细节。覆盖率是相关性证据，不是充分正确性证明。
安全数据流证据
AI 修改输入、权限、数据访问和外部调用时，需要额外安全证据。
安全证据可以包括：
用户输入是否经过校验。
权限判断是否仍然存在。
敏感数据是否进入日志或响应。
数据是否流向危险 Sink。
依赖包或外部 API 是否引入新风险。
这类证据可以来自静态规则、数据流分析和人工标注。即使不能完全自动证明安全，也应该提示 Reviewer 重点检查。
架构约束证据
架构证据关注修改是否破坏系统边界。
它可以检查：
是否新增跨层依赖。
是否绕过公共接口。
是否让业务模块依赖基础设施细节。
是否引入循环依赖。
是否修改了需要特定 owner 审核的模块。
AI 代码看起来能跑，不代表符合架构约束。架构证据层能把长期维护风险提前暴露。
运行时风险证据
如果目标代码处于生产高频路径、性能热点或错误高发路径，Review 应该更谨慎。
运行时证据可以包括：
Trace 中的调用频率。
平均耗时和 P95/P99 延迟。
错误率。
最近异常日志。
相关告警或事故记录。
这些证据让 Reviewer 知道某个改动是否影响核心运行路径。
Reviewer 检查清单
最终，证据层应该转化为可执行检查清单：
是否确认改动范围符合任务。
是否查看影响路径。
是否运行相关测试。
是否检查未覆盖高风险路径。
是否检查安全输入和权限。
是否确认架构依赖没有违规。
是否需要 owner 审核。
是否需要灰度或监控验证。
检查清单的价值是降低漏项。它把复杂图谱结果转化为 Review 动作。
证据层与 CI 集成
证据层不应该只存在于文档里。它可以集成到 CI 或 PR 流程中：
自动生成影响面报告。
自动推荐测试。
自动标记高风险路径。
自动检查架构规则。
自动提示缺少 owner Review。
自动记录 Agent 查询轨迹。
这样，AI 生成代码不再是“提交一个 Diff 等人看”，而是“提交一个带证据的变更包”。
小结
AI Review 的核心不是不信任 AI，而是要求所有修改都可验证。证据层把改动范围、影响面、测试、安全、架构和运行时风险统一起来，让人类 Reviewer 能做出更可靠的合并判断。
下一章会讨论更大范围的 AI 应用：辅助重构与系统迁移。
Last updated