自动化审查是让一个智能体审查另一个智能体的工作，通常使用不同的模型或系统提示词。它不是确定性的，因为需要形成判断。自动化审查可以在任何位置运行：PR 合并前、事后检查提交历史，或在会话中途作为子智能体运行。CI 中使用 LLM 充当裁判属于自动化审查，而不是自动化检查；分类取决于断言在做什么，而不是它在哪里运行。
与执行工作的智能体相互隔离，正是自动化审查能够发挥作用的原因。让编写代码的智能体审查自己的工作，收益很少——产生缺陷的会话也保存着产生缺陷的推理，智能体会把自己的结论重新读成确认。拥有全新上下文窗口的审查者没有这种依附，会像陌生人一样查看 diff，而审查正依赖这种视角。使用不同模型或审查专用系统提示词可以进一步强化效果——模型拥有不同盲点，提示词也可以聚焦你真正关心的内容（安全、API 契约、性能），而不是含糊地要求“找问题”。
它位于其他审查层之间。自动化检查具有确定性，负责捕获可以机械断言的问题；人工审查成本高，扩展性最差。自动化审查处在中间：以机器成本发现需要判断的问题，例如误导性的函数名或遗漏的边界情况。由于它不是确定性的，既可能漏报，也可能把正常内容标成问题；应把它视为人工查看前提高质量下限的过滤器，而不是取代人的门禁。
避免：称为“AI 审查”或“智能体审查”，因为过于含糊，无法与工作智能体自身的检查区分。
用法：
“AFK 运行产生了太多低质量 PR。”
“在合并前加入自动化审查步骤——使用不同模型、独立系统提示词，并把范围聚焦在安全和契约变更上。”