提问的智慧听课纯手打中文简体笔记（担心自己问不好问题？回答不好问题？提问的智慧比学编程更重要，学这一份就够了。赶紧收藏起来吧）
原视频地址：提问的智慧_哔哩哔哩_bilibili
1.简介
在程序员的世界里，当你抛出一个技术问题时，最终是否能得到有用的回答，往往取决于你所提问和追问的方式。
小提示
程序员们有着蔑视或傲慢面对简单的坏名声，这有时让我们看起来对新手、无知者似乎较有敌意，但其实不是那样的。
名词解释
撸瑟（lusers）：
不愿思考、或者在发问前不做他们该做的事的人。
那些人是时间杀手 —— 他们只想索取，从不付出，消耗我们可用在更有趣的问题或值得回答的人身上的时间。
小提示
能立刻得到快速并有效回答的最好方法，就是像温拿（Winner）那样提问 --聪明、自信、有解决问题的思路，只是偶尔在特定的问题上需要获得一点帮助。
2.提问之前
在提问之前，首先完成以下工作
1. 尝试在你准备提问的论坛的旧文章中搜索答案。
2. 尝试上网搜索以找到答案。
3. 尝试阅读手册以找到答案。
4. 尝试阅读常见问题文件（FAQ）以找到答案。
5. 尝试自己检查或试验以找到答案。
6. 像你身边的强者朋友打听以找到答案。
7. 如果你是程序开发者，请尝试阅读源代码以找到答案。
小提示
当你提出问题的时候，请先表明你已经做了上述的努力；这将有助于树立你并不是一个不劳而获且浪费别人时间的提问者。
如果你能一并表达了在做了上述努力的过程中所学到的知识会更好，因为我们更乐于回答那些表现出能从答案中学习的人的问题。
善用搜索引擎
运用某些策略，比如先用 Bing/Baidu 搜索你所遇到的各种错误信息，这样很可能直接就找到了能解决问题的线索。
即使没有结果，在寻求帮助时加上一句：
“我在 Bing 中搜过下列句子，但没有找到什么有用的东西 ”
也是件好事，即使它只是表明了搜索引擎不能提供哪些帮助。这么做（加上搜索过的字串）也让遇到相似问题的其他人能被搜索引擎引导到你的提问来。
小提示
准备好你的问题，再将问题仔细地思考过一遍，因为草率的发问只能得到草率的回答，或者根本得不到任何回答。
越是能表现出在寻求帮助前你为解决问题所付出的努力，你越有可能得到实质性的帮助。
小提示
小心别问错了问题。
如果你的问题基于错误的假设，某个普通程序员（Random Programmer）多半会一边在心里想着 蠢问题…，一边用无意义的字面解释来答复你，希望着你会从问题的回答（而非你想得到的答案）中汲取教训。
小提示
表明你愿意在找答案的过程中做点什么是一个非常好的开端。
谁能给点提示？我的这个例子里缺了什么？以及我应该检查什么地方？
比
谁把我需要的确切的过程贴出来。
更容易得到答复。
因为你表现出只要有人能指个正确方向，你就有完成它的能力和决心。
3.当你提问时
慎选提问的论坛
小心选择你要提问的场合。如果你做了下述的事情，你很可能被忽略掉或者被看作是Lusers：
- 在与主题不和的论坛上贴出你的问题。
- 在探讨进阶技术问题的论坛上张贴非常初级的问题；反之亦然。
- 在太多的不同群组上重复转贴同样的问题（cross-post）。
- 向既非熟人也没有义务解决你问题的人发送私人电邮。
Stack Overflow
搜索，然后在 Stack Exchange 问。
近年来，Stack Exchange community 社区已经成为回答技术及其他问题的主要渠道，尤其是那些开放源码的项目。
- Super User 是问一些通用的电脑问题，如果你的问题跟代码或是写程序无关，只是一些网络连线之类的，请到这里。
- Stack Overflow 是问写程序有关的问题。
- Server Fault 是问服务器和网管相关的问题。
使用有意义的且描述明确的标题
小提示
在邮件列表、新闻群组或论坛中，大约50字以内的标题是抓住资深专家注意力的好机会。
别用喋喋不休的 帮帮忙、跪求、急（更别说 救命啊！！！！ 这样让人反感的话，用这种标题会被条件反射式地忽略）来浪费这个机会。
不要妄想用你的痛苦程度来打动我们，而应该是在这点空间中使用极简单扼要的描述方式来提出问题。
一个好标题范例是目标 —— 差异式的描述，许多技术支持组织就是这样做的。
在目标部分指出哪一个或哪一组东西有问题；
在差异部分则描述与期望的行为不一致的地方。
蠢问题：救命啊！我的笔记本电脑不能正常显示了！
聪明问题：X.org 6.8.1 的鼠标光标会变形，某牌显卡 MV1005 芯片组。
更聪明问题：X.org 6.8.1 的鼠标光标，在某牌显卡 MV1005 芯片组环境下 - 会变形。
用清晰、正确、精准并语法正确的语句
如果你写得像是个半文盲，那多半得不到理睬，也不要使用即时通信中的简写或火星文。
如果在使用非母语的论坛提问，你可以犯点拼写或语法上的小错，但决不能在思考上马虎。
在英文论坛中提问时，提问潜在回复者你有潜在的语言困难是很好的。
- 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.
- 我对技术名词很熟悉，但对于俗语或是特别用法比较不甚了解。
精确地描述问题并言之有物
1. 仔细、清楚地描述你的问题或 Bug 的症状。
2. 描述问题发生的环境（机器配置、操作系统、应用程序、以及相关的信息），提供经销商的发行版和版本号（如：Fedora Core 4、Slackware9.1等）。
3. 描述在提问前你是怎样去研究和理解这个问题的。
4. 描述在提问前为确定问题而采取的诊断步骤。
5. 描述最近做过什么可能相关的硬件或软件变更。
6. 尽可能地提供一个可以重现这个问题地可控环境的方法。
话不在多而在精
你需要提供精确有内容的信息，这并不是要求你简单地把成堆的出错代码或者资料完全转录到你的提问中。如果你有庞大而复杂的测试样例能重现程序挂掉的情境，尽量将它裁剪得越小越好。
这样做的用处至少有三点：
1. 表现你为简化问题付出了努力，这可以使你得到回答的机会增加；
2. 简化问题使你更有可能得到有用的答案；
3. 在精炼你的 bug 报告的过程中，你很有可能就自己找到了解决方法或权宜之计。
低声下气不能代替你的功课
有些人明白他们不该粗鲁或傲慢的提问并要求得到答复，但他们选择另一个极端 —— 低声下气：
我知道我只是个可悲的新手，一个撸瑟，但…。
这既使人困扰，也没有用，尤其是伴随着与实际问题含糊不清的描述时更令人反感。
别用原始灵长类动物的把戏来浪费你我的时间。取而代之的是，尽可能清楚地描述背景条件和你的问题情况。这比低声下气更好地定位了你的位置。
有时网页论坛会设有专为新手提问的版面，如果你真的认为遇到了初学者的问题，到那去就是了，但一样别那么低声下气。
描述问题症状而非你的猜测
告诉程序员们你认为问题是怎样造成的并没什么帮助。（如果你的推断如此有效，还用向别人求助吗？）
因此要确信你原原本本告诉了他们问题的症状，而不是你的解释和理论，让大家来推测和诊断。如果你认为陈述自己的猜测很重要，清楚地说明这只是你的猜测，并描述为什么它们不起作用。
蠢问题：我在编译内核时接连遇到 SIG11 错误，我怀疑某条飞线搭在主板的走线上了，这种情况应该怎样检查最好？
聪明问题：我的组装电脑是 FIC-PA2007 主机板搭载 AMD K6/233 CPU（臧盛 Apollo VP2 芯片组），256MB Corsair PC133 SDRAM 内存，在编译内核时，从开机 20 分钟以后就频频产生 SIG11错误，但是在头 20分钟内从没发生过相同的问题。重新启动也没有用，但是关机一晚上就又能工作 20分钟。所有内存都换过了，没有效果。相关部分的标准编译记录如下…。
按发生时间先后列出问题症状
- 问题发生前的一系列操作，往往就是对找出问题最有帮助的线索。因此，你的说明里应该包含你的操作步骤，以及机器和软件的反应，直到问题发生。
- 如果挂掉的程序有诊断选项（如 -v 的详述开关），试着选择这些能在记录中增加调试信息的选项。记住，多不等于好，试着选取适当的调试级别以便提供有用的信息而不是让读者淹没在垃圾中。
- 如果你的说明很长（如超过四个段落），在开头简述问题，接下来再按时间顺序详述会有所帮助。这样黑客们会在读你的记录时就知道该注意哪些内容了。
描述目标而不是过程
在开头就描述你的目标，然后才陈述重现你所卡住的特定步骤。
经常寻求技术帮助的人在心中有个更高层次的目标，而他们在自以为能达到目标的特定道路上被卡住了，然后跑来问该怎么走，但没有意识到这条路本身就有问题。结果要费很大的劲才能搞定。
蠢问题：我怎样才能从某绘图程序的颜色选择器中取得十六进制的 RGB 值？
聪明问题：我正试着用替换一幅图片的色码（color table）成自己选定的色码，我现在知道的唯一方法是编辑每个色码区块（table slot），但却无法从某绘图程序的颜色选择器取得十六进制的 RGB 值。
清楚明确地表达你的问题以及需求
- 漫无边际的提问是近乎无休无止的时间黑洞。最有可能给你有用答案的人通常也正是最忙的人。这样的人对无节制的时间黑洞相当厌恶，所以他们也倾向于厌恶那些漫无边际的提问。
- 要理解专家们所处的世界，请把专业技能想象为充裕的资源，而回复的时间则是稀缺的资源。你要求他们奉献的时间越少，你越有可能从真正专业而且很忙的专家那里得到解答。
- 我想更好地理解 X，可否指点一下？哪有好一点说明？
通常比问
你能解释一下 X 吗？
更好。
- 如果你的代码不能运作，通常请别人看看哪里有问题，比要求别人替你改正要明智得多。
询问有关代码的问题时
- 别要求他人帮你调试有问题的代码，不提示一下应该从何入手。张贴几百行的代码，然后说一声：
它不能工作。
会让你完全被忽略。只贴几十行代码，然后说一句：
在第七行以后，我期待它显示
比较有可能让你得到回应。
- 最有效描述程序问题的方法是提供最精简的 Bug 展示测试用例（bug-demonstrating test case）。
- 什么是最精简的测试用例？那是问题的缩影；一小个程序片段能刚好展示出程序的异常行为，而不包含其他令人分散注意力的内容。
别把自己家庭作业的问题贴上来
- 程序员们很擅长分辨哪些问题是家庭作业式的问题；因为我们中的大多数都曾自己解决这类问题。同样，这些问题得由你来搞定，你会从中学到东西。你可以要求给点提示，但别要求得到完整的解决方案。
- 如果你怀疑自己碰到了一个家庭作业式的问题，但仍然无法解决，试试在使用者群组，论坛中提问。尽管黑客们会看出来，但一些有经验的使用者也许仍会给你一些提示。
去掉无意义的提问句
- 避免用无意义的话结束提问，例如有人能帮我吗？或者这有答案吗？。
- 首先：如果你对问题的描述不是很好，这样问更是画蛇添足。
- 其次：由于这样问题是画蛇添足，黑客们会很厌烦你 —— 而且通常会用逻辑上正确，但毫无意义的回答来表示他们的蔑视：’
例如：没错，有人能帮你或者不，没答案。
- 一般来说，避免用 是或否、对或错、有或没有类型的问句，除非你想得到是或否类型的回答。
礼多人不怪，而且有时还很有帮助
- 彬彬有礼，多用 请或谢谢您的关注，或谢谢您的关照。让大家都知道你对他们花时间免费提供帮助心存感激。
- 坦白说，这一点并没有比清晰、正确、精准重要。黑客们一般宁可读有点唐突但技术上鲜明的 Bug 报告，而不是那种有礼但含糊的报告。
- 然而，如果你有一串的问题待解决，客气肯定会增加你得到有用回应的机会。
4.如何解读答案
如何知道你已经完全搞砸了
有一个古老而神圣的传统：如果有人回复了 RTFM 及其年轻的亲戚STFW，那就说明你的提问搞砸了。
名词解释
RTFM：
Read The Fucking Manual
STFW：
Search The Fucking Web
（温和点的说法是：百度是你的朋友）
通常，用这两句之一回答你的人会给你一份包含你需要内容的手册或者一个网址，而且他们打这些字的时候也正在读着。这些答复意味着回答者认为：
- 你需要的信息非常容易获得；
- 你自己去搜索这些信息比灌给你，能让你学到更多。
你不应该因此不爽；依照程序员的标准，他已经表示对你一定程度的关注，而没有对你的要求视而不见。你应该对他慈母般的慈祥表示感谢。
如果你还是搞不懂
如果你看不懂回应，别立刻要求对方解释。像你以前试着自己解决问题时那样（利用手册，FAQ，网络，身边的高手），先试着去搞懂他的回应。如果你真的需要对方解释，记得表现出你已经从中学到了点什么。
比方说，如果我回答你：
看来似乎是个 zentry 卡住了；你应该先清除它。
然后，这是一个很糟的后续问题回应：
zentry 是什么？
好的问法应该是这样：
哦~~~我看过说明了但是只有 -z和 -p两个参数中提到了 zentries，而且还都没有清楚的解释如何清除它。你是指这两个中的哪一个吗？还是我看漏了什么？
5.如何避免扮演卢瑟
- 在开发社区的论坛中有那么几次你可能会搞砸 —— 以之前所描述到的或类似的方式。而你会在公共场合中被告知你是如何考砸的，也许攻击的言语中还会带点夹七杂八的颜色。
- 这种事发生以后，你能做的最糟糕的事莫过于哀嚎的遭遇、宣称被口头攻击、要求道歉、高声尖叫、憋闷气、威胁诉诸法律、向其雇主抱怨、忘了冲厕所等等。相反地，你该这么做：
- 熬过去，这很正常。事实上，它是有益健康且合理的。
你要的是友善还是有用？两个里面挑一个。
记着：
当程序员说你搞砸了，并且（无论多么刺耳）告诉你别再这样做时，他正在为关心你和他的社区而行动。对他而言，不理你并将你从他的生活中滤掉更简单。
如果你无法做到感谢，至少要表现得有点尊严，别大声哀嚎，也别因为自己是个有戏剧性超级敏感的灵魂和自以为有资格的新来者，就指望别人像对待脆弱的洋娃娃那样对你。
6.不该问的问题
Q：我能在哪找到 X 程序或 X 资源？
A：就在我找到它的地方啊，白痴 —— 搜索引擎的那一头。
天哪！难道还有人不会用百度吗？
Q：我怎样用 X 做 Y？
A：如果你想解决的是 Y，提问时别给出可能并不恰当的方法。这种问题说明提问者不但对于 X 完全无知，也对 Y 要解决的问题糊涂，还被特定形式禁锢了思维。最好忽略这种人，等他们把问题搞清楚了再说。
Q：如何设定我的 shell 提示？？
A：如果你有足够的智慧提这个问题，你也该有足够的智慧去 RTFM，然后自己去找出来。
Q：我可以用 Bass-o-matic 文件转换工具将 AcmeCorp 档案转换为 Tex 格式吗？
A：试试看就知道了。如果你试过，你既知道了答案，就不用浪费我的时间了。
Q：我的程序/设定/SQL 语句）不工作
A：这不算是问题吧，我对要我问你二十个问题才找的出你真正问题没兴趣 —— 我有更有意思的事情要做呢。在看到这类问题的时候，我的反应通常不外如下三种：
- 你还有什么要补充的吗？
- 真糟糕，希望你能搞定。
- 这关我什么屁事？
Q：我的程序不会动了，我认为系统工具 X 有问题
A：你完全有可能是第一个注意到被成千上万用户反复使用的系统调用与函数库档案有明显缺陷的人，更有可能的是你完全没有根据。不同凡响的说法需要不同凡响的证据，当你这样声称时，你必须有清楚而详尽的缺陷的说明文件作后盾。
Q：我怎么才能理解 root账号/窃取 OP 特权/读别人的邮件呢？
A:想要这样做，说明了你是个卑鄙小人；想找个程序员帮你，说明你是个白痴！
7.好问题和蠢问题
蠢问题：
我可以在哪里找到关于 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 的原因是什么？有谁知道接下来我该做些什么测试才能找出问题？
这个家伙，从另一个角度来看，值得去回答他。他表现出了解决问题的能力，而不是坐等天上掉答案。
8.如何更好地回答问题
1. 态度和善一点。问题带来的压力常使人显得屋里或愚蠢，其实并不是这样。
2. 对初犯者私下回复。对那些坦诚犯错之人没有必要当众羞辱，一个真正新手也许连怎么搜索或在哪找常见问题都不知道。
3. 如果你不确定，一定要说出来！一个听起来权威的错误回复比没有还要糟，别因为听起来像个专家很好玩，就给别人乱指路。要谦虚和诚实，给提问者与同行都树个好榜样。
4. 如果帮不了忙，也别妨碍他。不要在实际步骤上开玩笑，那样也许会毁了使用者的设置 —— 有些可怜的呆瓜会把它当成真的指令。
5. 试探性的反问以引出更多的细节。如果你做的好，提问者可以学到点东西 —— 你也可以。试试将蠢问题转变为好问题，别忘了我们都曾是新手。尽管对那些懒虫抱怨一声 RTFM 是正当的，能指出文件的位置（即使只是建议个 Google 搜索关键词）会更好。
6. 如果你决定回答，就请给出好的答案。当别人正在使用错误的工具或方法时别建议笨拙的权宜之计（wordaround），应推荐更好的工具，重新界定问题。
7. 正面地回答问题！如果这个提问者已经很深入地研究也表明过已经试过X、Y、Z、A、B、C 但没得到结果，回答 试试看 A 或是 B 或者 试试X、Y、Z、A、B、C 并附上一个链接一点用也没有。
8. 帮助你的社区从问题中学习。当回复一个好问题时，问问自己如何修改相关文件或常见问题文件以免再次解答同样的问题？，接着再向文件维护者发一份补丁。
如果你是在研究一番后才做出的回答，展现你的技巧而不是直接端出结果。毕竟授人以鱼不如授人以渔。
（码字不易。觉得这篇笔记对你有点用的话，麻烦你为本笔记点赞，评论，分享或收藏，因为这将是我输出更多笔记的动力，感谢！）