核心问题

为什么不能稳定复现的问题，很难稳定修复？

真实场景

用户反馈“偶尔提交失败”。测试试了几次没有出现，工程师看日志也没发现明显错误。于是团队说：“先观察。”

几天后，同样问题再次出现，影响了更重要的客户。

常见误区

坏判断是：

这个 Bug 很随机，先猜一个原因修了再说。

如果不知道触发条件，就很难确认修复是否真的有效。

工程视角

复现不是重复点击几次，而是找到触发问题的条件组合：

  • 哪个用户？
  • 哪个入口？
  • 哪个浏览器或设备？
  • 哪个数据状态？
  • 哪个时间段？
  • 是否和并发、缓存、权限有关？

复现路径越精确，修复质量越高。

PM 可以怎么做

PM 最适合帮助补齐上下文：

  • 收集用户操作路径。
  • 记录时间、账号、设备、截图。
  • 标记业务状态。
  • 区分“必现”“高概率”“偶现”。
  • 协助判断影响范围。

Atlas Action

建立一个 Bug 复现模板：

用户/账号：
发生时间：
入口页面：
前置数据状态：
操作步骤：
期望结果：
实际结果：
出现频率：
影响范围：

小结

复现是修复的地基。

PM 提供的上下文越完整，工程师越能从“猜原因”进入“验证原因”。