Codex 修 bug 回滚记录检查清单

这份清单用于每次让 Codex 辅助修 bug 前后。它不是让你变慢，而是避免“改完不知道改了什么”的尴尬。只要任务来自客户，就要留下原始证据、修改范围、验证命令和回滚方式。

这篇仍是草稿，只做流程参考。建议先读 Codex 修 bug 时如何保留回滚记录，再把下面的条目复制到自己的项目记录里。涉及权限、生产环境或真实数据时，要先人工确认。

适合谁

适合处理小范围 bug 修复的新手，例如页面样式异常、构建失败、简单报错、文案展示问题、轻量配置错误和可复现的小脚本问题。你需要能运行项目命令，至少能看懂本次 diff 是否超出范围。

也适合已经开始项目、但交付说明经常写得太短的人。清单能帮你把“我修了”变成“我修了哪里、怎么验证、怎么回退”。

不适合谁

不适合没有复现步骤、没有仓库权限说明、没有测试环境、没有回滚方式的高风险任务。尤其是数据库迁移、支付配置、账号权限、安全漏洞和生产部署，新手不应单独处理。

也不适合把 Codex 输出直接提交的人。工具建议只是候选方案，最终交付需要人工看 diff、跑命令、记录证据。

风险提醒

修 bug 最容易出现范围扩散。客户只要求修按钮错位，结果你顺手改了布局系统；客户只要求解释构建错误，结果你改了部署配置。每次变更都要问：它是否直接服务于这个 bug？是否能验证？是否能回滚？

具体步骤

一、修复前

• 是否保存了客户原始报错、截图、链接和复现步骤？
• 是否知道客户认为“修好”的标准？
• 是否确认当前分支和最新提交？
• 是否运行 git status，确认工作区有没有未解释的改动？
• 是否列出了本次允许修改的文件范围？
• 是否确认没有把客户密钥、账号、真实数据或生产日志交给工具？
• 是否准备了最小验证命令？

二、让 Codex 分析时

• 是否要求它先解释原因，而不是直接大范围重写？
• 是否告诉它只处理目标文件和目标 bug？
• 是否要求它列出验证命令？
• 是否要求它说明可能影响的功能？
• 是否把需要客户确认的权限动作单独列出？

可以使用这段提示：

请只基于脱敏材料分析这个 bug。
请优先给出最小修改方案，不要重构无关模块。
如果需要登录、授权、生产环境或真实数据，请停止并列出人工确认事项。

三、修复后

• git diff 是否只包含本次 bug 相关改动？
• 是否没有覆盖客户已有修改？
• 是否没有新增敏感配置、真实日志、临时调试输出或无关文件？
• 是否跑过 lint、build、测试或页面检查？
• 是否保留了命令输出摘要？
• 是否知道如果失败要恢复哪些文件或提交？

四、交付前

• 是否写清楚修改范围？
• 是否写清楚验证方式和结果？
• 是否写清楚未覆盖范围？
• 是否写清楚客户待确认事项？
• 是否写清楚回滚方式？
• 是否确认这篇或这批内容仍是 draft，没有进入公开入口？

交付记录最好能独立阅读。也就是说，即使客户没有看过你和 Codex 的对话，也应该能通过这份记录知道：问题是什么、你改了哪些文件、验证了什么、还有哪些没有覆盖。不要把“工具建议这样做”当成理由，交付理由应该来自复现、diff 和验证结果。

如果本次修复没有覆盖某些浏览器、设备、账号角色、语言版本或部署环境，要直接写出来。未覆盖范围不是缺点，它能避免客户把没有验证过的场景误认为已经完成。

回滚记录模板

Bug：
复现：
修改文件：
验证命令：
验证结果：
未覆盖：
客户待确认：
回滚方式：

CTA：下一步

如果检查中发现自己已经改大了范围，先看 常见错误和修复顺序。需要写客户回复时，可以用 Proposal 生成器 起草，再把验证和回滚记录手动补全。

免责声明

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