提问的智慧（删改版）

引言

本文将教你如何提问才更有可能得到满意的答复。

我们会毫无歉意地敌视那些提问前不愿思考、不做自己家庭作业的人。这种人就象时间无底洞──他们只知道索取，不愿意付出，他们浪费了时间，这些时间本可用于其它更有趣的问题或更值得回答的人。

对大多数人而言，互联网只是种工具，是种达到目的的手段而已。他们有自己的生活，并且有更要紧的事要做。但你要知道，我们没有义务为你回答任何问题，有时还可能力不从心。因此，我们会毫不留情地滤除问题，特别是那些看起来象是失败者提的，以便更有效地把回答问题的时间留给那些胜利者。

表现出能引导你在行的姿态──机敏、有想法、善于观察、乐于主动参与问题的解决。如果你做不到这些使你与众不同的事情，我们建议你付钱跟别人签商业服务合同，而不是要求他人无偿帮助。

提问前

在通过任何方式提问以前，做以下事情：

• 尝试搜索互联网以找到答案
• 尝试请教懂行的朋友以找到答案
• 尝试阅读错误信息

提问时，请先表明你已做了上述事情，这将有助于建立你不是寄生虫与浪费别人时间的印象。最好再表述你从中学到的东西 ，没有人不喜欢回答那些表现出能从答案中学习的人。

使用搜索引擎

我非常喜欢一句话「水一百度会开，人一百度会死」。事实上，绝大多数人遇到的问题90%都可以通过搜索引擎解决。运用某些策略，比如用百度（Baidu）搜索你遇到的各种错误提示，这样很可能直接就找到了解决问题的文档、方案或线索。

当你尝试启动某款游戏，却弹出错误窗口，示意无法找到d3dx9_39.dll时，你应该先使用搜索引擎搜索错误信息，而非求助他人。

在搜索时，尝试使用关键词，而非长句子。长句子使你的描述精确，但更不易找到答案。此外，你还需注意提问用词是否准确。

搜索「我怎么把VisualStudio放到E盘里？」不如搜索「VisualStudio 自定义安装位置」合适。

即使没有结果，在向他人寻求帮助时提一句「我在谷歌中搜过下列句子但没有找到什么有用的东西」也是件好事，至少它表明了搜索引擎不能提供你需要的帮助。将搜索关键词与你的问题及可能的解决方案联系起来，还有助于引导其他有类似问题的人。

更换搜索平台

中文互联网中充斥着复制粘贴、自动采集、答非所问的无用信息，且它们通常占据靠前的位置。虽然这种现象在整个互联网中较常见，但在中文互联网中，它们极其严重。所以，当你在百度中找不到有用的信息，可以尝试更换外国搜索引擎，并使用英文描述问题。

尝试使用百度和谷歌（或必应国际版）搜索IStringLocalizer<T>(.NET)错误信息「No manifests exist for the current culture」，观察搜索结果差别。

文档优先

遇到问题时，为什么不试试查看文档呢？文档中一般提供FAQ（常见问题解答）。另外，互联网上搜索到的信息可能过时，或者换句话说：它也许能解决你的问题，但你是否了解为什么出现了问题、解决方案为什么要这样做？查看文档有助于你理解细节。

另外，在安装家庭设备（如电视机）时，请按照说明书操作，除非你很懂这一方面。

思考

别着急，不要指望几秒钟的搜索就能解决一个复杂的问题。在提问之前，先思考一下问题。他人可以从你的提问中看出你有没有进行过思考，如果你是有备而来，将更有可能得到解答。不要将所有问题一股脑抛出，只因你的第一次搜索没有结果（或者结果太多）。

认真地思考，准备好你的问题。轻率的提问只能得到轻率的回答，或者压根没有。在提问时，你越是表现出在此前做过思考与努力去解决自己的问题，你越有可能得到真正的帮助。

注意别提错问题。如果提问基于错误的假设，帮助你的人多半会一边想 「愚蠢的问题……」，一边按将错就错的答案回复你，并且希望这种只是得到你自己「问的问题」而非真正所需的解答，给你一个教训。

