一、为什么 PR 场景特别适合 Codex？

很多人第一次用 Codex，会让它做这种任务：

帮我优化一下这个项目。 帮我看看代码有没有问题。 帮我把这个功能改好。

这类任务太泛，Codex 容易做得很散。

但 PR 不一样。

PR 天然自带上下文：

• 有明确的改动范围
• 有 reviewer 的具体评论
• 有 Git diff
• 有 CI 结果
• 有分支和提交历史
• 有团队 Review 规则
• 有合并前的验收标准

这正好是 Codex 最适合处理的结构化任务。

你不应该把 Codex 当成“一键合并机器人”，而应该把它当成一个能陪你完成 PR 闭环的协作者：

读评论 → 判断优先级 → 最小化修复 → 跑检查 → 生成说明 → 等 CI → 人类确认 → 合并

这套流程稳定之后，你会发现 PR 不再是一个“来回翻评论、翻文件、翻 CI”的机械活，而是可以被 Codex 承担掉大量上下文切换成本。

二、先讲清楚：Codex 能在 PR 里做什么，不能替你省掉什么？

Codex 在 PR 场景里主要能做 5 类事。

第一，读取 PR 上下文。

包括 changed files、review comments、当前分支 diff、相关代码、测试命令、失败日志等。

第二，处理 Review 评论。

比如 reviewer 提到：

这里没有处理 session 为空的情况。

你可以让 Codex 只处理这一条评论，改最小范围，并补测试。

第三，跑本地 Review。

CLI 里可以用 /review，让 Codex 作为一个独立 reviewer 读取 diff，输出优先级问题清单。它不会直接改你的工作区，适合提交前自查。

第四，在 GitHub PR 里触发 Codex Review。

配置好 Codex Cloud 和 GitHub 代码审查后，可以在 PR 评论里写：

@codex review

Codex 会像团队成员一样在 GitHub 上发起 Review。官方文档说明，这类 Review 会重点标记 P0/P1 等高优先级问题，避免把低价值建议刷满评论区。

第五，生成提交说明和 PR 更新说明。

它可以帮你把这次修复整理成：

• commit message
• PR comment
• reviewer 回复
• 测试结果摘要
• 合并前风险提示

但有几件事不要交给 Codex 自动跳过。

不要让它绕过 CI。

不要让它绕过 branch protection。

不要让它在你没看 diff 的情况下直接合并。

不要让它顺手重构与评论无关的代码。

PR 的最后责任仍然在你或者团队维护者身上。Codex 负责把过程变得更快、更清楚、更可验证。

三、四种 Review 模式：App、CLI、GitHub、Action 怎么选？

Codex 现在可以通过多个入口参与 Review。新手最容易混的是：我到底应该在哪个地方让它 Review？

可以按下面这张图理解。

1. Codex App Review 面板：适合本地修 PR 评论

如果你已经在本地 checkout 到某个 PR 分支，最顺手的是 Codex App 的 Review 面板。

官方文档里有一个很重要的提醒：

Review 面板反映的是 Git 仓库状态，而不只是 Codex 自己修改的内容。

也就是说，它会显示：

• Codex 改的文件
• 你自己改的文件
• 仓库里任何未提交改动

所以在修 PR 之前，先看一眼：

git status

如果当前工作区已经混着你自己的临时改动，建议先提交、stash，或者换到 Worktree 处理。否则 Codex 修完之后，Review 面板里会混在一起，最后你分不清谁改了什么。

官方文档还提到，当 Codex 有 GitHub 仓库访问权限，并且当前项目在 PR 分支上时，App 可以在侧边栏和 Review 面板里显示 PR 上下文、review comments 和 changed files。

如果 PR 信息没有出现，常见原因是本机没有安装或登录 GitHub CLI。

先检查：

gh auth status

如果没有登录：

gh auth login

然后再打开 PR 分支：

gh pr checkout 128

