摘要
很多开发者使用 Codex 完成代码修改后，只确认页面可以运行，就直接提交 Pull Request。结果审查时才发现修改范围过大、测试没有运行、提交说明不清楚，甚至混入了无关文件。本文分享一套 Codex 与 Git 配合的工程化流程，帮助开发者完成变更检查、风险分析、PR 描述生成和合并前验证。
在真实团队项目中，代码写完并不代表任务结束。
一个完整的开发任务通常还包括：
检查修改范围；
运行类型检查；
执行自动化测试；
审查 Git Diff；
整理提交记录；
编写 Pull Request 描述；
说明风险和验证结果；
等待团队成员审查。
很多人使用 Codex 时，只关注“代码有没有生成”，却忽略了代码如何安全地进入主分支。
实际上，Codex 不仅可以帮助修改代码，也可以参与 Pull Request 的准备和自查流程。
一、为什么 Pull Request 不能只写“修复 Bug”？
一个常见的 PR 标题是：
修复订单问题描述只有一句：
已经修好了，请帮忙合并。这种 PR 对审查者几乎没有帮助。
审查者仍然需要自己判断：
修复了什么问题；
为什么会出现这个问题；
修改了哪些文件；
是否影响其他模块；
测试是否通过；
是否存在兼容性风险；
应该重点审查哪里。
高质量 PR 的目标不是证明“我写完了”，而是降低别人理解和审查代码的成本。
二、提交前先检查工作区
Codex 修改完成后，第一步不要急着提交。
先运行：
git status它可以帮助确认：
哪些文件被修改；
是否出现新文件；
是否误修改配置；
是否包含临时文件；
是否生成了不应该提交的产物。
例如发现：
modified: package.json modified: src/views/order/List.vue modified: src/api/order.ts untracked: debug.log如果本次任务只是修复订单列表，就需要检查：
为什么
package.json被修改；debug.log是否是临时调试文件；接口文件是否真的需要调整。
可以让 Codex先分析：
请检查当前 git status。 本次任务只应该修改订单列表和相关测试。 请判断： 1. 哪些文件属于预期修改； 2. 哪些文件可能是无关修改； 3. 是否存在调试文件或生成产物； 4. 哪些文件需要在提交前恢复。三、先看统计，再看完整 Diff
推荐依次运行：
git diff --stat git diffgit diff --stat可以快速判断修改规模。
例如：
src/views/order/List.vue | 32 +++++++++---- src/api/order.ts | 18 +++++--- tests/order/List.test.ts | 46 +++++++++++++++++++ package-lock.json | 600 +++++++++++++++++++++如果一个小 Bug 导致 Lock 文件变化了几百行，需要立即检查是否误安装了依赖。
接下来再看完整 Diff：
git diff重点检查：
是否修改无关代码；
是否改变接口字段；
是否删除异常处理；
是否存在大面积格式化；
是否留下
console.log；是否加入硬编码；
是否降低测试标准；
是否修改公共类型；
是否新增未经允许的依赖。
四、让 Codex 做第一次 Diff 审查
可以把当前 Git Diff 交给 Codex，让它先做一轮自查。
推荐提示词：
请审查当前 Git Diff，不要继续修改代码。 本次任务目标： 修复订单列表切换筛选条件时重复请求的问题。 请检查： 1. 修改是否围绕任务目标； 2. 是否存在无关文件变化； 3. 是否改变原有接口行为； 4. 是否遗漏边界条件； 5. 是否引入重复请求或状态问题； 6. 是否补充了有效测试； 7. 是否存在为了通过测试而降低断言的情况； 8. 是否留下调试代码； 9. 是否适合提交 Pull Request。 最后按照高风险、中风险、低风险输出问题。这一步不能替代人工审查，但可以提前发现明显问题。
五、Pull Request 应该包含哪些内容？
一份完整的 PR 描述，至少应该包含以下部分。
1. 变更背景
说明为什么要修改。
例如：
订单列表在切换状态筛选时，会同时触发监听器和初始化请求，导致接口重复调用。
2. 根本原因
说明问题发生在哪里。
例如：
页面初始化逻辑和筛选条件监听器使用了相同请求方法，但没有区分首次加载与用户主动切换。
3. 修改内容
列出具体变化。
例如：
调整首次加载逻辑；
避免监听器重复触发；
保留原有分页和筛选行为；
增加重复请求回归测试。
4. 验证结果
说明运行了哪些检查。
例如：
类型检查：通过；
单元测试：通过；
构建：通过；
手动切换筛选条件：通过；
分页切换：通过。
5. 风险说明
说明可能影响哪里。
例如：
本次仅调整订单列表请求触发时机，没有修改接口参数、状态枚举和权限逻辑。
六、让 Codex 生成 PR 描述
代码和测试验证完成后，可以使用：
请根据当前任务、Git Diff 和测试结果生成 Pull Request 描述。 格式包括： ## 变更背景 ## 根本原因 ## 修改内容 ## 涉及文件 ## 验证结果 ## 风险说明 ## 审查重点 要求： - 不夸大修改效果； - 不填写没有实际运行的测试； - 明确说明未处理的内容； - 使用简洁、可审查的语言。生成结果可以是：
## 变更背景 订单列表切换状态筛选时，会出现两次相同接口请求。 ## 根本原因 页面首次加载和筛选条件监听器同时触发查询方法。 ## 修改内容 - 区分首次加载与筛选条件变更； - 保持分页切换行为不变； - 增加重复请求回归测试。 ## 涉及文件 - src/views/order/List.vue - tests/order/List.test.ts ## 验证结果 - npm run type-check：通过 - npm run test：通过 - npm run build：通过 ## 风险说明 未修改订单接口、权限逻辑和状态枚举。 ## 审查重点 请重点检查筛选条件监听逻辑和首次加载行为。七、不要让 Codex 虚构验证结果
这是 AI 生成 PR 描述时最需要注意的问题。
如果没有真正运行测试，不能写：
所有测试均已通过。正确方式是明确告诉 Codex：
只能写入实际执行过的验证结果。 如果某项没有运行，请标记为“未执行”，不要推测结果。例如：
## 验证结果 - 类型检查：通过 - 订单模块测试：通过 - 完整测试：未执行 - 构建：通过 - 手动回归：未执行这种写法比虚构“全部通过”更可靠。
八、提交记录也要保持清晰
一个 PR 如果包含十几个混乱提交，审查和回滚都会变得困难。
不推荐：
修改一下 继续修改 测试 再修复 最终版 最终版2更推荐使用表达明确的提交信息：
fix: avoid duplicate order requests test: add regression tests for order filters docs: update order module notes提交信息至少应该说明：
修改类型；
修改对象；
修改目的。
如果任务很小，可以整理成一个完整提交。
如果任务包含代码和文档两个独立部分，也可以拆成多个清晰提交。
九、合并前必须重新验证
PR 创建后，代码可能继续发生变化。
例如：
主分支出现新提交；
解决冲突时误改代码；
根据审查意见继续调整；
测试文件发生变化；
依赖版本更新。
因此，最终合并前要重新执行：
npm run type-check npm run lint npm run test npm run build并重新检查：
git status git diff如果使用远程分支，还要确认当前代码已经同步最新主分支。
十、让 Codex 根据审查意见修改代码
收到审查意见后，不要只输入：
按照评论修改。更推荐逐条整理：
下面是 Pull Request 的审查意见。 意见一： 筛选条件变化时应该重置页码。 意见二： 当前测试没有覆盖快速连续切换状态。 意见三： 不要修改公共请求工具。 请先分析： 1. 每条意见是否合理； 2. 需要修改哪些文件； 3. 是否会扩大任务范围； 4. 需要增加哪些测试。 确认方案后，再按照最小修改原则调整。这样可以避免 Codex 为了解决一条评论，顺手重写整个模块。
十一、建立固定的 PR 检查清单
可以在仓库中增加 Pull Request 模板：
## 变更类型 - [ ] 新功能 - [ ] Bug 修复 - [ ] 重构 - [ ] 测试 - [ ] 文档 - [ ] 配置 ## 提交前检查 - [ ] 已确认修改范围 - [ ] 已检查 Git Diff - [ ] 没有无关文件变化 - [ ] 没有调试代码 - [ ] 没有未经允许的新依赖 - [ ] 已运行类型检查 - [ ] 已运行自动化测试 - [ ] 已运行构建 - [ ] 已补充必要文档 - [ ] 已说明风险和未处理内容以后无论是开发者还是 Codex 参与修改，都按照同一套标准交付。
十二、一套可以直接复用的工作流
确认任务目标 ↓ Codex 分析项目 ↓ 限定修改范围 ↓ 完成代码修改 ↓ 补充测试 ↓ 运行类型检查、测试和构建 ↓ 检查 git status ↓ 检查 Git Diff ↓ Codex 执行第一轮代码审查 ↓ 生成 PR 描述 ↓ 人工复核并提交 ↓ 根据审查意见继续调整 ↓ 合并前重新验证这套流程的核心是：
Codex 负责提高分析和整理效率，Git 负责保留变更证据，开发者负责最终判断。
总结
使用 Codex 完成代码修改后，不能直接把“代码生成完成”当作任务结束。
高质量 Pull Request 需要做到：
修改范围清楚；
Git Diff 可审查；
测试结果真实；
变更原因明确；
风险说明完整；
提交记录可追踪；
合并前重新验证。
更推荐的做法是：
先检查工作区，再审查 Diff；先运行验证，再生成 PR 描述；先说明风险，再请求合并。
Codex 可以帮助开发者生成代码，也可以帮助整理变更、分析风险和编写 PR 说明。
但最终能否合并，仍然应该由测试结果、代码差异和人工审查共同决定。
CSDN 文章描述
如何使用 Codex 编写高质量 Pull Request？本文介绍 Git Status、Git Diff 审查、测试验证、提交信息、PR 描述生成和合并前检查等完整工程流程。
参考资料
Git 官方文档
GitHub Pull Request 官方文档
GitHub Code Review 官方文档
OpenAI Codex 使用文档
Conventional Commits 规范
