核心问题

为什么碰运气式修 Bug 很危险？

真实场景

线上出现一个支付失败问题。有人说：“可能是缓存问题，清一下试试。”另一个人说：“可能是最近改了接口，我回滚一下看看。”

几次操作后，问题似乎消失了，但没人知道为什么。

这不是修复，这是把事故埋回地里。

常见误区

坏判断是：

先改一处试试，没好再改下一处。

这种方式最大的问题是：你无法知道到底是哪一步起作用，也无法保证同类问题不会再来。

工程视角

调试应该像科学实验：

  • 先观察现象。
  • 再提出假设。
  • 然后设计最小实验。
  • 最后验证假设是否成立。

一次只改一个变量。否则结果没有解释力。

PM 可以怎么做

PM 在事故现场不要催“赶紧改”，而要帮团队保持问题清晰：

  • 现象是什么？
  • 影响范围多大？
  • 能否稳定复现？
  • 当前假设是什么？
  • 这次操作想验证什么？

Atlas Action

Bug 讨论里听到“可能是”时，立刻补一句：

我们怎么验证这个可能性？

把猜测变成可验证假设。

小结

猜 Bug 会制造偶然修复和隐性复发。

真正的调试不是快点改，而是让每一步操作都能缩小真相范围。