进入 Codex App 后，你可以这样说：

请读取当前 PR 的 review comments 和 changed files。 只处理 reviewer 明确指出的 P0/P1 问题，以及我下面指定的评论： 1. src/auth/callback.ts 里 session 为空时会抛异常 2. tests/auth/callback.test.ts 缺少 expired session 用例 要求： 1. 保持改动最小，不做顺手重构。 2. 不改变 API response shape。 3. 补充或更新最小相关测试。 4. 完成后运行相关测试。 5. 最后列出改动文件、测试命令、结果和剩余风险。

这个 Prompt 的重点不是“帮我修一下”，而是把 Codex 的行动范围收紧。

2. CLI /review：适合提交前自查

如果你在 Codex CLI 里，可以直接输入：

/review

官方文档说明，/review 会启动一个专门的 reviewer，读取你选择的 diff，并输出优先级明确、可执行的问题清单。它不会直接修改工作区。

常见选项包括：

• review against a base branch：像 PR 一样对比基线分支
• review uncommitted changes：检查未提交改动
• review a commit：检查某个具体提交
• custom review instructions：加入自定义审查重点

比如你准备开 PR 前，可以让它对比 main：

/review

然后选择 base branch，再补充自定义要求：

Focus on authentication regressions, input validation, error handling, and tests. Ignore naming nitpicks unless they hide a real bug.

中文可以这样写：

请把本次 diff 当作即将提交的 PR 来审查。 重点关注： 1. 鉴权、权限绕过、输入校验。 2. 错误处理是否会吞掉异常。 3. 是否有行为回归。 4. 是否缺少必要测试。 不要输出低价值风格建议。只列出真正可能影响正确性、安全性或可维护性的发现。

这一步适合在正式提交前跑一遍，等于让 Codex 做第二双眼睛。

3. GitHub @codex review：适合让 Codex 像队友一样审 PR

如果你的仓库已经配置了 Codex Cloud 和 Code review，可以在 GitHub PR 评论里触发：

@codex review

如果想让它聚焦某类风险，可以写：

@codex review for security regressions and auth edge cases

或者：

@codex review focusing on data migration safety and rollback risks

官方文档说明，Codex 会读取 PR diff、遵循仓库里的 AGENTS.md 指导，并在 GitHub 上发起标准 Code Review。

如果你想让它持续关注团队规则，可以在仓库根目录的 AGENTS.md 里加 Review 指南：

## Review guidelines - Treat authentication bypasses as P1. - Verify that all new API routes have authorization checks. - Do not flag formatting-only issues unless they hide a functional problem. - For migrations, check rollback safety and data compatibility.

如果某个子目录有更细的规则，也可以放更近的 AGENTS.md。Codex 会按文件位置读取更贴近的指导。

4. GitHub Action：适合把 Review 固定进 CI

如果你想让 Codex 在 PR 更新时自动跑一个固定检查流程，可以使用 openai/codex-action@v1。

官方文档给出的思路是：GitHub Action checkout 代码，然后运行 Codex CLI 的非交互任务，把最终输出保存下来，再回帖到 PR。

一个简化版工作流可以这样理解：

name: Codex pull request review on: pull_request: types: [opened, synchronize, reopened] jobs: codex: runs-on: ubuntu-latest permissions: contents: read steps: - uses: actions/checkout@v5 with: ref: refs/pull/${{ github.event.pull_request.number }}/merge fetch-depth: 0 persist-credentials: false - name: Run Codex uses: openai/codex-action@v1 with: openai-api-key: ${{ secrets.OPENAI_API_KEY }} prompt-file: .github/codex/prompts/review.md output-file: codex-output.md

真实项目里，你还需要再加一步把结果发回 PR，或者上传为 artifact。

这里最重要的不是 YAML，而是安全边界。

做 GitHub Action 自动 Review 时，一定注意：

