如何向别人提问
:::声明
本文为提問的智慧的总结笔记，有兴趣的可以链到原作者欣赏
如何向别人提问
简介
在计算机领域的世界里，你遇到的大大小小的问题大多数都已经被前人踩过，想要快速地解决一个错误，都可以通过提问或追问得到有用的答案（当然你有耐心或是享受这种独立解决问题的过程也算是件好事）。而正确的提问能帮助你获得满意的答案。
这里有一个比较有意思的，大多数其他有更多经验的用户或是骇客面对提问还是比较接纳的，当然，用户对新手常遇到的问题更宽容一些。如果你问了一个有趣的，能够引起思考，或是别人没有想到的问题，你将得到诚挚的大力赞扬。
在这里提问者被分成两类：那些不愿思考，甚至在发问前都没怎么做自己要做的事，只会索取的人，被称作失败者（撸瑟）(loser)；而那些聪明、自信、有解决问题的思路，只是偶尔在特定的问题上需要获得一点帮助的人，被称为赢家(winner)。
所以你决定向别人寻求帮助的时候，你也不会想成为撸瑟吧，不会吧，不会吧，那就像一个winner一样去提问。
在提问之前
虽然找别人帮忙好像很方便，但是在此之前应该试着自己去解决问题，这样更加高效快速，并且减少社交负担（如果你想借着问问题的手段去和心仪对象唠嗑，我已经想象出ta回答不出时用脚趾抠出三室一厅的画面了）。
- 使用搜索引擎
- 在相关论坛里的旧文章里搜索答案
- 尝试阅读使用手册/文档来找到答案
- 询问ChatGPT
- 尝试自己检查，试验找到答案
- 如果你能力够强，可以阅读代码来找到答案
使用搜索引擎应该算是21世纪人无师自通的技能，在这里你大概率能够在一些论坛或是个人网站里找到有关的回答。
在平台里搜索也差不多一个意思。只不过一个是在大海里，一个是在池塘里——池塘里能找到的相关度可能更高一些。一般是SCDN、知乎、掘金一系列这样的知识交流平台，然后是Stack Exchange——一个国外编程社区，它已经发展成超过一百个网站，常用的网站有：
- Super User 是问一些通用的电脑问题，如果你的问题跟代码或是写程序无关，只是一些网络连线之类的，请到这里。
- Stack Overflow 是问写程序有关的问题。
- Server Fault 是问服务器和网管相关的问题。
在使用某些类库、工具或是插件的时候，阅读使用手册是一个很有必要的过程，能够帮助你全面地理解你用的玩意儿，一般也会带有一些常见的Q&A也许刚好能够帮助你解决遇到的问题，当然这玩意儿看起来有点累，需要一定的使用门槛，啥也不会最好不要硬啃，既消磨热情又收益少，去找一些前辈嚼过的总结来看比较轻松。
现在很多有关ChatGPT的宣传和使用教学，但是我作为一个普通的使用者最大的感想，就是把它当做一个“高级搜索引擎”。你可以在这得到一些基础工具的命令行的作用，可以询问它一大段对你很繁琐复杂，但是只差临门一脚的代码，或者更多的是哪些总是会用到但还不够熟悉的操作…总之，对于初学者，用ChatGPT来进行CS学习真的是一个很好的方法，有种请了个私人教师的感觉(～￣▽￣)～
自己检查试验问题，我觉得这点是必须，或多或少都肯定得干，能干出来最好，没整出来也正常。这个过程你可以准备好你的问题，再将问题仔细地思考过一遍，因为草率的发问只能得到草率的回答，或者根本得不到任何答案。越是能表现出在寻求帮助前你为解决问题所付出的努力，你越有可能得到实质性的帮助。
##当你提问时
现在你已经做完上面这六步了，而且反复确认还是没有得到任何足够你解决问题的信息。这个时候你就可以提问了。
有礼貌
我们做人做事的第一步，就是用礼貌地表达你的诉求。要知道你向别人索取帮助，别人可以选择帮你或者不帮你，除去金钱交易或是一些复杂的社会关系外，一个客气礼貌的态度会让人觉得你是一个希望在某个方面有追求有想法的初学者，而不是一个loser。记得别人帮你解决问题后，不要忘记对回复者表达感谢。
把问题说清楚
如果你要是问出“怎么才能学好XXX””XXX怎么使用”“我的电脑显示器不能用了”这一系列粗浅且不容易回答的问题，那么你要么不是没完成提问前的步骤，要么就是一个不折不扣的loser。要想不被当成loser，那就把问题说明清楚明白具体。
- 仔细，清楚地描述bug/问题的状况
- 描述问题发生的环境（机器配置、操作系统、应用程序、以及相关的信息），提供经销商的发行版和版本号（如：Fedora Core 4、Slackware 9.1等）
- 描述在提问前你是怎样去研究和理解这个问题的。（即你是怎么操作会有这个结果的）
- 描述在提问前为确定问题而采取的诊断步骤。
- 描述最近做过什么可能相关的硬件或软件变更。
- 尽可能地提供一个可以重现这个问题的可控环境的方法。
精确地描述问题并言之有物能够然你得到有效的回答的机会和速度都会大大的提升。
描述目标而不是过程
如果你想弄清楚如何做某事（而不是报告一个 Bug），在开头就描述你的目标，然后才陈述重现你所卡住的特定步骤。
经常寻求技术帮助的人在心中有个更高层次的目标，而他们在自以为能达到目标的特定道路上被卡住了，然后跑来问该怎么走，但没有意识到这条路本身就有问题。结果要费很大的劲才能搞定。
蠢问题
我怎样才能从某绘图程序的颜色选择器中取得十六进制的 RGB 值？
聪明问题
我正试着用替换一幅图片的色码（color table）成自己选定的色码，我现在知道的唯一方法是编辑每个色码区块（table slot）， 但却无法从某绘图程序的颜色选择器取得十六进制的 RGB 值。
第二种提问法比较聪明，你可能得到像是建议采用另一个更合适的工具的回复。
描述问题症状而非你的猜测
告诉黑客们你认为问题是怎样造成的并没什么帮助。（如果你的推断如此有效，还用向别人求助吗？），因此要确信你原原本本告诉了他们问题的症状，而不是你的解释和理论；让黑客们来推测和诊断。如果你认为陈述自己的猜测很重要，清楚地说明这只是你的猜测，并描述为什么它们不起作用。
蠢问题
我在编译内核时接连遇到 SIG11 错误， 我怀疑某条飞线搭在主板的走线上了，这种情况应该怎样检查最好？
聪明问题
我的组装电脑是 FIC-PA2007 主机板搭载 AMD K6/233 CPU（威盛 Apollo VP2 芯片组）， 256MB Corsair PC133 SDRAM 内存，在编译内核时，从开机 20 分钟以后就频频产生 SIG11 错误， 但是在头 20 分钟内从没发生过相同的问题。重新启动也没有用，但是关机一晚上就又能工作 20 分钟。 所有内存都换过了，没有效果。相关部分的标准编译记录如下…
询问有关代码的问题时明确出问题的部分
如果没有提示别人应该从何入手，别要求他人帮你调试有问题的代码。张贴几百行的代码，然后说一声：它不能工作会让你完全被忽略。只贴几十行代码，然后说一句：在第七行以后，我期待它显示 <x>，但实际出现的是 <y>比较有可能让你得到回应。
最有效描述程序问题的方法是提供最精简的 Bug 展示测试用例（bug-demonstrating test case）。什么是最精简的测试用例？那是问题的缩影；一小个程序片段能刚好展示出程序的异常行为，而不包含其他令人分散注意力的内容。怎么制作最精简的测试用例？如果你知道哪一行或哪一段代码会造成异常的行为，复制下来并加入足够重现这个状况的代码（例如，足以让这段代码能被编译/直译/被应用程序处理）。如果你无法将问题缩减到一个特定区块，就复制一份代码并移除不影响产生问题行为的部分。总之，测试用例越小越好。
一般而言，要得到一段相当精简的测试用例并不太容易，但永远先尝试这样做是一个好习惯。这种方式可以帮助你了解如何自行解决这个问题 —— 而且即使你的尝试不成功，黑客们也会看到你在尝试取得答案的过程中付出了努力，这可以让他们更愿意与你合作。
如果你只是想让别人帮忙审查（Review）一下代码，在信的开头就要说出来，并且一定要提到你认为哪一部分特别需要关注以及为什么。
当你提问被回复后后
如果这时候已经解决问题了最好，要是还没有解决……
RTFM 和 STFW：如何知道你已完全搞砸了
有一个古老而神圣的传统：如果你收到RTFM（Read The Fucking Manual）的回应，回答者认为你应该去读他妈的手册。当然，基本上他是对的，你应该去读一读。
RTFM 有一个年轻的亲戚。如果你收到STFW（Search The Fucking Web）的回应，回答者认为你应该到他妈的网上搜索。那人多半也是对的，去搜索一下吧。（更温和一点的说法是Google 是你的朋友）(中国话通俗来说，叫百度一下)
在论坛，你也可能被要求去爬爬论坛的旧文。事实上，有人甚至可能热心地为你提供以前解决此问题的讨论串。但不要依赖这种关照，提问前应该先搜索一下旧文。
通常，用这两句之一回答你的人会给你一份包含你需要内容的手册或者一个网址，而且他们打这些字的时候也正在读着。这些答复意味着回答者认为：
- 你需要的信息非常容易获得；
- 你自己去搜索这些信息比灌给你，能让你学到更多。
你不应该因此不爽；依照黑客的标准，他已经表示了对你一定程度的关注，而没有对你的要求视而不见。你应该对他祖母般的慈祥表示感谢。
如果还是搞不懂
如果你看不懂回应，别立刻要求对方解释。像你以前试着自己解决问题时那样（利用手册，FAQ，网络，身边的高手），先试着去搞懂他的回应。如果你真的需要对方解释，记得表现出你已经从中学到了点什么。
比方说，如果我回答你：看来似乎是 zentry 卡住了；你应该先清除它。，然后，这是一个很糟的后续问题回应：zentry 是什么？ 好的问法应该是这样：哦~~~我看过说明了但是只有 -z 和 -p 两个参数中提到了 zentries，而且还都没有清楚的解释如何清除它。你是指这两个中的哪一个吗？还是我看漏了什么？
最后
希望你能从这里学到点什么，从而避免一些错误。
原文的后面还有一些比较有趣的分论点：
- 如何避免扮演失败者
- 不该问的问题
- 好问题与蠢问题
- 如果得不到回答
- 如何更好地回答问题
在此不再多说，作者已经说得很好了，有兴趣的可以去了解一下。
