How to Ask Questions

February 15, 2025

This post is reprinted from “How to ask questions”.

简介

在黑客的世界里，你所提技术问题的好坏，很大程度上取决于你提问的方式和此问题的难度。

首先你应该明白，黑客们喜爱有挑战性的问题，或者能激发他们思维的好问题。如果我们并非如此，那我们也不会成为你想询问的对象。如果你给了我们一个值得反复咀嚼玩味的好问题，我们自会对你感激不尽。好问题是激励，是厚礼。好问题可以提高我们的理解力，而且通常会暴露我们以前从没意识到或者思考过的问题。对黑客而言，“好问题！”是诚挚的大力称赞。尽管如此，黑客们有着蔑视或傲慢面对简单问题的坏名声，这有时让我们看起来对新手、无知者似乎较有敌意，但其实不是那样的。我们不讳言我们对那些不愿思考、或者在发问前不做他们该做的事的人的蔑视。那些人是时间杀手 —— 他们只想索取，从不付出，消耗我们可用在更有趣的问题或更值得回答的人身上的时间。我们称这样的人为 失败者（loser） （由于历史原因，我们有时把它拼作 lusers）。

除了黑客，其实各个领域的大佬，都很讨厌只提问而不思考的人，这种人只会索取而不付出。因此，想要自己的问题得到很好的解决和解答，学会在提问前认真思考是很重要的。

无知没有关系，但装白痴就是不行。

无知代表对特定领域的知识不了解；白痴则是指明知道不了解特定领域的知识，还不思进取，只想着索取，白痴是一种没有智慧的愚昧表现。

所以，你不必在技术上很在行才能吸引我们的注意，但你必须表现出能引导你变得在行的特质 —— 机敏、有想法、善于观察、乐于主动参与解决问题。如果你做不到这些使你与众不同的事情，我们建议你花点钱找家商业公司签个技术支持服务合同，而不是要求黑客个人无偿地帮助你。如果你决定向我们求助，当然你也不希望被视为失败者，更不愿成为失败者中的一员。能立刻得到快速并有效答案的最好方法，就是像赢家那样提问 —— 聪明、自信、有解决问题的思路，只是偶尔在特定的问题上需要获得一点帮助。

在向技术大佬提问前，纵使自己很无知，但是自己必须表现出能够被引导到变得在行的特质——机敏、有想法、善于观察和思考，主动解决问题。否则就是在浪费彼此的时间。因此，提问最重要的一个前提条件就是”有思路“，思路能够说明你是对这个问题进行过思考的，这是对对方，更是对自己的尊重。

在提问前

在提出技术问题之前，尝试通过下面的方式自行解决问题：

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

即使这些方式没有解决你的问题，但是至少表明了自己做出了努力，而不是只想着不劳而获且浪费时间。因此，就算在提问中表明自己通过这些方式没有解决问题，也是一种经过思考的表现。

准备好你的问题，再将问题仔细地思考过一遍，因为草率的发问只能得到草率的回答，或者根本得不到任何答案。越是能表现出在寻求帮助前你为解决问题所付出的努力，你越有可能得到实质性的帮助。

这个和使用GPT是通用的。我们和GPT对话本质上就是对一个普遍领域的大佬进行问答以获得我们想要的答案。因此，想要获得能够解决问题的答案，必须经过谨慎地通过结构化思考将自己的问题拆解，提取思路，再进行提问，这样才能获得自己想要的答案。

小心别问错了问题。如果你的问题基于错误的假设，某个普通黑客（J. Random Hacker）多半会一边在心里想着蠢问题…，一边用无意义的字面解释来答复你，希望着你会从问题的回答（而非你想得到的答案）中汲取教训。绝不要自以为够格得到答案，你没有；你并没有。毕竟你没有为这种服务支付任何报酬。你将会是自己去挣到一个答案，靠提出有内涵的、有趣的、有思维激励作用的问题 —— 一个有潜力能贡献社区经验的问题，而不仅仅是被动地从他人处索取知识。另一方面，表明你愿意在找答案的过程中做点什么是一个非常好的开端。谁能给点提示？、我的这个例子里缺了什么？以及我应该检查什么地方比请把我需要的确切的过程贴出来更容易得到答复。因为你表现出只要有人能指个正确方向，你就有完成它的能力和决心。

在向技术大佬进行无报酬地提问时，答案是靠自己挣来的，而不是别人施舍来的。

