> For the complete documentation index, see [llms.txt](https://code-visualization.shawnxie.top/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://code-visualization.shawnxie.top/di-wu-pian-ai-shi-dai-de-xin-ying-yong/ai-code-review-evidence.md).

# AI 生成代码的 Review 证据层

AI 生成代码不能只看 Diff。Reviewer 需要一组证据来判断它是否改对位置、影响范围是否可控、验证是否充分。

传统 Review 依赖人的经验和局部阅读。AI 时代，代码生成速度更快，Review 更需要系统化证据。证据层的作用是把代码图谱、影响面分析、测试覆盖、运行时数据和架构规则组织成可检查的报告。

## 为什么自然语言解释不够

AI 可以解释自己做了什么，但解释不等于证据。一个流畅的解释可能遗漏关键调用方，也可能没有检查测试覆盖。

Reviewer 需要看到可验证材料：

* 哪些文件和方法被修改。
* 这些方法被哪些入口调用。
* 哪些测试覆盖了受影响路径。
* 哪些路径没有覆盖。
* 是否触碰核心业务或高频路径。
* 是否违反架构依赖。
* 是否引入新的安全数据流。

自然语言总结可以作为辅助，但不能替代结构化证据。

## 改动范围证据

第一层证据是改动范围。

它应该说明：

* 修改了哪些文件。
* 修改了哪些类、方法、配置和资源。
* 哪些是功能改动。
* 哪些是测试改动。
* 哪些是格式化或重构改动。
* 是否修改了任务范围之外的文件。

改动范围证据可以帮助 Reviewer 快速判断 AI 是否过度修改。对于 Agent 来说，常见风险是为了完成局部任务而顺手重构无关代码。证据层应该把这类扩散显式暴露出来。

## 影响面证据

第二层证据是影响面。

影响面证据来自调用图、依赖图、资源关系和运行时路径。它应该展示从变更实体到业务入口、测试和服务的关键路径。

例如：

```
变更：OrderService.cancel
  -> 调用方：OrderController.cancel
  -> 业务入口：DELETE /orders/{id}
  -> 下游依赖：InventoryService.release
  -> 相关测试：OrderServiceTest.cancel_shouldReleaseStock
```

这样的路径比“修改了订单取消逻辑”更可验证。

## 测试覆盖证据

测试证据应该回答：

* 哪些测试和改动相关。
* 哪些测试已运行。
* 哪些测试失败或未运行。
* 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 应用：辅助重构与系统迁移。