永远不要假设你有资格得到解答。你没有这种资格，毕竟你没有为此服务付费。如果你能够提出有内容、有趣和激励思考的问题──那种毫无疑问能够向社区贡献经验，而不仅仅是消极地要求从别人那获取知识的问题，你将「挣到」答案。

另一方面，表明你有能力也乐意参与问题的解决是个很好的开端。「有没有人能指个方向？」，我这还差点什么？」，「我应该查哪个网站？」，通常要比 「请给出我可以用的完整步骤」更容易得到回复，因为你表明了只要有人能指个方向，你就很乐意完成剩下的过程。

请先阅读错误信息

你可能会犯把Main写成Mian、使用中文全角符号之类的初级问题，对于这些问题，你的编译器会输出完整、有效、易读的错误信息。我们不指望你能够立刻理解问题所在，但我们希望你能够使用搜索引擎搜索错误信息。

提问时

仔细挑选论坛

要对在哪提问留心，如果你做了下述事情，多半会被一笔勾销或被看成「失败者」：

• 张贴与论坛主题无关的问题
• 在面向高级技术问题的论坛上张贴肤浅的问题，或者反之。
• 给既非熟人也没有义务解决你问题的人发送问题

百度和其它搜索引擎还是你的朋友，可以用它们搜索你遇到困难的软硬件问题最相关的项目网站。那里通常都有项目的常见问题（FAQ）、邮件列表及文档的链接。

向陌生的人、群聊或论坛提问极有可能是在冒险。譬如，不要假设一个内容丰富的网页的作者想充当你的免费顾问，不要对你的问题是否会受到欢迎做太乐观的估计──如果你不确定，向别处发或者压根别发。另外，不要假定他人完全了解你的环境和话题。

一般来说，在仔细挑选的公共论坛中提问比在私有论坛中提同样的问题更容易得到有用的回答。

面向新手的论坛和群组通常响应最快

本地的贴吧、群聊和论坛，这些地方是开始提问的好去处，特别是当你觉得遇到的也许只是相对简单或者很普通的问题时。经过宣传的聊天室是公开邀请提问的地方，通常可以得到实时的回复。

在任何论坛发贴以前，先看看有没有搜索功能。如果有，就试着用问题的几个关键词搜索一下，也许就有帮助。如果在此之前你已做过全面的网页搜索（你应该这样去做），还是再搜索一下论坛，搜索引擎有可能没来得及索引此论坛的全部内容。

使用有意义且明确的主题

不要用诸如 「请帮我！！！」 之类的与主题无关的废话。不要用你痛苦的深度来打动我们，相反，要在这点空间中使用超级简明扼要的问题描述。

使用主题的好惯例是「对象──偏差」（式的描述），许多技术支持组织就是这样做的。在「对象」部分指明是哪一个或哪一组东西有问题，在「偏差」部分则描述与期望的行为不一致的地方。

愚蠢：

救命啊！我的Minecraft好卡！

明智：

12代i9，RTX3070Ti，Minecraft1.18卡顿严重

更明智：

Minecraft 1.18 Optifine加载XX光影严重卡顿，运行于 JDK17, Windows 11笔记本电脑上，无模组安装，配置是12代i7，RTX3060，但显卡无占用。

使问题容易回复

以请向……回复来结束问题多半会使你得不到回答。

在论坛要求他人添加自己的QQ解答问题是最愚蠢的做法。

用清晰、语法、拼写正确的语句书写

清楚、良好地表达你的问题非常重要。你的提问无需过于庄重正式，但它必须很准确，而且有迹象表明你是在思考和关注问题：正确地拼写、使用标点和大小写。

如果在非母语论坛提问，你的拼写与语法错误会得到有限的宽容，但懒惰完全不会被容忍。同时，除非你知道回复者使用的语言，请使用英语书写。在互联网上英语是工作语言，用英语书写可以将你的问题不被阅读就被直接删除的可能性降到最低。

如果你用英语书写但它是你的第二语言，最好说明一下，比如：

• 英语不是我的母语，请谅解拼写错误。
• 如果您使用某某语言，请私聊我，也许我需要您的协助翻译我的问题。
• 对于这个技术术语本身我很熟悉，但对于它的一些俚语或习惯表达方式就不太明白了。
• 我已经同时用某某语及英语提问，如果您使用两者之一回复，我很乐意翻译。