在提问时

慎选提问的论坛（或者说是场合）

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

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

黑客会剔除掉那些搞错场合的问题，以保护他们沟通的渠道不被无关的东西淹没。你不会想让这种事发生在自己身上的。

因此，第一步是找到对的论坛。再说一次，Google 和其它搜索引擎还是你的朋友，用它们来找到与你遭遇到困难的软硬件问题最相关的网站。通常那儿都有常见问题（FAQ）、邮件列表及相关说明文件的链接。如果你的努力（包括阅读 FAQ）都没有结果，网站上也许还有报告 Bug（Bug-reporting）的流程或链接，如果是这样，链过去看看。向陌生的人或论坛发送邮件最可能是风险最大的事情。举例来说，别假设一个提供丰富内容的网页的作者会想充当你的免费顾问。不要对你的问题是否会受到欢迎做太乐观的估计 —— 如果你不确定，那就向别处发送，或者压根别发。在选择论坛、新闻群组或邮件列表时，别太相信它的名字，先看看 FAQ 或者许可书以弄清楚你的问题是否切题。发文前先翻翻已有的话题，这样可以让你感受一下那里的文化。事实上，事先在新闻组或邮件列表的历史记录中搜索与你问题相关的关键词是个极好的主意，也许这样就找到答案了。即使没有，也能帮助你归纳出更好的问题。别像机关枪似的一次“扫射”所有的帮助渠道，这就像大喊大叫一样会使人不快。要一个一个地来。搞清楚你的主题！最典型的错误之一是在某种致力于跨平台可移植的语言、套件或工具的论坛中提关于 Unix 或 Windows 操作系统程序界面的问题。如果你不明白为什么这是大错，最好在搞清楚这之间差异之前什么也别问。

在提问之前，花点时间搞清楚自己提问的帖子该出现在什么场合，一个一个找，搞清楚所有场合之间的区别和差异，出现在正确场合的问题才能够得到较好的解答。

一般来说，在仔细挑选的公共论坛中提问，会比在私有论坛中提同样的问题更容易得到有用的回答。有几个理由可以支持这点，一是看潜在的回复者有多少，二是看观众有多少。黑客较愿意回答那些能帮助到许多人的问题。可以理解的是，老练的黑客和一些热门软件的作者正在接受过多的错发信息。就像那根最后压垮骆驼背的稻草一样，你的加入也有可能使情况走向极端 —— 已经好几次了，一些热门软件的作者由于涌入其私人邮箱的大量不堪忍受的无用邮件而不再提供支持。

如果有必要，先将提问帖子发表在公共区域而非私人区域，因为发表在公共区域的提问能够被更多人看到，大佬也就不需要对同一个常见问题针对不同的人进行多次重复解答。

如果你还是找不到任何对你的问题有用的内容，请把你的问题发在与它最相关的网站上。提问的时候请善用格式化工具，尤其注意为代码添加格式，并且添加相关的标签（特别是编程语言、操作系统或库/包的名称）。当有人要求你提供更多相关信息时，请编辑你的贴子来补充它们[译注：而不是发一个回帖或回答！]。如果你觉得一个答案对你有帮助，点击向上的箭头来为它投票；如果一个答案提供了问题的正确解决方案，点击投票按钮下方的对勾来将它标记为正解。

这是具体的通过发帖子进行提问的规范。

本地的用户群组（user group），或者你所用的 Linux 发行版本也许正在宣传他们的网页论坛或 IRC 频道，并提供新手帮助（在一些非英语国家，新手论坛很可能还是邮件列表），这些都是开始提问的好地方，特别是当你觉得遇到的也许只是相对简单或者很普通的问题时。有广告赞助的 IRC 频道是公开欢迎提问的地方，通常可以即时得到回应。事实上，如果程序出的问题只发生在特定 Linux 发行版提供的版本（这很常见），最好先去该发行版的论坛或邮件列表中提问，再到程序本身的论坛或邮件列表提问。（否则）该项目的黑客可能仅仅回复“使用我们的版本”。在任何论坛发文以前，先确认一下有没有搜索功能。如果有，就试着搜索一下问题的几个关键词，也许这会有帮助。如果在此之前你已做过通用的网页搜索（你也该这样做），还是再搜索一下论坛，搜索引擎有可能没来得及索引此论坛的全部内容。通过论坛或 IRC 频道来提供用户支持服务有增长的趋势，电子邮件则大多为项目开发者间的交流而保留。所以最好先在论坛或 IRC 中寻求与该项目相关的协助。在使用 IRC 的时候，首先最好不要发布很长的问题描述，有些人称之为频道洪水。最好通过一句话的问题描述来开始聊天。

