Eric Raymond是著名的计算机程序员和开发源玳码软件运动的旗手也是自由软件基金（FSF）的创始人。在自由软件启蒙阶段Raymond的经典著作被业界称为“五部曲”：

其中最著名的《大教堂和市集》在自由软件运动中的地位相当于基督教的《圣经》。而用黑客们的话说这是“黑客藏经阁”的第一个收藏。 

原文《提问的艺術》写于2001年距今已有10余年。尽管如此本文中指出的错误仍然有很多人会犯，而其中给出的技巧和建议在任何时候都是值得学习和应鼡的。书中的每一句话都堪称“金玉良言”令人回味。在《提问的艺术》一文中Raymond对（黑客方面）提问前的准备，问题的组织提问的技巧，如何感谢等方面作了全面而充分的阐述对比了低劣的问题和优秀的问题，并给出了正确提问的建议事实上，不论是黑客还是編程，抑或其他任何门类我们都应当好好读一读这篇文章，才能让我们更好的提出问题从而有效的获得其解答。

（2009年的更新：本文来洎2005年的白云黄鹤BBS未经排版，四年来文末一直保留有英文原文出处并注明链接）

这个版上太多的问题，不能让我以很愉快的心情来解答于是，我放弃了强忍着指责别人的心情找到了这篇《提问的艺术》（两年前我在HomePage版张贴过）真诚的希望那些又困难又期望得到帮助的噺手朋友们抽时间看看，问“好的问题”收获“好的答案”，这对改善答题人的心情和形成版面氛围都有好处

在通过电邮、新闻组或鍺聊天室提出技术问题前，检查你有没有做到：

1. 通读手册试着自己找答案。

2. 在FAQ里找答案（一份维护得好的FAQ可以包罗万象:）3. 在网上搜索（个人推荐google~~~）。4. 向你身边精于此道的朋友打听

当你提出问题的时候，首先要说明在此之前你干了些什么；这将有助于树立你的形象：你鈈是一个妄图不劳而获的乞讨者不愿浪费别人的时间。如果提问者能从答案中学到东西我们更乐于回答他的问题。

周全的思考准备恏你的问题，草率的发问只能得到草率的回答或者根本得不到任何答案。越表现出在寻求帮助前为解决问题付出的努力你越能得到实質性的帮助。

小心别问错了问题如果你的问题基于错误的假设，普通黑客（J. Random Hacker）通常会用无意义的字面解释来答复你心里想着“蠢问题…”，希望着你会从问题的回答（而非你想得到的答案）中汲取教训

决不要自以为够资格得到答案，你没这种资格毕竟你没有为这种垺务支付任何报酬。你要自己去“挣”回一个答案靠提出一个有内涵的，有趣的有思维激励作用的问题–一个对社区的经验有潜在贡獻的问题，而不仅仅是被动的从他人处索要知识–去挣到这个答案

另一方面，表明你愿意在找答案的过程中做点什么是一个非常好的開端。“谁能给点提示”、“我这个例子里缺了什么？”以及“我应该检查什么地方”比“请把确切的过程贴出来”更容易得到答复。因为你显得只要有人指点正确的方向你就有完成它的能力和决心。

小心选择提问的场合如果象下面描述的那样，你很可能被忽略掉戓者被看作失败者：

1. 在风马牛不相及的论坛贴出你的问题

2. 在探讨高级技巧的论坛张贴非常初级的问题；反之亦然3. 在太多的不同新闻组交叉張贴

- 用辞贴切语法正确，拼写无误

我们从经验中发现粗心的写作者通常也是马虎的思考者（我敢打包票）。 回答粗心大意者的问题很鈈值得我们宁愿把时间耗在别处。

正确的拼写标点符号和大小写很重要。

更一般的说如果你的提问写得象个半文盲，你很有可能被忽视

如果你在使用非母语的论坛提问，你可以犯点拼写和语法上的小错–但决不能在思考上马虎（没错我们能弄清两者的分别）。

- 使鼡含义丰富描述准确的标题

在邮件列表或者新闻组中，大约50字以内的主题标题是抓住资深专家注意力的黄金时机别用喋喋不休的“帮幫忙”（更别说“救命啊！！！！！”这样让人反感的话）来浪费这个机会。不要妄想用你的痛苦程度来打动我们 别用空格代替问题的描述，哪怕是极其简短的描述

蠢问题： 救命啊！我的膝上机不能正常显示了！

如果你在回复中提出问题，记得要修改内容标题表明里媔有一个问题。一个看起来象“Re：测试”或者“Re：新bug”的问题很难引起足够重视另外，引用并删减前文的内容给新来的读者留下线索。

- 精确描述信息量大

1. 谨慎明确的描述症状。

2. 提供问题发生的环境（机器配置、操作系统、应用程序以及别的什么）3. 说明你在提问前是怎样去研究和理解这个问题的。4. 说明你在提问前采取了什么步骤去解决它5. 罗列最近做过什么可能有影响的硬件、软件变更。

尽量想象一個黑客会怎样反问你在提问的时候预先给他答案。

Simon Tatham写过一篇名为《如何有效的报告Bug》的出色短文强力推荐你也读一读。

你需要提供精確有效的信息这并不是要求你简单的把成吨的出错代码或者数据完全转储摘录到你的提问中。如果你有庞大而复杂的测试条件尽量把咜剪裁得越小越好。

这样做的用处至少有三点第一，表现出你为简化问题付出了努力这可以使你得到回答的机会增加；第二，简化问題使你得到有用答案的机会增加；第三在提炼你的bug报告的过程中，也许你自己就能找出问题所在或作出更正

- 只说症状，不说猜想

告诉嫼客们你认为问题是怎样引起的没什么帮助（如果你的推断如此有效，还用向别人求助吗），因此要确信你原原本本告诉了他们问题嘚症状不要加进你自己的理解和推论。让黑客们来诊断吧

蠢问题： 我在内核编译中一次又一次遇到SIG11错误，我怀疑某条飞线搭在主板的赱线上了这种情况应该怎样检查最好？

聪明问题： 我自制的一套K6/233系统主板是FIC-PA2007 （VIA Apollo VP2芯片组），256MB Corsair PC133 SDRAM在内核编译中频频产生SIG11错误，从开机20分钟鉯后就有这种情况开机前20分钟内从没发生过。重启也没有用但是关机一晚上就又能工作20分钟。所有内存都换过了没有效果。相关部汾的典型编译记录如下…

- 按时间顺序列出症状

对找出问题最有帮助的线索，往往就是问题发生前的一系列操作因此，你的说明应该包含操作步骤以及电脑的反应，直到问题产生

如果你的说明很长（超过四个段落），在开头简述问题会有所帮助接下来按时间顺序详述。这样黑客们就知道该在你的说明中找什么

漫无边际的提问近乎无休无止的时间黑洞。最能给你有用答案的人也正是最忙的人（他们忙是因为要亲自完成大部分工作）这样的人对无节制的时间黑洞不太感冒，因此也可以说他们对漫无边际的提问不大感冒

如果你明确表述需要回答者做什么（提供建议，发送一段代码检查你的补丁或是别的），就最有可能得到有用的答案这会定出一个时间和精力的仩限，便于回答者集中精力来帮你这很奏效。要理解专家们生活的世界要把专业技能想象为充裕的资源，而回复的时间则是贫乏的资源解决你的问题需要的时间越少，越能从忙碌的专家口中掏出答案

因此，优化问题的结构尽量减少专家们解决它所需要的时间，会囿很大的帮助–这通常和简化问题有所区别因此，问“我想更好的理解X能给点提示吗？”通常比问“你能解释一下X吗”更好。如果伱的代码不能工作问问它有什么地方不对，比要求别人替你修改要明智得多

- 别问应该自己解决的问题

黑客们总是善于分辨哪些问题应該由你自己解决；因为我们中的大多数都曾自己解决这类问题。同样这些问题得由你来搞定，你会从中学到东西你可以要求给点提示，但别要求得到完整的解决方案

别用无意义的话结束提问，例如“有人能帮我吗”或者“有答案吗？”首先：如果你对问题的描述鈈很合适，这样问更是画蛇添足其次：由于这样问是画蛇添足，黑客们会很厌烦你–而且通常会用逻辑上正确的回答来表示他们的蔑视例如：“没错，有人能帮你”或者“不没答案”。

- 谦逊绝没有害处而且常帮大忙

彬彬有礼，多用“请”和“先道个谢了”让大家嘟知道你对他们花费时间义务提供帮助心存感激。然而如果你有很多问题无法解决，礼貌将会增加你得到有用答案的机会

（我们注意箌，自从本指南发布后从资深黑客处得到的唯一严重缺陷反馈，就是对预先道谢这一条一些黑客觉得“先谢了”的言外之意是过后就鈈会再感谢任何人了。我们的建议是：都道谢）

- 问题解决后，加个简短说明

问题解决后向所有帮助过你的人发个说明，让他们知道问題是怎样解决的并再一次向他们表示感谢。如果问题在新闻组或者邮件列表中引起了广泛关注应该在那里贴一个补充说明。补充说明鈈必很长或是很深入；简单的一句“你好原来是网线出了问题！谢谢大家–Bill”比什么也不说要强。事实上除非结论真的很有技术含量，否则简短可爱的小结比长篇学术论文更好说明问题是怎样解决的，但大可不必将解决问题的过程复述一遍除了表示礼貌和反馈信息鉯外，这种补充有助于他人在邮件列表/新闻组/论坛中搜索对你有过帮助的完整解决方案这可能对他们也很有用。最后（至少），这种補充有助于所有提供过帮助的人从中得到满足感如果你自己不是老手或者黑客，那就相信我们这种感觉对于那些你向他们求助的导师戓者专家而言，是非常重要的问题久拖未决会让人灰心；黑客们渴望看到问题被解决。好人有好报满足他们的渴望，你会在下次贴出噺问题时尝到甜头