• OPENAI_API_KEY 放在 GitHub Secrets，不要写进仓库
• 限制 workflow 触发者，不要让任意外部用户随便触发高权限任务
• 不要把不可信 PR 文本、commit message、issue body 原样当成最高优先级指令
• 尽量用只读权限做 Review
• 如果只是审查，就不要给 Codex 写权限
• 不要让 Action 绕过团队已有的 CI 和 branch protection

Action 很适合自动化“审查和报告”，但不建议新手一上来就做“自动修改并推送”。

四、实战流程：让 Codex 修一个 PR 评论

假设你收到一个 PR Review：

callback.ts 里直接读取 session.user.id。 如果 session 为空，这里会抛异常，导致 expired session 返回 500。

你的目标不是让 Codex “优化 auth 模块”，而是让它只修这条评论。

推荐流程如下。

第 1 步：拉到 PR 分支

gh pr checkout 128 git status

确认：

• 当前分支是 PR 分支
• 没有混入无关本地改动
• 你知道这个 PR 的 base branch 是什么

如果当前目录里有自己的临时改动，先处理掉：

git stash push -m "wip before codex pr review"

或者新开 Worktree 来处理这个 PR。

第 2 步：让 Codex 先读，不要先改

第一轮不要直接让它改。

先让它理解评论：

请读取当前 PR 的 Review 评论和 changed files。 先不要修改文件。 请输出： 1. 每条评论对应的文件和代码位置。 2. 评论是否仍然适用于当前 diff。 3. 你建议处理的优先级。 4. 每条评论需要修改哪些文件。 5. 可能需要跑哪些测试。

这一步的价值很大。

因为 GitHub Review 评论可能已经过期。比如 reviewer 评论的是旧 diff，后面你自己已经改过了。如果 Codex 不先判断评论是否还适用，它可能会为一个不存在的问题继续补丁。

第 3 步：指定它只处理目标评论

等 Codex 梳理完之后，再发第二条：

现在只处理第 1 条评论：session 为空时 callback 返回 500。 要求： 1. 只修改与这个问题直接相关的代码和测试。 2. 不重构 auth 模块。 3. 不改变公开 API 的 response shape。 4. 如果已有测试风格，请沿用。 5. 完成后运行最小相关测试。 6. 如果测试跑不起来，说明原因，不要假装通过。

这条 Prompt 里最关键的是两句话：

只修改与这个问题直接相关的代码和测试。 如果测试跑不起来，说明原因，不要假装通过。

第一句防止改太多。

第二句防止“口头通过”。

第 4 步：看 Codex 的 diff

修完之后，不要马上提交。

先看：

git diff --stat git diff

或者在 Codex App 的 Review 面板里逐文件看。

重点看 4 件事：

• 有没有改到无关文件
• 有没有改变 API 行为
• 有没有把测试写得过于宽松
• 有没有为了让测试过而降低校验强度

如果你发现它顺手改了很多，可以直接说：

这次 diff 范围过大。 请回到最小修复方案： 1. 保留 session 为空的保护。 2. 保留必要测试。 3. 撤回与本条 review 评论无关的重构、命名调整和格式化。 4. 重新列出最终 diff 范围。

第 5 步：让 Codex 复述验证结果

不要只问：

跑过测试了吗？

要让它给证据：

请汇总本次修复的验证结果。 格式： 1. 改动文件列表。 2. 运行过的命令。 3. 每条命令的结果。 4. 没有运行的检查以及原因。 5. 合并前仍需注意的风险。

一个好的输出应该像这样：

改动文件： - src/auth/callback.ts - tests/auth/callback.test.ts 运行命令： - pnpm test auth-callback：通过 - pnpm run lint：通过 未运行： - e2e：本地缺少测试浏览器依赖，建议依赖 CI 覆盖 剩余风险： - 只覆盖 expired session 场景，未覆盖第三方登录服务异常超时

这才是可以放进 PR comment 的信息。

