提问的智慧-提问前都请看看好吧

前言
这本指南中是教你如何从那些真正懂得的人取得协助。
除非你确定被你艾特的人刚好是你所遇到的问题领域的专家,
否则请不要打扰他,这样大家都会开心一点。
当你在这里询问时如果遇到我对你说 RTFM 或者 STFW 的话,
你就应该反思下自己的行为了。
RTFM是Read The Fucking Manual的意思,中文就是“你TMD去读下手册啊”。
STFW是Search The Fucking Web的意思,中文就是“你TMD上网搜啊”。更温和一点的说法是“谷歌/百度/搜狗/必应是你的朋友!”。
不被我喷的守则
伸手前先想一想你的问题会不会太白痴。
别随意引战,站长可是权限gou…咦不对,权限组。
如果你知道关键词,那就发出来。
如果不知道解压密码,你要去配老花眼镜。
如果你知道游戏/资源制作公司/作者的名字,发出来。
如果问我/站长/其他大大还是找不到,可以等社区上线后和其他人交流,别刷屏。

P.S. 欢迎任何人对本指南提出改进意见。

在提问之前
在你准备询问我之前,请先做到以下事情:
尝试在你准备提问的问题关键词在搜索栏搜索答案。
尝试上网搜索以找到答案。
尝试阅读说明(书)以找到答案。
尝试阅读常见问题文件(FAQ)以找到答案。
尝试自己检查或试验以找到答案。

秒传问题补充准备
先尝试排除是自己电脑的问题
准备好自己电脑的系统配置图
别问在哪里下载秒传!RTFM!STFW!

小心别问错了问题。
如果你的问题基于错误的假设,大佬们多半会一边在心里想着蠢问题…
一边用无意义的字面解释来答复你,希望着你会从问题的回答(而非你想得到的答案)中汲取教训。

当你提问时
使用有意义且描述明确的标题,别用喋喋不休的帮帮忙、跪求、急(更别说救命啊!!!!这样让人反感的话,用这种标题会被条件反射式地忽略)
不要妄想用你的痛苦程度来打动大佬们,而应该是在这点空间中使用极简单扼要的描述方式来提出问题。
另外还有非常重要的一点:别在标题简单描述问题后,内容就用一个标点符号带过!
eg.
蠢问题:救命啊!XX游戏无法打开……
聪明问题:我打开游戏时不断崩溃,大佬们帮我看看是怎么一回事。
更聪明问题:XX游戏在YY系统下不断崩溃,并弹出此弹窗,求解决办法[附:弹窗截图.jpg]

精确地描述问题并言之有物
仔细、清楚地描述你的问题或 Bug 的症状。
描述问题发生的环境(机器配置、操作系统、应用程序、以及相关的信息),提供经销商的发行版和版本号(如:Fedora Core 4、Slackware 9.1等)。
描述在提问前你是怎样去研究和理解这个问题的。
描述在提问前为确定问题而采取的诊断步骤。
描述最近做过什么可能相关的硬件或软件变更。
尽可能的提供一个可以重现这个问题的可控环境的方法。
尽量去揣测一个对方会怎样反问你,在你提问之前预先将对方可能遇到的问题回答一遍。

话不在多而在精
你需要提供精确有内容的信息。这并不是要求你简单的把成堆的出错代码或者资料完全转录到你的提问中。
如果你有庞大而复杂的测试样例能重现程序挂掉的情境,尽量将它剪裁得越小越好。
这样做的用处至少有三点:
第一,表现出你为简化问题付出了努力,这可以使你得到回答的机会增加;
第二,简化问题使你更有可能得到有用的答案;
第三,在精炼你的 bug 报告的过程中,你很可能就自己找到了解决方法或权宜之计。

低声下气不能代替你的功课
有些人明白他们不该粗鲁或傲慢的提问并要求得到答复,但他们选择另一个极端
—— 低声下气:我不懂啊,我没接触过,我是新手……
这既使人困扰,也没有用,尤其是伴随着与实际问题含糊不清的描述时更令人反感。
别用原始灵长类动物的把戏来浪费你我的时间。
取而代之的是,尽可能清楚地描述背景条件和你的问题情况。
这比低声下气更好地定位了你的位置。
大佬们多半会在博客发布一些新手类的教程,并在该页面下方提供留言交流的地方。
如果你真的认为自己是个什么都不懂的人,先照这学习、实践一遍,但一样别那么低声下气。

