# How to Ask Questions the Smart Way

在黑客世界里，你所提技术问题解答的好坏，很大程度上取决你提问的方式与此问题的难度。《提问的智慧》就是一篇教我们如何提问的文章。

黑客们喜爱有挑战性的问题，或者能激发他们思维的好问题。如果你给了我们一个值得反复咀嚼玩味的好问题，我们自会对你感激不尽。好问题是激励，是厚礼。 **好问题可以提高我们的理解力，而且通常会暴露我们以前从没意识到或者思考过的问题** 。对黑客而言，「好问题！」是诚挚的大力称赞。

我们不讳言我们对那些不愿思考、或者在发问前不做他们该做的事的人的蔑视。那些人是时间杀手------他们只想索取，从不付出， **消耗我们可用在更有趣的问题或更值得回答的人身上的时间** 。

你不必在技术上很在行才能吸引我们的注意，但你必须表现出能引导你变得在行的特质------机敏、有想法、善于观察、乐于主动参与解决问题。

## 在提问之前

在你准备向别人提问前，请先完成一下步骤：

1. 尝试在你准备提问的论坛档案或邮件列表中找到答案
2. 尝试上网搜索以找到答案
3. 尝试阅读手册以找到答案
4. 尝试阅读常见问题以找到答案
5. 尝试自己检查或试验以找到答案
6. 向身边的强者朋友打听以找到答案
7. 如果你是一名程序员，尝试阅读源码寻找答案

当你提出问题时，请先表明你已经做了上述努力；这将有助于你获得想得到的答案。如果你能一并表达在做了上述努力的过程中所 ***学到** 的东西会更好，因为我们更乐于回答那些表现出 **能从答案中学习的人的问题*** 。