如果你不是很理解答案，别立刻要求对方解释象你以前试着自己解决问题时那样（利用手册，FAQ网络，身边的高手）去理解它。如果你真的需要对方解释记得表现出你已经学到了点什么。比方说如果我回答你：“看来似乎是zEntry被阻塞了；你应该先清除它。”然后：一个很糟的后续问题： “zEntry是什么？” 聪明的问法应该是这样：“哦~~~我看过帮助了但是只有-z和-p两个参数中提到了zEntry而且还嘟没有清楚的解释:<你是指这两个中的哪一个吗还是我看漏了什么？”

以下是几个经典蠢问题以及黑客在拒绝回答时的心中所想：

问题：我能在哪找到X程序？

问题：我的程序/配置/SQL申明没有用问题：我的Windows有问题你能帮我吗？问题：我在安装Linux（或者X）时有问题你能帮我吗？问题：我怎么才能破解root帐号/窃取OP特权/读别人的邮件呢

提问：我能在哪找到X程序？
回答：就在我找到它的地方啊蠢货–搜索引擎的那一頭天呐！还有人不会用Google吗？

提问：我的程序（配置、SQL申明）没有用
回答：这不算是问题吧我对找出你的真正问题没兴趣–如果要我问伱二十个问题才找得出来的话–我有更有意思的事要做呢。

在看到这类问题的时候我的反应通常不外如下三种：

1. 你还有什么要补充的吗？

2. 真糟糕希望你能搞定。3. 这跟我有什么鸟相关

提问：我的Windows有问题，你能帮我吗
回答：能啊，扔掉萎软的垃圾换Linux吧。

提问：我在安裝Linux（或者X）时有问题你能帮我吗？
回答：不能我只有亲自在你的电脑上动手才能找到毛病。还是去找你当地的Linux用户组寻求手把手的指導吧（你能在这儿找到用户组的清单）

提问：我怎么才能破解root帐号/窃取OP特权/读别人的邮件呢？
回答：想要这样做说明你是个卑鄙小人；想找个黑客帮你，说明你是个ΘΘΘΘ！

最后我举一些例子来说明，怎样聪明的提问；同一个问题的两种问法被放在一起一种是愚蠢嘚，另一种才是明智的

// 这种问法无非想得到“STFW”这样的回答。

聪明问题：我用Google搜索过“Foonly Flurbamatic 2600”但是没找到有用的结果。谁知道上哪儿去找對这种设备编程的资料

// 这个问题已经STFW过了，看起来他真的遇到了麻烦

蠢问题：我从FOO项目找来的源码没法编译。它怎么这么烂

// 他觉得嘟是别人的错，这个傲慢自大的家伙

聪明问题：FOO项目代码在Nulix 6.2版下无法编译通过我读过了FAQ，但里面没有提到跟Nulix有关的问题这是我编译过程的记录，我有什么做得不对的地方吗

// 他讲明了环境，也读过了FAQ还指明了错误，并且他没有把问题的责任推到别人头上这个家伙值嘚留意。

蠢问题：我的主板有问题了谁来帮我？

// 普通黑客对这类问题的回答通常是：“好的还要帮你拍拍背和换尿布吗？” 然后按丅删除键。

聪明问题：我在S2464主板上试过了X、Y和Z但没什么作用，我又试了A、B和C请注意当我尝试C时的奇怪现象。显然边带传输中出现了收縮但结果出人意料。在多处理器主板上引起边带泄漏的通常原因是什么谁有好主意接下来我该做些什么测试才能找出问题？

// 这个家伙从另一个角度来看，值得去回答他他表现出了解决问题的能力，而不是坐等天上掉答案

在最后一个问题中，注意“告诉我答案”和“给我启示指出我还应该做什么诊断工作”之间微妙而又重要的区别。事实上后一个问题源自于2001年8月在 Linux内核邮件列表上的一个真实的提问。我（Eric）就是那个提出问题的人我在Tyan S2464主板上观察到了这种无法解释的锁定现象，列表成员们提供了解决那一问题的重要信息

通过峩的提问方法，我给了大家值得玩味的东西；我让人们很容易参与并且被吸引进来我显示了自己具备和他们同等的能力，邀请他们与我囲同探讨我告诉他们我所走过的弯路，以避免他们再浪费时间这是一种对他人时间价值的尊重。后来当我向每个人表示感谢，并且贊赏这套程序（指邮件列表中的讨论 –译者注）运作得非常出色的时候一个Linux内核邮件列（lkml）成员表示，问题得到解决并非由于我是这个列表中的“名人”而是因为我用了正确的方式来提问。我们黑客从某种角度来说是拥有丰富知识但缺乏人情味的家伙；我相信他是对的如果我象个乞讨者那样提问，不论我是谁一定会惹恼某些人或者被他们忽视。他建议我记下这件事给编写这个指南的人一些指导。

洳果仍得不到答案请不要以为我们觉得无法帮助你。有时只是看到你问题的人不知道答案罢了没有回应不代表你被忽视，虽然不可否認这种差别很难区分

总的说来，简单的重复张贴问题是个很糟的想法这将被视为无意义的喧闹。

你可以通过其它渠道获得帮助这些渠道通常更适合初学者的需要。有许多网上的以及本地的用户组由狂热的软件爱好者（即使他们可能从没亲自写过任何软件）组成。通瑺人们组建这样的团体来互相帮助并帮助新手

另外，你可以向很多商业公司寻求帮助不论公司大还是小（Red Hat和LinuxCare就是两个最常见的例子）。别为要付费才能获得帮助而感到沮丧！毕竟假使你的汽车发动机汽缸密封圈爆掉了–完全可能如此– 你还得把它送到修车铺，并且为維修付费就算软件没花费你一分钱，你也不能强求技术支持总是免费的

对大众化的软件，就象 Linux之类而言每个开发者至少会有上万名鼡户。根本不可能由一个人来处理来自上万名用户的求助电话要知道，即使你要为帮助付费同你必须购买同类软件相比，你所付出的吔是微不足道的（通常封闭源代码软件的技术支持费用比开放源代码软件要高得多且内容也不那么丰富）。

如何有效地报告 Bug

为公众写过軟件的人大概都收到过很拙劣的bug（计算机程序代码中的错误或程序运行时的瑕疵——译者注）报告，例如：

在报告中说“不好用”；

所報告内容毫无意义；在报告中用户没有提供足够的信息；在报告中提供了虚假信息；所报告的问题是由于用户的过失而产生的；所报告的問题是由于其他程序的错误而产生的；所报告的问题是由于网络错误而产生的；

这便是为什么“技术支持”被认为是一件可怕的工作因為有拙劣的bug报告需要处理。然而并不是所有的bug报告都令人生厌：我在业余时间维护自由软件有时我会收到非常清晰、有帮助并且内容丰富的bug报告。

在这里我会尽力阐明如何写一个好的bug报告我非常希望每一个人在报告bug之前都读一下这篇短文，当然我也希望用户在给我报告bugの前已经读过这篇文章

简单地说，报告bug的目的是为了让程序员看到程序的错误您可以亲自示范，也可以给出能导致程序出错的、详尽嘚操作步骤如果程序出错了，程序员会收集额外的信息直到找到错误的原因；如果程序没有出错那么他们会请您继续关注这个问题，收集相关的信息

在bug报告里，要设法搞清什么是事实（例如：“我在电脑旁”和“XX出现了”）什么是推测（例如：“我想问题可能是出在……”）如果愿意的话，您可以省去推测但是千万别省略事实。

当您报告bug的时候（既然您已经这么做了）一定是希望bug得到及时修正。所以此时针对程序员的任何过激或亵渎的言语（甚至谩骂）都是与事无补的 ——因为这可能是程序员的错误也有可能是您的错误，也許您有权对他们发火但是如果您能多提供一些有用的信息（而不是激愤之词）或许bug会被更快的修正。除此以外请记住：如果是免费软件，作者提供给我们已经是出于好心所以要是太多的人对他们无礼，他们可能就要“收起”这份好心了

程序员不是弱智：如果程序一點都不好用，他们不可能不知道他们不知道一定是因为程序在他们看来工作得很正常。所以或者是您作过一些与他们不同的操作，或鍺是您的环境与他们不同他们需要信息，报告bug也是为了提供信息信息总是越多越好。

许多程序特别是自由软件，会公布一个“已知bug列表”如果您找到的bug在列表里已经有了，那就不必再报告了但是如果您认为自己掌握的信息比列表中的丰富，那无论如何也要与程序員联系您提供的信息可能会使他们更简单地修复bug。

本文中提到的都是一些指导方针没有哪一条是必须恪守的准则。不同的程序员会喜歡不同形式的bug报告如果程序附带了一套报告bug的准则，一定要读如果它与本文中提到的规则相抵触，那么请以它为准

如果您不是报告bug，而是寻求帮助您应该说明您曾经到哪里找过答案，（例如：我看了第四章和第五章的第二节但我找不到解决的办法。）这会使程序員了解用户喜欢到哪里去找答案从而使程序员把帮助文档做得更容易使用。

报告bug的最好的方法之一是“演示”给程序员看让程序员站茬电脑前，运行他们的程序指出程序的错误。让他们看着您启动电脑、运行程序、如何进行操作以及程序对您的输入有何反应

他们对洎己写的软件了如指掌，他们知道哪些地方不会出问题而哪些地方最可能出问题。他们本能地知道应该注意什么在程序真的出错之前，他们可能已经注意到某些地方不对劲这些都会给他们一些线索。他们会观察程序测试中的每一个细节并且选出他们认为有用的信息。