描述问题而非你的猜测
告诉大佬们你认为问题是怎样造成的并没什么帮助。
(如果你的推断如此有效,还用向大佬们求助吗?)
因此要确信你原原本本告诉大佬们问题的症状,而不是你的解释和理论。
让大佬们来推测和诊断。如果你认为陈述自己的猜测很重要,清楚地说明这只是你的猜测,并描述为什么它们不起作用。
eg.
蠢问题:我电脑无法开机了,屏幕是黑的,我怀疑是显示器坏了,怎么办?
聪明问题:我的台式电脑无法开机了,并且主机指示灯亮,显示器指示灯亮,昨天还能正常使用。
今天开机就显示器黑屏了,没有任何反应,重启后仍旧如此。请问是什么问题导致的?

按发生时间先后列出问题症状
问题发生前的一系列操作,往往就是对找出问题最有帮助的线索。
因此,你的说明里应该包含你的操作步骤,以及机器和软件的反应,直到问题发生。
在命令行处理的情况下,提供一段操作记录(例如运行脚本工具所生成的),并引用相关的若干行(如 20 行)记录会非常有帮助。
如果挂掉的程序有诊断选项(如 -v 的详述开关),试着选择这些能在记录中增加调试信息的选项。
记住,多不等于好。试着选取适当的调试级别以便提供有用的信息而不是让读者淹没在垃圾中。

描述目标而不是过程
如果你想弄清楚如何做某事(而不是报告一个 Bug),在开头就描述你的目标,然后才陈述重现你所卡住的特定步骤。
eg.
蠢问题:我怎样才能从某绘图程序的颜色选择器中取得十六进制的的 RGB 值?
聪明问题:我正试着用替换一幅图片的色码(color table)成自己选定的色码。
我现在知道的唯一方法是编辑每个色码区块(table slot)。
但却无法从某绘图程序的颜色选择器取得十六进制的的 RGB 值。
第二种提问法比较聪明,你可能得到像是建议采用另一个更合适的工具的回复。

清楚明确的表达你的问题以及需求
漫无边际的提问是近乎无休无止的时间黑洞。
最有可能给你有用答案的人通常也正是最忙的人。
(他们忙是因为要亲自完成大部分工作)
这样的人对无节制的时间黑洞相当厌恶,所以大佬们也倾向于厌恶那些漫无边际的提问。
如果你明确表述需要大佬们做什么,就最有可能得到有用的答案。
因为这会定出一个时间和精力的上限,便于回答者能集中精力来帮你。
要理解大佬们所处的世界,请把专业技能想像为充裕的资源,而回复的时间则是稀缺的资源。
你要求大佬们奉献的时间越少,你越有可能从真正专业而且很忙的大佬那里得到解答。

即使你很急也不要在标题写紧急
这是你的问题,不是大佬们的问题。宣称紧急极有可能事与愿违:
大多数大佬们会直接删除无礼和自私地企图即时引起关注的问题。
有半个例外的情况是,如果你是在一些很高调,会使大佬们兴奋的地方,也许值得这样去做。
当然,这风险很大,因为大佬们兴奋的点多半与你的不同。
礼多人不怪,而且有时还很有帮助。彬彬有礼,多用请和谢谢您的关注,或谢谢你的关照。
让大家都知道你对他们花时间免费提供帮助心存感激。

写在最后:
如果你自己不是技术专家,那就相信大佬们。
这种感觉对于那些你向他们求助的大师或者专家而言,是非常重要的,大佬们同样渴望看到问题被解决。
好人有好报,满足大佬们的渴望,你会在下次提问时让大佬们更感兴趣。

© 版权声明
THE END
喜欢就支持一下吧
点赞12 分享
评论 共3条
头像
欢迎您留下宝贵的见解!
提交
头像

昵称

取消
昵称表情