AI编程工具越来越强以后，很多团队会自然走到一个新问题：代码可以让 AI 帮忙写，那代码审查是不是也能交给 AI？我的答案是，可以让 AI 承担大量前置检查，但不要让它替你做最终合并判断。
真正靠谱的 AI 代码审查，不是“把 diff 贴给模型，让它说有没有问题”，而是把 PR 合并前的检查标准化：先让 AI 读变更意图，再跑测试和静态检查，然后做风险扫描，最后由人确认关键业务逻辑。这样 AI 才是审查流程的一部分，而不是一个随机给建议的聊天窗口。
如果你正在系统学习 AI 编程工具，可以先看 AI编程工具专题 和 AI工具评测专题。本文会把 Codex、Claude Code、Cursor 放到一个 PR 审查流程里讲，重点是小团队怎么落地，而不是追求复杂平台化。
先明确：AI代码审查到底审什么
人类做代码审查时，通常会同时看很多东西：需求有没有实现、逻辑有没有漏洞、边界条件是否覆盖、命名是否清晰、测试是否足够、是否引入安全风险、是否破坏已有兼容性。
AI很适合做其中几类工作。
第一，快速阅读差异。它能把几十个文件的变更总结成“这次PR改了什么、影响哪些模块、为什么要改”。这能节省审查者进入上下文的时间。
第二，发现常见问题。比如空值处理、异常吞掉、重复逻辑、未更新测试、配置缺失、明显的类型错误、文档和代码不一致。
第三，补充测试视角。AI可以根据变更建议测试用例，尤其是边界值、失败路径、权限场景和回归风险。
第四，生成审查清单。对于重复出现的项目，比如前端表单、支付逻辑、权限控制、WordPress发布脚本、API鉴权，AI可以把检查项固定下来，减少遗漏。
但AI不适合独立决定业务正确性。比如“这个折扣规则是否符合本月活动策略”“这个灰度方案能不能上线”“这个日志字段是否满足合规要求”，这些仍然需要负责人判断。
一条小团队可执行的PR审查流程
我建议把 AI 代码审查拆成五步。
第一步，让 AI 读PR目的。输入需求描述、相关 issue、主要 diff，让它用几句话说明：本次变更要解决什么问题，改了哪些模块，最可能影响哪些路径。
第二步，跑本地检查。包括格式化、lint、类型检查、单元测试、构建检查。AI可以帮你执行命令、解释失败原因、定位报错文件，但不要跳过这些机械检查。
第三步，做风险扫描。让 AI 重点看权限、数据写入、支付、登录、文件上传、外部API、缓存、定时任务、数据库迁移等高风险区域。普通样式调整不需要同样强度的扫描。
第四步，补测试。让 AI 根据 diff 生成“应该新增或补充的测试清单”，然后由开发者决定哪些必须补，哪些可以记录为后续任务。
第五步，人工复核。人类审查者只看AI总结、失败项、风险项和关键业务代码，不再从零读所有文件。这样不是降低审查质量，而是把注意力集中到更值得人判断的地方。
这套流程和 AI编程调试怎么做 的思路是一致的：让AI处理繁琐定位和重复检查，人负责边界、取舍和最终责任。
Codex适合做什么：跑检查和整理证据
Codex这类命令行编程助手，最适合放在“执行和验收”环节。它可以读取项目文件、运行测试、根据失败日志修改代码，也可以把结果整理成审查说明。
一个实用指令可以这样写：
请审查当前工作树相对主分支的变更。先总结本次改动意图和受影响模块，再运行项目已有的格式化、lint、测试或构建命令。不要修改业务逻辑，除非测试失败且修复点明确。最后输出：已运行检查、失败项、潜在风险、建议补充的测试。
如果你的项目里已经有 AGENTS.md、README、测试脚本和发布流程，Codex能更容易按项目规范执行。站内 Codex CLI 权限怎么设置 也讲过，权限和沙箱不要随便放开。代码审查场景里尤其要避免让AI直接执行危险命令或改动无关文件。
Codex的优势是能把“审查建议”和“实际命令输出”结合起来。比如它不只是说“建议运行测试”，而是真的跑了测试，并告诉你哪个测试失败、失败原因是什么、是否已经修复。
Claude Code适合做什么：拆任务和做深度阅读
Claude Code更适合长上下文阅读、复杂变更拆解和多角色审查。如果一个PR涉及多个模块，可以让它按角色拆开：架构审查、测试审查、文档审查、安全审查。
例如你可以让它先回答三个问题：
- 这个PR的核心设计是否和现有项目结构一致？
- 有没有重复逻辑、隐藏副作用或状态同步问题？
- 哪些测试必须补，哪些风险需要人工确认？
如果你已经在用 Subagents，可以参考 Claude Code Subagents怎么用，把代码审查、测试和文档拆给不同助手。对于中大型项目，这种拆分比一个通用提示词更稳定。
不过要注意，Claude Code给出的建议也要落到证据上。好的审查结论应该能指向文件、函数、测试和具体风险，而不是只说“建议增强健壮性”。如果建议无法落地，就让它继续追问：影响路径是什么？复现条件是什么？应该补哪一个测试？
Cursor适合做什么：在编辑器里快速修小问题
Cursor更适合开发者在编辑器里边看边改。AI审查过程中发现命名、类型、重复代码、局部测试缺失时，可以直接在相关文件里让 Cursor 辅助修改。
Cursor的价值在于贴近代码现场。你可以选中一个函数，让它解释为什么这个边界条件没覆盖；也可以选中一个测试文件，让它按现有风格补一个失败路径；还可以用项目规则约束它不要改变公共接口。
如果你的团队还没有统一规则，建议先看 Cursor Rules怎么写。AI代码审查要想稳定，工具本身不是第一位，项目规范才是第一位。没有规则，AI只能凭通用经验给建议；有规则，它才知道什么是这个项目里的“正确写法”。
一份可以直接复用的AI审查清单
下面这份清单适合小团队放进 PR 模板、AGENTS.md、CLAUDE.md 或 Cursor Rules 里。
- 变更意图：这次PR解决什么问题，是否和需求描述一致？
- 影响范围：涉及哪些模块、入口、配置、数据库、外部服务？
- 运行检查：格式化、lint、类型检查、单元测试、构建是否通过？
- 失败路径：异常、空值、超时、权限不足、外部接口失败是否处理？
- 数据风险：是否改变写入逻辑、迁移脚本、缓存键、幂等策略？
- 安全风险：是否涉及鉴权、文件上传、用户输入、密钥、日志脱敏？
- 兼容性：是否破坏已有API、URL、字段、配置或旧数据？
- 测试补充：新增了哪些测试，还缺哪些关键测试？
- 文档同步：README、环境变量、发布说明、后台配置是否需要更新？
- 人工确认：哪些问题AI不能判断，必须由负责人确认？
这份清单不需要每个PR都完整跑一遍。低风险改动可以轻量执行，高风险改动必须严格执行。关键是团队要知道哪些检查是“建议”，哪些是“合并前必须通过”。
不要让AI审查变成新的噪音源
AI代码审查最容易失败的地方，是建议太多但没有优先级。它可能一次性输出20条意见，其中15条是风格偏好，3条是小优化，真正重要的问题反而被淹没。
所以提示词里要明确输出格式：
请按P0、P1、P2分类输出审查结果。P0是会导致线上错误、数据损坏或安全风险的问题；P1是会影响功能、测试或可维护性的明显问题；P2是可选优化。每条必须包含文件位置、原因、影响和建议动作。没有证据的问题不要写。
这样做可以减少“AI为了显得有用而硬找问题”。如果没有严重问题，就让它明确说“未发现P0/P1问题，但建议补充某些测试”。这比堆满泛泛建议更有价值。
老达点评：AI审查的目标是提高合并信心
我不建议把 AI 代码审查理解成“替代人审代码”。更合理的目标是：提高合并前的信心，减少低级错误，把人从重复检查里解放出来。
小团队最应该先自动化的，不是复杂架构评审，而是那些每次都要做、但很容易忘的事情：测试有没有跑，配置有没有漏，权限有没有破，错误路径有没有处理，文档有没有同步。
当 AI 能稳定完成这些前置工作后，人类审查者就可以把注意力放在业务正确性、用户影响和上线取舍上。这个分工才是目前最现实、也最值得落地的 AI 编程工作流。