运用某些策略，比如先用 Google 搜索你所遇到的各种错误信息（搜索[Google 论坛](<https://groups.google.com/)和网页>），这样很可能就直接找到了能解决问题的文件或邮件列表线索。即使没有结果，在邮件列表或新闻组寻求帮助时加上一句 `我用 Google 搜过下列关键字但是没有我想要的结果` 也是件好事，即使它只是表明了搜索引擎不能提供哪些帮助。这么做（指加上已经用 Google 搜过什么）也让遇到相似问题的人能被搜索引擎引导到你的提问来。

别着急，不要指望几秒钟的 Google 搜索就能解决一个复杂的问题。在向专家求助之前，再阅读一下常见问题，再花些时间思考这个问题。他们能从你的提问看出你做了多少阅读与思考，如果你是有备而来，将更有可能得到解答。不要一次提太多问题，这样让回答者也摸不清什么是重点。

**小心别问错了问题** 。如果你的问题基于错误的假设，黑客会用无意义的字面解释答复你，希望你会从问题的回答（不是你想得到的答案）中吸取教训。

**绝不要自以为有资格得到答案** 。之所以能够得到答案，是因为你提出有内涵、有趣、有激励作用的问题------一个有潜力能贡献社区经验的问题，而不仅仅是被动地从他人处索取知识。

**表明你愿意在找答案的过程中做点什么是极好的** 。 `谁能给点提示？` 、 `我的这个例子里缺了什么？` 或者 `我应该检查什么地方？` 比 `请把我需要的确切的过程贴出来` 更容易得到答复。因为你表现出只要有人能指个正确的方向，自己就有解决它的决心。

## 当你提问时

### 慎重地选择提问的论坛

**小心选择你要提问的场合** 。如果做了下述的事情，你很可能被忽略掉或者被看作失败者：

- 在与主题不合的论坛上贴出你的问题
- 在探讨进阶技术问题的论坛上发布非常初级的问题；反之亦然
- 在太多的不同新闻组上重复发布同样的问题
- 向既非熟人也没有义务解决你问题的人发送私人电子邮件

在选择论坛、新闻群组或邮件列表时，别太相信名字，先看看 FAQ 或者许可证以弄清楚你的问题是否切题。提问前先翻翻已有的话题，也许你能找到答案。即使找不到，也能帮助你归纳出更好的问题。

**在仔细挑选的公共论坛中提问比在私有论坛中更容易得到有用的回答** 。理由如下：

- 潜在的回复者更多
- 观众更多

黑客较愿意回答那些能帮助到许多人的问题。

### Stack Exchange {#stack-exchange}

搜索，然后在 Stack Exchange 提问。

近年来，Stack Exchange 社区已经成为回答技术及其他问题的主要渠道，尤其是那些开放源码的项目。

Google 索引网站是即时的，在看 Stack Exchange 之前先在 Google 搜索。有很大几率找到某人已经提问的问题，而且 Stack Exchange 社区的网站往往会是搜索结果中最前面几个。如果你在 Google 上没找到任何答案，再到相关主题的网站去找。使用标签以缩小搜索范围。

Stack Exchange 已经成长到[超过一百个网站](https://stackexchange.com/sites)，以下是最常用的几个：

- Stack Overflow 是问写程序相关的问题
- Super User 是问一些通用的电脑问题，如果你的问题跟代码或写程序无关，只是一些网络连线之类的，请到这里
- Server Fault 是问服务器和网络管理相关的问题

### 网站和 IRC 论坛 {#网站和-irc-论坛}

本地的使用者群组，或者你所使用软件的开发者正在宣传他们的网页论坛或 IRC 频道，并提供新手帮助，这些地方是开始提问的好地方，特别是当你觉得遇到的也许只是相对简单或者很普通的问题时。

如果程序出的问题只发生在特定 Linux 发行版提供的版本，最好先去该发行版的论坛或邮件列表中提问，再到程序本身的论坛或邮件列表提问。否则该项目的黑客可能仅仅回复，"用我们的版本"。

在任何论坛发文以前，先确认有没有搜索功能。如果有，试着从自己的问题提取关键字搜索。如果之前你已经进行过搜索引擎搜索，还是在论坛中搜索一下，因为搜索引擎有可能并未索引论坛的全部内容。

通过论坛或 IRC 频道来提供使用者支持服务有增长的趋势，电子邮件则大多是项目开发者间的交流，因为可能对别人有用，所以被保留。所以最好现在论坛或 IRC 中寻求帮助。

在使用 IRC 时，首先最好不要发布很长的问题描述，有些人称之为「频道洪水」。最好通过一句话的问题描述来开始聊天。

### 使用项目邮件列表 {#使用项目邮件列表}

当某个项目提供开发者邮件列表时，要向列表而不是其中的个别成员提问，即使你确信他一定能回答你的问题。查一查项目的文件和首页，找到项目的邮件列表并使用它。有几个很好的理由支持我们采用这种办法：

- 任何好到需要向个别开发者提出的问题，也将对整个项目群组有益。反之，如果你认为自己的问题对整个项目群组来说太愚蠢，也不能成为骚扰个别开发者的理由。
- 向列表提问可以分散开发者的负担，个别开发者（尤其是当他是项目负责人时）也许太忙以至于没法回答你的问题。
- 大多数邮件列表都会被存档，那些被存档的内容将被搜索引擎索引。如果你向列表提问并得到解答，将来其他人可以通过网页搜索找到你的问题和答案，也就不用再次发问了。
- 如果某些问题经常被问到，开发者可以利用此信息改进说明文件或软件本身，以使其更清楚。如果只是私下提问，就没有人能看到最常见问题的完整场景。

如果一个项目既有”使用者”也有”开发者”（或”黑客”）列表或论坛，而你又不会动到那些源代码，那么就向”使用者”列表或论坛提问。不要假设自己会在开发者列表中受到欢迎，那些人多半会将你的提问视为干扰他们开发的噪音。

然而，如果你 **确信** 你的问题很特别，而且在”使用者”列表或论坛中几天都没有回复，可以试试前往”开发者”列表或论坛发问。建议你张贴前最好先暗地里观察几天以了解那里的行事方式（事实上，这是参与任何私有或半私有列表的好主意）。

如果你找不到一个项目的邮件列表，而只能查到项目维护者的电子邮件地址，尽管向他发信。即使是在这种情况下，也别假设（项目）邮件列表不存在。在你的电子邮件中，请陈述你已经试过但没有找到合适的邮件列表，也提及你不反对将自己的邮件转发给他人（许多人认为，即使没什么秘密，私人电子邮件也不应该被公开。通过允许将你的电子邮件转发他人，你给了相应人员处置你邮件的选择）。

### 使用有意义并且描述明确的标题 {#使用有意义并且描述明确的标题}

在邮件列表、新闻群组或论坛中，大约 50 字以内的标题是抓住资深专家注意力的好机会。别用喋喋不休的 `帮帮忙` 、 `跪求` 、 `急` （更别说 `救命啊！！！` 这样令人反感的话，用这种标题会被条件反射式地忽略）来浪费这个机会。要在这点空间中使用极简单扼要的描述方式来提出问题。

一个好标题的范例是 `目标 ------ 差异` 式的描述，许多技术支持组织就是这样做的。在 `目标` 部分指出是哪一个或哪一组东西有问题，在 `差异` 部分则描述与期望的行为不一致的地方。

**蠢问题** ：

> 救命啊！我的笔记本电脑不能正常显示了！

**聪明问题** ：

> X.org 6.8.1 鼠标光标变形，Fooware MV1005 vid.芯片组。

**更聪明的问题** ：

> X.org 6.8.1 的鼠标光标，在某牌显卡 MV1005 芯片组环境下 ------ 会变形

**编写 `目标 ------ 差异` 式描述的过程有助于你对问题进行细致的思考** 。是什么被影响了？仅仅是鼠标光标或者还有其他图形？只在 X.org 的 X 版中出现？是针对某牌显卡芯片组？或者只是其中的 MV 1005 型号？一个黑客只需瞄一眼就能够立即明白你的环境和你遇到的问题。

如果你想在回复中提出问题，记得要修改内容标题，以表明你是如何问一个问题，一个看起来像 `Re：测试` 或者 `Re：新 Bug` 的标题很难引起足够重视。另外，在不影响连贯性之下，适当引用并删减前文的内容，能给新的读者留下线索。

在网页论坛上，好的提问方式稍有不同，因为讨论串与特定的信息紧密结合，并且通常在讨论串外就看不到里面的内容，故通过回复提问，而非改变标题是可接受的。

不是所有论坛都允许在回复中出现分离的标题，而且这样做了基本上没有人回去看。不过通过回复提问，这本身就是暧昧的行为，因为它们只会被正在查看该标题的人读到。所以，除非你只想在该讨论串当前活跃的人群中提问，不然还是另起炉灶比较好。

### 使问题容易回复 {#使问题容易回复}

不要因为麻烦而放弃在邮件客户端设置回复地址，这会降低回复的概率。在论坛，要求通过电子邮件回复是非常无礼的，除非你认为回复的信息可能比较敏感（有人会为了某些未知的原因，只让你而不是整个论坛知道答案）。

如果你只是想在有人回复讨论串时得到电子邮件提醒，可以要求网页论坛发送给你。几乎所有论坛都支持诸如 `追踪此讨论串` 、 `有回复时发送邮件提醒` 等功能。

### 用清晰、正确、精准且语法正确的语句 {#用清晰-正确-精准且语法正确的语句}

正确的拼写、标点符号和大小写是很重要的。如果你觉得这样做很麻烦，那你多半得不到别人的帮助。不用太僵硬与正式------在黑客文化里，在保证 **很准确** 的情况下，能够使用非正式的语句也是一种得到关注的能力。这能够表明你是在思考和关注问题。

如果在非母语论坛提问，犯点拼写和语法上的小错误是可以原谅的，但绝不能在思考上马虎（这时可以区分的）。英语是通用的网络语言。

如果英语是你的第二外语，提示潜在回复者「你有潜在的语言困难是很好的」：

> English is not my native language; please excuse typing errors. > > 英语不是我的母语，请原谅我的错别字。 > > If you speak `$LANGUAGE` , please email/PM me; I may need assistance > translating my question. > > 如果你说 `某语言` ，请电邮或私信我；我可能需要帮助以翻译我的问题。 > > I am familiar with the technical terms, but some slang expressions and > idioms are difficult for me. > > 我对技术名词很熟悉，但对俗语或是特别用法比较不甚了解。 > > I've posted my question in `$LANGUAGE` and English. I'll be glad to > translate responses, if you only use one or the other. > > 我把我的问题用某语言和英文写出来，如果你只用一种语言回答，我会乐意将其翻译成另一种。

### 使用易于读取且标准的文件格式发送问题 {#使用易于读取且标准的文件格式发送问题}

需要做到：

- 使用纯文字而不是 HTML（[关闭 HTML](<http://archive.birdhouse.org/etc/evilmail.html)并不难>）。
- 可以使用 MIME 附件，前提是真正有内容（譬如附带的源代码或 patch）。
- 不要发送「一段文字只是一行句子但在自动换行后会变成多行」的邮件（这样回复部分内容就变得很困难）。
- 但是，不要对一些特殊文件设置固定宽度（譬如日志档案拷贝或会话记录）。数据应该原样包含，让回复者有信心------觉得他们自己看到的和你看到的是一样的。
- 在英文论坛中不要使用 `Quoted-Printable` MIME 编码发送消息。这种编码对于张贴非 ASCII 语言可能是必须的，但很多邮件程序并不支持这种编码。当它们处理换行时，那些文本中四处散布的 `=20` 符号既难看也分散注意力，甚至有可能破坏内容的语意。
- 永远不要向黑客发送使用封闭格式编写的文档，像微软公司的 Word 或 Excel 文件等。
- 如果使用 Windows 的电脑发送电子邮件，关闭 `智能引号` 功能（位于 [选项] --> [校订] --> [自动矫正选项]，取消勾选 `智能引号` ），以免在你的邮件中到处散布垃圾字符。
- 在论坛，不要滥用 `表情符号` 和 `HTML` 功能（当它们提供时）。

注意自己所使用的邮件客户端，可能它们的默认设置满足不了这些要求。注意检查是否有 `查看源代码` 功能，以确保发送的是纯文本文件同时没有一些奇怪的字符。

### 精确地描述问题并言之有物 {#精确地描述问题并言之有物}

- 仔细、清楚地描述你的问题或 Bug 的症状。
- 描述问题发生的环境（机器配置、操作系统、应用程序以及相关的信息），提供经销商的发行版和版本号（如： `Fedora Core 4` 、 `Slackware 9.1` 等）。
- 描述在提问前你是怎样去研究和理解这个问题的。
- 描述在提问前为确定问题而采取的诊断步骤。
- 描述最近做过什么可能相关的硬件或软件变更。
- 尽可能地提供一个可以 `重现这个问题的可控环境` 的方法。

揣测黑客会怎样反问你，在你提问之前预先将黑客们可能遇到的问题回答一遍。

以上几点中，当你报告的是你认为可能在代码中的问题时，给黑客一个可以重现你的问题的环境尤其重要。当你这么做时，你得到有效回答的机会和速度都会大大地提升。

[Simon Tatham](https://www.chiark.greenend.org.uk/~sgtatham/) 写过一篇名为《[如何有效的报告 Bug](https://www.chiark.greenend.org.uk/~sgtatham/bugs-cn.html)》的出色文章。强力推荐你也读一读。

### 话不在多而在精 {#话不在多而在精}

你需要提供精确有内容的信息。这并不是要求你简单地把成堆的出错代码或者资料完全放到你的提问中。如果你有庞大而复杂的测试样例能重现程序挂掉的情境，尽量将它裁剪得越小越好。

这样做的三点好处：

第一，能表现出你为简化问题付出了努力，这可以使你得到回答的机会增加；

第二，简化问题使你更有可能得到有用的答案；

第三，在精炼你的 bug 报告的过程中，你很可能就自己找到了解决办法。

### 别动辄声称找到 Bug {#别动辄声称找到-bug}

除非你能提供解决问题的源代码补丁，或者提供回归测试来表明前一版本中行为不正确，否则你多半不能够完全确信。这同样适用于文件，如果你（声称）发现了文件的 bug，你应该能提供相应位置的修正或替代文件。

如果你的问题并不常见，那么它可能不是 bug。开发者总是希望软件足够完美，出现 bug 会冒犯他们（如果不是真正的 bug 会更严重）。

### 低声下气不能减少你的工作 {#低声下气不能减少你的工作}

过于卑微同样无法为你带来问题的解决办法。做好前文所说明的步骤。

### 描述问题症状而不是你的猜测 {#描述问题症状而不是你的猜测}

**蠢问题** ：

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

**聪明问题** ：

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

### 按发生时间先后列出问题症状 {#按发生时间先后列出问题症状}

在说明中包含操作步骤，以及机器和软件的反应，直到问题发生。

### 描述目标而不是过程 {#描述目标而不是过程}

寻求帮助的人经常在心中有个更高层次的目标，而在他们认为达成目标的一条特定路径上停滞了。他们不会思考：会不会这条路本身就有问题？

**蠢问题** ：

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

**聪明问题** ：

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

第二种提问法比较聪明，你可能得到像是=建议采用另一个更合适的工具=的回复。

### 别要求使用私人电邮回复 {#别要求使用私人电邮回复}

黑客们认为问题的解决过程应该公开透明，可能会有更有经验的人能够注意到不完整或者不当之处，最初的回复才能够、也应该被纠正。同时，提供帮助的人也能借此展示自己的才能，给同行看。

### 清楚明确地表达你的问题以及需求 {#清楚明确地表达你的问题以及需求}

向别人提问时，要明确表述需要回答者做什么，这样做会定出一个时间和精力的上限，便于回答者能够集中精力帮助你。

要理解专家们所处的世界，要把专业技能想象为充裕的资源，而回复的时间则是稀缺的资源。要求他们奉献的时间越少，就越有可能从真正专业而且很忙的专家那里得到解答。

### 询问有关代码的问题时 {#询问有关代码的问题时}

不要让别人帮你调试问题代码，也不提示以下应该如何入手。

**愚蠢的做法** ：

张贴几百行代码，然后只是说，"某某不能工作"。

**聪明的做法** ：

只贴几十行代码，然后说，"在某行以后，我期待 x，但实际是 y。"

***最有效描述程序问题的方法是提供最精简的 Bug 展示测试用例（bug-demonstrating test case）** 。如何定义 **最精简的测试用例** ？那是问题的缩影；一个小程序片段能 **刚好*** 展示出程序的异常行为，而不包含其他令人分散注意力的内容。

**怎么制作最精简的测试用例** ？如果你知道哪一行或哪一段代码会造成异常的行为，复制下来并加入足够重现这个状况的代码。如果你无法将问题缩减到一个特定区块，就复制一份代码并移除不影响产生问题行为的部分。总之，测试用例越小越好。

### 别把自己家庭作业的问题贴上来 {#别把自己家庭作业的问题贴上来}

这些问题是需要我们自己独自解决的，可能有经验的人会给我们一些提示，但是仍然需要自己解决。

### 去掉无意义的句子 {#去掉无意义的句子}

### 即使很急也别在标题中写「紧急」 {#即使很急也别在标题中写-紧急}

### 礼貌些没有坏处 {#礼貌些没有坏处}

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

坦白说，这一点并没有比清晰、正确、精准并合法语法和避免使用专用格式重要（也不能取而代之）。黑客们一般宁可读有点唐突但技术上鲜明的 Bug 报告，而不是那种有礼但含糊的报告（如果这点让你不解，记住我们是按问题能教给我们什么来评价问题的价值的）。

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

（我们注意到，自从本指南发布后，从资深黑客那里得到的唯一严重缺陷反馈，就是对预先道谢这一条。一些黑客觉得 `先谢了` 意味着事后就不用再感谢任何人的暗示。我们的建议是要么先说 `先谢了` ， **然后** 事后再对回复者表示感谢，或者换种方式表达感激，譬如用 `谢谢你的关注` 或 `谢谢你的关照` 。）

### 问题解决后，加个简短的补充说明 {#问题解决后-加个简短的补充说明}

问题解决后，向所有帮助过你的人发个说明，让他们知道问题是怎样解决的，并再一次向他们表示感谢。如果问题在新闻组或者邮件列表中引起了广泛关注，应该在那里贴一个说明比较恰当。

最理想的方式是向最初提问的话题回复此消息，并在标题中包含 `已修正` ， `已解决` 或其它同等含义的明显标记。在人来人往的邮件列表里，一个看见讨论串 `问题 X` 和 `问题 X - 已解决` 的潜在回复者就明白不用再浪费时间了（除非他个人觉得 `问题 X` 的有趣），因此可以利用此时间去解决其它问题。

补充说明不必很长或是很深入；简单的一句 `你好，原来是网线出了问题！谢谢大家 -- Bill` 比什么也不说要来的好。事实上，除非结论真的很有技术含量，否则简短可爱的小结比长篇大论更好。说明问题是怎样解决的，但大可不必将解决问题的过程复述一遍。

对于有深度的问题，张贴调试记录的摘要是有帮助的。

思考一下怎样才能避免他人将来也遇到类似的问题，自问写一份文件或加个常见问题（FAQ）会不会有帮助。如果是的话就将它们发给维护者。

在黑客中，这种良好的后继行动实际上比传统的礼节更为重要，也是你如何透过善待他人而赢得声誉的方式，这是非常有价值的资产。

## 如何解读答案 {#如何解读答案}

### RTFM 和 STFW：如何知道你已完全搞砸了 {#rtfm-和-stfw-如何知道你已完全搞砸了}

RTFM: Read The Fucking Manual

STFW: Search The Fucking Web

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

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

你不应该因此不爽； **依照黑客的标准，他已经表示了对你一定程度的关注，而没有对你的要求视而不见** 。你应该对他祖母般的慈祥表示感谢。

### 如果还是搞不懂

如果你看不懂回应，别立刻要求对方解释。像你以前试着自己解决问题时那样（利用手册，FAQ，网络，身边的高手），先试着去搞懂他的回应。如果你真的需要对方解释，记得表现出你已经从中学到了点什么。

比方说，如果我回答你： `看来似乎是 zentry 卡住了；你应该先清除它。` ，然后，这是一个 ***很糟的** 后续问题回应： `zentry 是什么？` ***好**** 的问法应该是这样： `哦~~~我看过说明了但是只有 -z 和 -p 两个参数中提到了 zentries，而且还都没有清楚的解释如何清除它。你是指这两个中的哪一个吗？还是我看漏了什么？`

### 处理无礼的回应

很多黑客圈子中看似无礼的行为并不是存心冒犯。相反，它是直接了当，一针见血式的交流风格，这种风格更注重解决问题，而不是使人感觉舒服而却模模糊糊。

如果你觉得被冒犯了，试着平静地反应。如果有人真的做了出格的事，邮件列表、新闻群组或论坛中的前辈多半会招呼他。如果这 **没有** 发生而你却发火了，那么你发火对象的言语可能在黑客社区中看起来是正常的，而 **你** 将被视为有错的一方，这将伤害到你获取信息或帮助的机会。

另一方面，你偶尔真的会碰到无礼和无聊的言行。与上述相反，对真正的冒犯者狠狠地打击，用犀利的语言将其驳得体无完肤都是可以接受的。然而，在行事之前一定要非常非常的有根据。纠正无礼的言论与开始一场毫无意义的口水战仅一线之隔，黑客们自己莽撞地越线的情况并不鲜见。如果你是新手或外人，避开这种莽撞的机会并不高。如果你想得到的是信息而不是消磨时光，这时最好不要把手放在键盘上以免冒险。

## 如何避免扮演失败者

社区的标准不会自行维持，它们是通过参与者积极而*公开地*执行来维持的。

夸张的讲法是：你要的是”友善”（以上述方式）还是有用？两个里面挑一个。

## 不该问的问题

以下是几个经典蠢问题，以及黑客没回答时心中所想的：

问题：我能在哪找到 X 程序或 X 资源？

问题：我怎样用 X 做 Y？

问题：如何设定我的 shell 提示？

问题：我可以用 Bass-o-matic 文件转换工具将 AcmeCorp 档案转换为 TeX 格式吗？

问题：我的程序/设定/SQL 语句没有用

问题：我的 Windows 电脑有问题，你能帮我吗？

问题：我的程序不会动了，我认为系统工具 X 有问题

问题：我在安装 Linux（或者 X ）时有问题，你能帮我吗？

问题：我怎么才能破解 root 帐号/窃取 OP 特权/读别人的邮件呢？

---

> 问题：我能在哪找到 X 程序或 X 资源？

回答：就在我找到它的地方啊，白痴------搜索引擎的那一头。天哪！难道还有人不会用[Google](https://www.google.com) 吗？

> 问题：我怎样用 X 做 Y？

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

>问题：如何设定我的 shell 提示？？

回答：如果你有足够的智慧提这个问题，你也该有足够的智慧去 RTFM，然后自己去找出来。

> 问题：我可以用 Bass-o-matic 文件转换工具将 AcmeCorp 档案转换为 TeX 格式吗？

回答：试试看就知道了。如果你试过，你既知道了答案，就不用浪费我的时间了。

> 问题：我的{程序/设定/SQL 语句}不工作

回答：这不算是问题吧，我对要我问你二十个问题才找得出你真正问题的问题没兴趣

---

我有更有意思的事要做呢。在看到这类问题的时候，我的反应通常不外如下三种

- 你还有什么要补充的吗？
- 真糟糕，希望你能搞定。
- 这关我屁事？

> 问题：我的 Windows 电脑有问题，你能帮我吗？

回答：能啊，扔掉微软的垃圾，换个像 Linux 或 BSD 的开源操作系统吧。

注意：如果程序有官方版 Windows 或者与 Windows 有互动（如 Samba），你*可以*问与 Windows 相关的问题，只是别对问题是由 Windows 操作系统而不是程序本身造成的回复感到惊讶， 因为 Windows 一般来说实在太烂，这种说法通常都是对的。

> 问题：我的程序不会动了，我认为系统工具 X 有问题

回答：你完全有可能是第一个注意到被成千上万用户反复使用的系统调用与函数库档案有明显缺陷的人，更有可能的是你完全没有根据。不同凡响的说法需要不同凡响的证据，当你这样声称时，你必须有清楚而详尽的缺陷说明文件作后盾。

> 问题：我在安装 Linux（或者 X ）时有问题，你能帮我吗？

回答：不能，我只有亲自在你的电脑上动手才能找到毛病。还是去找你当地的 Linux 使用群组者寻求实际的指导吧（你能在[这儿](<http://www.linux.org/groups/index.html)找到使用者群组的清单>）。

注意：如果安装问题与某 Linux 的发行版有关，在它的邮件列表、论坛或本地使用者群组中提问也许是恰当的。此时，应描述问题的准确细节。在此之前，先用`Linux` 和*所有*被怀疑的硬件作关键词仔细搜索。

> 问题：我怎么才能破解 root 帐号/窃取 OP 特权/读别人的邮件呢？

回答：想要这样做，说明了你是个卑鄙小人；想找个黑客帮你，说明你是个白痴！

## 好问题与蠢问题

最后，我将透过举一些例子，来说明怎样聪明的提问；同一个问题的两种问法被放在一起，一种是愚蠢的，另一种才是明智的。

**蠢问题** ：

> 我可以在哪儿找到关于 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 内核邮件列表的成员表示，他觉得我的问题得到解决并非由于我是这个列表中的*名*人，而是因为我用了正确的方式来提问。

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

## 如果得不到回答

如果仍得不到回答，请不要以为我们觉得无法帮助你。有时只是看到你问题的人不知道答案罢了。没有回应不代表你被忽视，虽然不可否认这种差别很难区分。

总的来说，简单的重复张贴问题是个很糟的点子。这将被视为无意义的喧闹。有点耐心，知道你问题答案的人可能生活在不同的时区，可能正在睡觉，也有可能你的问题一开始就没有组织好。

## 如何更好地回答问题 **态度和善一点** 。问题带来的压力常使人显得无礼或愚蠢，其实并不是这样。

**对初犯者私下回复** 。对那些坦诚犯错之人没有必要当众羞辱，一个真正的新手也许连怎么搜索或在哪找常见问题都不知道。

**如果你不确定，一定要说出来**！一个听起来权威的错误回复比没有还要糟，别因为听起来像个专家很好玩，就给别人乱指路。要谦虚和诚实，给提问者与同行都树个好榜样。

**如果帮不了忙，也别妨碍他** 。不要在实际步骤上开玩笑，那样也许会毁了使用者的设置------有些可怜的呆瓜会把它当成真的指令。

**试探性的反问以引出更多的细节** 。如果你做得好，提问者可以学到点东西------你也可以。试试将蠢问题转变成好问题，别忘了我们都曾是新手。

尽管对那些懒虫抱怨一声 RTFM 是正当的，能指出文件的位置（即使只是建议个 Google 搜索关键词）会更好。

**如果你决定回答，就请给出好的答案** 。当别人正在用错误的工具或方法时别建议笨拙的权宜之计（workaround），应推荐更好的工具，重新界定问题。

**正面地回答问题**！如果这个提问者已经很深入的研究而且也表明已经试过 X 、Y 、 Z 、 A 、 B 、 C 但没得到结果，回答 `试试看 A 或是 B` 或者`试试 X 、 Y 、 Z 、 A 、 B 、 C` 并附上一个链接一点用都没有。

**帮助你的社区从问题中学习** 。当回复一个好问题时，问问自己”如何修改相关文件或常见问题文件以免再次解答同样的问题？“，接着再向文件维护者发一份补丁。

如果你是在研究一番后才做出的回答，**展现你的技巧而不是直接端出结果** 。毕竟「授人以鱼不如授人以渔」。

## 相关资源

如果你需要个人电脑、Unix 系统和网络如何运作的基础知识，参阅[Unix 系统和网络基本原理](http://en.tldp.org/HOWTO/Unix-and-Internet-Fundamentals-HOWTO/)。

当你发布软件或补丁时，试着按[软件发布实践](<http://en.tldp.org/HOWTO/Software-Release-Practice-HOWTO/index.html)操作>。

## 鸣谢

Evelyn Mitchel 贡献了一些愚蠢问题例子并启发了编写「如何更好地回答问题」这一节，Mikhail Ramendik 贡献了一些特别有价值的建议和改进。

## 参考
- [How To Ask Questions The Smart Way](http://www.catb.org/~esr/faqs/smart-questions.html)
- [提问的智慧 (中文翻译)](https://github.com/ryanhanwu/How-To-Ask-Questions-The-Smart-Way/blob/main/README-zh_CN.md)
- [Wikipedia: Stack Exchange](https://en.wikipedia.org/wiki/Stack_Exchange)


相关：[[privacy|privacy]]