Codex 自动生成 Pull Request：代码修改、说明和审查流程

让 Codex 改代码只是第一步，真正进入团队协作时，还需要把改动整理成 Pull Request。一个好的 PR 不只是代码提交，还要说明改了什么、为什么改、如何验证、有什么风险，以及审查者应该重点看哪里。

如果你正在搭建 AI 编程协作流程，可以继续阅读站内 实战工作流；如果你关注代码质量和排查，也可以查看 问题排查教程 和 使用技巧教程。

为什么要让 Codex 生成 Pull Request

Pull Request 是团队代码交付的核心节点。它把需求、代码、测试、截图和审查意见放在同一个地方。Codex 自动生成 PR，可以减少整理说明的重复工作，也能让 AI 在提交前先做一次自查。

PR 不等于简单提交代码

一个完整 PR 应该包含改动背景、核心修改、影响范围、测试结果、截图或录屏、风险说明和回滚建议。只有这些信息完整，审查者才能快速判断改动是否可靠。

适合 Codex 生成 PR 的场景

适合自动生成 PR 的任务包括：小功能开发、Bug 修复、测试补充、文档更新、性能优化、脚本改造和 WordPress 自动化流程增强。高风险改动仍需要人工确认范围和发布节奏。

第一步：先明确代码修改范围

PR 质量取决于修改范围是否清晰。让 Codex 开始之前，应该明确目标、相关文件、不能修改的区域和验证方式。不要让 AI 在一个 PR 里同时做功能开发、重构、样式调整和依赖升级。

推荐提示词

请基于当前需求完成最小代码修改。
要求：
1. 先阅读相关文件并说明修改计划；
2. 只修改和任务直接相关的文件；
3. 不做无关重构；
4. 修改后展示 diff 摘要；
5. 运行可用测试；
6. 最后准备 PR 标题和说明。

这条提示词能让 Codex 把“代码修改”和“PR 准备”连接起来，而不是只给出零散代码片段。

第二步：让 Codex 查看差异并自查

在生成 PR 之前，Codex 应该先检查本地差异。它需要确认修改文件是否符合预期，是否意外改动了无关文件，是否有调试日志、临时文件、密钥或格式化噪音。

自查清单

• 是否只修改了任务相关文件。
• 是否没有把密钥写入源码。
• 是否没有删除线上数据或危险逻辑。
• 是否没有修改主题核心文件。
• 是否运行了必要测试。
• 是否有清晰的回滚方式。

适合站长项目的边界

如果项目涉及 WordPress 自动发布，PR 中应特别说明：密钥来自 .env，默认文章状态为 draft，不允许直接 publish，不删除线上文章，不修改管理员密码。这些边界可以写进 PR 风险说明。

第三步：自动生成 PR 标题和说明

PR 标题要短，说明要完整。Codex 可以根据 diff 自动总结改动，但你需要要求它按固定格式输出，避免说明过于随意。

PR 说明模板

## Summary
- 说明本次 PR 解决了什么问题
- 列出核心改动

## Changed Files
- 说明关键文件和职责

## Tests
- npm run check
- 其他验证命令或手动检查

## Screenshots
- 如果是前端改动，附截图说明

## Risks
- 说明可能影响范围和回滚方式

如果团队使用中文，也可以把模板改成“修改摘要、文件清单、测试结果、截图、风险说明”。关键是保持格式固定，方便审查。

标题怎么写

标题建议使用动词开头，例如“修复文章发布脚本的标签权限处理”“新增正文图片上传替换逻辑”“补充 Codex 测试工作流文档”。不要写成“更新代码”这种无法判断内容的标题。

第四步：运行检查并记录结果

PR 最重要的信任来源是验证结果。Codex 应该运行项目已有检查，例如语法检查、单元测试、构建命令、格式化检查或手动验证清单。无法运行时，也要说明原因。

测试记录要具体

不要只写“测试通过”。应该写清楚运行了什么命令、结果是什么、是否有警告、是否跳过了某些检查。对于前端页面，还可以附截图；对于 WordPress 发布脚本，可以说明是否只发布草稿。

失败时不要强行开 PR

如果检查失败，Codex 应先分析失败原因，判断是代码问题、环境问题还是测试需要更新。失败状态下也可以开草稿 PR，但说明里必须明确标出阻塞项。

第五步：审查流程如何设计

PR 创建后，审查者需要快速知道重点。Codex 可以在说明中加入“Review Focus”，提示审查者重点看权限、边界条件、数据写入、UI 状态或兼容性。

审查者应该看什么

审查重点包括：修改范围是否合理，业务逻辑是否正确，是否有安全风险，测试是否覆盖关键路径，说明是否真实反映改动，是否有回滚方案。对于高风险改动，不要只依赖自动检查。

如何处理审查意见

当审查者提出问题后，可以让 Codex 逐条读取评论，判断哪些需要改代码、哪些需要补说明、哪些需要补测试。处理完后重新运行检查，并在 PR 中回复变更摘要。

第六步：适合 Codex 的 PR Prompt 模板

下面是一条可直接复用的完整 Prompt，适合让 Codex 从代码修改走到 PR 草稿。

完整模板

请完成本次任务并准备 Pull Request。
任务目标：[写清楚需求]
限制条件：只改相关文件，不写入密钥，不做无关重构。
步骤：
1. 阅读相关代码并说明计划；
2. 完成最小修改；
3. 查看 diff 并自查风险；
4. 运行可用测试；
5. 生成 PR 标题和说明；
6. 标出审查重点和剩余风险。

如果团队已经有 PR 模板，可以让 Codex 严格按现有模板填写，不要重新设计格式。

常见问题

Codex 可以直接帮我创建 PR 吗？

可以，但前提是本地仓库和 GitHub 权限已经配置好。更稳妥的做法是先让 Codex 准备改动、运行检查并生成 PR 说明，再由你确认后创建。

PR 说明需要写多详细？

要足够让审查者理解改动背景、核心文件、测试结果和风险。小改动可以简洁，大改动必须说明影响范围和回滚方式。

测试没跑通可以开 PR 吗？

可以开草稿 PR，但必须明确标记失败原因和待处理项。不要把失败检查包装成通过。

AI 生成 PR 会不会引入无关改动？

有可能。因此必须让 Codex 查看 diff，自查修改范围，并在 PR 中列出关键文件。审查者也要重点检查是否有无关重构或格式化噪音。