好问题和坏问题

最后，我们通过几个对照例子来说明什么叫“聪明地提问”。同一个问题会以两种方式出现：一种暴露出懒惰、傲慢或信息不足，另一种则展示了准备、边界和可协作性。

阅读这些例子时，不要只记住句式。真正重要的是背后的判断标准：你是否说明了目标，是否展示了尝试，是否给出了环境，是否把责任推给别人，是否让回答者有足够的信息继续分析。

查找资料类问题

蠢问题：

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

这种问法无非想得到 STFW 这样的回答。

聪明问题：

我用 Google 搜索过 "Foonly Flurbamatic 2600"，但是没找到有用的结果。谁知道上哪儿去找对这种设备编程的资料？

这个问题已经 STFW 过了，看起来他真的遇到了麻烦。

编译失败类问题

蠢问题：

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

他觉得都是别人的错，这个傲慢自大的提问者。

聪明问题：

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

提问者已经指明了环境，也读过了 FAQ，还列出了错误，并且他没有把问题的责任推到别人头上，他的问题值得被关注。

硬件或环境异常类问题

蠢问题：

我的主机板有问题了，谁来帮我？

某黑客对这类问题的回答通常是：好的，还要帮你拍拍背和换尿布吗？，然后按下删除键。

聪明问题：

我在 S2464 主机板上试过了 X 、 Y 和 Z ，但没什么作用，我又试了 A 、 B 和 C 。请注意当我尝试 C 时的奇怪现象。显然 florbish 正在 grommicking，但结果出人意料。通常在 Athlon MP 主机板上引起 grommicking 的原因是什么？有谁知道接下来我该做些什么测试才能找出问题？

这个家伙，从另一个角度来看，值得去回答他。他表现出了解决问题的能力，而不是坐等天上掉答案。

“告诉我答案”与“指引我排查”

在最后一个问题中，注意告诉我答案和给我启示，指出我还应该做什么诊断工作之间微妙而又重要的区别。

事实上，后一个问题源自于 2001 年 8 月在 Linux 内核邮件列表（lkml）上的一个真实的提问。我（Eric）就是那个提出问题的人。我在 Tyan S2464 主板上观察到了这种无法解释的锁定现象，列表成员们提供了解决这一问题的重要信息。

通过我的提问方法，我给了别人可以咀嚼玩味的东西；我设法让人们很容易参与并且被吸引进来。我显示了自己具备和他们同等的能力，并邀请他们与我共同探讨。通过告诉他们我所走过的弯路，以避免他们再浪费时间，我也表明了对他们宝贵时间的尊重。

例子背后的教训

事后，当我向每个人表示感谢，并且赞赏这次良好的讨论经历的时候，一个 Linux 内核邮件列表的成员表示，他觉得我的问题得到解决并非由于我是这个列表中的名人，而是因为我用了正确的方式来提问。

黑客从某种角度来说是拥有丰富知识但缺乏人情味的家伙；我相信他是对的，如果我像个乞讨者那样提问，不论我是谁，一定会惹恼某些人或者被他们忽视。他建议我记下这件事，这直接导致了本指南的出现。

一个好问题不保证一定有人回答，但它会显著提高别人愿意投入时间的概率。它传达的不是“替我完成工作”，而是“我已经做了该做的准备，现在需要更有经验的人帮助我继续判断”。