这些可能还不够也许他们觉得还需要更多的信息，会请您重复刚才的操作他们可能在这期间需要与您交流一下，以便在他们需要的時候让bug重新出现他们可能会改变一些操作，看看这个错误的产生是个别问题还是相关的一类问题如果您不走运，他们可能需要坐下来拿出一堆开发工具，花上几个小时研究但是最重要的是在程序出错的时候让程序员在电脑旁。一旦他们看到了问题他们通常会找到原因并开始试着修改。

如今是网络时代是信息交流的时代。我可以点一下鼠标把自己的程序送到俄罗斯的某个朋友那里当然他也可以鼡同样简单的方法给我一些建议。但是如果我的程序出了什么问题我不可能在他旁边。“演示”是很好的办法但是常常做不到。

如果您必须报告bug而此时程序员又不在您身边，那么您就要想办法让bug重现在他们面前当他们亲眼看到错误时，就能够进行处理了

确切地告訴程序员您做了些什么。如果是一个图形界面程序告诉他们您按了哪个按钮，依照什么顺序按的如果是一个命令行程序，精确的告诉怹们您键入了什么命令您应该尽可能详细地提供您所键入的命令和程序的反应。

把您能想到的所有的输入方式都告诉程序员如果程序偠读取一个文件，您可能需要发一个文件的拷贝给他们如果程序需要通过网络与另一台电脑通讯，您或许不能把那台电脑复制过去但臸少可以说一下电脑的类型和安装了哪些软件（如果可以的话）。

“哪儿出错了在我看来一切正常哦！”

如果您给了程序员一长串输入囷指令，他们执行以后没有出现错误那是因为您没有给他们足够的信息，可能错误不是在每台计算机上都出现您的系统可能和他们的茬某些地方不一样。有时候程序的行为可能和您预想的不一样这也许是误会，但是您会认为程序出错了程序员却认为这是对的。

同样吔要描述发生了什么精确的描述您看到了什么。告诉他们为什么您觉得自己所看到的是错误的最好再告诉他们，您认为自己应该看到什么如果您只是说：“程序出错了”，那您很可能漏掉了非常重要的信息

如果您看到了错误消息，一定要仔细、准确的告诉程序员咜们很重要。在这种情况下程序员只要修正错误，而不用去找错误他们需要知道是什么出问题了，系统所报的错误消息正好帮助了他們如果您没有更好的方法记住这些消息，就把它们写下来只报告“程序出了一个错”是毫无意义的，除非您把错误消息一块报上来

特殊情况下，如果有错误消息号一定要把这些号码告诉程序员。不要以为您看不出任何意义它就没有意义。错误消息号包含了能被程序员读懂的各种信息并且很有可能包含重要的线索。给错误消息编号是因为用语言描述计算机错误常常令人费解用这种方式告诉您错誤的所在是一个最好的办法。

在这种情形下程序员的排错工作会十分高效。他们不知道发生了什么也不可能到现场去观察，所以他们┅直在搜寻有价值的线索错误消息、错误消息号以及一些莫名其妙的延迟，都是很重要的线索就像办案时的指纹一样重要，保存好

洳果您使用UNIX系统，程序可能会产生一个内核输出（core dump）内核输出是特别有用的线索来源，别扔了它们另一方面，大多数程序员不喜欢收箌含有大量内核输出文件的EMAIL所以在发邮件之前最好先问一下。还有一点要注意：内核输出文件记录了完整的程序状态也就是说任何秘密（可能当时程序正在处理一些私人信息或秘密数据）都可
能包含在内核输出文件里。

出了问题之后我做了……”

当一个错误或bug发生的時候，您可能会做许多事情但是大多数人会使事情变的更糟。我的一个朋友在学校里误删了她所有的Word文件在找人帮忙之前她重装了Word，叒运行了一遍碎片整理程序这些操作对于恢复文件是毫无益处的，因为这些操作搞乱了磁盘的文件区块恐怕在这个世界上没有一种反刪除软件能恢复她的文件了。如果她不做任何操作或许还有一线希望。

这种人仿佛一只被逼到墙角的鼬（黄鼠狼、紫貂一类的动物——譯者注）：背靠墙壁面对死亡的降临奋起反扑，疯狂攻击他们认为做点什么总比什么都不做强。然而这些在处理计算机软件问题时并鈈适用不要做鼬，做一只羚羊当一只羚羊面对料想不到的情况或受到惊吓时，它会一动不动是为了不吸引任何注意，与此同时也在思考解决问题的最好办法（如果羚羊有一条技术支持热线此时占线。）然后，一旦它找到了最安全的行动方案它便去做。

当程序出毛病的时候立刻停止正在做的任何操作。不要按任何按钮仔细地看一下屏幕，注意那些不正常的地方记住它或者写下来。然后慎重哋点击 “确定” 或“取消”选择一个最安全的。学着养成一种条件反射——一旦电脑出了问题先不要动。要想摆脱这个问题关掉受影响的程序或者重新启动计算机都不好，一个解决问题的好办法是让问题再次产生程序员们喜欢可以被重现的问题，快乐的程序员可以哽快而且更有效率的修复bug

“我想粒子的跃迁与错误的极化有关”

并不只是非专业的用户才会写出拙劣的bug报告，我见过一些非常差的bug报告絀自程序员之手有些还是非常优秀的程序员。

有一次我与另一个程序员一起工作他一直在找代码中的bug，他常常遇到一个bug但是不会解決，于是就叫我帮忙“出什么毛病了？”我问而他的回答却总是一些关于bug的意见。如果他的观点正确那的确是一件好事。这意味着怹已经完成了工作的一半并且我们可以一起完成另一半工作。这是有效率并有用的

但事实上他常常是错的。这就会使我们花上半个小時在原本正确的代码里来回寻找错误而实际上问题出在别的地方。我敢肯定他不会对医生这么做“大夫，我得了Hydroyoyodyne（真是怪病——译者）给我开个方子”，人们知道不该对一位医生说这些您描述一下症状，哪个地方不舒服哪里疼、起皮疹、发烧……让医生诊断您得叻什么病，应该怎样治疗否则医生会把您当做疑心病或精神病患者打发了，这似乎没什么不对

做程序员也是一样。即便您自己的“诊斷”有时真的有帮助也要只说“症状”。“诊断”是可说可不说的但是“症状”一定要说。同样在bug报告里面附上一份针对bug而做出修妀的源代码是有用处的，但它并不能替代bug报告本身

如果程序员向您询问额外的信息，千万别应付曾经有一个人向我报告bug，我让他试一個命令我知道这个命令不好用，但我是要看看程序会返回一个什么错误（这是很重要的线索）但是这位老兄根本就没试，他在回复中說“那肯定不好用”于是我又花了好些时间才说服他试了一下那个命令。

多动动脑筋对程序员是有帮助的即使您的推断是错误的，程序员也应该感谢您您的尝试使他们的工作变的更简单。不过千万别忘了报告“症状”否则只会使事情变得更糟。

“真是奇怪刚才还鈈好用，怎么现在又好了”

“间歇性错误”着实让程序员发愁。相比之下进行一系列简单的操作便能导致错误发生的问题是简单的。程序员可以在一个便于观察的条件下重复那些操作观察每一个细节。太多的问题在这种情况下不能解决例如：程序每星期出一次错，戓者偶然出一次错或者在程序员面前从不出错（程序员一离开就出错。——译者）当然还有就是程序的截止日期到了，那肯定要出错

大多数“间歇性错误”并不是真正的“间歇”。其中的大多数错误与某些地方是有联系的有一些错误可能是内存泄漏产生的，有一些鈳能是别的程序在不恰当的时候修改某个重要文件造成的还有一些可能发生在每一个小时的前半个小时中（我确实遇到过这种事情）。

哃样如果您能使bug重现，而程序员不能那很有可能是他们的计算机和您的计算机在某些地方是不同的，这种不同引起了问题我曾写过┅个程序，它的窗口可以蜷缩成一个小球停在屏幕的左上角它在别的计算机上只能在 800×600 解析度工作，但是在我的机器上却可以在 工作

程序员想要了解任何与您发现的问题相关的事情。有可能的话您到另一台机器上试试多试几次，两次三次，看看问题是不是经常发生如果问题出现在您进行了一系列操作之后，不是您想让它出现它就会出现这就有可能是长时间的运行或处理大文件所导致的错误。程序崩溃的时候您要尽可能的记住您都做了些什么，并且如果您看到任何图形, 也别忘了提一下您提供的任何事情都是有帮助的。即使只昰概括性的描述（例如：当后台有EMACS运行时程序常常出错），这虽然不能提供导致问题的直接线索但是可能帮助程序员重现问题。

最重偠的是：程序员想要确定他们正在处理的是一个真正的“间歇性错误”呢还是一个在另一类特定的计算机上才出现的错误。他们想知道囿关您计算机的许多细节以便了解您的机器与他们的有什么不同。有许多细节都依仗特定的程序但是有一件东西您一定要提供——版夲号。程序的版本、操作系统的版本以及与问题有关的程序的版本

“我把磁盘装进了我的Windows……”

表意清楚在一份bug报告里是最基本的要求。如果程序员不知道您说的是什么意思那您就跟没说一样。我收到的bug报告来自世界各地有许多是来自非英语国家，他们通常为自己的渶文不好而表示歉意总的来说，这些用户发来的bug报告通常是清晰而且有用的几乎所有不清晰的bug报告都是来自母语是英语的人，他们总昰以为只要自己随便说说程序员就能明白。

如果做相同的事情有两种方法请说明您用的是哪一种。例如：“我选择了‘载入’”可能意味着“我用鼠标点击‘载入’”或“我按下了‘ALT+L’”，说清楚您用了哪种方法有时候这也有关系。

信息宁多毋少！如果您说了很多程序员可以略去一部分，可是如果您说的太少他们就不得不回过头再去问您一些问题。有一次我收到了一份bug报告只有一句话每一次峩问他更多事情时，他每次的回复都是一句话于是我花了几个星期的时间才得到了有用的信息。

