Codex 修 bug 时如何保留回滚记录

用 Codex 修客户项目里的 bug，最怕的不是“没修好”，而是修到一半发现不知道自己改了什么、客户原来有什么改动、哪条命令验证过、出了问题能不能退回。新手项目练习时，回滚记录就是你的安全绳：它让每一次修改都有来源、有边界、有验证、有退路。

这篇是草稿，只做流程学习和人工审核参考，不构成具体项目承诺。你可以配合 报错解释器、Proposal 生成器 和 模板库 使用：先把 bug 拆清楚，再让 Codex 处理小范围修改。

适合谁

适合刚开始用 Codex 处理前端样式错误、构建失败、文案错位、小脚本异常、配置疏漏和轻量功能修复的新手。你可以还不熟悉大型工程，但需要愿意保存原始报错、阅读 diff、跑验证命令，并把结果写进交付记录。

也适合想建立项目 SOP 的人。客户不只关心你用了什么工具，更关心修复是否能复查、是否影响其他功能、出了问题能否快速回到修改前状态。

不适合谁

不适合直接在生产环境里大范围修改、没有仓库记录、没有测试方式、没有客户授权却要动支付、账号、数据库或真实用户数据的任务。遇到这些情况，新手应先暂停，要求补充环境和权限说明。

也不适合把 Codex 的一次输出当成完整修复的人。AI 可以给出候选修改，但是否真的解决 bug，要看复现、验证、diff 和人工复核。

风险提醒

任何修 bug 任务都可能引入新问题。尤其是涉及生产数据、账号权限、支付配置、安全漏洞、部署回滚、数据库迁移时，不能只靠“看起来能跑”来交付。需要客户确认授权和回滚方案的事项，先写成待确认项，不要擅自执行。

具体步骤

1. 保存客户原始报错、截图、复现步骤和预期结果。
2. 运行 git status，确认工作区是否干净，是否有客户已有改动。
3. 记录当前分支、最新提交和本次预计修改范围。
4. 让 Codex 先解释可能原因，不要马上改全项目。
5. 只修改和 bug 直接相关的文件，避免顺手重构。
6. 修改后查看 git diff，确认每一处变化都能解释。
7. 跑验证命令，例如 lint、build、测试、页面 smoke test 或内容检查。
8. 写回滚记录：如果修复失败，应该撤回哪个提交、恢复哪些文件、提醒客户确认什么。

回滚记录模板

任务目标：
原始报错：
复现步骤：
修改前状态：
- 分支：
- 提交：
- 工作区状态：

修改文件：
验证命令：
验证结果：

未覆盖范围：
客户待确认：
回滚方式：

这份记录不用写得很花哨，但必须能让另一个人看懂：发生了什么、你改了哪里、如何判断修好了、如果没修好该怎么退。

Codex 提示词模板

请先阅读下面的脱敏报错和相关文件片段。
不要扩大修改范围，不要修改未提到的功能。
请输出：
1. 可能原因
2. 最小修改方案
3. 需要验证的命令
4. 可能影响的边界
5. 回滚建议

如果 Codex 建议大范围重写、删除大量文件、修改权限配置或调整生产环境设置，要停下来复核。新手最稳的做法是先完成最小修复，再决定是否需要后续优化。

交付时怎么说

交付不要只写“已修复”。更好的写法是：

已根据复现步骤修复该问题。
修改范围：
验证方式：
验证结果：
未覆盖范围：
如需回滚，可恢复到提交/文件：
仍需客户确认：

这种表达能减少误会，也能保护你自己。客户后续如果要求追加功能，你可以清楚地区分“原 bug 修复”和“新增需求”。

为什么记录比速度更重要

新手常以为修 bug 的价值只在于把问题解决掉，但项目场景里，记录本身也是交付的一部分。客户看不到你在本地做了多少判断，他只能从修改文件、验证命令、截图说明和回滚方式判断你是否可靠。没有记录的修复，即使当前看起来可用，也很难在后续沟通里证明边界。

记录还能帮助你复盘报价。一次 bug 修复到底花在复现、阅读代码、实际修改、验证还是客户等待上，只有留下过程，下一次报价才不会只凭感觉。对 AI 工具新手来说，这些记录会慢慢变成作品集素材和 SOP，而不是一次性聊天记录。

CTA：下一步

想直接执行，可以看 Codex 修 bug 回滚记录检查清单。如果你常常修着修着改大了范围，继续看 常见错误和修复顺序。项目前拿不准风险，可以用 项目边界判断 和 报价计算器 拆范围。

免责声明

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