PR 被人评审打回，多数情况栽在同三件事上：缺测试、违反团队约定、顺手带出来的副作用。OpenAI 的 Codex 现在内置了一个专门的评审器，能在人还没打开 diff 之前就把这三类问题抓出来——前提是你喂给它的是团队真实规则，而不是放任它退回到”互联网平均建议”。这篇讲清楚三件事：Codex CLI 里的 /review 命令、GitHub 上的 @codex review 触发方式，以及那段写在 AGENTS.md 里、能把 Codex 从”凭感觉吐槽”变成”贴出带引用的 P0/P1 finding”的评审规则块。
一句话总结
- Codex 有一个独立的代码评审器（和写代码的 agent 分开），它读 diff、输出按优先级排序的 finding，而且完全不碰你的工作区。
- 本地用 CLI 的
/review命令跑；GitHub 上则在 PR 里评论@codex review。截至 2026 年 6 月，Codex 由 GPT-5.5-Codex 驱动，已包含在 ChatGPT Plus（$20/月）、Pro 和 Business（$30/人/月） 里——没有单独的 Codex 订阅。 - 在 GitHub 上，Codex 只贴 P0 和 P1 问题，让 PR 评论区聚焦真实风险，不被琐碎小事淹没。
- 它认你顶层
AGENTS.md里的## Review guidelines段落，并对每个改动文件套用最近的那个AGENTS.md。 - 把它当预审，不当终审：Codex 稳定抓约定漂移和缺失测试，但业务逻辑的判断仍归人管。
这篇适合谁看
PR 协作的工程团队、没有第二个 reviewer 的单干者、以及总收到”能编译但感觉不对”PR 的 tech lead。约定已经漂移、却没人写下来的快速演进代码库，收益最大。
什么时候别用：20 行以内的小改动，来回开销大于收益；以及速度优先的生产 hotfix。
Codex 评审到底是怎么工作的
Codex 的评审器是专门训练来抓高危缺陷的，它和 linter 有三处不同：
- 它会把 PR 的声明意图（标题、描述、commit 信息）和实际 diff 做比对，因此能标出”悄悄做了比 PR 声称的更多事”的改动。
- 它会在周边代码库和依赖上做推理，而不只看改动那几行——这正是它能发现你忘了的调用方那里回退的原因。
- 它默认会浮出三类具体问题：回退、缺失测试、文档缺口。
在 GitHub 上它刻意只报 P0/P1。本地的 CLI 评审器同样按优先级输出 finding，并且从不改你的文件——每次评审都是 transcript 里独立的一轮，代码演进时可以反复重跑、对比反馈。
开始前准备
- 写 / 更新顶层
AGENTS.md，加一段## Review guidelines，列团队真实规则：命名、错误处理、“绝不记录 PII”、“鉴权中间件必须包住每个路由”。Codex 对每个改动文件套用最近的AGENTS.md，所以可以在更深目录的包级文件里加更严的规则。 - 确认 CI 在 base 分支上是绿的。脏基线会被 Codex 当噪声继承。
- 想清楚你们团队”必修”的定义。Codex 会打 P0/P1，但最终拍板靠你的判断。
一段最小可用的 AGENTS.md 块长这样：
## Review guidelines
- Never log PII or secrets; flag any new logger call that touches user objects.
- Every new HTTP route must be wrapped by the auth middleware in src/middleware/auth.ts.
- New public functions require a unit test and a JSDoc block.
- Prefer Result<T, E> over throwing in the services/ layer.路线 A —— 本地用 CLI 的 /review 命令
在 Codex CLI 的交互会话里输入 /review，它会启动那个专门的评审器，提供四种预设模式：
| 模式 | 评审范围 | 什么时候用 |
|---|---|---|
| 对照 base 分支评审 | 与 upstream 的 merge-base diff | 开 PR 之前 |
| 评审未提交改动 | 已暂存 + 未暂存 + 未跟踪 | 提交之前抓问题 |
| 评审某个 commit | 从列表里选 SHA，评审那一笔的确切改动集 | 审计具体某个 commit |
| 自定义评审指令 | 同一个评审器，按你的关注点 | ”重点看可访问性回退” |
默认评审器用你当前会话的模型。想专门为评审固定一个更强的模型，在 ~/.codex/config.toml 里设 review_model：
review_model = "gpt-5.5-codex"评审器输出按优先级排序、可直接行动的 finding，且不改你的工作区，所以你可以放心反复跑，不用担心被意外改文件。
路线 B —— 在 GitHub 上用 @codex review
- 把 Codex cloud 接到你的仓库，然后打开 Codex 代码评审设置，给该仓库打开 Code review 开关。
- 在任意 PR 下评论
@codex review。Codex 会用 👀 回应，并贴出一条带行内评论的标准 GitHub code review。 - 想给单次运行限定范围，在评论里补上下文：
@codex review for security regressions。 - 想让它对每个新 PR 自动跑，在设置里打开 Automatic reviews——不用再评论。
- Codex 标出问题后，用一条后续评论让它修：
@codex fix the P1 issue。这会起一个 cloud 任务来更新 PR。
因为 GitHub 评审只限 P0/P1，你不会在 PR 评论区收到 40 条琐碎小事堆成的墙；其余的用 AGENTS.md 规则去收紧。
人机交接
- 先跑 Codex（CLI 或 GitHub）。每条 finding 自己 triage 一遍——和你的上下文冲突的就反驳。P0/P1 标签让分歧显式化，而不是埋在散文里。
- 接受的 P0/P1 在请人审之前修掉。故意保留的就标注清楚。
- 缺测试时直接让 Codex 提：“
auth.ts这个改动，提 3 个单测：无效 token、过期 token、缺 claims。” 合理的就实现；别让它不经审就把修复合进去。 - 交给人 reviewer 时附一句：“Codex 已预审；遗留事项在 PR 评论里。” 既省对方时间，也让对方知道你自己读过 diff。
第一次怎么校准
拿一个已经合并的 PR 让 Codex 跑一遍，再对比它的 finding 和当时人审实际写的内容。重合的部分就是 Codex 稳定能抓的。两边的漏标都有启发：Codex 容易漏掉需要产品上下文的微妙业务逻辑 bug，而人容易漏枯燥的约定漂移。如果 Codex 漏了明显的东西，那条规则就是你 AGENTS.md 里缺的——补上。跑两三次校准之后，你就清楚每个优先级该信几分。
容易踩的坑
- 把 Codex 评审当终审。 它会漏只有”带上下文的人”才能抓的业务逻辑 bug。它是预审，不是定论。
- 完全跳过人审。 Codex 是便宜的第一道过滤，不是决策者。
- 没有
AGENTS.md评审规则。 没有它，Codex 套通用建议，可能和你团队的实际选择冲突。 - 让 Codex 自己提修复又自己合，不经人审。 finding 和提交修复补丁可以，自动合不行。
- 因为”Codex 都管了”就不跑 lint 和类型检查。 lint 和类型检查便宜地抓语法层问题；Codex 抓约定和逻辑。两个都跑。
- 永远不清积压。 哪怕 GitHub 上只报 P0/P1，低优先级的清理也要季度批量做一次，否则变成技术债。
FAQ
- Codex 审一次多久？：典型 PR 一般 2-10 分钟，随 diff 大小和它要推理的周边代码量而变。
- 要花多少钱？：截至 2026 年 6 月，Codex 捆绑在 ChatGPT Plus（$20/月）、Pro、Business（$30/人/月）里——没有单独套餐。2026 年 4 月 2 日 OpenAI 把 Codex 从按消息计费改为按 token 的 credit 计费，所以大量自动化评审会像 API 用量一样扣 credit。
- 能取代 lint 和 type check 吗？：不能。那些抓语法层问题；Codex 评审器抓约定和逻辑问题。CI 里两个都留着。
- 能审 draft PR 吗？：能，而且通常应该。早反馈比 diff 变大后再返工便宜。
- 为什么 GitHub 上只报 P0/P1？：刻意设计，让 PR 评论区聚焦高优先级风险而非风格琐事。把低优先级偏好写进
AGENTS.md规则里。 - 评审用的是哪个模型？：默认 GPT-5.5-Codex；想给评审和写代码用不同模型，在
config.toml里用review_model按运行覆盖。