提问的智慧

是否能得到有用的回答，往往取决于你所提问和追问的方式。

一次吃晚餐，和同事讨论在开发过程中遇到了问题，怎么有效的向牛牛请教问题，同事推荐了下github上的这篇文章。卷呗～

https://github.com/HandSonic/HTQ

1、提问题之前要做的事

1. 尝试在你准备提问的论坛的旧文章中搜索答案。
2. 尝试上网搜索以找到答案。
3. 尝试阅读手册以找到答案。
4. 尝试阅读常见问题文件以找到答案。
5. 尝试自己检查或试验以找到答案。
6. 向你身边的强者朋友打听以找到答案。
7. 如果说程序开发者，尝试阅读源代码以找到答案。

这有助于树立一个并不是不劳而获且浪费别人时间的提问者。

如果能一并表达在做了上述努力的过程中所学到的东西会更好，因为牛牛更乐于回答那些表现出能从答案中学习的人的问题。

草率的发问只能得到草率的回答，或者根本得不到任何答案。越是能表现出在寻求帮助前为你解决问题所付出的努力，你越有可能得到实质性的帮助！

2、有意义且描述明确的标题

好标题的范例 目标--差异的描述。不要用喋喋不休的帮帮忙、跪求、急（更别说救命啊！！！！）这样让人反感的话。

• 目标

  指出哪一个或者哪一组东西有问题

• 差异

  描述与期望的行为不一致的地方。

蠢问题：救命啊！我的笔电不能正常显示了！

聪明问题：X.org 6.8.1 的鼠标游标会变形，某牌显卡 MV1005 芯片组。

更聪明问题：X.org 6.8.1 的鼠标游标，在某牌显卡 MV1005 芯片组环境下 - 会变形。

方便让牛牛一眼就能明白你的环境和你遇到的问题。

3、精确的描述问题

• 仔细、清楚地描述你的问题或Bug的症状。
• 描述问题发生的环境。
• 描述在提问前你是怎样去研究和理解这个问题的。
• 描述在提问前为确定问题而采取的诊断步骤。
• 描述最近做过什么可能相关硬件或软件变更。
• 尽可能提供一个可以重现这个问题的可控环境的方法。

3.1、话不在多而在精

有庞大而复杂的测试样例能重现程序挂掉的情境，尽量将它剪裁的越小越好。

1. 表现出你为简化问题付出了努力，这可以使你得到回答的机会增加。
2. 简化问题是你更有可能得到有用的答案。
3. 精炼Bug报告的过程中，很可能就自己找到了解决方法或权宜之计。

3.2、描述问题症状而非猜测

属于下头提问方式了...你怀疑是啥问题咋不去自己看捏

蠢问题:

我在编译内核时接连遇到 SIG11 错误，我怀疑某条飞线搭在主板的走线上了，这种情况应该怎样检查最好？

聪明问题:

我的组装电脑是 FIC-PA2007 主机板搭载 AMD K6/233 CPU（威盛 Apollo VP2 芯片组），
256MB Corsair PC133 SDRAM 内存，在编译内核时，从开机 20 分钟以后就频频产生 SIG11 错误，
但是在头 20 分钟内从没发生过相同的问题。重新启动也没有用，但是关机一晚上就又能工作 20 分钟。
所有内存都换过了，没有效果。相关部分的标准编译记录如下…。

3.3、描述目标而不是过程

在想弄清楚如何做什么事，在开头就描述你的目的，然后才陈述重现你所卡住的特定步骤。

蠢问题:

我怎样才能从某绘图程序的颜色选择器中取得十六进制的的 RGB 值？

聪明问题:

我正试着用替换一幅图片的色码（color table）成自己选定的色码，我现在知道的唯一方法是编辑每个色码区块（table slot），
但却无法从某绘图程序的颜色选择器取得十六进制的的 RGB 值。

3.4、清楚明确的表达你的问题和需求

问“我想更好的理解X，可否指点一下哪有好一点说明？”通常比问“你能解释一下 X 吗？”更好。如果你的代码不能运作，请别人看看哪里有问题，比要求别人替你改正要明智得多。

