Pull Request 已提交、CI 也通过时，很容易产生“可以合并了”的错觉。真正影响线上行为的改动，可能藏在一两行里：少了一个权限分支、迁移脚本不兼容旧数据，或测试只覆盖了顺利路径。
Codex 接入 GitHub 后，可以读取 PR diff，结合仓库规则做高信号检查，也能在同一个 PR 上继续处理修复。但最后的 Merge 仍应由人决定。
Codex 先看高影响问题
官方对 GitHub Code Review 的定位是：读取 PR 改动，结合仓库指导，做一轮高信号检查。
手动触发只需要在 PR 评论中写：
@codex review
当前官方文档强调的是 P0、P1 级别问题，例如数据损坏、安全绕过和严重回归。格式、Lint、类型检查和单元测试继续交给 CI，因为这些检查有确定答案，适合确定性工具。
Codex 更适合需要理解上下文的判断：鉴权条件是否可能被绕过，迁移是否破坏旧版本，某个业务分支是否漏了测试。这样可以避免评论区被大量低价值建议淹没。
第一次接入先手动触发
使用前要完成两件事：将目标仓库接入 Codex cloud，并在 Codex 的 Code review 设置中打开这个仓库。
刚开始建议手动触发，先拿一个普通 PR 试跑，观察报告是否符合团队真正关心的风险。确认规则和结果稳定后，再开启 Automatic reviews，让新 PR 自动进入审查。
如果评论没有反应，按这个顺序排查：
- 仓库是否已经连接 Codex cloud；
- Code review 开关是否已打开；
- 评论中的触发词是否完整写成
@codex review。
少一个环节，机器人就不会出现。
把 Review 规则写成判断条件
“注意安全”对模型帮助有限。规则应该明确：
- 哪个边界必须检查；
- 什么情况才算问题；
- 什么做法属于安全路径。
这些内容可以写在仓库的 AGENTS.md 中。官方建议使用 ## Code Review Rules 章节，并把服务专属规则放在更靠近代码的目录。
例如：
## Code Review Rules
### Authentication
- Flag any route that reads private data without the repository's authorization middleware.
- Treat service-to-service tokens as distinct from end-user sessions.
- Report the file location and the verification command.
第一条规定检查对象，第二条避免混淆服务间 token 和终端用户会话，第三条规定输出如何落地。这比“注意鉴权安全”具体得多。
规则不宜写成一本手册。先挑两三条 reviewer 经常重复解释的约束，拿一个代表性 PR 试跑，再根据误报和漏报调整。把格式要求大量塞进这里，反而会让真正的风险失去注意力。
让修复留在同一个 PR
Review 发现问题后，可以直接在同一条 PR 评论中写：
@codex fix the P1 issue
官方文档说明，这会启动一个带有当前 PR 上下文的云端任务；权限允许时，Codex 可以将修复推回对应分支。
这样原始 diff、Review 意见、修复提交和后续 CI 都保留在同一个地方，维护者可以直接比较修复前后的变化。
但修复推回分支不等于自动通过。新的 diff 仍要检查，测试仍要运行，业务影响仍应由熟悉系统的人判断。
CI 失败时先给证据
CI 变红后，直接说“把 CI 修好”通常不够。更稳妥的请求应包含范围和验收方式：
@codex fix the CI failures. Focus on the failing test log, do not skip assertions, and report the command used to verify the fix.
这句话要求 Codex 先看失败日志，不能通过删除断言换绿色，还要说明使用什么命令验证。如果日志不完整或依赖无法复现，它只能给出假设；它可以减少定位工作，但无法补齐缺失的工程信息。
人工 Review 仍是最后一关
Codex 适合做第一轮筛查，也可以按 PR 指令继续修复，但不负责决定产品方向，也不替团队承担生产风险。
涉及权限、支付、数据迁移、公共 API 或外部系统的改动，尤其要保留人工复审：看完 Codex 评论后，还要看新的 diff、重新跑测试，并确认分支保护和审批要求没有被绕开。
Code Review 规则不能替代测试、分支保护和必需的人工批准。Codex 能把问题摆到面前，但按不按下 Merge，是另一回事。
结论
Codex 接入 GitHub 后，变化不在于谁来写代码，而在于 Review 可以更早开始：问题还在 PR 中时就被指出，修复留在同一条记录里，验证命令也能追溯。
它仍不知道线上真实流量，不知道哪些客户还在使用旧接口，也不会替你承担合并后的后果。
可以先拿一个低风险 PR 手动运行 @codex review，确认报告是否符合关注点，再考虑自动审查。团队应把 reviewer 经常重复解释的两三条约束写进 AGENTS.md 的 Code Review Rules，并把规则写成判断条件，而不是态度口号。公共仓库则应把它当作第一轮高信号筛查，合并权仍属于维护者。