核心问题

为什么调试是一种科学方法？

真实场景

订单列表偶尔少一条数据。有人怀疑是前端分页问题，有人怀疑是后端查询条件，有人怀疑是数据库延迟。

如果大家同时改，就会乱成一团。

常见误区

坏判断是：

多改几个地方，反正总会好。

这会让修复结果不可解释，也会引入新问题。

工程视角

科学式调试的基本节奏是：

现象 -> 假设 -> 实验 -> 结果 -> 新假设

例如：

现象：订单列表少一条。
假设：后端查询过滤了 status = pending。
实验：直接查数据库和接口返回，对比两边数据。
结果：数据库有，接口无。
结论：问题在后端查询之后，不在前端。

PM 可以怎么做

PM 可以要求团队把当前判断说清楚：

  • 当前最可能假设是什么？
  • 证据是什么？
  • 反证是什么？
  • 这次实验会排除哪一段？
  • 实验结果出来后下一步是什么？

Atlas Action

在 Bug 复盘里增加一栏：

我们当时的假设是什么？后来被证实还是推翻？

训练团队从经验主义走向可验证判断。

小结

调试不是一次性找到答案，而是不断排除不可能。

PM 的作用，是帮助团队把混乱讨论变成清晰实验。