“溯因推理是推理到最佳解释的过程。或者说，溯因推理就是从结果出发，推测出事件发生的原因的过程。”
在编程界，溯因推理发生的常见场景是维护/bug 修理。
举例说明，你的 PM 或者上级观察到了一连串错误 log ，或者用户的投诉 ，问你是怎么回事，要求你马上回复。此时你就会构思出几个猜想，你从中选出最可信，最有说服力的那一个，作为答案回复了。
那么猜想如何产生？肯定是根据每个人的工作范围，知识经验产生。这里就有一个 Availability Bias 的问题，也就是走思维捷径，思考的素材，思考的方式，都是选择最熟悉的，最偏爱的，这里甚至有随机性，比如某人早上看了一篇关于吸烟的英文文章，结果思考的时候不自觉的把“smoking test”给考虑进来了。这种 availability bias 会让人的思维产生局限。
另外，逻辑上说，“说得通”并不能证明这个解释就是正确的原因，所以你还是得找证据证明你的猜想是不是对的。而人有一种很严重的缺陷，就是会不由自主寻找支持自己偏爱的结论的证据，而忽略其他事实。结果是把人引入死胡同。同理，还有工作上各种成见，摩擦，误会的产生，大半可归因于此。
在一个很复杂的系统中，搜集信息进行推理成本很高的，甚至连部署某个小改动的成本都很高。
可能解决的办法：建立一系列小的因果关系集合，里面每个结论都是清晰，可靠，经过证明的。推理从这里出发，可确保结论的正确性，防止不必要的，错误的调查分析。
各位觉得如何？
