提问的艺术
在资深技术专家的世界里，你所提技术问题的解答很大程度上取决于你提问的方式与解决此问题的难度，本文将教你如何提问才更有可能得到满意的答复。
提问前
在通过电子邮件、社交群或论坛提技术问题以前，务必先做以下事情：
- 尝试在你准备提问论坛的历史文档中搜索答案
- 尝试搜索互联网以找到答案（基本上可以解决 90% 的问题）
- 尝试阅读手册以找到答案
- 尝试阅读 “常见问题文档”（FAQ）以找到答案
- 尝试自己检查或试验以找到答案
- 尝试请教懂行的朋友以找到答案
如果你是程序员，尝试阅读源代码以找到答案。
提问时
仔细挑选论坛
第一步是找对论坛，可以利用搜索引擎查询你遇到困难的软硬件问题最相关的项目网站。那里通常有项目的常见问题（FAQ）及文档；如果你的努力没有结果，项目的网站也许还有报告 Bug 的流程或链接。
不要轻易向陌生的人或论坛求助，更不要假设别人会充当你的免费顾问。因为你愚蠢的提问可能会迎来攻击！确定好提问的论坛，务必再搜索一下论坛，搜索引擎有可能没来得及索引此论坛的全部内容。
最后请先翻阅已有的帖子，了解社区文化后再发帖提问。
社交群通常响应最快
在国内可以选择 QQ 群；
使用有意义且明确的主题
在论坛或社交群中，大约 50 字以内的标题是抓住资深专家注意力的好机会，别用喋喋不休的帮帮忙、跪求、急（更别说救命啊！！！！这样让人反感的话，用这种标题会被条件反射式地忽略）来浪费这个机会。
一个好标题范例是目标 —— 差异式的描述，在目标部分指出是哪一个或哪一组东西有问题，在差异部分则描述与期望的行为不一致的地方。
蠢问题：救命啊！我的笔记本电脑不能正常显示了！
聪明问题：X.org 6.8.1 的鼠标光标会变形，某牌显卡 MV1005 芯片组。
更聪明问题：X.org 6.8.1 的鼠标光标，在某牌显卡 MV1005 芯片组环境下 - 会变形。
去掉无意义的提问句
避免用无意义的话结束提问，例如有人能帮我吗？或者这有答案吗？。
即使你很急也不要在标题写紧急
用清晰、正确、精准且语法正确的语句
正确的拼写、标点符号和大小写是很重要的！如果你写得像是个半文盲，那多半得不到理睬。
使用易于读取且标准的文件格式发送问题
绝对，永远不要指望资深专家们阅读使用封闭格式编写的文档，像微软公司的 Word 或 Excel 文件等。大多数资深专家对此的反应就像有人将还在冒热气的猪粪倒在你家门口时你的反应一样。
精确地描述问题并言之有物
- 仔细、清楚地描述你的问题或 Bug 的症状。
- 描述问题发生的环境（机器配置、操作系统、应用程序、以及相关的信息），提供经销商的发行版和版本号（如：
Fedora Core 4、Slackware 9.1等）。 - 描述在提问前你是怎样去研究和理解这个问题的。
- 描述在提问前为确定问题而采取的诊断步骤。
- 描述最近做过什么可能相关的硬件或软件变更。
- 尽可能的提供一个可以
重现这个问题的可控环境的方法。
话不在多而在精
别动辄声称找到 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和问题 X - 已 解决的潜在回复者就明白不用再浪费时间了。
如何解读答案
RTFM 和 STFW
有一个古老而神圣的传统：如果你收到RTFM （Read The Fucking Manual）的回应，回答者认为你应该去读他妈的手册。当然，基本上他是对的，你应该去读一读。
RTFM 有一个年轻的亲戚。如果你收到STFW（Search The Fucking Web）的回应，回答者认为你应该到他妈的网上搜索。那人多半也是对的，去搜索一下吧。（更温和一点的说法是 Google 是你的朋友！）
你不应该因此不爽；依照黑客的标准，他已经表示了对你一定程度的关注，而没有对你的要求视而不见。
你应该对他祖母般的慈祥表示感谢。
如果还是搞不懂
如果你看不懂回应，别立刻要求对方解释。像你以前试着自己解决问题时那样（利用手册，FAQ，网络，身边的高手），先试着去搞懂他的回应。如果你真的需要对方解释，记得表现出你已经从中学到了点什么。
处理无礼的回应
如果你觉得被冒犯了，试着平静地反应。如果有人真的做了出格的事，前辈多半会招呼他。
不该问的问题
问题：我能在哪找到 X 程序或 X 资源？
问题：我怎样用 X 做 Y？
问题：我的 Windows 电脑有问题，你能帮我吗？
问题：我的程序不会动了，我认为系统工具 X 有问题
问题：我在安装 Linux（或者 X ）时有问题，你能帮我吗？
问题：我怎么才能破解 root 帐号/窃取 QQ 账号/游戏开挂呢？
问题：我能在哪找到 X 程序或 X 资源？
回答：就在我找到它的地方啊，白痴 —— 搜索引擎的那一头。天哪！难道还有人不会用 Google 吗？
问题：我怎样用 X 做 Y？
回答：如果你想解决的是 Y ，提问时别给出可能并不恰当的方法。这种问题说明提问者不但对 X 完全无知，也对 Y 要解决的问题糊涂，还被特定形势禁锢了思维。
问题：我的 Windows 电脑有问题，你能帮我吗？
回答：能啊，扔掉微软的垃圾，换个像 Linux 或 BSD 的开源操作系统吧。
问题：我的程序不会动了，我认为系统工具 X 有问题
回答：你完全有可能是第一个注意到被成千上万用户反复使用的系统调用与函数库档案有明显缺陷的人，更有可能的是你完全没有根据。不同凡响的说法需要不同凡响的证据，当你这样声称时，你必须有清楚而详尽的缺陷说明文件作后盾。
问题：我在安装 Linux（或者 X ）时有问题，你能帮我吗？
回答：不能，我只有亲自在你的电脑上动手才能找到毛病。
问题：我怎么才能破解 root 帐号/窃取 QQ 账号/游戏开挂呢？
回答：想要这样做，说明了你是个沙壁；想找个资深专家帮你，说明你是个大沙壁！
好问题与蠢问题
蠢问题：
我可以在哪儿找到关于 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 的原因是什么？有谁知道接下来我该做些什么测试才能找出问题？
如果得不到回答
如果仍得不到回答，请不要以为我们觉得无法帮助你。有时只是看到你问题的人不知道答案罢了。没有回应不代表你被忽视，虽然不可否认这种差别很难区分。
你仍然可以通过其他渠道获得帮助，例如商业公司。别为要付费才能获得帮助而感到 沮丧！毕竟，假使你的汽车发动机汽缸密封圈爆掉了 —— 完全可能如此 —— 你还得把它送到修车铺，并且为维修付费。
就算软件没花费你一分钱，你也不能强求技术支持总是免费的。
如何更好地回答问题
态度和善一点。问题带来的压力常使人显得无礼或愚蠢，其实并不是这样。
对初犯者私下回复。对那些坦诚犯错之人没有必要当众羞辱，一个真正的新手也许连怎么搜索或在哪找常见问题都不知道。
如果你不确定，一定要说出来！一个听起来权威的错误回复比没有还要糟，别因为听起来像个专家很好玩，就给别人乱指路。要谦虚和诚实，给提问者与同行都树个好榜样。
如果帮不了忙，也别妨碍他。不要在实际步骤上开玩笑，那样也许会毁了使用者的设置 —— 有些可怜的呆瓜会把它当成真的指令（例如 sudo rm -rf /*）。
试探性的反问以引出更多的细节。如果你做得好，提问者可以学到点东西 —— 你也可以。试试将蠢问题转变成好问题，别忘了我们都曾是新手。
尽管对那些懒虫抱怨一声 RTFM 是正当的，能指出文件的位置（即使只是建议个 Google 搜索关键词）会更好。
如果你决定回答，就请给出好的答案。当别人正在用错误的工具或方法时别建议笨拙的权宜之（wordaround），应推荐更好的工具，重新界定问题。
正面的回答问题！如果这个提问者已经很深入的研 究而且也表明已经试过 X 、 Y 、 Z 、 A 、 B 、 C 但没得到结果，回答 试试看 A 或是 B 或者 试试 X 、 Y 、 Z 、 A 、 B 、 C 并附上一个链接一点用都没有。
帮助你的社区从问题中学习。当回复一个好问题时，问问自己如何修改相关文件或常见问题文件以免再次解答同样的问题？，接着再向文件维护者发一份补丁。
如果你是在研究一番后才做出的回答，展现你的技巧而不是直接端出结果。毕竟授人以鱼不如授人以渔。
声明
How To Ask Questions The Smart Way
Copyright © 2001,2006,2014 Eric S. Raymond, Rick Moen
本指南英文版版权为 Eric S. Raymond, Rick Moen 所有。
原文网址：http://www.catb.org/~esr/faqs/smart-questions.html
Copyleft 2001 by D.H.Grand(nOBODY/Ginux), 2010 by Gasolin, 2015 by Ryan Wu
本中文指南是基于原文 3.10 版以及 2010 年由 Gasolin 所翻译版本的最新翻译；
协助指出翻译问题，请发 Issue，或直接发 Pull Request 给我。
本文另有：简体中文版
