我在各个社区里潜水，经常能看见有人求助，大家互相帮助的情况。但遗憾的是，我发现绝大多数的帮助都是无效的，最终能够真正解决问题的很少。比如一个人在群里问："我遇到了问题X，怎么去解决？"大家可能会给出很多建议："你试试A行不行，试试B行不行。"但最终试了之后，发现都没什么用，整个求助也就不了了之。
这里面的原因很复杂，但在这里我只想从一个很小的角度来讨论。在很多情况下，我们只要用一些简单的面向注释编程的技巧，稍微改一下问问题的方式，就可以极大地提升求助的效果，可能可以很快得到真正有用的回应。
在看这个小技巧之前，我们先去观察一下大家求助和互相帮助的时候遇到的最大的问题是什么。我的观察是，这个最大的问题是大家只是单纯的拍脑袋去想有什么原因能够解释求助的人遇到的问题。换言之，A可以导致X，你应该去试试改正A这个事情。
举个最简单的例子，比如有个小白求助："我家里灯泡不亮，应该怎么办？"一个很自然的回复就是："如果灯泡坏了，会导致灯不亮，所以你应该去买个灯泡换上。"这样的思路看起来没什么问题，但如果观察得多了就会发现它是一种非常低效的解决问题的方法。在编程里面叫做random debugging，或者叫拍脑袋解决问题。这是因为导致X的原因可能有很多，一个个试过去需要很长的时间。
还是用刚才的灯泡不亮的例子来看，可能是因为停电了，可能是因为插线板坏了，可能是因为电灯的开关坏了，或者某个电线断了，当然也有可能是灯泡坏了。一个一个可能的原因排查过去的话要查到猴年马月。而且还有一种可能是人自己的问题，比如可能在换了灯泡换了灯之后还是没用，最后一个星期以后发现是空气开关没打开。不要笑，这个在求助的情况下非常常见。
那如果我们不想用Random debugging，有没有什么方法能够高效地找到问题的原因呢？这其实是一个很值钱很根本的问题，做好了这一点基本上就能在工作和生活中上一个巨大的台阶。说穿了它也并不复杂，就是我们不要从正面拍脑袋去凑X可能的原因，而是通过设计一系列的实验，逆向一步步的缩小范围。
对这个灯泡的例子而言，比如说可以先试一下同一个插线板的其他灯亮不亮。如果不亮，可能就是插线板或者空气开关或者停电的问题。如果亮，就说明是灯本身的问题。那灯本身又可能是灯泡的问题、线路的问题、开关的问题等等。我们可以直接用一个测电笔在灯泡附近测一下看看有没有电。如果有电但是灯泡不亮，就说明是灯泡的问题，我们就去换灯泡就好了。如果没电，就说明可能是线路包括开关的问题。通过这一系列非常简单的实验，我们可以在一两分钟内就可以非常精确的判断出问题的真因，然后去加以解决。这个过程比比如去换一个插线板、去买一个新灯泡要省时间多了。
但是为什么大家在网上不这么帮助别人呢？这一方面是因为拥有这种逆向debug mindset的人非常少，但另一个非常重要的原因是提问的方法不对。绝大多数求助的帖子问的问题都是"我应该怎么办"，那大家自然而然就会给你提你应该怎么办的建议，比如你应该去换个灯泡，你应该去换个插线板。这种提问的方式就暗示了你想要的是一个直接的最终的解决方法，求仁得仁，自然你得到的也是零散且无章法的答案。
如何解决这个问题呢？在AI领域有一个Prompt Engineering的小技巧叫做Chain of Thought，其实正好可以用在这里。与其问最终的解决方法，更好的问题是问大家"这可能是什么原因导致的，并且我怎样判断是这个原因"。在灯泡的例子里，比如我们可以说："现在我的灯不亮，有没有什么方法能够帮助我找到是哪个环节出了问题？"这样的问法就可以逼着大家去思考可能有很多种不同的问题，而不一定是灯泡坏了，从而可以给你更有效的答案。
当然从另一个角度来说，有可能你这么思考下去会发现我根本不需要上网去问别人，而可能自己就解决了。或者另一种情况是，等到你真的发现自己解决不了上网要问别人的时候，你会自然而然把你的思路给写出来，这样对你得到更有效的帮助也是非常有力的。
所以总的来说，这种逆向debug的mindset是工作和生活中非常关键的一个技能。它可以帮我们节约大量的时间，同时让我们能做到以前做不到的事情。而且通过一些简单的prompt engineering的技巧，我们也可以给别人带来这样的mindset，帮助他们一方面更有效的解决我们自己求助的问题，另外一方面也可以给他们启发，让他们更高效的解决他们自己的问题。这也是我写这篇文章的目的。
Comments