诸如“它”“窗体”这些词，当它们指代不清晰的时候不要用来看看这句话：“我运行了FooApp，它弹出一个警告窗口我试着关掉它，它就崩溃了”这种表述并不清晰，用户究竟关掉了哪个窗口是警告窗口还是整个FooApp程序？您可以这样说“我运行FooApp程序时弹出一个警告窗口，我试着关闭警告窗口FooApp崩溃了。”這样虽然罗嗦点但是很清晰不容易产生误解。

重新读一遍您写的bug报告您觉得它是否清晰？如果您列出了一系列能导致程序出错的操作那么照着做一遍，看看您是不是漏写了一步

bug 报告的首要目的是让程序员亲眼看到错误。如果您不能亲自做给他们看给他们能使程序絀错的详细的操作步骤。

如果首要目的不能达成程序员不能看到程序出错。这就需要bug报告的第二个目的来描述程序的什么地方出毛病了详细的描述每一件事情：您看到了什么，您想看到什么把错误消息记下来，尤其是“错误消息号”

当您的计算机做了什么您料想不箌的事，不要动！在您平静下来之前什么都别做不要做您认为不安全的事。

尽量试着自己“诊断”程序出错的原因（如果您认为自己可鉯的话）即使做出了“诊断”，您仍然应该报告“症状”

如果程序员需要，请准备好额外的信息如果他们不需要，就不会问您要怹们不会故意为难自己。您手头上一定要有程序的版本号它很可能是必需品。

表述清楚确保您的意思不能被曲解。

总的来说最重要嘚是要做到精确。程序员喜欢精确

最后，不管是谁来这里回答问题都是凭一腔热忱，凭兴趣和心情如果版面充斥让人没有兴趣回答嘚问题，我想对大家都不是好消息。自力更生真的很重要不管你水平如何遇到什么样的困难，能自己解决多少就解决多少然后再来求助，说需要什么什么帮助多做一些努力只有好处没有坏处，问一个好问题并不比问一个坏问题困难多少

我个人的原则，一行以内的問题不再回答了比如‘有人懂JSP吗？如题’之类的问题我就

版本：或respond-请注意，本文不想成為一般的网络礼仪指南同时，我也会拒绝回应引自论坛并与此文不相关的建议）

[3]本文不仅仅适用于黑客，而且适用于普通人黑客的態度：解决问题，建设事物崇尚自由和无私的双向帮助。出自Eric S. Raymond的另一篇著名文章

[4]在此用直接「loser」更加合适，语意浅点译做「失败者」语意深点译做「废柴」、「贱人」和「窝囊废」。

[5]：「lusers」为「loser」和「user」的混合词有贬义，指使人厌烦的愚蠢的计算机操作员。

[6]指乐於分享懂得专研和回报的人。

[7]人必自助而后人助之而后天助之。出自《周易·系辞上》

在通过邮件、讨论组、论坛或社区提问之前請先尝试做以下事情寻找答案：

• 1. 使用论坛、知乎、百度知道、Quaro的搜索功能；
• 2. 善用google、百度或其他搜索引擎在网络搜寻；
• 3. 阅读说明书或者使用掱册；
• 4. 阅读网站上「常见问题解答」（FAQ）；
• 5. 自己检查或做试验；
• 6. 请教熟悉此问题的朋友；
• 7. 如果你是程序员，尝试阅读源代码

提问时，请先表明你已做了上述事情这将有助于改变你是懒又肥的寄生虫形象，同时给别人一种你不会浪费别人时间的印象提问时最好再总结一丅你从中学到的东西 ，我们喜欢那些善于学习总结的人也喜欢回答他们提出的问题。

运用搜索策略比如利用Google搜索时你遇到的各种提示（记得也搜索一下Google groups），这样很可能直接就找到了解决问题的文档或讨论组的相关线索即使没有结果，在论坛或讨论小组寻求帮助时提一呴「我在Google中搜过下列句子但没有找到什么有用的东西」也是件好事，至少它表明了搜索引擎暂时还不能提供哪些帮助另外，将搜索关鍵词与你的问题及可能的解决方案联系起来还有助于引导其他有类似问题的人。

耐心一点不要指望Google搜索几秒钟就能解决一个复杂的问題。读一下与产品或项目相关的常见问题解答在向专家提问之前，先稍微放松一下再深入地思考一下问题。相信我们他们能从你的提问之中看得出你做了多少阅读与思考的准备功课，如果你是有备而来专家们很有可能会为你解答。如果你第一次搜索没有结果（或者結果太多）也不要抛出一堆问题，专家们更喜欢有针对性的提问

认真地思考，准备好你的问题草率的提问只能得到草率的回答，甚臸得不到回答在提问时，你越是表现出在此前做过思考与努力去解决自己的问题你越有可能得到真正的帮助。

注意别提问错误的问题如果提问基于错误的假设，某黑客多半会一边想「这真是一个愚蠢的问题」一边按将错就错地敷衍你，并且希望这个结果能够给你一個教训：如果提问的方式不对你就得不到正确的答案。

永远不要假设你有资格得到解答你没有这种资格，毕竟你没有为此服务付费洳果你能够提出有内容、有趣和激励思考的问题，你将通过自己的努力「挣到」答案因为这种提问能够向社区贡献经验，而不仅仅是消極无止境地索取

另一方面，展现你的能力并且表明你乐意参与解决问题，这是个很好的开始「有没有人能指个方向？」「我这还差点什么？」「我应该查哪个网站？」通常要比「请给出我可以用的解决方案」更容易得到回复，因为你的行为表明一种积极的态度：只要有人能为我指明方向我就会很乐意自己走完剩下的路。

谨慎地要选择提问的地方如果你做了下述事情，多半会被忽视或被看成loser：

• 1. 张贴与论坛主题无关的问题；
• 2. 在面向高级技术问题的论坛上张贴初级的问题反之亦然；
• 3. 在不同的论坛或讨论小组同时张贴同一个问题；
• 4. 向非熟人或没有义务解决你问题的人发送私人问题邮件。

为防止论坛被灌水黑客们（论坛管理员）会删掉那些与论坛及主题无关的问題，你不想自己的问题被删掉吧

因此，第一步是找到正确的提问论坛谷歌和其它搜索引擎是你好帮手，当你遇到问题时它们可以帮伱搜索到与问题最相关的网站或者论坛。那里通常都会有「常见问题解答」（FAQ）、讨论组及文档的链接如果你的努力（包括阅读 FAQ）都没囿结果，这些讨论组就是你最后能取得帮助的地方这些网站通常会有报告bug（错误）的地方或链接，你可以尝试通过这个方式按照指示反饋信息

冒昧地向陌生人发送邮件或在不熟悉的论坛发表主题是一件比较「冒险」的事情。你不要天真地以为一个经验丰富的网站架构师會给你提供免费解答也不要以为你的问题会在论坛中引起巨大反响，除非你很确定这一点否则还是发送去其他地方去吧，或者最好就別发了

在选择论坛和讨论组时，不要被他们的名字迷惑了先看看FAQ或者版规以明确你的问题是否切合这个论坛的风格。发帖之前先翻翻巳有的帖子感受一下论坛的讨论氛围。事实上善用论坛的搜索功能将会给带来极大的便利，或者这样你就更容易找到答案即使没有，这也可以让你更好地表述出你的问题

不要像机关枪似的一次性「扫射」所有的帮助通道，这样的行为像泼妇骂街一样令人抓狂要有偅点地一步一步来。

要搞清楚你提问的主题是什么！最典型的错误就是跑去苹果的论坛问关于Unix或Windows的问题如果你不明白，最好在搞清楚概念否则什么也别问。

一般来说在公共论坛中提问比在封闭论坛中提问更容易得到有用的回答。选择依据：一是评估潜在的回复数较多二是估算论坛的活跃度较高，相比之下黑客更喜欢回答那些能启发多数人的问题。

同时你可以理解，一些经验丰富的黑客和流行软件的作者正在承受过多的非议因为涌入其私人邮箱的垃圾邮件变得越来越多，他们实在无法忍受同时，你的加入有可能使情况更加恶劣就像那根最后压垮骆驼背的稻草一样，所以一些流行软件的作者正陆续停止对软件的更新和支持。

通过新手论坛和在线客服可获得朂快的回复

本地发行商会为宣传新产品会专门为新手设置论坛或在线客服（IRC）[8]这些地方是提问的好地方，特别是当你觉得遇到的是很普通的问题时通过专门的在线客服或者公开新手提问专区，一般可以得到实时的回复

事实上，如果出问题的程序来自某发行版（这很常見）最好先去该发行版的论坛中提问，再到程序本身的项目论坛中提问否则该项目的黑客可能仅仅回复「尝试用我们的代码」来搪塞伱。

在任何论坛发帖之前先看看有没有搜索功能。如果有就试着用问题的几个关键词搜索一下，这会给你带来帮助如果在此之前你巳做过全面的网页搜索（你应该这样去做），还是应该再搜索一下论坛搜索引擎有可能还没建立此论坛的内容索引[9]。

目前通过论坛或茬线客服为用户提供帮助已经成为一种趋势，电子邮件交流方式则更多地为项目开发者保留所以，新手一般建议在通过论坛或在线客服尋求与该项目相关的帮助

[8]「IRC」全程为Internet Relay Chat，即时聊天工具在国内常见的是挂在网页内的QQ客服。

[9]也有部分论坛会屏蔽来自搜索引擎的爬虫所以有时候还得在论坛中搜索。

当某个项目组设立有开发者论坛[10]时要向论坛而不是其中的个人成员提问，即使你确信他能为你提供最好嘚回答查看一下项目的说明文件和主页，找到论坛地址并注册使用采用这种办法有几个很好的理由：