描述问题应准确且有内容

• 仔细、清楚地描述问题的症状
• 描述问题发生的环境(主机、操作系统、应用程序，任何相关的)，提供销售商的发行版和版本号
• 描述提问前做过的研究及其理解。
• 描述提问前为确定问题而采取的诊断步骤。
• 描述最近对计算机或软件配置的任何相关改变。
• 如果可能，提供在可控环境下重现问题的方法。
• 尽最大努力预测他人会提到的问题。

我的操作系统是 Windows 10 1907，当我点击操作栏中的「文件→保存结果为PDF文件」时，程序无响应。下面是应用程序的日志文件。

素质问题

请遵循最基本的礼仪。

不要「轰炸」他人。

在吗？在吗？[抖动窗口][戳一戳][拍一拍][语音电话][抖动窗口][视频电话]赶紧的行不行！！！你**做的什么**东西，我要上课了能不能快点？

描述问题症状而不是猜测

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

我们希望看到与原始证据尽可能一致的东西，而不是你的猜测与总结。

按时间先后罗列问题症状

刚出问题之前发生的事情通常包含有解决问题最有效的线索。所以，记录中应准确地描述你、电脑和软件在崩溃前都做了什么。如果有日志就更好了。

描述目标而不是过程

如果你想弄清楚如何做某事，在开头就描述你的目标，然后才陈述遇到问题的特定步骤。

经常出现这种情况，寻求技术帮助的人在脑袋里有个更高层次的目标，他们在自以为能达到目标的特定道路上被卡住了，然后跑来问该怎么走，但没有意识到这条路本身有问题，结果要费很大的劲才能通过。

愚蠢：

我怎样才能让某图形程序的颜色拾取器取得十六进制的 RGB 值？

明智：

我正试着用自己选定数值的颜色替换一幅图片的色表，我现在知道的唯一方法是编辑每个表槽，但却无法让某图形程序的颜色拾取器取得十六进制的 RGB 值。

第二种提法是明智的，它使得建议采用更合适的工具以完成任务的回复成为可能。

提问应明确

漫无边际的问题通常也被视为没有明确限制的时间无底洞。最有可能给你有用答案的人通常也是最忙的人（假如只是因为他们承担了太多工作的话），这些人对于没有止境的时间无底洞极其敏感，所以他们也倾向于讨厌那些漫无边际的问题。

如果你明确了想让回复者做的事（如指点方向、发送代码、检查补丁或其它），你更有可能得到有用的回复。（因为）这样可以让他们集中精力并间接地设定了他们为帮助你需要花费的时间和精力上限，这很好。

关于代码的问题

别要求他人给你出问题的代码排错而不提及应该从何入手。张贴几百行的代码，然后说一声「它不能运行」会让你得不到理睬。只贴几十行代码，然后说一句「在第七行以后，本应该显示，但实际出现的是」非常有可能让你得到回复。

最精确描述代码问题的方法是提供一个能展示问题的最小测试样例。什么是最小测试样例？它是对问题的展现，只需要刚好能够重现非预期行为的代码即可。如何生成一个最小测试样例？如果你知道哪一行或哪一段代码会产生问题，将其复制并提供刚好够用的外围支撑代码以构成一个完整的样例（够用是指源码刚好能被编译器、解释器或任何处理它的程序所接受）。如果你不能将问题缩小到特定的段落，复制源码并去除那些与问题无关的代码段。你能提供的最小测试样例越小越好（参见 量不在多，精炼则灵 ）。

生成一个非常小的最小测试样例并不总是可能，但尽力去做是很好的锻练，这有可能帮助你找到需要自己解决的问题。即使你找不到，黑客们喜欢看到你努力过，这将使他们更合作。

如果你只是想让别人帮忙审一下代码，在最开头就要说出来，并且一定要提到你认为哪一部分特别需要关注以及为什么。

别张贴家庭作业式问题

我们一眼就能看出这是否是你的「家庭作业」，因为我们中的大多数人已经做过这些作业，那是你该做的，以便从中学到东西。问一下提示没有关系，但不是要求完整的解决方案。

删除无意义的要求

