Codex 修 bug 回滚记录常见错误和修复顺序

新手用 Codex 修 bug，很容易被“工具很快给出补丁”带着走。结果是 bug 可能修好了，但记录没有留下；或者 bug 没修好，却已经改了一堆无关文件。客户一问怎么验证、怎么回滚，你才发现自己没有证据。

这篇是草稿，只做复盘参考，不替代具体项目的人工审核。还没有固定流程的，先看 回滚记录主流程 和 检查清单。

适合谁

适合已经让 Codex 参与 bug 修复、但常常出现“修完才想起没截图”“提交前才发现改了别的文件”“交付时说不清验证结果”的新手。

也适合做项目复盘的人。你可以把这些错误改成自己的开工检查项，让每次修复都有明确的证据和边界。

不适合谁

不适合正在处理高风险生产事故、但没有客户授权或团队流程的人。真实事故需要按客户流程处理，不能只靠文章建议自行推进。

也不适合想让 Codex 自动决定是否上线、是否回滚、是否修改权限的人。工具可以辅助整理，但上线和回滚判断必须由有权限的人确认。

风险提醒

发现修复方向不对时，最重要的是停下来，不要用更多改动掩盖前面的不确定。先保存当前状态、看 diff、恢复无关改动，再重新确认复现步骤和验收标准。

错误一：没看工作区就开始改

如果工作区里已经有客户或自己之前的改动，Codex 继续修改时可能把它们混在一起。最后交付时，你很难说明哪些是本次 bug 修复，哪些是原本就存在的变更。

修复方式：每次开始前运行 git status，如果有不认识的改动，先记录并询问来源。不要把不属于本次任务的变化一起提交。

错误二：没有复现记录

只看客户一句“页面坏了”就开始修，容易修到错的地方。没有复现步骤，就无法证明修复有效，也无法区分客户后续反馈是同一个 bug 还是新问题。

修复方式：保存原始报错、截图、链接、浏览器、环境、操作步骤和预期结果。能本地复现就本地复现，不能复现就把缺失材料列为客户待确认。

错误三：修改范围过大

Codex 有时会给出顺手优化、重构或风格调整。它们可能看起来合理，但会增加验证成本。小 bug 被改成大变更，是新手最常见的项目风险之一。

修复方式：先做最小修改。任何额外优化都写成“后续建议”，不要混进本次交付。看 diff 时，如果一处变化不能直接解释它和 bug 的关系，就先移出。

错误四：没有验证命令

交付时只说“我试过了”，客户很难信任。验证命令、截图、页面路径、测试结果和失败范围，才是可复查的证据。

修复方式：至少记录一条验证命令或人工检查路径。比如 npm run build、npm run lint、某个页面的 smoke test、某个表单的复现步骤。没有验证方式的任务，不适合承诺已经完成。

错误五：没有回滚点

如果修复后出现新问题，你需要知道怎么退回。没有分支、提交、文件列表和回滚说明，客户会觉得你在边试边改。

修复方式：提交前记录修改文件和当前提交。交付时写清楚“如果需要回滚，恢复这些文件或退回到这个提交”。对高风险变更，先让客户确认回滚窗口和责任范围。

具体步骤：发现改乱后的处理顺序

1. 暂停继续修改，不要继续让 Codex 扩大范围。
2. 查看 git status 和 git diff，列出所有变化。
3. 区分目标 bug 相关改动、无关改动、无法解释的改动。
4. 保留必要证据：原始报错、当前 diff、验证命令输出。
5. 移除无关改动，或单独记录为后续建议。
6. 重新确认复现步骤和验收标准。
7. 只提交最小修复，并写清验证和回滚方式。
8. 对需要客户授权的事项，记录为待确认，不继续执行。

复盘模板

本次问题：
出现的错误：
原因：
已恢复的无关改动：
保留的修复：
验证方式：
回滚方式：
下次开工前新增检查项：

CTA：下一步

如果你想把这些错误变成固定流程，回到 修 bug 检查清单。需要向客户解释范围变化时，可以先用 Proposal 生成器 起草，再手动加入验证、未覆盖和回滚说明。

免责声明

本文只用于 AI 工具实践流程学习和草稿复核，不构成法律意见、安全审计、职业建议或具体项目承诺。真实项目应以客户授权、平台规则、合同约定和人工复核为准；需要登录、授权、上线或回滚的事项，应先记录并由客户确认。