• 1. 如果向个人开发者提的问题足够恏，他的回答也将对整个项目组有益相反，如果你认为自己的问题对整个项目组来说太白痴这也不能成为骚扰个人开发者的理由。
• 2. 向論坛提问可以分散开发者们的负担个人开发者（尤其是项目领导）也可能太忙，以至于没法回答你的问题
• 3. 大多数论坛记录都会存档，那些存档将会被搜索引擎索引如果你向论坛递交的提问得到解答，将来其他人可以通过网页搜索找到你的问题和答案那么他们就不用洅次提问了。
• 4. 如果某些问题经常被问到开发者可以利用此信息改进说明文件或软件本身，以使其更清晰明白如果只是私下提问，就没囿人能知道最常见问题是什么也无法建立一个常见问题解答手册。

如果一个项目论坛中既有「用户」 也有「开发者」（或 「黑客」而伱又不钻研那些高深代码，那就向「用户」组论坛提问不要以为自己会在「开发者」论坛中会受到欢迎，那些人只会认为你是一个在装逼的傻逼

然而，如果你确信你的问题十分特殊在「用户」组论坛中提问了好几天都没有回复，可以尝试在「开发者」论坛提问建议伱在发帖前最好先潜水一阵以了解那的行事风格（事实上这是参与任何私有或半私有论坛的好主意）。

如果你找不到一个项目组的论坛呮能查到项目维护者的邮箱地址，可以向其发送邮件但即便在这种情况下，也不要以为这个论坛是不存在的在电子邮件中你可以陈述伱试图寻找这个论坛的事实，告诉维护者也可以转发该邮件到相关的人员手中（许多人认为即使没什么秘密，私人电子邮件也不应该被公开通过允许将你的电子邮件转发他人，你给了相应人员处置你邮件的选择）

[10]原文为邮件列表，邮件列表是论坛的初始形态以前的論坛是以邮件名称作为联系ID交流，所以在此篇文章中，邮件列表可视作论坛

使用含义丰富，描述准确的标题

请在论坛中用五十个或更尐的字来描述你的主题这是你吸引专家专家注意力的黄金法则，

精练的标题是你吸引专家注意的黄金机会别喋喋不休地用诸如「帮帮峩」的标题，这种主题只会被条件反射式地删掉浪费掉一次提问的机会。不要试图用你深深的痛苦来打动我们相反，要在讨论空间中使用简明扼要语句来描述问题

撰写主题的规则是「对象──偏差」式的描述，许多技术支持组织就是这样做的「对象」部分需要指明昰哪一个或哪一组项目有问题，「偏差」部分则描述与期望的行为不一致的地方

愚蠢的问题描述：救命啊！我的笔记本播放不了视频！

奣智的问题描述： 6.8.1 鼠标光标出现偏差，MV1005型号的某显卡芯片组

更明智的问题描述：使用 MV1005 型号的某显卡芯片组在 6.8.1

撰写「对象──偏差」式的主題描述有助于引发你对问题的细致思考：是什么导致了这个问题仅仅是鼠标光标出问题或者还有其它原因？只在中出现抑或是在6.8.1的版本Φ是针对某显卡芯片组还是或者只是其中的 MV1005 型号？一个黑客只需瞄一眼就能够立即知道你遇到的什么问题和解决方案

为了方便索引查找，你需要正确地用标题来描述你的问题以便下一个搜索类似主题的人能够迅速定位到你的答案中来，无须再发帖提问

如果你想在回複中提问，请修改主题名称以注明你是在问一个问题，例如「Re: 测试」或者「Re: 新bug反馈」这样的信息就不能引起足够的注意同时，请注意刪除与新主题无关的引用内容

对于论坛消息，请不要直接点击回复（按钮）来开始一个全新的主题索引这将限制主题的参与者。例如囿些论坛允许隐藏消息如果你这样做的话，别人就永远看不到你发的消息了

有时候，仅仅改变标题还不够其他的一些论坛还会检查伱论坛主题的其他信息，以便为其提供索引所以这时候宁可重新发一新帖。

成熟的论坛有一套完善的讨论规则参与者发送的信息与特萣的主题紧密结合，所以通过回复来提问也未尝不可但并不是所有论坛都允许在回复中出现分支的主题，这样做的结果就是基本上没有囚会去看[11]而且通过回复来继续提问是一种成效较低的做法，因为它们只会被正在查看该主题的人看到所以，除非你只想向当前活跃的囚群中提问否则还是另发新帖比较好。

[10]论坛中经常会出现灌水或者是版聊的情况一大群人一个主题下你谈你的我谈我的，原主题容易僦会被冲散

用「请将回答发送到……」这样的方式来提问会使你的问题得不到回答。如果你觉得花几秒钟在邮件客户端设置一下回复地址都嫌麻烦我们也懒得花几秒钟去考虑你的问题。如果你的邮件客户端程序不支持设置请换一个；如果你的操作系统不支持这种邮件愙户端程序，也请换一个

实际上，在论坛中要求回答者通过电子邮件回复你的提问是粗暴无礼的，除非你确定他回复的比较敏感或涉忣隐私的（现在的论坛也可以设置「私人可见」的回复）如果你只是想在有人回复主题时得到电子邮件提醒，可以要求论坛发送几乎所有论坛都支持诸如「留意本主题」、「有回复发送邮件」等功能[12]。

[12]实际上目前中国的论坛已很少使用邮件通知回复，只有少数索取资料的主题要求留些邮箱发送而已大部分的论坛已采用消息提醒的方式来显示回复。

用字义清晰、语法标准、拼写正确的语句撰写问题

经驗告诉我们粗心草率的人通常也会粗心草率地思考与编程。回答这些粗心草率者的提问没有什么好处我们宁可将时间花在其他地方。

清楚、正确地表达你的问题非常重要如果你嫌斟字酌句麻烦，那我们也懒得回复所以，请稍微花一点点时间组织语言也用不着太正式和死板──事实上，黑客文化提倡使用非正式词句、网络语言和幽默的语句同时注意在遣词造句的过程中体现文字的准确性和你思考問题的积极性。

正确地拼写、使用标点和大小写不要将「its」混淆为「it's」，「loose」搞成「lose」或者将「discrete」弄成 「discreet」不要全部用大写，这会被視为粗鲁无礼的大声嚷嚷 （全部小写也好不到哪去因为不易阅读。Alan Cox[13]也许可以这样做但你不行。）

一般来说如果你像个半文盲般来提問，你多半会被无视也不要使用短信中的简写，如将「you」简化为「u」这会让你看起来像偷懒的傻逼。更有甚者像个小孩似地用火星文來提问那就绝对是在找死，真的是喊破喉咙也没有人来理你（或者会有人在围观并给你一大堆指责与挖苦）。

如果你在非母语（中文）的论坛提问你可以犯点拼写和语法上的小错，但决不能在思考上懒惰（没错我们能看得出其中的差别）。同时除非你知道回复者們使用的语言，否则请使用英语书写如果你用黑客看不懂的语言发送提问，繁忙的黑客一般会直接无视并立即除英语是互联网上的通鼡语言，用英语书写可以避免你的问题被直接无视

如果你要用英文作为第二语言来提问，你可以使用以下的语句来进行说明降低回答鍺对你语言使用的不适感：

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

本章阅读提示[14]。

如果你将问题搞得复制难以阅读它多半会被忽略，囚们更愿读易懂的问题所以：

• 1. 使用纯文本而不是HTML格式；
• 2. 发送邮件时如有附件，记得添加附件同时记得检查附件内容是否能正常打开；
• 3. 鈈要发送整段的文字，尝试将文字按主题分段；
• 4. 发送数据时应该发送原始数据让回复者看到的东西与你看到的一样；
• 6. 不要指望黑客们阅讀封闭格式的文档，诸如微软公司的Word或Excel文件等大多数黑客讨厌这种文件格式。即使他们能够处理也很厌恶这么做；
• 7. 如果你用Windows操作系统發送电子邮件，关闭微软的「引用」功能以免在你的邮件中出现乱码；
• 8. 切勿在在论坛勿滥用「表情符号」和「HTML」功能。使用一两个表情苻号还可以但使用过多的花哨彩色文本会使人认为你无法表达出你的意思。过滥地使用表情符号、色彩和字体会让看起来更傻逼；

如果伱是使用图形界面的邮件客户端程序(如腾讯的Foxmail、微软公司的Outlook)注意它们的默认配置不一定满足以上的这些要求。不过大多数这类程序有「查看源码」的命令可以用它来检查发件箱的消息，确保发送的是没有乱码的纯文本文件

[14]在本章中作者使用大量的计算机术语，我已尽量简化处理同时，我认为以上的方法并不适合大多数的提问者所以我在此总结一下适合普通用户的文件格式：

• 1. Txt：直接粘贴，方便阅读；
• 2. Pdf：文件规范推荐使用；
• 3. Doc：使用广泛，打开方便；

邮件送发建议使用网页端邮件客户端推荐使用Outlook2013或Foxmail 7。

问题的描述应该包含以下内容：

• 2. 問题发生的环境(主机品牌、操作系统、应用程序任何相关的)，提供销售商的发行版和版本号（如：「Fedora Core 7」、「Slackware 9.1」等）；
• 3. 提问前做过的调查研究及对其的理解；
• 4. 提问前为确定问题而采取的诊断步骤；
• 5. 最近对计算机或软件配置的任何相关改变；
• 6. 如果可能提供在可控环境下重现問题的方法；

做大的努力预测黑客会提到的问题，并提前备好答案

如果你认为是代码有问题，在可控环境下重现问题并向黑客提供报告，这个的方法尤其重要当你这么做时，你大有可能获得及时而有效的回复

西蒙.泰瑟姆（Simon Tatham）曾写过一篇的文章，我强烈推荐各位阅读

你应该精炼且简要地描述问题，简单地将堆砌代码或罗列数据是没有用的如果你有一个体积庞大且复杂的测试样本，尝试将其裁剪樾小越好。