五、让 Codex 跑 Review：不是让它挑刺，而是让它找高风险问题

很多人用 Codex Review 时，会得到一堆“这里可以命名更好”“这里可以抽函数”的建议。

这通常不是 Codex 的问题，而是 Review 指令太泛。

你要告诉它：什么问题值得报，什么问题不要报。

提交前 Review 模板

请对当前未提交改动做一次代码审查。 审查标准： 1. 只报告可能导致 bug、安全问题、数据错误、兼容性问题或测试缺失的发现。 2. 不报告纯风格、命名、个人偏好的问题。 3. 每个发现必须包含： - 严重程度：P0/P1/P2 - 文件和位置 - 为什么这是问题 - 最小修复建议 - 是否需要测试 4. 如果没有高价值发现，请明确说没有发现阻塞问题。 重点关注： - 鉴权和权限判断 - 输入校验 - 空值和异常路径 - 数据迁移兼容性 - 并发或重复提交 - 测试覆盖

PR 分支 Review 模板

请把当前分支相对于 base branch 的 diff 当作一个 PR 来审查。 要求： 1. 先识别 base branch 和变更范围。 2. 只输出高价值问题，不输出 nit。 3. 对每个问题给出 P0/P1/P2。 4. 优先检查用户可见行为、安全边界、数据一致性和回滚风险。 5. 不要修改文件，只输出 Review 结果。

修复 Review 发现的模板

请修复 Review 中的 P1 问题。 范围： 1. 只处理 P1，不处理 P2 和优化建议。 2. 每个问题采用最小修复。 3. 修改后补充或更新相关测试。 4. 运行相关检查。 5. 最后输出： - 修复了哪些发现 - 改了哪些文件 - 跑了哪些命令 - 哪些检查未跑以及原因

这里有一个原则：

Review 阶段让 Codex 多看少改，Fix 阶段让 Codex 少看少改。

先让它审，范围可以广一点。

让它修的时候，范围一定要收紧。

六、让 Codex 生成 Commit Message 和 PR 更新说明

很多人会让 Codex 直接：

帮我写个提交说明。

它当然能写，但容易写成一段空泛总结。

你要给它结构。

推荐 Prompt：

请基于当前 staged diff 生成 commit message 和 PR 更新说明。 要求： 1. commit message 使用 Conventional Commits。 2. subject 不超过 72 个字符。 3. body 包含： - 为什么改 - 改了什么 - 如何验证 - 剩余风险 4. PR 更新说明使用中文，适合直接贴到 GitHub 评论区。 5. 不要夸大，没有跑过的测试不能写通过。

如果你的团队不用 Conventional Commits，就换成团队格式：

请按我们团队格式生成提交说明： [模块] 简短描述 变更： - ... 验证： - ... 风险： - ...

一个比较好的 Commit Message 是：

fix(auth): handle missing session in callback - add a null guard before reading session.user - cover expired-session callback with a regression test - keep the API response shape unchanged Verification: - pnpm test auth-callback - pnpm run lint

一个比较好的 PR 更新说明是：

已处理本轮 Review 中的 P1 问题： 1. 修复 session 缺失时 callback 返回 500 的问题。 2. 增加 expired session 回归测试。 3. 未改变 API response shape。 验证： - pnpm test auth-callback：通过 - pnpm run lint：通过 剩余风险： - 未在本地运行完整 e2e，建议以 CI 结果为准。

这类说明 reviewer 很容易看懂，也方便以后回滚和追溯。

七、Codex 帮你提交前，先做一次“分层验收”

当 Codex 完成修复后，不要直接：

git add . git commit -m "fix" git push

更稳的流程是分层验收。

1. 文件层：确认改了哪些文件

git status --short git diff --stat

如果看到不该出现的文件，比如：

package-lock.json .env README.md src/unrelated-module.ts

先停下来问 Codex：