抵制这种诱惑，即在求助消息末尾加上诸如「有人能帮我吗？」或「有没有答案？」之类在语义上毫无意义的东西。第一，如果问题描述还不完整，这些附加的东西最多也只能是多余的。第二，因为它们是多余的，这很烦。

一般来说，避免提「是或否」类型的问题，除非你想得到 「是或否」类型的回答。

不要把问题标记为「紧急」，即使对你而言的确如此

这是你的问题，不要我们的。宣称「紧急」极有可能事与愿违。你是否无礼和自私地企图得到即时与特殊的关照？

礼貌总是有益的

礼貌一点，使用 请 和 谢谢你的关注 或者 谢谢你的关照，让别人明白你感谢他们无偿花时间帮助你。

问题解决后追加一条简要说明

问题解决后向所有帮助过的人追加一条消息，让他们知道问题是如何解决的并再次感谢。如果问题在邮件列表或新闻组中受到广泛关注，在那里追加此消息比较恰当。

如果可以修改主题，建议添加 已解决、已搞定 或其它同等含义的明显标记。

追加的消息用不着太长或太复杂，一句简单的「你好──是网线坏了！谢谢大家！」就比什么都没有要强。事实上，除非解决问题的技术真正高深，一条简短而亲切的总结比长篇大论要好。说明是什么行动解决了问题，用不着重演整个排错的故事。

对于有深度的问题，张贴排错历史的摘要是恰当的。描述问题的最终状态，说明是什么解决了问题，在此之后 才指明可以避免的弯路。应避免的弯路部分应放在正确的解决方案和其它总结材料之后，而不要将此消息搞成侦探推理小说。列出那些帮助过你的名字，那样你会交到朋友的。

除了有礼貌、有内容以外，这种类型的追帖将帮助同样遇到此问题的人。

最后，此类追帖还让每位参与协助的人因问题的解决而产生一种满足感。

提问后

不要像一个失败者

在社区的论坛中有那么几次你可能会搞砸──以本文描述或类似的方式。你会被示众是如何搞砸的，也许言语中还会带点颜色。

这种事发生以后，你能做的最糟糕的事莫过于哀嚎你的遭遇、宣称被口头攻击、要求道歉、高声尖叫、憋闷气、威胁诉诸法律、向其雇主报怨、忘了关马桶盖等等。相反，你该这样去做：

熬过去，这很正常。事实上，它是有益健康与恰当的。

社区的标准不会自己维持，它们是通过参与者积极而 公开 地执行来维持的。不要哭嚎所有的批评都应该私下给出，这不是事情运作的方式。当有人评论你的一个说法有误或者提出不同看法时，坚持声称受到个人攻击也毫无益处，这些都是失败者的态度。

记着：当专业人士说你搞砸了，并且(无论多么刺耳地)告诉你别再这样做时，他正在为关心你和他的社区而行动。对他而言，不理你并将你从他的生活中滤除要容易得多。如果你无法做到感谢，至少要有点尊严，别大声哀嚎，也别因为自己是个有戏剧性超级敏感的灵魂和自以为有资格的新来者，就指望别人象对待脆弱的洋娃娃那样对你。

有时候，即使你没有搞砸（或者只是别人想象你搞砸了）， 有些人也会无缘无故地攻击你本人。在这种情况下，报怨倒是 真的 会把问题搞砸。

这些找茬者要么是毫无办法但自以为是专家的不中用家伙，要么就是测试你是否真会搞砸的心理专家。其它读者要么不理睬，要么用自己的方式对付他们。这些找茬者在给自己找麻烦，这点你不用操心。

也别让自己卷入口水战，大多数口水战最好不要理睬──当然，是在你核实它们只是口水战、没有指出你搞砸的地方，而且没有巧妙地将问题真正的答案藏于其中之后（这也是可能的）。

提问禁忌

问：我到哪可以找到某程序或 X 资源？

问：我怎样用 X 做 Y？

问：如何配置我的 shell 提示？

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

问：我的{程序、配置、SQL 语句}不运行了

问：我的Windows电脑出问题了，你能帮忙吗？

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

问：我安装 Linux 或 X 遇到困难，你能帮忙吗？

问：我如何才能破解超级用户口令/盗取通道操作员的特权/查看某人的电子邮件？

