审查一个 PR 时，先把对象说准。记录仓库、目标分支、PR 分支、最新提交 SHA 和改动目的，再列出本次关注的兼容性、数据安全、测试与界面行为。没有明确范围，审查很容易滑向整仓库体检。
先读差异和上下文
在 Codex 桌面端、CLI 或 IDE 中，/review 可以审查相对基础分支的差异、未提交改动或指定提交。专用审查会报告按优先级整理的问题，不会直接修改工作树。桌面端的审查面板还能在具体代码行留下评论，随后再明确要求 Codex 处理选中的意见。
若要读取 GitHub 上的 PR 评论和上下文，当前客户端需要具备仓库访问能力。桌面端官方流程可配合已安装且完成鉴权的 GitHub CLI。Web 端通常依赖可用的源码插件。插件能否安装、读取哪些仓库，会受到客户端版本、ChatGPT 计划、工作区管理员和源系统权限限制。
每条意见都要落到证据
先查功能路径是否符合需求，再看错误处理、权限、数据迁移和兼容性。测试要覆盖新行为与高风险旧行为，文档和配置也要跟代码同步。发现问题时，指出具体文件和行，说明触发条件、实际后果与可验证的修复方向。只写“可能有问题”无法支持作者行动。
修复评论后重新查看差异，确认改动范围没有扩大。新的提交可能让旧批准过时，仓库也可以要求解决全部审查对话。不要把评论标成已解决以后才开始验证，代码和测试要先提供可复查结果。
CI 看最新提交
打开 GitHub Actions 运行记录，确认每个检查对应 PR 的最新提交 SHA。日志会显示任务与步骤状态，必要时可以下载或用 gh run view 查看。受保护分支能够要求批准审查、必需状态检查和对话解决以后才允许合并，具体规则取决于仓库类型、套餐与管理员配置。
检查失败时先定位第一处有效错误，修复后让同一检查在新提交上重跑。检查仍在排队，就保留“CI 进行中”的状态。全部必需检查通过、意见已处理、最终差异也完成复看，才进入可合并状态。
让作者能逐条处理
把发现分成阻断问题、需要确认的风险和可选改进。阻断问题要有可复现路径，风险要写清缺少哪份证据，可选改进不能冒充合并门槛。一次评论只处理一个位置和一种后果，作者修复后才能准确回看。
作者推送新提交以后，重新取得基础分支和 PR 头部的差异。重点复查刚处理的行，也看修复是否改动了相邻接口。若目标分支期间前进，严格状态检查可能要求 PR 更新到最新基础分支，随后 CI 会重新运行。
审查者不要代替仓库策略宣布结果。批准审查、绿色 CI、已解决对话和可合并状态分别来自不同证据。PR 页面显示可合并以后，发布者还要确认合并方式、提交信息与目标分支。
交付记录应包含 PR 链接、审查过的提交、已处理意见、未采纳意见及理由、测试命令和 CI 结果。合并、部署与线上验证仍要分别记录。