这些文件为什么会出现在 diff 里？ 请逐个解释是否与本次 Review 评论相关。 如果无关，请撤回这些文件的改动。

2. 代码层：看关键 diff

git diff src/auth/callback.ts git diff tests/auth/callback.test.ts

你要确认：

• 修复点直接命中评论
• 没有降低校验强度
• 没有吞掉异常
• 测试不是只为了覆盖行数

3. 测试层：跑最小相关检查

比如：

pnpm test auth-callback pnpm run lint

如果项目大，不一定每次都跑全量，但至少要跑与本次改动直接相关的命令。

然后等 CI 跑全量。

4. Review 层：再跑一次 /review

可以让 Codex 做最后一遍本地审查：

/review

或者：

请审查当前 staged diff。 重点确认： 1. 是否真正解决 reviewer 评论。 2. 是否引入新的异常路径。 3. 测试是否覆盖了修复场景。 4. 是否存在无关改动。 不要修改文件，只输出发现。

5. Git 层：选择性 stage

如果你在 App Review 面板里，可以按 file 或 hunk stage。

在命令行里也可以：

git add src/auth/callback.ts git add tests/auth/callback.test.ts git diff --cached --stat git diff --cached

不要无脑 git add .。

尤其是 PR 修评论这种任务，最怕把本地临时文件、调试日志、格式化大改一起提交进去。

八、安全合并前的 10 项清单

Codex 可以帮助你走到“看起来能合并”的位置。

但最后合并前，建议逐项确认：

1. 工作区是否干净？

git status

确认没有未提交的奇怪文件。

2. PR 分支是否基于最新 base？

git fetch origin git status

如果落后太多，先 rebase 或 merge 最新 base，再看 CI。

3. Review 评论是否都处理完？

不是所有评论都要 Resolve。

只 Resolve 你确认已经处理的评论。

如果某条评论不适用，应该回复原因，而不是假装修了。

4. Diff 是否逐文件看过？

重点看：

• 鉴权
• 配置
• 数据迁移
• workflow
• lockfile
• 依赖版本
• 测试断言

5. 本地测试是否跑过？

至少跑最小相关测试。

如果没有跑，PR 说明里要写清楚原因。

6. CI 是否全绿？

本地通过不代表 CI 通过。

合并以远端 CI 为准。

7. 是否还有 Codex Review 高优问题？

如果用了 @codex review 或 /review，确认 P0/P1 都处理完。

P2 可以根据团队情况决定是否合并前处理。

8. 提交说明是否可追溯？

一个月后回来看，应该能知道：

• 为什么改
• 改了什么
• 怎么验证
• 有什么风险

9. 是否遵守 branch protection？

不要让 Codex 帮你绕过团队规则。

如果需要管理员权限合并，要让维护者确认。

10. 合并方式是否符合团队习惯？

有的团队用 squash merge。

有的团队保留 merge commit。

有的团队要求 rebase。

Codex 可以帮你生成说明，但合并策略要按团队规范来。

九、把 Codex 固定成团队 PR 工作流

如果你是个人项目，按上面的流程手动用就够了。

如果是团队项目，建议把 Codex PR 工作流沉淀成 3 个文件。

1. AGENTS.md

放项目规则和 Review 规则。

示例：

# AGENTS.md ## Build and test - Use pnpm. - Run `pnpm test <name>` for focused tests. - Run `pnpm run lint` before final handoff. ## Review guidelines - Treat auth bypass, data loss, secret leakage, and migration rollback failure as P1. - Do not report naming or formatting issues unless they hide a real bug. - For API changes, verify backward compatibility. - For UI changes, verify loading, empty, error, and mobile states. ## PR handoff Every PR update must include: - changed files - commands run - test results - remaining risks

2. .github/codex/prompts/review.md

放 GitHub Action 或团队复用的 Review Prompt。

示例：