---

问：

我到哪可以找到某程序或 X 资源？

答：

在我找到它的同样地方，笨旦──在网页搜索引擎上。上帝啊，难道还有人不知道如何使用 谷歌 吗？

问：

我怎样用 X 做 Y？

答：

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

问：

如何配置我的 shell 提示？

答：

如果你有足够的智慧提这个问题，你也该有足够的智慧去 「读读该死的手册」（RTFM），然后自己去找出来。

问：

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

答：

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

问：

我的{程序、配置、SQL 语句}不运行了

答：

这不是一个问题，我也没有兴趣去猜你有什么问题──我有更要紧的事要做。看到这种东西，我的反应一般如下：

• 你还有什么补充吗？
• 噢，太糟了，希望你能搞定。
• 这跟我究竟有什么关系？

问：

我的程序不运行了，我认为系统工具 X 有问题

答：

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

问：

我安装 Linux 或 X 遇到困难，你能帮忙吗？

答：

不行，我需要亲手操作你的电脑才能帮你排错，去向当地的 Linux 用户组寻求方便的帮助（你可以在 这里 找到用户组列表）

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

问：

我如何才能破解超级用户口令/盗取通道操作员的特权/查看某人的电子邮件？

答：

想做这种事情说明你是个卑劣的家伙，想让黑客教你做这种事情说明你是个白痴。

好问题与坏问题

最后，我将通过举例来演示提问的智慧。同样的问题两种提法，一种愚蠢，另一种明智。

愚蠢：我在哪能找到关于 Foonly Flurbamatic 设备的东西？

这个问题在乞求得到 「搜搜该死的网络」（STFW） 式的回复。

明智： 我用谷歌搜索过「Foonly Flurbamatic 2600」，但没有找到什么有用的，有谁知道在哪能找到这种设备的编程信息？

这个人已经搜索过网络了，而且听起来他可能真的遇到了问题。

愚蠢： 我不能编译某项目的源代码，它为什么这么破？

提问者假设是别人搞砸了，太自大了。

明智： 某项目的源代码不能在某 Linux 6.2 版下编译。我读了常见问题文档，但其中没有与某 Linux 相关的内容。这是编译时的记录，我做错了什么吗？

提问者已经指明了运行环境，读了常见问题文档（FAQ），列出了错误，也没有假设问题是别人的过错，这家伙值得注意。

愚蠢： 我的主板有问题，谁能帮我？

某黑客对此的反应可能是：「是的，还需要帮你拍背和换尿布吗？」，然后是敲下删除键。

明智： 我在 S2464 主板上试过 X、Y 和 Z，当它们都失败后，又试了 A、B 和 C。注意我试 C 时的奇怪症状，显然某某东西正在做某某事情，这不是期望的行为。通常在 Athlon MP 主板上导致某某事情的原因是什么？有谁知道我还能再试点什么以确定问题？

相反地，这个人看来值得回答。他或她展现了解决问题的能力而不是坐等天上掉馅饼。

在最后那个问题中，注意「给我一个回答」与「请帮我看看我还能再做点什么测试以得到启发」之间细微但重要的差别。

如何更好地回答

态度和善一点。问题带来的压力常使人显得无礼或愚蠢，其实并不是这样。

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

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

如果帮不了忙，别妨碍。 不要在具体步骤上开玩笑，那样也许会毁了用户的安装──有些可怜的呆瓜会把它当成真的指令。

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

尽管对那些懒虫报怨一声「读读该死的手册」（RTFM）是正当的，指出文档的位置（即使只是建议做个谷歌关键词搜索）会更好

如果你决意回答，给出好的答案。 当别人正在用错误的工具或方法时别建议笨拙的权宜之计，应推荐更好的工具，重新组织问题。

请回答真正的问题！如果提问者已经做了自己该做的研究，并且说明尝试过X，Y，Z，A，B 与 C 都没有得到想要的結果，那么回复 试试 A 或 B 或者给出一个内容为 试一下 X，Y，Z，A，B 或 C 的链接将极其无益！

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

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

鸣谢

本文对https://github.com/tvvocold/How-To-Ask-Questions-The-Smart-Way进行增添、删除、修改内容而得到。