先将自己的问题局限在一个精确的，足够小的板块内，找到对应的板块发表提问帖子。提问的开始通常用一句非常简短的，足够概括整个问题的句子作为标题。

使用有意义且描述明确的标题

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

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

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

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

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

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

在网页论坛上，好的提问方式稍有不同，因为讨论串与特定的信息紧密结合，并且通常在讨论串外就看不到里面的内容，故通过回复提问，而非改变标题是可接受的。不是所有论坛都允许在回复中出现分离的标题，而且这样做了基本上没有人会去看。不过，通过回复提问，这本身就是暧昧的做法，因为它们只会被正在查看该标题的人读到。所以，除非你只想在该讨论串当前活跃的人群中提问，不然还是另起炉灶比较好。

在消息回复列，例如Github Issue中，通常只有标题的关键词才能够被搜索引擎索引，因此在某个特定的Issue的回复中的提问，是无法被搜索引擎索引的，它只能被正在看该帖子的人看到，所以如果你想要你的问题能够被更多人看到，最好还是再单独开一个Issue而不是直接在回复里提问。

使问题容易得到回复

不要要求别人通过电子邮件来回复你在论坛中发表的问题，这是非常不礼貌的。

使用清晰准确且符合语法的语句提问

大多数情况下，英语是通用的。如果自己是非英语母语者，在提问中表明自己可能出现英语拼写的错误也是可以的。

使用易于读取、通用、标准的文件格式发送问题

精确地描述问题并附上依据

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

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

话不在多而在于精

别动辄声称找到了一个Bug，这是非常不礼貌的

当你在使用软件中遇到问题，除非你非常、非常的有根据，不要动辄声称找到了 Bug。提示：除非你能提供解决问题的源代码补丁，或者提供回归测试来表明前一版本中行为不正确，否则你都多半不够完全确信。这同样适用在网页和文件，如果你（声称）发现了文件的Bug，你应该能提供相应位置的修正或替代文件。请记得，还有其他许多用户没遇到你发现的问题，否则你在阅读文件或搜索网页时就应该发现了（你在抱怨前已经做了这些，是吧？）。这也意味着很有可能是你弄错了而不是软件本身有问题。编写软件的人总是非常辛苦地使它尽可能完美。如果你声称找到了 Bug，也就是在质疑他们的能力，即使你是对的，也有可能会冒犯到其中某部分人。当你在标题中嚷嚷着有Bug时，这尤其严重。提问时，即使你私下非常确信已经发现一个真正的 Bug，最好写得像是你做错了什么。如果真的有 Bug，你会在回复中看到这点。这样做的话，如果真有 Bug，维护者就会向你道歉，这总比你惹恼别人然后欠别人一个道歉要好一点。

扩大到其他领域，在向大佬提问时，要注意言辞，不要一来就否定大佬的努力，指出他可能存在的错误，就算他真的存在错误并且你也准确地找到了该错误，你也应该非常谦虚的向他指出你遇到了困难而不是他的成果有问题。

低声下气不能代替自己的努力

别用原始灵长类动物的把戏来浪费你我的时间。

着重描述问题症状而非你的猜测

尽管你认为描述自己的猜测很重要，你也要在非常清楚地描述了问题症状之后再描述自己的猜测并清楚地表明这是自己的猜测。

例子如下：

蠢问题

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

聪明问题

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

按照问题发生时间先后例举出问题症状

重点描述目标而不是过程

如果你想弄清楚如何做某事（而不是报告一个 Bug），在开头就描述你的目标，然后才陈述重现你所卡住的特定步骤。经常寻求技术帮助的人在心中有个更高层次的目标，而他们在自以为能达到目标的特定道路上被卡住了，然后跑来问该怎么走，但没有意识到这条路本身就有问题。结果要费很大的劲才能搞定。

这非常重要，因为选择大于努力，如果自己的选择是错误的，要让别人能够帮你纠正错误的选择而不是帮助你在这条错误的道路上继续走下去。

举例如下：

蠢问题

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

聪明问题

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

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

别要求别人使用私人邮件进行回复

在公开场合进行提问并要求别人使用私人邮件进行回复是非常不礼貌的。

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

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

