摘要很多开发者使用 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 文件变化了几百行需要立即检查是否误安装了依赖。接下来再看完整 Diffgit 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 规范
摘要很多开发者使用 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 文件变化了几百行需要立即检查是否误安装了依赖。接下来再看完整 Diffgit 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 规范
 - 劳力士官方服务中心)
![[C++]内存管理：串顺序存储的内存回收](http://pic.xiahunao.cn/yaotu/[C++]内存管理：串顺序存储的内存回收)
