1 简介
能否得到有用的回答，往往取决于你所提问和追问的方式
本书将教你如何正确的提问以获得你满意的答案
能立刻得到快速并有效答案的最好方法，就是像赢家那样提问──聪明、自信、有解决问题的思路，只是偶尔在特定的问题上需要获得一点帮助
2 在提问之前
在提问之前，请先做到以下事情：
- 尝试在你准备提问的论坛的旧文章中搜寻答案。
- 尝试上网搜寻来找到答案。
- 尝试阅读手册来找到答案。
- 尝试阅读常见问题文件（FAQ）来找到答案。
- 尝试自己检查或试验来找到答案
- 向你身边的强者朋友打听来找到答案。
- 如果你是编程开发者，请尝试阅读原始码来找到答案
草率的发问只能得到草率的回答，或者根本得不到任何答案
3 当你提问时
- 谨慎选择提问的论坛（避免主题/技术级别不符的论坛；避免已重复提问过的问题；避免向既非熟人也没有义务解决你问题的人发送私人电邮）
- Stack Exchange community 是回答技术及其他问题的主流社群（通用电脑问题提问在 Super User；编程相关问题提问在Stack Overflow；服务器和网络问题提问在Server Fault）
- 面向新手的论坛和互联网中继聊天（IRC，基于文本的即时聊天）通常响应最快
- 向开发者邮件列表（如果有的话）而不是其中的个别成员提问（分散个别开发者的负担；方便其他人复用你的问题和答案；有助于说明文档或软件的改善）
- 使用有意义且描述明确的标题（50字以内，说清楚所面对的问题和环境）
- 使问题更容易回复（在邮件中配置回复地址；在论坛中配置关注或回复提醒）
- 使用清晰、精准、正确、并合乎语法的书写（正确地拼写、使用标点和大小写；避免简写或火星文；非母语论坛提示时最好说明一下）
- 使用易于读取且标准的文件格式发送问题（尽量使用纯文本；避免单行句子多次断行；尽量包含数据原样；避免非常规编码；避免表情符号和标记符号滥用）
- 精确的描述问题并言之有物（问题发生的配置环境、软件信息和版本号；个人的理解和诊断步骤；尽量提供可问题复现的环境/方法；提前揣测可能反问的问题并预先给出答案）
- 话不在多而在精（提供精确有内容的信息，尽量裁剪测试样例与环境）
- 不要急于宣称找到Bug（质疑他人可能是令人不悦的，也会显得自己不够“老练”；一定要给出非常合理的依据或者解决问题的源代码补丁）
- 不要低声下气地提问，描述清楚问题背景和细节就好
- 描述问题症状而非猜测，让诊断问题的人看到与原始证据尽可能一致的东西
- 按发生时间先后列出问题症状，这通常包含有解决问题最有效的线索
- 先描述你的目标，再陈述遇到问题的特定步骤（避免方法/路线上的错误）
- 别要求私下回复电子邮件，问题的解决过程应该公开、透明
- 提问应明确，最有可能给你有用答案的人通常也是最忙的人
- 最精确描述代码问题的方法是提供一个能展示问题的最小测试样例
- 别把自己家庭作业的问题贴上来（自己的作业自己做，可以要求给点提示）
- 去掉无意义的提问句（“有人能帮我吗”）
- 不要把问题标记为“紧急”，即使对你而言的确如此（适当的刺激会让回答更快，但会有些无礼自私，而且还很容易被识别为垃圾邮件/信息）
- 礼貌一点，让别人明白你感谢他们无偿花时间帮助你
- 问题解决后追加一条简要说明（标注-
已解决；说清解决思路，让后人受益）
4 如何解读回答
- RTFM（Read The Fucking Manual，自己看手册）和STFW（Search The Fucking Web，自己去网上索）：按黑客的标准，回复者没有不理你就是在向你表示某种尊敬
- 如果你看不懂回应，别立刻要求对方解释，先试着去搞懂他的回应（利用手册，FAQ，网络，身边的高手）；真的需要对方解释时，先说清自己已明白的部分
- 处理无礼的回应：(a)一针见血式的交流并不是存心冒犯，这种看似无礼的风格更注重解决问题；(b)如果你感觉被冒犯，先试着平静地反应；(c)如果对方真的很出格，那就求锤得锤；(d)纠正无礼的言论与开始一场毫无意义的口水战仅一线之隔
5 别像个loser（失败者）那样反应
当你把问题搞砸了并被示众时请忍一忍，它是有益健康与恰当的
社区的标准是通过参与者积极而公开地执行来维持的
如果你无法做到感谢，至少要有点尊严，别大声哀嚎
找茬者要么是外强中干的不中用家伙，要么就是测试你是否真会搞砸的心理专家
也别让自己卷入口水战，大多数口水战最好不要理睬
6 不该问的问题
问：我到哪可以找到某程序或 X 资源？——难道还有人不会用搜索引擎吗
问：我怎样用 X 做 Y？——这种问题说明提问者不但对 X 完全无知，也对 Y 要解决的问题糊涂
问：如何配置我的 shell 提示？——去 RTFM，然后自己去找出来
问：我可以用 Bass-o-matic 文件转换工具将 AcmeCorp 文档转为 TeX 格式吗？——试试看就知道了。如果你试过，你既知道了答案，就不用浪费我的时间了
问：我的{程序、配置、SQL 语句}不运行了——我起码还要再问你二十个问题，才能找得出你真正的问题。溜了溜了
问：我的Windows电脑出问题了，你能帮忙吗？——能啊，换Linux吧
问：我的程序不运行了，我认为系统工具X有问题——不同凡响的说法需要不同凡响的证据
问：我安装 Linux 或 X 遇到困难，你能帮忙吗？——不能，你的电脑离我太远了
问：我如何才能破解超级用户口令/盗取通道操作员的特权/查看某人的电子邮件？——卑劣的笨蛋
7 蠢问题与好问题
蠢问题：我在哪能找到关于 Foonly Flurbamatic 设备的东西？ 好问题：我用谷歌搜索过“Foonly Flurbamatic 2600”，但没有找到什么有用的，有谁知道在哪能找到这种设备的编程信息？
蠢问题：我不能编译某项目的源代码，它为什么这么破？ 好问题：某项目的源代码不能在某 Linux 6.2 版下编译。我读了常见问题文档，但其中没有与某 Linux 相关的内容。这是编译时的记录：xx，我做错了什么吗？
蠢问题：我的主板有问题，谁能帮我？ 好问题：我在 S2464 主板上试过 X、Y 和 Z，当它们都失败后，又试了 A、B 和 C。注意我试 C 时的奇怪症状，显然某某东西正在做某某事情，这不是期望的行为。通常在 Athlon MP 主板上导致某某事情的原因是什么？有谁知道我还能再试点什么以确定问题？
8 如果你得不到答案
有时只是因为看到问题的人，或者被问到的人的确不知道答案
直接将问题再张贴一次不好，这会被视为毫无意义的骚扰
耐心一点，审视自己的提问方式，寻找其他面向新手的资源
即使软件没花你一分钱，你总不能指望服务支持都是免费的
9 如何更好地回答
- 态度和善一点。问题带来的压力常使人显得无礼或愚蠢，请原谅提问者
- 对初犯者私下回复。 对那些坦诚犯错之人没有必要当众羞辱
- 请说清楚你不确定的地方，一个听起来权威的错误回复比没有还要糟
- 如果帮不了忙，别妨碍。 不要在具体步骤上开玩笑
- 探索性的反问以引出更多的细节。 如果你做得好，提问者可以学到点东西
- 尽管报怨一声“RTFM/STFW”是正当的，指出文档位置/搜索关键词会更好
- 当别人正在用错误的工具或方法时避免权宜之计，应推荐更好的工具，重新组织问题
- 请回答真正的问题，避免说一些提问者已经尝试过的方法
- 帮助你的社区从中学习，当回复一个好问题时不妨向文档维护者发一份补丁
- 展现你的技巧而不是直接端出结果。毕竟“授人以鱼，不如授人以渔”
相关资源
关于个人电脑、Unix 和互联网的基础知识，参阅 Unix 和互联网工作的基本原理
当你发布软件或补丁时，试着按 软件发布实践 操作