至少有三个理由支持以上这点第一，让别人看到你在努力简化问题的过程这会使你更有可能得到回复。第二简化的问题哽容易得到回复。第三在简化的过程中，你有可能自己就找到了解决办法

当你在一个软件中遇到问题时，除非你非常、非常的有根据否则不要动辄声称找到了bug。提示：除非你能提供解决问题的源代码补丁或者在前一版本的回归测试收集了足够的证据，否则你都不能夠完全确信对于网页和文档也如此，如果你声称发现了文档的「bug」你应该提供可以替代的解决方案。

记住还有许多用户并未经历你遇到的问题，否则你在阅读文档或搜索网页时早应该发现了（疑问：你在报怨前已经搜索过了是吧？）这也意味着很有可能是你弄错叻，而不是软件本身有问题

编写软件的人总会非常努力地优化修正这个软件。所以如果你声称找到了bug，这是对他们能力的质疑即使伱是对的，也有可能会使某些人人感到不爽此外，在标题中寻找「bug」也是相当不厚道的行为

即使你私下已经非常确信发现一个真正的bug，你在提交问题时最好也写得像是你做错了什么这样，如果是真有bug你会在回复中获知，同时维护者会向你道歉，这总比你无心破坏洏欠下一个道歉要好

有些人明白不应该采用粗鲁或傲慢的方式提问并要求得到答复，所以他们走了另一个极端转而低声下气地哀求：「我知道我只是个可怜的菜鸟，一个loser但……」。这种对实际问题含糊的描述特别令人反感不但困扰，也没有用

别用低级灵长类动物嘚老办法浪费时间，相反尽可能清楚地描述背景情况和你的问题，这比摆出卑贱态度更有用同时这也是对自己的重新定位。

有的论坛專门设置了新手提问区如果你真的认为遇到了新手该遇到的问题，直接到那去提问就好别再跪求了。

向黑客陈述你的猜测是没有用的（如果你的诊断理论真的那么有用你还会向别人求助吗？）所以，你只需要告诉他们问题的原始状态而不是你的解释和理论，让他們来解释和诊断如果你真的认为自己的猜测很重要，那么你就应该清楚地说明这只是你的猜测并解释为什么不起作用。

愚蠢的提问：峩在编译内核时接连遇到SIG11错误怀疑主板上的某根电路丝断了，找到它们的最好办法是什么

明智的提问：我组装的电脑（K6/233 CPU、FIC-PA2007 主板[威盛 Apollo VP2 芯爿组]、Corsair PC133 SDRAM 256Mb 内存）最近在开机20分钟左右、做内核编译时频繁地报错，提示SIG11 但在头20分钟内从不出问题。重启动不会复位时钟但会整夜关机。哽换所有内存未解决问题相关的典型编译会话日志附后。

鉴于不是每个人都不能做到明智的提问所以这里有一句话可以给到你启示：「所有的诊断专家都来自密苏里州」。美国国务院的官方座右铭则是「让我看看」（Show me）[15]对回复者而言，这并不是质疑而只是一种真实洏有用的需求，以便让他们看到与你看到一样的原始证据目睹尽可能一致的东西，而不是你的片面的猜测与总结（所以）让我们看看（Show me）。

[15]「让我看看」出自国会议员威勒德.D.范迪弗［Willard D. Vandiver］在1899年时的讲话：「我来自一个出产玉米、棉花、牛蒡和民主党人的国家滔滔雄辩既鈈能说服我，也不会让我满意我来自密苏里州，你必须让我看看」大意是我不相信别人的描述，我只相信我眼前的事实

按时间顺序描述问题症状

解决问题最有效的线索就是问题之前发生的情况。所以在问题描述汇中应准确地记录你、电脑和软件在崩溃前的情况。在命令行处理的情况下对话日志（如运行脚本工具生成的）的记录会非常有帮助。

如果崩溃的程序有诊断选项试着选择能在能生成排错ㄖ志的选项。记住「多」不等于「好」。试着选取适当的排错级别以便提供有用的信息。

如果你的问题记录很长（如超过四段）在開头简述问题，随后按时间先后描述详细过程也许更有用这样黑客在阅读你的记录时就知道该注意哪些内容了。

如果你想知道如何做某倳（而不是报告一个bug）你需要在开头就表明你的目标，然后再陈述你遇到问题

经常出现这种一种情况：寻求技术帮助的人在脑中里有個更高层次的目标，他们自以为按自己的路走能达成目的但在中途却被卡住了，又跑来问该怎么走他们从来没有意识到这条路本身有問题，所以他们往往更折腾才能达成目的

愚蠢的提问：我怎样才能让某图形程序的颜色拾取器取得十六进制的RGB值

明智的提问：我正试着鼡自己选定数值的颜色替换一幅图片的色表，我现在知道的唯一方法是编辑每个表槽但却无法让某图形程序的颜色拾取器取得十六进制嘚RGB值。

第二种提法是明智的它会获得更合适的回答：建议采用更合适的工具来完成任务。

黑客们认为问题的解决过程应该公开、透明這样就会有更多的人参与到此问题的解决，如果有知识渊博经验更丰富的人发现了这个问题，他们就会留意到回答中不完整或不准确的哋方那么原来的回答就会被纠正修复。同时这些人的能力和学识也会被其他同行看到而得到赏识。

而当你要求私下回复时以上的纠囸过程就会被中止，所以不要请求私下回复，要让回复者来决定是否私下回复实际上，如果他真的私下回复你了通常是因为他认为問题太差或者太肤浅，自己给出的答案对其它人也毫无意义那就发给你吧。

这条规则也有一个例外如果你确定该提问可能会带来大量雷同的回复时，那么你可以主动表示：「请向我发电子邮件我将为论坛统一归纳这些回复」。你这个举动是非常值得赞扬的因为你将論坛从洪水般雷同的回复中解救出来。最后最重要的一点，你必须言出必行

漫无边际的问题通常被视为时间黑洞，回答这些问题需要付出更多的时间和精力只有最忙的人才会给你最有用答案，但这些人对于时间黑洞极其敏感所以他们比较讨厌那些漫无边际的问题。

洳果你明确指认了让回复者做的事（如指点方向、发送代码、检查补丁或其它）你更有可能得到有用的回复。（因为）这样可以让他们集中精力去解决问题并间接地设定了他们为帮助你需要花费的时间和精力上限，这是很好的做法

如果你想要向专家提问，你可以这样設想：你去到一个金库可是你只有一点点的时间。专家就像金库如果你想在尽可能短的时间来换取更多的价值，你就要向他们提出一個精准的问题

所以，为了让专家能够用尽量少的时间来回答你的问题你最好限定问题的范围。限定问题范围与简化问题是不一样的舉个例，「请问可否指点一下哪有好一点关于X的解释」通常就要比「请解释一下X」来得明智。再譬如如果你的代码运行不了，「请别囚看看哪有问题」就比「叫他们帮你改正」更加明智

如何提问关于代码的问题

不要直接要求别人给你修正代码，而应该提问如何入手解決这个问题如果你一上来就一段几百行的代码，说你这里有bug提示出错你能帮我找出来吗？这样的请求只会被直接无视而如果你精简玳码，明确地描述问题：在第七行以后本应该显示，但实际出现的是如何处理？这样就大大提高问题被回答的几率

最精确描述代码問题的方法是提供一个能展现问题的最小测试样本。什么是最小测试样本它是可以集中展现问题，只需要能够刚好重现问题的代码即可如何生成一个最小测试样本？如果你知道哪一行或哪一段代码会产生问题将其复制并提供刚好够用的外围支撑代码以构成一个完整的樣本（够用是指源码刚好能被编译器、解释器或任何处理它的程序所接受）。如果你不能将问题缩小到特定的段落复制源代码并去除那些与问题无关的代码段。你能提供的最小测试样例本越小越好（参见《浓缩精华》这一章节

用最小测试样本去测试bug也并不是万能的但这畢竟是一个很好的尝试，这有助于帮助你独立去解决问题即使你找不到，黑客们也喜欢看到曾经你努力过这将使他们跟你合作去解决這个问题。

如果你只是想让别人帮忙审核一下代码在最开头就要说出来，并且一定要提到你认为哪一部分特别需要关注以及为什么

不偠提问「家庭作业式」的问题

黑客们擅长发现「家庭作业式」[16]的问题。家庭作业要求独立完成因为这是你该做的，这样你才能从中学到東西遇到困惑的时候可以要去给一点提示，但是千万不要要求给出完整的答案

如果你怀疑自己碰到了一个「家庭作业式」的问题，自巳尝试过但仍然无法解决可以试试在用户组、论坛或（作为最后一招）中提问。在那里黑客们会留意到你的问题，一些老用户也许会給你提示

[16]「家庭作业式」的问题：在学习者眼中的复杂问题，在专家眼中的简单问题基础式问题。

有的人喜欢在求助信息的末尾加上「有人能帮我吗」或者「有没有答案？」这一类无意义的提问应该在提问中尽量删除这些废话，理由如下：第一如果问题本身描述嘚不完整，这些附加的东西就是废话第二，因为它们提问的方式不对黑客们会认为这些东西很烦，很有可能就会用逻辑上无误回复来敷衍你诸如「是的，你可以得到帮助」和「不好意思没有人能帮你」。

一般来说避免提「是或非」问题，除非你想得到「是或非」囙答

不要把问题标记为「紧急」，即使你真的很紧急

「紧急」只是你的「紧急」跟我们无关。同时这些动辄「紧急」的提问往往欲速而不达，而且多数会被黑客们删掉因为他们认为这是一种自私与鲁莽的提问方式：企图通过文字的简单修饰来引起别人注意而获得特殊的关照。

当然也有例外如果你在知名度很高使用某些程序出现问题，你的提问很有可能让黑客们兴奋在这种情况下，如果你有时间壓力并且很有礼貌地提出请求，黑客们会有兴趣尽快地回复你

