IT从业者一部分时间花在如何偷懒（即，尽可能自动化），另外一部分时间则是在解决问题，例如Bug Fix（修复故障）、性能提升、体验优化等等。

而解决问题中的绝大部分时间则是在寻找问题，也就是我们所说的「问题重现」，重现问题的操作路径，顺藤摸瓜，就能找到症结所在。

看上去很简单是不是，这只是理想状态。

首先，用户基本上不会记得Ta曾经历的步骤，再加上如果是小概率事件，那么就更难以描述了。而关键在于，用户通常不会告诉程序员们他们不记得了，大多数时候，他们会把依稀记得的场景「做实」，很笃定地告诉程序员们「是的，我就是正常操作的」。

单纯的程序员们也许就信了这样的「正常操作」，但是为了找到那个点，还是得自己尝试，运气好的还真能试出来，但大多数情况下，没这么顺利，开启了「yak shaving」之旅。(参见 造轮子还是用轮子)

就这样，当不能确定问题到底在哪里的时候，就算路过的好心的同事也帮不了你。因为，「我现在碰到的是个什么问题」大概连自己都说不清楚。

对于技术工作者而言，碰到问题，最重要的美德是想办法自己去解决。

搜索引擎也好，写个测试用例也好，重新审阅代码逻辑也好，总之，在提问之前，至少自己要有所尝试。而有趣的是，一开始一团迷雾的你，在一层一层去搜索的过程中，关键词越来越明确，也就越来越接近真相了。相信很多人都有这样的感受，有时候在搜索框里都不知道该输入什么关键词，而尝试着搜了一搜，或许正是在搜索结果中才意外发现了「哦，原来是应该要用这样的关键词搜」

「关键词」是「如何提问」其中一个重要的因素。

举个稍微偏专业一点的例子，对 JavaScript 有了解的同学，多半都有听过「闭包」这个词，关于「闭包」，定义是这样的：

闭包就是能够读取其他函数内部变量的函数。例如在 javascript 中，只有函数内部的子函数才能读取局部变量，所以闭包可以理解成“定义在一个函数内部的函数”。在本质上，闭包是将函数内部和函数外部连接起来的桥梁。

以上摘自百度百科

很专业，很深奥是不是？但是很多人一开始是怎么认识到「闭包」的呢？可能一点儿都不技术，多半是碰到了一个很奇怪的现象，特别是后端程序员，比如，写了一个简单的 for 循环，理所当然应该打印从1到10的数字，结果每次却只打印了最大的那个10，这是什么原因？百思不得其解，那么去搜索引擎要用什么关键字？「for循环 输出不正确」「js 循环」「循环 输出最大值」…… 在当下那个时间点，如果对「闭包」闻所未闻，那么很有可能就一直纠缠于这些无关的关键词之间，找不到真正的问题所在。

运气好的话，如果前人有同样的经历，又刚好以这些看似无关的关键词写了一篇问答，这才万事大吉。但更多时候，则是在真相的门外不停兜圈子。

这是个很要命的问题，我们看到的其实是现象，但正因为对于原因不解，找不到原因，则会加上自己的一些猜测，有时候，就误把现象当成了成因，而如果再把这猜测的原因和现象糅合在一起，去提问，多半也会让对方费解，把思路给带偏了。

所以，好的提问中非常重要的另一点则是「真实地描述现象，不要把自己还不确定的猜测带入其中」

举个例子，好的提问和不好的提问

愚蠢：

我在编译内核时接连遇到 SIG11 错误，怀疑主板上的某根电路丝断了，找到它们的最好办法是什么？

明智：

我组装的电脑（K6/233 CPU、FIC-PA2007 主板威盛 Apollo VP2 芯片组、Corsair PC133 SDRAM 256Mb 内存）最近在开机 20 分钟左右、做内核编译时频繁地报 SIG11 错，但在头 20 分钟内从不出问题。重启动不会复位时钟，但整夜关机会。更换所有内存未解决问题，相关的典型编译会话日志附后。

不好在哪里？

告诉高手是什么导致了问题是没用的（如果你的诊断理论是了不起的东西，你还会向别人咨询求助吗？）。所以，确保只是告诉他们问题的原始症状，而不是你的解释和理论，让他们来解释和诊断。如果你认为陈述自己的猜测很重要，应清楚地说明这只是你的猜测并描述为什么它们不起作用。

这个例子来自于今天看到的一篇程序员们翻译的《How-To-Ask-Questions-The-Smart-Way》，其中提到的一些提问禁忌和秘诀，很有指导意义，全文篇幅并不短，除了「如何提问」，还列举了「如何回答」的一些要点。

很多人大概没耐心看完，这么麻烦，本来问人就是图个省事儿，这么费劲还有什么意义？

的确如此，提问一般分为两种，一种是想走捷径，尽快从别人那里得到现成的答案；另一种则真的是黔驴技穷，需要有人来指点迷津。无论哪一种，都逃不过最关键的那一步「让别人清楚明白地知道你寻求解决的问题究竟是什么」，对于简单的问题，自己动动手指就能查阅到的，一般高手也不屑于回答或者不会把时间花在这上面。而对于复杂的问题，如果没有经过自己的分析，就算拉了个高手到身边，你也很难在有限的时间内「描述清楚」。

所以，「问别人能够节省时间」的前提是 「问题很清楚，对方也能很快明白，并且在有限的时间内可以无限接近真相」。

否则，只会把双方的时间都耗尽，因为，从提问到反复确认问题，直到问题真正解决，可能会是一个非常漫长的过程，有时候真不如自己研究个透彻，但是既然走到了这一步，想必是自己已经无力解决了，除了请教别人，大概也别无他法了。

既然如此，那么就好好遵循「提问的技巧」，双方都可以愉快地你问我答 Happy Ending了，点击原文可以直达该篇指南。无论你是否从事技术类工作，都可以看一看，毕竟在日常工作的大部分内容都可以归咎于「提问」和「回答」。

最后，摘录文中「如何解读回答」中的一段文字感受一下。很多时候，并不是那些「厉害的人」傲慢无礼，而是提问的人真的很让人抓狂😓

有一个古老而神圣的传统：如果你收到 读读该死的手册（RTFM） 的回复，发信人认为你应该去“读读该死的手册”。他或她多半是对的，去读一下吧。

通常，叫你搜索的人已经打开了能解决你问题的手册或网页，正在一边看一边敲键盘。这些回复意味着他认为：

第一，你要的信息很容易找到。

第二，自已找要比别人喂到嘴里能学得更多。

你不应该觉得这样就被冒犯了，按黑客的标准，回复者没有不理你就是在向你表示某种尊敬，你反而应该感谢他热切地想帮助你。