速查表：Bug 修复流程 · Atlas PM 软件工程课

核心问题

一个 Bug 从发现到修复，应该怎么推进？

Bug 出现时，大家都想马上解决。但没有流程的快，常常只是乱。

这张表的目的，是让 PM 和工程师在同一张排障地图上协作。

坏判断是：

先修，复盘以后再说。

如果修复过程没有记录，复盘时只剩记忆和情绪。

一个高质量 Bug 处理流程至少包括：

发现 -> 复现 -> 定级 -> 假设 -> 实验 -> 修复 -> 验证 -> 发布 -> 复盘

每一步都应该留下最小记录。

使用这张检查清单：

1. 现象是否描述清楚？
2. 是否有稳定复现路径？
3. 是否知道影响范围？
4. 是否确定优先级和严重等级？
5. 当前技术假设是什么？
6. 每次操作验证什么？
7. 是否需要回滚、降级或公告？
8. 修复后如何验证？
9. 是否需要补数据或补偿用户？
10. 是否留下复盘记录？

把 Bug 单从“问题描述”升级为“三段式”：

现象：
复现：
影响：

这是 PM 最容易立刻提升工程协作质量的动作。

Bug 修复不是单纯写代码，而是一次从混乱走向确定的过程。

PM 做得好，团队会更快进入真实问题，而不是在噪音里打转。