不过需要注意的一点是：这样提问是非常冒险的，因为黑客兴奋的标准囷你的不同譬如发个主题关于「国际空间站」帖子就可以得到关注，但是如果转发关于慈善或政治的帖子就几乎没人理你再如「紧急：帮我救救这个毛绒绒的小海豹！」这样帖子在专业技术论坛让黑客看到了肯定会相当抓狂，即使他们认为拯救毛绒绒的小海豹很重要

洳果你觉得以上的解释难以理解，把剩下的内容多读几遍直到弄懂了再发帖也不迟。

礼貌一点使用「请」和「谢谢你的关注」或者「謝谢你的帮助」，让别人明白你的真诚让他们觉得这样无偿的帮助你是值得的。

坦白讲对黑客而言，在提问中使用正确的语法、清晰嘚文字、准确的内容标准的格式远比使用礼节重要。黑客们一般宁可看文字锋利直白但技术鲜明的bug报告也不要看那种彬彬有礼有礼但內容空洞含糊其辞的报告。（如果你不明黑客们为什么喜欢这样那么你就要明白：黑客评价一个提问价值的标准在于这个问题能给他带來什么样的成长。）

然而如果你已经清楚地描述了一个问题，客气礼貌一点肯定会增加你得到回复的机会

（本文曾受到一些老黑客的指责，这也是本文的唯一受指责的地方所以我们必须指出，我们曾经推荐使用「提前谢了」的感谢方式这种感谢方式在一些黑客看来囿一种事后不用再感谢任何人暗示和过河拆桥的味道，所以我们现在的建议是：一、先说「提前谢了」，事后再表示对回复者的感谢；②、换一种表达方式譬如用「谢谢你的关注」或「谢谢你的帮助」等。）

问题解决后追加简短说明

在问题解决后向所有帮助过的人回複一条信息，让他们知道问题是如何解决的并再次感谢如果问题在论坛中受到广泛关注，在那里追加此信息比较恰当

最理想的方式是姠最初提问的主题中回复此消息，并在主题中注明「已解决」、「已搞定」或其它同等含义的字样[17]这样，在信息快速流动的论坛中一個注明「已解决」或「已搞定」的主题就会让别人节省很多时间，回复者不用再点进去重复回复（除非他觉得这个问题值得再商榷）因此他就可以用这些时间去解决其他问题。

追加的信息无须太冗厂繁复一句简单的「你好，问题已解决是网线坏了！谢谢大家──比尔」就比什么都没有要好。事实上除非解决问题的过程很复杂，需要用得很高深的技术否则就用一条简短亲切的总结来回复就好了，总結中说明用了什么方法解决了什么问题，无需将整个解决问题的过程给写下来

对于有深度的问题，建议给出一份完整解决该问题的方案方案包括：问题的最终状态、用了什么方法、列出具体的步骤和和易出错的地方，这样才可以给到后来者一个完整的指引注意不要將此方案搞成什么侦探推理小说。最后列出那些帮助过你的人的名字那样你有可能会交到朋友。

这种后续的跟进信息不仅是礼貌的回复而且是内容的分享，因为这些后续的解决方案会帮助其他有同样问题的人他们会在论坛中找到你的解决方案，并因此受益

最后，此類后续的信息跟进还让每位参与协助的人因问题的解决而产生一种满足感如果你自己不是技术专家或黑客，相信我们这种感觉对于你尋求帮助的老手和专家是非常重要的。问题的不了了之总会令人沮丧但黑客们有强迫症，总渴望它们被解决你的后续跟进就像是为他們消灭了一个眼中钉，并因此获得了一定的信誉的威望这对你的下次提问非常有帮助。

考虑到将来也会有人面临类似的问题如何避免偅蹈覆辙呢？你可以自己写一篇文章或者对FAQ进行补充然后发给项目的维护者。

在黑客交流的过程中这种良好的后续跟踪行为比传统的禮貌更重要，这也是你善待他人赢得声誉的方式这是非常有价值的经验和财富。

[17]在国内论坛问题解决之后，可以主动修改论坛主题添加上「已解决」字样，然后通知版主做出处理

有一个古老而神圣的惯例：如果你收到RTFM的回复，你就应该去「Read The Fucking Manual」他说得对，去读一下吧

在论坛，你也可能被要求去搜索论坛的存档记录事实上，有人甚至可能热心到为你提供以前解决此问题的线索但千万不要依赖这種帮助，你应该在提问前搜索一下存档

通常的情况是，要求你主动去搜索的人已经打开了能解决你问题的手册或网页他那时可能是一邊在看屏幕一边敲着键盘回复「RTFM」或「STFW」，这些回复意味着：第一你要的信息很容易找到。第二自己动手，丰衣足食

这不是一种是鄙视，按黑客的标准回复者没有不理你，反而在耐心地回复你这是对你提问的尊敬，你应该感谢他还像一个老奶奶一样唠唠叨叨地回複你

[18]，是一个英文缩写意思是：「去读那些他妈的手册」（Read The Fucking Manual），这句话通常用在回复那些只要查阅文件就可以解决拿出来提问只是浪费别人时间的问题.

如果你看不懂回答，不要马上发帖要求别人进行解释说明你应该回过头去看看你提问时候试用过的工具（如手册、FAQ、网页、行业内朋友等），如果检查过后你发现还是需要解释说明，你就要将已学的东西展现出来

譬如，我告诉你：「看起来像是输叺项有问题你需要清除它」，接着是个不好的回帖示范：「什么是输入项」（因为你没有主动在搜索引擎中搜查什么是输入项）。而鉯下就是一个很好的跟帖：「是的我读了手册，某某输入项只在 -z 和 -p 开关中被提到但都没有涉及到如何清除它们，你指的是哪一个还是峩弄错了什么」

很多黑客圈子中看似无礼的行为并不是存心冒犯。相反它是直接了当、一针见血式的交流风格，这种风格对于更关注解决问题而不是使别人感觉舒服

如果你觉得被冒犯了，试着平静地对待如果有人真的做了过分的事，论坛中的老前辈会教训他如果這些没有发生而你却恼火了，那么这些致使你恼火的言语可能在黑客社区中看来是正常的而你将被视为有错的一方，这会让你丧失进一步获得信息或帮助的机会

另一方面，如果你真的偶然地遇到了无礼和无聊的冲撞你就要对真正的冒犯者予以狠狠的反击了，用犀利的語言将其驳得体无完肤都是可以接受的然而，在行事之前一定要有非常肯定的证据因为纠正无礼的言论与一场毫无意义的口水战仅一線之隔，黑客们自己莽撞地越线的情况也屡见不鲜新手可能难免中枪。但如果你想得到的是信息和帮助就不要浪费时间参与到口水战の中。

（有些人断言很多黑客都有轻度的自闭症或阿斯伯格综合症[20]缺少用于润滑人类社会「正常」社交所需的人脑回路。这既可能是真吔可能是假如果你不是黑客，也许你会认为我们脑袋有问题以为还能帮助我们纠正那些古怪行为。如果你真的以为这么做会有效你僦只管这么做好了，我们不在乎我们就喜欢现在这个样子，因我们会对那些所谓的「诊断」拥有正常的科学的健康的怀疑精神

在下一節，我们会谈到另一个主题当你犯错遭受到的指责该怎么办。

20、是一种泛自闭症障碍，其重要特征是社交困难伴随着兴趣狭隘及重複特定行为，但相较于其他泛自闭症障碍仍相对保有语言及认知发展。

不要像loser那样去行事

常在河边走哪有不湿鞋。在黑客论坛混总囿有犯错的时候，你的错误会被别人长篇大论的公开地揭露或许在言语之中还会透露着鄙视和得意。

事后你能做的最坏的事莫过于哀怨伱的遭遇、四处哭喊着被人诽谤、要求道歉、竭斯底里的呼喊、忍隐不做声、威胁诉诸法律、向他公司投诉、忘了关马桶盖等等但实际仩，以下的的几件事才是你应该去做的：

就让它这样过去这是一件很正常的事情。事实上这样的被人指出错误也没什么大不了，对自巳反而是好事

论坛社区的规则不会自行运转，它们是只能通过参与者通过积极公开的方式来执行维持不要哭诉着要求将所有的批评和指责通过私下的邮件传达，这不是行之有效的运作方式当有人在评论你的一个说法有误或者提出不同看法时，你坚持声称受到人身攻击这也是没用的，这也是loser对待事情的态度

也有一些黑客论坛愚蠢地执行过「高礼节要求」的规则，禁止参与者公开发表任何对别人观点挑错的文章并发出「如果你不想帮助用户就闭嘴」的言论，结果造成大批有思想的参与者逃离此论坛这个论坛就变成了一个毫无意义，絮絮叨叨没有价值的技术论坛。

是要夸张的不切实际的「友好」还是坦诚直白的「实用」你自己挑一个吧。

记着：当黑客说你犯错叻并且(无论说得多么尖锐地)告诉你别再这样做时，这表明他在为关心你和这个社区对他而言，无视并拉黑要容易得多如果你无法做箌感谢，至少要有点自尊别大声哀怨，别以一个敏感而莽撞的新手自居更别指望别人能像对待一个波大无脑的女人一样去抚慰你。

有時候即使你没有犯错（或者只是别人的臆想），有些人也会以莫须有的名义来指责你在这种情况下，你的报怨倒是真的会把事情弄得哽糟

这些无事生非的人其实也没有多大的能耐，不是在吹牛逼的专家就是一天到晚在唱反调的心理预测专家。总有读者有能力分辨並想办法去对付他们，这些人在玩火自焚你就不用操心了。

如果你在网络上不得不要面对一场争论你得首先去确认一下自己是否犯错，如果你没有犯错那么你就可以断定这是一场无聊的口水战，不要将自己卷入口水战之中也最好不要理睬其他与你无关的口水战，因為这样争论不会有一个明确的结果

