那次我在群里贴了一行报错，问这个怎么解决，然后去接了杯水。回来消息是零。
过了几个小时有人回了一句：什么环境，什么时候开始的，改过什么。三个问题，我一个都答不利索。
以前我提问都是这个形状，抓一个最显眼的报错往群里一丢，以为这样最省事。实际上省下的时间是从别人那里挪的：对方要花时间猜我在干什么，猜错了再问一轮。一个问题被反问三遍才有人能答，说明提问的人省下的时间是由回答的人付的。
后来我给自己定了个格式，提问前先写三行：我试过什么，结果是什么，我猜是什么。
最近一次用得上的是接口在本地正常、部署到测试环境就返回五百这件事。
我照着格式写：我试过清缓存重发，试过把参数换成最简单的一组，结果都没变；结果是本地用同一组参数返回正常，测试环境稳定报错，日志里只有一行框架堆栈，指不到业务代码；我猜是两边配置不一样。写到第三行我停住了，因为我意识到自己从来没确认过两个环境连的是不是同一个库。
去查，果然不是。测试环境连的是一个新建的库，我前一天在那边加的字段没有加。补上，通了。
这段排查真正花时间的地方是写那三行，剩下的都是执行。
带上下文去问还有个副作用。对方不需要替我把整件事想一遍，只需要回答我猜的那一行，也就是方向对不对。如果不对，他会直接给一个我没想过的方向，这比让他从头复述一遍排查思路快得多。
多数本地好、部署后不好的问题，查到底都落在配置和数据的差异上，跟代码关系不大。这个规律是我一次次猜错攒出来的，也是我现在写第三行时最先想到的几个方向之一。
写这三行的过程本身解决了一半问题，因为写的时候会被迫检查一遍前提。很多问题不是不会解，是漏了一个自己以为早就确认过的条件。
提问质量取决于带了多少上下文。带够上下文的问题经常自己就答出来了，答不出来，也是问对了人。反过来，一个需要对方问三遍才能答的问题，本质上是把排查成本转嫁给了别人。我宁可在提问框里多写五分钟，也不想让别人替我走一遍我该走的路。