Review this pull request as a senior engineer. Only report findings that could affect correctness, security, data integrity, compatibility, or test reliability. For each finding, include: - severity: P0, P1, or P2 - file and location - why it matters - minimal fix recommendation - whether a test is needed Do not report style-only comments. Do not suggest broad refactors unless the current diff introduces a concrete risk.

3. .github/PULL_REQUEST_TEMPLATE.md

让人类和 Codex 都按同一套信息交付。

示例：

## Summary - ## Verification - ## Risk - ## Codex notes - Review comments handled: - Tests run: - Follow-up:

这三个文件的作用是：把“你脑子里的团队标准”变成 Codex 能读到、能复用、能检查的规则。

十、新手最容易卡住的地方

PR + Codex 场景里，真正卡人的通常不是模型能力，而是上下文和权限。

1. Codex 看不到 PR 评论

先确认三件事：

gh auth status git branch --show-current gh pr status

你需要：

• 在 PR 分支上
• 本机 gh 已登录
• Codex 对该 GitHub 仓库有访问权限

如果你只是把代码 clone 下来，但没有 PR 上下文，Codex 只能看本地 diff，看不到 GitHub 上的 reviewer 评论。

2. Review 面板里混入了自己的改动

这是正常现象。

官方文档说得很明确：Review 面板显示的是 Git 仓库状态，不只显示 Codex 的改动。

所以修 PR 前先清工作区。

3. Codex 修过头

这通常是 Prompt 没有限定范围。

把：

帮我处理一下 Review 评论。

换成：

只处理 reviewer A 在 file X 上的 P1 评论。 禁止重构、禁止格式化无关文件、禁止修改公开 API 行为。

4. 评论已经过期

先让 Codex 判断评论是否仍适用。

不要一上来就修。

5. 测试跑不起来

让 Codex 做两件事：

先找出项目里最小相关测试命令。 如果命令失败，请区分是代码失败、依赖缺失、环境缺失还是命令不存在。

不要让它把“跑不了”写成“已通过”。

6. 提交说明看起来很空

给格式。

永远要求它写：

动机 / 变更 / 验证 / 风险

7. CI 和本地结果不一致

以 CI 为准。

让 Codex 帮你读 CI 日志时，可以这样问：

请读取这次 PR CI 失败日志。 要求： 1. 判断失败是否由本 PR 引入。 2. 找出最小相关文件。 3. 不要直接大范围修改。 4. 先给修复计划，再动手。

8. 合并权限不清

Codex 不应该替你绕过 GitHub 的保护规则。

如果 branch protection 要求 reviewer approve、CI 全绿、线性历史，那就按规则走。

十一、可直接复制的 Prompt 模板

下面这些模板可以直接保存起来，之后每个 PR 都能用。

模板 1：读取 PR 评论

请读取当前 PR 的 review comments、changed files 和当前 diff。 先不要修改文件。 请输出： 1. 评论列表，按文件分组。 2. 每条评论是否仍适用于当前 diff。 3. 建议优先级：P0/P1/P2。 4. 每条评论的最小修复范围。 5. 需要运行的测试命令。

模板 2：修指定评论

请只处理下面这条 PR Review 评论： [粘贴评论内容] 要求： 1. 保持改动最小。 2. 不做顺手重构。 3. 不修改无关文件。 4. 不改变公开 API 或用户可见行为，除非这是修复所必需。 5. 补充或更新最小相关测试。 6. 完成后运行相关测试，并列出命令和结果。 7. 如果有检查无法运行，说明具体原因。

模板 3：提交前 Review

请审查当前 staged diff。 只报告可能影响正确性、安全、数据一致性、兼容性或测试可靠性的问题。 每个发现必须包含： 1. 严重程度：P0/P1/P2。 2. 文件和位置。 3. 为什么这是问题。 4. 最小修复建议。 5. 是否需要测试。 不要输出风格类、命名类、个人偏好类建议。 不要修改文件。

