AI 代码审查闭环：验证优先与敏感信息清理

背景：AI 生成速度超过人工审查能力

当 Claude Code、Codex 等编码 Agent 能快速生成数千行改动时，人工逐行审查很难跟上。AI 生成的代码通常结构整齐、命名规范、注释完整，静态阅读时看起来合理，但运行后仍可能暴露系统设计、交互边界、UI 可用性或上下文理解方面的问题。

让 AI 审查 AI 生成的代码可以缓解吞吐压力，但不能把“另一个模型给出的评论”直接当作正确结论。AI 很擅长生成自洽的解释；如果解释建立在错误假设上，跟随建议修改反而可能破坏原本正确的代码。因此，可靠流程必须把评论转化为可以验证的假设。

质量门禁是底线

无论代码由人还是 AI 编写，合并前都应具备基本质量门禁：

  • Lint
  • 类型检查
  • 单元测试
  • 集成测试
  • 端到端测试

AI 编程不会降低这些门禁的重要性，反而要求测试更全面。AI 生成的代码可能绕过人的直觉，但更难绕过能够真实覆盖行为的测试套件。

如果项目尚未建立基本门禁，第一项 AI 编程任务应是补齐门禁，而不是直接增加功能。

把 PR 放入独立工作树

将待审 PR 拉取到独立 Git Worktree，可以避免审查和验证过程污染正在进行的其他工作。审查 Agent 应读取完整代码库，而不是只看变更 diff。

完整上下文用于回答：

  • 修改的代码由谁调用？
  • 它依赖哪些配置、数据模型和隐含约定？
  • 是否破坏了跨模块行为？
  • 是否存在 diff 之外的兼容性约束？

知识图谱工具可以进一步提供调用关系、继承关系和影响范围，参见 AI/Code review和知识图谱/code-review-graph-本地代码知识图谱 与 AI/Code review和知识图谱/CodeGraph-代码语义知识图谱。

验证比静态审查更重要

静态审查只能发现审查者能够想到的问题。更可靠的做法是给 Agent 一个受控、真实的运行环境，让它：

  1. 构建修改后的代码；
  2. 运行既有质量门禁；
  3. 执行贴近真实用户路径的场景；
  4. 主动设计边界条件和对抗式测试；
  5. 用可复现结果证明或推翻审查意见。

重点不是让 Agent 在语言层面解释“为什么可能有问题”，而是要求它提供失败测试、运行日志、可重现步骤或行为差异。

文章引用 Claude Code 团队成员 Boris Cherny 的观点：LLM 生成代码的问题逐渐从低级语法错误转向系统设计、UI 可用性和上下文缺失。这类问题仅靠阅读代码难以发现，实际运行往往更有效。

真实环境验证的两个副作用

安全风险

安全问题常出现在交互边界，例如：

  • 输入校验
  • 身份认证与权限检查
  • 敏感数据处理
  • 外部命令与网络调用
  • 文件系统和基础设施权限

可使用编码 Agent 的安全审查能力辅助模式匹配，但不能替代项目自身的威胁模型、权限隔离和安全测试。

本地信息泄漏

Agent 在真实环境中验证时会接触本地服务和基础设施。生成审查评论或 PR 描述时，它可能把这些“验证证据”一并写入公开内容，例如：

  • Kubernetes 集群名称和命名空间
  • 用户名、内部主机名
  • IP 地址和内部 URL
  • 凭据、Token 或密钥片段
  • 本地路径和环境变量

审查流程末尾必须增加独立的信息清理步骤，扫描代码差异、审查评论、测试日志和 PR 描述。发布证据应使用脱敏后的通用描述，敏感原始记录只保留在受控环境中。

人仍然负责“是否合适”

AI 可以判断代码在给定约束下是否正确，但不一定能判断它是否值得做、是否满足真实用户需求，或是否符合产品和组织的长期方向。

仍需要人重点把关：

  • 需求是否真实
  • 系统设计是否合适
  • 用户体验是否可接受
  • 安全策略和风险偏好
  • 技术路线与长期维护成本
  • “该不该做”以及“做到什么程度”

“代码能跑”不等于“产品能用”。人的判断空间存在于正确性与适用性之间。

五步审查闭环

1. 完整仓库上下文

在独立 Worktree 中检出 PR，允许 Agent 阅读相关调用方、共享工具、配置、测试和文档，而不是只分析 diff。

2. 真实环境验证

构建并运行代码，执行项目质量门禁和真实场景测试。审查意见必须尽量附带可复现证据。

3. 安全扫描

检查输入、权限、敏感数据、外部交互和依赖风险。安全扫描结果仍需结合项目威胁模型判断。

4. 敏感信息清理

在发布评论或 PR 描述前，扫描内部环境信息、凭据、IP、用户名、集群和命名空间等内容。

5. 对抗式审查测试

不要只问“有没有问题”，而要主动要求 Agent：

  • 寻找能使实现失败的输入；
  • 构造边界条件；
  • 挑战实现所依赖的假设；
  • 比较修改前后的行为；
  • 为每个高风险结论提供证据。

项目级配置优于通用大方案

不同项目的环境准备、验证命令、风险边界和完成标准不同。不要试图创建一个覆盖所有仓库的庞大通用审查方案。

更稳妥的方式是为每个项目维护独立审查配置，明确：

  • 安装、构建和启动命令
  • 必须通过的测试与检查
  • 关键业务不变量
  • 高风险目录和接口
  • 禁止访问或发布的信息
  • 审查结果的证据标准
  • 失败后的退出和人工接管条件

AI 生成的代码只有通过这些项目约束才能合入；无法通过时应返回修复，而不是降低门禁。

如何开始

原文建议把 Claude Code 的 /code-review、/security-review 和 Codex 的审查功能作为起点，并提到可按风险选择 /code-review low、/code-review medium 等深度。命令是否存在及参数格式应先通过当前版本的帮助信息确认。

最小可行实践：

  1. 在提交 PR 前调用当前编码 Agent 提供的代码审查功能；
  2. 要求审查完整仓库上下文，而非仅看 diff；
  3. 要求运行项目测试并设计至少一个对抗式场景；
  4. 单独执行安全检查；
  5. 发布前扫描审查内容和 PR 描述中的敏感信息；
  6. 由人确认需求、设计和风险取舍。

版本差异

原文提到 Claude Code 的 /code-review、/security-review 及不同审查深度，也提到 Codex 的审查能力。具体命令、参数和可用范围可能随产品版本变化，使用前应以当前工具帮助和官方文档为准。

核心原则

  • 验证比生成重要。
  • 审查配置比一次审查本身重要。
  • AI 审查意见是待验证假设，不是事实。
  • 自动化负责扩大覆盖，人负责目标、设计和风险判断。