要求他人帮你调试有问题的代码，不提示一下应该从何入手。张贴几百行的代码，然后说一声：“它不能工作”会让你完全被忽略

只贴几十行代码，然后说一句：“在第七行以后，我期待它显示 x，但实际出现的是 y” 比较有可能让你得到回应。

3.5、去掉无意义的提问句

避免用无意义的话结束提问，如 是或否、对或错、有或没有类型的问句。除非你想得到是或否类型的答案。

有人能帮我吗？---没错，有人能帮你。

这有答案吗？---不，没有答案。

3.6、礼多人不怪

彬彬有礼，多用请和谢谢您的关注，或谢谢你的关照。让大家都知道你对他们花时间免费提供帮助心存感激。

如果你有一串的问题待解决，客气一点肯定会增加你得到有用回应的机会。

4、如何解读答案

4.1、RTFM和STFW

• RTFM

  RTFM （Read The Fucking Manual），回答者认为你应该去读他妈的手册。

• STFW

  STFW（Search The Fucking Web），回答者认为你应该到他妈的网上搜索。

这些答复意味着回答者认为

1. 你需要的信息非常容易获得。
2. 你自己去搜索这些信息比灌给你能让你学到更多。

4.2、如果还是搞不懂

先试着去搞懂他的回应。如果你真的需要对方解释，记得表现出你已经从中学到了点什么。

4.3、处理无理的回应

如果你觉得被冒犯了，试着平静地反应。有些牛牛们回答问题可能是直接了当，一针见血式的交流风格，这种风格更注重解决问题，而不是使人感觉舒服而却模模糊糊。

你想得到的是信息而不是消磨时光，这时最好不要把手放在键盘上以免冒险。

5、不该问的问题

几个经典蠢问题，以及牛牛心中所想的

我能在哪找到 X 程序或 X 资源？---就在我找到它的地方啊，白痴 -- 搜索引擎的那一头。天哪！难道还有人不会用 Google 吗？

我怎样用 X 做 Y？---如果你想解决的是 Y ，提问时别给出可能并不恰当的方法。这种问题说明提问者不但对 X 完全无知，也对 Y 要解决的问题糊涂，还被特定形势禁锢了思维。最好忽略这种人，等他们把问题搞清楚了再说。

如何设定我的 shell 提示？？---如果你有足够的智慧提这个问题，你也该有足够的智慧去RTFM，然后自己去找出来。

我可以用 xxx方法 将 yyy 去实现 zzz 效果吗？---试试看就知道了。如果你试过，你既知道了答案，就不用浪费我的时间了。

我的{程序/SQL 语句}不工作 ---你还有什么要补充的吗？/真糟糕，希望你能搞定。/这关我有什么屁事？

我的 Windows 电脑有问题，你能帮我吗？ ---能啊，扔掉微软的垃圾，换个Linux开放源代码操作系统吧。

我在安装 Linux（或者 X ）时有问题，你能帮我吗？ ---不能，我只有亲自在你的电脑上动手才能找到毛病。

6、好问题和蠢问题

• 蠢问题：

  我可以在哪儿找到关于 xxx 的资料？

伸手党白嫖呗。

• 聪明问题：

  我用 Google 搜索过 "xxx"，但是没找到有用的结果。谁知道上哪儿去找xxx的资料？

• 蠢问题：

  我从 xxx 项目找来的源码没法编译。它怎么这么烂？

都是别人的问题呗。

• 聪明问题：

  xxx 项目代码在 Nulix 6.2 版下无法编译通过。我读过了 FAQ，但里面没有提到跟 Nulix 有关的问题。这是我编译过程的记录，我有什么做的不对的地方吗？

​

7、如何更好的回答问题

• 态度和善一点
• 对初犯者私下回复
• 如果不确定，一定要说出来
• 如果帮不了忙，也别妨碍他
• 试探性的反问以引出更多的细节
• 如果你决定回答，就请给出好的答案
• 正面的回答问题
• 如果是在研究一番后才做出的回答，展现你的技巧而不是直接端出结果。毕竟授人以鱼不如授人以渔。

8、分享一个教科书级别的例子

是之前在Halo的作者仙总的博客上看见的

https://ryanc.cc/archives/textbook-style-questioning.html