模板 4：生成 Commit Message

请基于当前 staged diff 生成 commit message。 要求： 1. 使用 Conventional Commits。 2. subject 不超过 72 个字符。 3. body 包含： - why - what changed - verification - risk 4. 不要写没有真实运行过的测试。

模板 5：生成 PR 更新评论

请生成一段适合贴到 GitHub PR 的更新说明。 格式： 1. 已处理的问题。 2. 改动文件。 3. 验证命令和结果。 4. 未运行的检查及原因。 5. 剩余风险或需要 reviewer 重点看的地方。 语气简洁，面向 reviewer。

模板 6：合并前最终检查

请做一次合并前最终检查。 检查内容： 1. 当前工作区是否干净。 2. staged diff 是否只包含本 PR 需要的改动。 3. 是否还有未处理的 P0/P1 Review 问题。 4. 本地测试和 CI 状态是否足够支持合并。 5. commit message 和 PR 说明是否完整。 6. 是否存在 secrets、权限放宽、workflow 风险或无关 lockfile 变化。 不要修改文件，只输出检查结果和建议。

十二、一个完整示例：从评论到提交

你可以把整个流程串成这样。

1. 拉取 PR

gh pr checkout 128 git status

2. 让 Codex 读取评论

请读取当前 PR 的 review comments 和 changed files。 先不要修改文件。 请按优先级列出仍然适用的评论，以及每条评论的最小修复范围。

3. 指定修复范围

只处理 P1：session 为空时 callback 返回 500。 保持改动最小，不改 API shape。 补充 expired session 测试。 完成后运行相关测试。

4. 查看 diff

git diff --stat git diff

5. 跑 Review

请审查当前 diff 是否真正解决该 PR 评论。 不要修改文件，只输出高价值发现。

6. Stage 指定文件

git add src/auth/callback.ts git add tests/auth/callback.test.ts git diff --cached --stat

7. 生成提交说明

请基于 staged diff 生成 commit message 和 PR 更新说明。 要求包含：动机、变更、验证、风险。

8. 提交并推送

git commit git push

9. 等 CI 和 reviewer

CI 绿、P0/P1 清空、reviewer approve，再合并。

如果 CI 失败，不要让 Codex 大范围改：

请读取 CI 失败日志。 先判断失败是否与本次提交有关。 只提出最小修复计划，不要直接改文件。

十三、我的建议：不要追求“一键合并”，要追求“可审查闭环”

Codex + GitHub PR 的正确打开方式，不是：

@codex 帮我全自动合并。

而是：

Codex 帮我把 PR 反馈处理成一个可审查、可验证、可回滚的变更。

真正成熟的流程应该是：

Codex 读取上下文 Codex 提出最小修复 Codex 修改代码和测试 Codex 跑检查并说明结果 Codex 生成提交说明 Codex 再 Review 一遍 人类看 diff CI 验证 团队规则决定是否合并

这才是工程团队能长期使用的方式。

你会发现，Codex 最强的地方不是“替你点 merge 按钮”，而是把 PR 过程中最消耗注意力的工作拆成清楚的步骤，并且每一步都有记录、有证据、有回滚空间。

十四、总结

这篇我们讲的是 Codex 系列里非常实战的一环：GitHub PR。

可以记住 5 句话：

1. PR 是 Codex 最适合发挥的结构化场景之一。
2. 修 Review 评论前，先让 Codex 读评论、判定是否仍适用。
3. 修复时一定要限制范围：只处理指定评论，保持最小改动。
4. /review、@codex review、GitHub Action 适合不同阶段，不要混用成一锅粥。
5. 合并前必须看 diff、跑测试、等 CI、遵守团队规则。

如果你能把这套流程固定下来，Codex 就不只是“帮你写代码”的工具，而会变成一个参与 PR 协作、降低 Review 成本、稳定输出交付结果的长期工程伙伴。