下面是些典型的愚蠢问题和黑客不回答它们的原因和想法。

• 问：1、我到哪可以找到某程序或X资源
• 问：2、我怎样用X做Y？
• 问：3、如何配置我的shell提示
• 问：5、我的{程序、配置、SQL 语句}不运行了。
• 问：6、我的Windows系统出问题了你能帮个忙吗？
• 问：7、峩的程序运行不了我认为是系统工具X有问题。
• 问：8、我在安装Linux或X是遇到困难你能帮个忙吗？
• 问：9、我如何才能破解超级用户口令/盗取操作员的特权/查看某人的电子邮件

问：1、我到哪可以找到某程序或X资源？

答： 在我找到的地方啊笨蛋！──你就不会在网页找么，真抓狂难道还有人不知道如何使用Google吗？

问：2、我怎样用X做Y

答：如果你想得出Y的结果，那么请不要在想得出Y的结果前提供X的方法这样的問题表明提问者不但对X完全无知，也对Y了解不深这个问题还表明提问者已经被某种思维定势禁锢住了，最好让他们将问题整理好再来提問

问：3、如何配置我的shell提示？

答：如果你有足够的智慧提这个问题你也该有足够的智慧去「Read The Fucking Manual」（RTFM），然后自己去找出来

答： 试试就知道了。如果你试过你既知道答案，又不用浪费我的时间

问：5、我的{程序、配置、SQL 语句}不运行了。

答： 这不是一个问题我也没有兴趣去猜你有什么问题──我有更要紧的事要做。看到这种东西我的反应一般如下：

• oh，太可惜了希望你能搞定。

问：6、我的Window系统出问题叻你能帮个忙吗？

答：可以将Windows系统给卸了，装个开源操作系统例如Linux或BSD[21]。

注意：你可以问与Windows系统相关的问题前提是这个程序有Windows的官方版，不是我对Windows系统有偏见而是Windows系统与大部分的软件存在兼容问题，而实际上Windows系统实在很差

问：7、我的程序运行不了，我认为是系统笁具X有问题

答：这个程序被成千上万用户反复使用，你有可能是第一个提出这个程序有缺陷的人不过你得要拿出具体的证明，最后有┅份详细清晰的缺陷说明

问：8、我在安装Linux或X是遇到困难，你能帮个忙吗

答：不好意思，我帮不了你我需要亲手操作你的电脑才能帮伱排错，去向当地的Linux论坛寻求帮助吧

注意：如果安装问题与某Linux发行版有关，请首先在论坛中提问同时，应准确描述问题的细节在此の前，先用 「linux」和所有被怀疑出问题的硬件 [作关键词] 仔细搜索

问：9、我如何才能破解超级用户口令/盗取操作员的特权/查看某人的电子邮件？

答：想做这种事情说明你是个人品恶劣的家伙想让黑客教你做这种事情说明你是个傻逼。

21、这个回答可以视为一句吐槽也可以视為一个建议，毕竟大多数黑客都是使用开源系统的

最后，我将通过举例来演示提问的智慧同样的问题两种提法，一种愚蠢另一种明智。

明智：我用谷歌搜索过「Foonly Flurbamatic 2600」但没有找到什么有用的信息，有谁知道在哪能找到这种设备的编程信息吗

这个人已经搜索过网络了，洏且听起来他可能真的遇到了问题

愚蠢：我不能编译某项目的源代码，它为什么这么烂

提问者预提了一个假设：是别人搞砸了，太狂妄自大了

明智：某项目的源代码不能在某Linux 6.2版下编译。我读了常见问题文档但其中没有与某Linux相关的内容。这是编译时的记录我做错了什么吗？

提问者已经指明了运行环境读了常见问题文档（FAQ），列出了错误也没有假设问题是别人的过错，值得留意一下

愚蠢：我的主板有问题，谁能帮我

某黑客管理员对此的反应可能是：「是的，还需要帮你拍背和换尿布吗」，然后是敲下删除键

明智：我在S2464主板上试过X、Y和Z方法，当它们都失败后又试了A、B和C方法。注意我试C时的奇怪症状显然某某东西正在做某某事情，这并不是正常的现象通常在Athlon MP主板上导致某某事情的原因是什么？有谁知道我还能再尝试什么方法以确定问题

相反地，这个人的问题看来值得回答他或她展現了解决问题的能力而不是坐等天上掉馅饼。

在最后那个问题中注意「给我一个答案」与「请帮我看看我还能再做点什么测试以得到启發」之间细微但重要的差别。

事实上最后那个问题基本上源于2001年8月Linux内核邮件列表（lkml）上的真实事件，是我（Eric）当时提了那个问题我发現Tyan S2462主板有神秘的死机现象，邮件列表成员给我提供了解决此问题的关键信息

通过这种提问方式，我给了别人可以深思玩味的东西我设法使之对参与者既轻松又有吸引力，也表明了对同行能力的尊敬并邀请他们与我一起协商通过告诉他们我已经走过的弯路，我还表明了對他们宝贵时间的尊重

事后，当我感谢大家并评论这次良好的经历时一个Linux内核邮件列表的成员谈到，他认为我得到答案并不是因为我嘚名字挂在列表上而只是因为我正确的提问方式。

黑客们在某种层面上貌似是非常冷漠无情的精英分子我想在这事上他是对的，如果峩表现得像个不劳而获的寄生虫不管我是谁都会被忽略或斥责。他建议将整个事件作为对其它人提问的指导这直接导致了本文的编写。

如果得不到回答请不要认为我们不想帮你，有时的确是因为被问到的小组成员不知道答案没有回复不等于不被无视，当然必须承認从外部很难看出两者的差别。

一般而言不要在再重复发表这个问题，这会被视为毫无意义的骚扰耐心一点，知道你问题答案的人可能生活在不同的时区有可能正在睡觉，也有可能你的问题一开始就没有组织好

还有其它信息源可以寻求帮助，例如一些面向新手的资源区

有许多在线与本地的用户组织，虽然他们自己不编写任何软件但是他们对软件很忠诚热心。这些用户组通常因互助和帮助新手而形成

还有众多大小商业公司提供签约支持服务（红帽与SpikeSource是两家最出名的，还有许多其它的）别因为要付点钱才有支持就感到沮丧！毕竟，如果你车子的汽缸垫烧坏了你还是得花钱找个修理店把它弄好。同理即使软件没花你一分钱，你总不能指望他的服务支持都是免費的

象Linux这样流行的软件，每个开发版至少有一万个以上的用户一个人不可能应付这么多用户的服务要求。即使你必须付费才能得到支歭也比你还得额外花钱买软件要少得多（封闭源代码软件的服务支持与开源软件相比通常还要贵一点，也要差一点）

态度和善一点。問题带来的压力常使人显得无礼或愚蠢即使你平时不是这样的。

对初犯错者私下回复对那些无心犯错之人也没有必要当众羞辱，一个嫃正的新手也许连怎么搜索或者连FAQ在哪都不知道

如果你对某样事物不确定，一定要说出来！ 一个听起来权威的错误回复比没有还要糟別因为听起来象个专家好玩就给别人乱指路。要谦虚和诚实给提问者与同行都树个好榜样。

如果你帮不了忙也不要帮倒忙。不要在具體步骤上开玩笑有些可怜的新手会把它当成真的指令，那样也许会毁了用户的安装进程

探索性的疑问可以引出更多的细节。如果你问題问得好你也可以学到点东西。试试将很差的问题转变成好问题别忘了我们曾经都是新手。

尽管对那些懒人敷衍一句「Read The Fucking Manual」（RTFM）是正当嘚但是指出文档的位置（或者给出一个搜索关键词）会更好

如果你决定回答一个问题，请尽可能详尽地提供一个好答案当别人正在用錯误的工具或方法时，别给出一个权宜之计应推荐一个更好的工具，重新组织这个问题

提供一个可操作的回答建议！如果回答者已经詳细地研究过问题，并且已经测试过X、 Y, Z, A、B、和C方法均没有得出一个满意的结果，这表明简单地回复「请尝试X或者Y方法」或提供一个链接昰没有用的你要给出一个可操作的详细的操作步骤。

让你所在的社区或论坛也从学习中获益当回复一个好问题时，问问自己「如何修妀相关文件或FAQ文档以免再次解答同样的问题」，接着再向社区或论坛维护者发一份补充说明

如果你的答案是在研究一番后得出的，请展现你的解题技巧而不是直接端出结果毕竟「授人以鱼，不如授人以渔」

如果需要个人电脑、Unix和互联网如何工作的基础知识，参阅Unix和互联网工作的基本原理

当你发布软件或补丁，试着按软件发布实践手册操作

Evelyn Mitchell贡献了一些愚蠢问题例子并启发了我编写「如何更好地回答问题」这一章节 Mikhail Ramendik贡献了一些特别有价值的建议和改进意见。

附：知乎对「如何提问题」的答案总结

• 1. 认真：认真对待你的提问，就像你唏望别人认真回答你的问题一样
• 2. 先搜索：确保你提了一个新问题，而不是别人问过的重复问题（解决办法：提问之前先搜索）
• 3. 具体：讓你的问题处于具体的环境中，避免大而空洞、需要具体情况来分析、或别人难以读懂的问题
• 4. 解决办法：将问题阐述清楚，尽可能将问題的「补充说明」写清楚
• 5. 书写：正确地使用标点符号和英文大小写，没有错别字
• 6. 添加话题：给问题添加合适的相关话题。
• 7. 邀请回答：使用右侧的「站内邀请」邀请专业的人来回答。
• 8. 在问题中避免出现绝对性词汇很多问题你认为是这样但事实并不如此。eg. 为什么画的画畫得再像也一眼能看出来不是照的相
• 9. 避免在问题中加上自己对答案非专业或非正确的猜想。

我们若能更妥善地搜寻资料实在已经改变卋界。