本文作者：sitin（@sitinme）。版权归作者所有，未经授权禁止转载。
PR 已经提交，CI 也绿了，这时最容易出现一种错觉，既然自动检查通过了，代码应该可以合并。
可真正影响线上行为的改动，往往藏在一两行里：权限条件少了一个分支，迁移脚本没有兼容旧数据，或者测试只覆盖了顺利路径。
Codex 接入 GitHub 后，可以先帮你把这类高影响问题挑出来，它能读 Pull Request 的 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.
这比“注意鉴权安全”具体得多。第一条告诉它看什么，第二条告诉它不要混淆哪两种身份，第三条规定了输出应该怎样落地。
规则不宜写成一本手册。先挑两三条 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 规则不能替代测试、分支保护和必需的人工批准。
说白了，它能把问题摆到你面前，但摆完之后按不按下 Merge，是另一回事。
写在最后
Codex 接入 GitHub 之后，真正变了的不是谁来写代码，是 Review 的起点提前了，问题还在 PR 里的时候就被指出来，修复留在同一条记录里，连验证命令都能翻得到。这比事后在群里问一句这个改动有没有人看过，要靠谱得多。
但它的边界也很清楚：它不知道你们线上真实的流量长什么样，不知道哪个客户还在用那条老接口，更不会替你承担合并之后的后果。
天天自己提 PR 的： 先拿一个低风险 PR 手动跑一次 @codex review，看它报的东西是不是你关心的。对不上就先别开自动。
给团队定规矩的： 花半小时把 reviewer 最常重复的两三条约束写进 AGENTS.md 的 Code Review Rules，比写一本审查手册管用。规则要写成判断条件，不是写成态度。
维护公共仓库的： 把它当第一轮高信号筛查，帮你挡掉明显有问题的 PR，合并权还是维护者的。
至于最终是否 Merge，依然应该是一个清楚的人类决定。
参考来源：OpenAI Codex GitHub Code Review 官方文档：https://learn.chatgpt.com/docs/third-party/githubOpenAI Codex GitHub Action 官方文档：https://learn.chatgpt.com/docs/github-actionOpenAI Codex Cloud 官方文档：https://learn.chatgpt.com/docs/cloud
最近发现一个好用的 AI 生图工具，分享一下。
写文章、做 PPT、搞 README 配图的时候经常需要快速出一张图，HiAPI.ai 直接输入描述就能出图，也支持生视频，响应很快，出图质量也不错。
新注册用户送 50 张 GPT Image 2 免费额度，不用绑卡，需要快速出图的可以试试。
👉 HiAPI.ai(直达链接：https://www.hiapi.ai/invite/QwfK)
想了解更多可以加我 vx: 257735 聊。