有些问题需要自己独立去解决而不是要求别人无偿提供给你一个解决方案。如果你不想独立解决问题，那么花点钱找商业支持是最好的选择。

去掉无意义的提问句

例如“有人能帮我吗？”，“这有答案吗”。

即使你很急也不要在标题写“紧急”。

解决问题是自己的事情，而不是别人的事情，不要妄想别人无偿地帮助你解决紧急问题。

礼多人不怪，而且有时还很有帮助

讲礼貌比不讲礼貌肯定是要强的，但是还是要注意礼貌的提问也不能代替自己的思考，在技术大佬眼里，清晰明确地表明自己的问题依然是最重要的，礼貌地提问是锦上添花地作用。

问题解决后，加个简短的补充说明

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

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

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

对于有深度的问题，张贴调试记录的摘要是有帮助的。描述问题的最终状态，说明是什么解决了问题，在此之后才指明可以避免的盲点。避免盲点的部分应放在正确的解决方案和其它总结材料之后，而不要将此信息搞成侦探推理小说。列出那些帮助过你的名字，会让你交到更多朋友。

除了有礼貌和有内涵以外，这种类型的补充也有助于他人在邮件列表/新闻群组/论坛中搜索到真正解决你问题的方案，让他们也从中受益。

至少，这种补充有助于让每位参与协助的人因问题的解决而从中得到满足感。如果你自己不是技术专家或者黑客，那就相信我们，这种感觉对于那些你向他们求助的大师或者专家而言，是非常重要的。问题悬而未决会让人灰心；黑客们渴望看到问题被解决。好人有好报，满足他们的渴望，你会在下次提问时尝到甜头。

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

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

在提问后

RTFM 和 STFW：如何知道你已完全搞砸了

有一个古老而神圣的传统：如果你收到RTFM（Read The Fucking Manual）的回应，回答者认为你应该去读他妈的手册。当然，基本上他是对的，你应该去读一读。

RTFM 有一个年轻的亲戚。如果你收到STFW（Search The Fucking Web）的回应，回答者认为你应该到他妈的网上搜索。那人多半也是对的，去搜索一下吧。（更温和一点的说法是 Google 是你的朋友！）

在论坛，你也可能被要求去爬爬论坛的旧文。事实上，有人甚至可能热心地为你提供以前解决此问题的讨论串。但不要依赖这种关照，提问前应该先搜索一下旧文。

通常，用这两句之一回答你的人会给你一份包含你需要内容的手册或者一个网址，而且他们打这些字的时候也正在读着。这些答复意味着回答者认为：

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

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

如果还是搞不懂

先自行尝试学习并解决问题而不是继续提出未经思考的问题。

处理无礼地回应

很多技术大佬地脾气是很暴躁的，因为他们的时间会被大量的、来自不同地方、不同时间，不同账号的人的愚昧的提问所浪费，尽管不回答这些愚昧的提问而仅仅是筛选掉这些愚昧的提问也是很浪费时间和精力的。因此在收到无礼的回应之前，想想是不是自己的问题，表达歉意或者忍气吞声比疯狂地展开回击更能帮助你解决问题。

不该问的问题

我能在哪找到 X 程序或 X 资源？
- 就在我找到它的地方啊，白痴 —— 搜索引擎的那一头。天哪！难道还有人不会用 Google 吗？
我怎样用 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 使用群组者寻求实际的指导吧（你能在这儿找到用户群组的清单）。
  
  注意：如果安装问题与某 Linux 的发行版有关，在它的邮件列表、论坛或本地用户群组中提问也许是恰当的。此时，应描述问题的准确细节。在此之前，先用 Linux 和所有被怀疑的硬件作关键词仔细搜索。
我怎么才能破解 root 帐号/窃取 OP 特权/读别人的邮件呢？
- 想要这样做，说明了你是个卑鄙小人；想找个黑客帮你，说明你是个白痴！

如果得不到回答

要么细心等待、要么付费寻找商业支持。

如何更好地回答问题

态度和善。
对初犯者私下回复，不要公众羞辱。
如果不确定，一定要清楚的说出来。
如果帮不了忙，也别妨碍他。
试探性地反问以引出更多解决问题所需要的细节。
如果你决定回答，就请给出好的答案。
正面回答问题。
帮助你的社区从问题中学习。
如果解决问题的过程比较复杂，展示出解决问题的技巧比直接呈现结果更好。