baize白泽明理

AI编程

Codex 代码审查：PR 交给它，人还看什么？

研发团队引入 Codex 代码审查处理日常变更时，可通过评论指令或自动开关扫描缺陷并结合仓库规则输出评审意见。人工继续把关需求设计合理性、跨服务影响与修复方案真伪，原有的测试校验、分支保护与合并审批保持不变。

白泽明理

深墨绿底座上，左侧 PR 卡片与代码条喂入灰色圆形 Agent 模块，翡翠绿箭头分向右侧规则书本与带三个空槽的人工复核托盘

把 Codex 代码审查放进 GitHub 仓库后，它可以承担日常 PR 评审里的第一遍缺陷扫描，合并决定权与架构设计把关仍然留在工程师手里。团队按仓库里的 AGENTS.md 给它定好约束，让它先标出最严重的两级问题；代码所有者和研发负责人集中精力看这次改动该不该做、跨服务调用与数据迁移稳不稳、工具标出的问题准不准；原有的自动化测试、分支保护和人工批准规则全部照旧执行。

从左到右四个小模型：放大镜审 PR 卡片与评论泡、分层约束书本、三类人工复核托盘、周复盘台历并有回指规则的箭头，各配中文标注板
图：「Codex 代码审查」｜「PR 评审」

Codex 在 PR 上怎么触发与看什么

按官方文档说明，触发方式分手动和自动两种。提交 PR 的工程师或评审人只要在 GitHub 的 PR 下评论「@codex review」，Codex 就会读取这次代码改动，对照仓库里的指引写一条标准的 GitHub 代码审查；如果团队希望每次提交都先过一遍筛查，也可以在设置里打开自动审查开关，之后每个新开的 PR 都会被审一遍。帮助中心写明，代码审查插件可用于桌面端和网页端；GitLab 合并请求审查目前是预览，预览里不包含 GitLab 云端自动审查。日常开发里哪些任务适合交给它、哪些任务适合别的编码工具，见 Claude Code 和 Codex：什么活给谁。

默认情况下，Codex 只标出最严重的两级问题，避免把评论区塞满琐碎提示。某次 PR 评审如果有明确的关注重点，工程师可以在评论指令后面直接补充说明，例如指定这一次专门看数据库迁移里的问题。另外，针对安全漏洞的「@codex security review」目前处于研究预览阶段，团队可以按需在小范围试用，暂不拿它替代正式的安全上线门禁。

审查规则写在哪与怎么写

为了让工具懂本仓库的业务边界，官方文档给出了分层配置办法：把审查约定写进仓库 AGENTS.md 的「代码审查规则」小节。仓库根目录的 AGENTS.md 放全仓库通用的底线规则，各个子目录的 AGENTS.md 放对应服务或模块自己的规则；Codex 检查每一个改动文件时，会同时读取根目录规则以及离该文件最近的更具体的子目录规则。

写规则时不用一上来铺长篇规范。官方博客提到的做法是，起步阶段先写两三条简短规则，每一条都写清楚不能被破坏的约束条件以及对应的安全做法；至于缩进排版、命名样式这类格式和代码风格检查，直接交给持续集成流水线里的静态检查工具处理，不用塞进 AGENTS.md 消耗审查注意力。官方文档写明，这些规则只用来引导 Codex 看代码，不替代测试、分支保护和规定的人工批准；官方博客也说，Codex 只是团队额外增加的一个审查者。

第一遍审完后人还要看哪三类

PR 里通常看不到需求评审时的业务背景，也看不到跨服务调用在线上的实际情况。把第一遍扫描交给 Codex 之后，代码所有者和研发负责人在 PR 评审里腾出精力，重点把关三类人工评审事项。

  • 需求与设计方向：这次改动到底该不该做，改动方案跟产品需求、模块职责边界对不对得上，有没有把本该在配置层或上游解决的问题硬塞进业务代码里。
  • 跨模块影响与数据迁移：这次改动会不会波及上下游服务接口、消息协议或共享表结构，涉及线上历史数据迁移与回滚路径时能不能平滑切换。
  • 审查意见与修复方案核验：帮助中心写到，依赖生成的审查意见前要对照代码核实，Codex 给出的修复在提交或合并前也要先审；人要逐条判断它标出的缺陷是真问题还是误报，合入前先看清修复代码有没有带来新隐患。

合并按钮和仓库权限边界维持原样，不给工具开放直接合入主干的权限。工具进入研发体系后在权限、测试和交付流程上还要理顺哪些事，见 Codex 真正进入研发流程，需要解决哪些问题？。

怎么判断它审得好不好与迭代规则

工具接进仓库后不能开完自动审查就放着不管，研发负责人需要盯住信噪比，免得误报太多让工程师养成直接忽略评论的习惯。团队可以每周抽时间汇总一次本周 PR 评审记录，把 Codex 标出的问题分成被工程师采纳修改的和被直接驳回的两堆，摆在一起核对。

复盘时重点看高频被驳回的那批意见：如果是因为工具不了解某个服务的特殊历史约定而反复报错，代码所有者就把这条例外约束补充写进该服务子目录的 AGENTS.md；如果发现某类线上事故隐患漏过了第一遍扫描，就在根目录或对应子目录的「代码审查规则」小节里补一条明确禁令。每次只增改一两条具体规则，跟着下周的审查结果继续微调。

Codex 代码审查：常见问题

Codex 标出的问题要全改吗？

不用全改。帮助中心写到，依赖生成的审查意见前要对照实际代码核实。提交 PR 的工程师和代码所有者核对上下文后，确认属于真实缺陷的再修改，或者在审过 Codex 给出的修复代码无误后再合入；确认属于误报或不符合当前业务约定的，在评论里写明原因直接略过。

格式问题也让 Codex 审吗？

不让它审格式。按官方博客给出的做法，缩进、换行、导入顺序等格式与代码风格问题交给持续集成里的检查工具拦截；AGENTS.md 里的代码审查规则只留给不能被破坏的业务与工程约束，让 Codex 聚焦最严重的两级问题。

有了 Codex，PR 评审还要几个人批？

按团队原有的分支保护配置和人工审批人数执行，不因为加了工具就减少签批人。官方文档说明，审查规则不替代测试、分支保护和必须的人工批准，Codex 在 PR 评审里只是多出来的一个审查者，最终合并仍由具备权限的工程师人工批准。