新人报道应该看看！

fayisan

如何让自己的提问能够得到快速、高效的回答。这是个困扰很多朋友的新的老问题。

效率的问答，使得讨论氛围更加热烈、更加切入主题。有时候，往往会给提问者提供多种解决问题的思路。好处多多，这里不再赘述。

现在就把《How ToAsk Questions The Smart Way》这篇我还在学园时，就耳熟能详的佳作介绍给大家，文章从作者自身的角度贴切的对提问的艺术进行了分析和详尽的举例，请静下心来，认真读完。如果你读完并实践之，日后的收益将证明你今天花费宝贵时间读完这篇文章是一个多么明智的选择！这篇文章的作者是Eric，是开放源码界的元老之一，文章以《The Cathedral and the Bazaar》最为著名。

以下为该文的一个翻译后版本：

引言
在Hacker的世界，你所提技术问题的回答很大程度上取决于你提问的方式与解决此问题的难度，本文将教你如何提问才更有可能得到满意的答复。

开源程序的使用已经很广，你通常可以从其它更有经验的用户而不是Hacker那里得到回答。这是好事，他们一般对新手常有的毛病更容忍一点。然尔，使用我们介绍的方法象对待Hacker那样对待这些有经验的用户，通常能最有效地得到问题的解答。

第一件需要明白的事是Hacker喜欢难题和激发思考的好问题。假如不是这样，我们也不会写本文了。如果你能提出一个有趣的问题让我们咀嚼玩味，我们会感激你。好的问题是种激励与礼物，帮助我们发展认知，揭示没有注意或想过的问题。在Hacker中，“好问题!”是非常真挚的赞许。

除此而外，Hacker有遇到简单问题就表现出敌视或傲慢的名声，有时候我们看起来还对新手和愚蠢的家伙有条件反射式的无礼，但并不真正是这样。

我们只是毫无歉意地敌视那些提问前 不愿思考、不做自己该做之事的人。这种人就象时间无底洞──他们只知道获取，不愿意付出，他们浪费了时间，这些时间本可用于其它更值得回答的人和 更有趣 的问题。我们将这种人叫做“失败者 (loser)” (由于历史原因，我们有时将“loser”拼为“lusers")

我们注意到许多人只想用我们写的软件，他们对学习技术细节没有兴趣。对大多数人而言，计算机只是种工具，是种达到目的的手段。他们要生活并且有更要 紧的事要做，我们承认这点，也从不指望每个人都对这些让我们着迷的技术问题感兴趣。不过，我们回答问题的风格是为了适应那些真正对此有兴趣并愿意主动参与 问题解决的 人，这一点不会变，也不该变。如果这都变了，我们就会在自己能做得最好的事情上不再那么犀利。

我们(多数)是自愿者，从自己繁忙的生活中抽时间来回答问题，有时会力不从心。因此，我们会无情地滤除问题，特别是那些看起来象是失败者的，以便更有效地把回答问题的时间留给那些“胜利者”

如果你认为这种态度 令人憎恶、以施惠者自居或傲慢自大，请检查你的假设，我们并未要求你屈服──事实上，假如你做了该做的努力使之成为可能，我们中的大多数人非常乐意平等地与你交流并欢迎你接纳我们的文化。试图去帮助那些不愿自救的人对我们简直没有效率，不懂没有关系，但愚蠢地行事不行。

所以，你不必在技术上很在行才能吸引我们的注意，但你必须表现出能引导你在行的姿态──机 敏、思考、善于观察、乐于主动参与问题的解决。如果你做不到这些使你与众不同的事情，我们建议你付钱跟别人签商业服务合同，而不是要求Hacker无偿帮助。

如果你决定向我们求助，你不会想成为一名失败者，你也不想被看成一个失败者。得到快速有效回复的最好方法是使提问者看起来象个聪明、自信的人，并且暗示只是碰巧在某一特别问题上需要帮助。

提问前

在通过电子邮件、新闻组或网页论坛提技术问题之前，做以下事情：

尝试搜索互联网以找到答案

尝试阅读手册以找到答案

尝试阅读FAQ(常见问题)文档以找到答案

尝试自己检查或试验以 找到答案

尝试请教懂行的朋友以找到答案

如果你是程序员，尝试阅读源代码以找到答案

提问时，请先表述你已经做了上述事情，这将有助于建立你不是寄生虫与浪费别人时间的印象。最好再表述你从中学到的东西，我们喜欢 回答那些表现出能从答案中学习的人。

使用某些策略，比如用Google搜索你遇到的错误提示(既搜索网页也查查讨论组)，可能就直接找到了解决问题的文档或邮件列表线索。即使没有结 果，在电子邮件或新闻组张贴问题时提一句“我在Google中查过下列句子但没有找到什么有用的东西”也是件好事。

准备你的问题，彻底地思考。轻率的提问只能得到轻率的回答，或者压根没有。在提问时，越是表现出做过思考并在努力解决问题，你越有可能得到 实际帮助。

注意别提错问题。如果提问基于错误的假设，某Hacker多半会一边想”愚蠢的问题……“，一边用按照问题字面的无用答案回复你，并且希望这种只 是得到字面回答而不是真正所需的经历给你一个教训。

永远不要假设你有资格得 到解答。你没有这种资格，毕竟你没有为此服务付费。如果你能够提出有内容、有趣和激励思考的问题──那种毫无疑问能够向社区贡献经验而不仅仅是消极地要求从别人那获取知识的问题，你将“挣到”答案。

另一方面，表明你能够也乐意参与问题的解决是个很好的开端。“有没有人能指个方向？”、“我这还漏点什么？”、“我应该查哪些网站？”通常要比“请给出我可以用的完整步骤”更容易得到回复，因为你表明了只要有人能指个方向你就很乐意完成剩下的过程。
提问时
仔细挑选论坛

要对在哪提问留心，如果你做了下述事情，多半会被一笔勾销或被看成“失败者”：

张贴与论坛主题完全无关的问题

在面向高级技术问题的论坛上提非常 初浅的问题，或者反之。

在太多不同的新闻组同时交叉张贴

给既非熟人也没有义务解决你问题的个人张贴你私人的电子邮件

为保护通信的渠道不被无 关的东西淹没，Hacker会除掉那些没有找对地方的问题，你不会想有这种经历的。

所以第一步是找对论坛，Google与其它搜索引擎还是你的朋友，可以用它们搜索与你遇到困难的软硬件问题最相关的项目的网站。那 里通常都有项目的FAQ列表、邮件列表及其文档的链接。如果你的努力(包括阅读FAQ)都没有结果，这些邮件列表就是最后能取得帮助 的地方。项目的网站也许还有报告臭虫的流程或链接，如果是这样，去看看。

向陌生的人或论坛发送邮件极有可能是在冒险。譬如，不要假设一个富含信息的网页的编写者想充当你的免费顾问，不要对你 的问题是否会受到欢迎做乐 观的 估计──如果你 不确定，向别处发或者根本别发。

在选择网页论坛、新闻组或邮件列表时，不要太相信名字，先看看FAQ或者许可书以明确你的问题 是否与其主题相关。张贴前先翻翻已有的帖 子可 以 帮助你感受一下那里行事的方式。事实上，张贴之前在新闻组或邮件列表中搜索与你问题相关的关键词是个很好的主意，也许就找到答案了。即使没有，也能帮助你 整理 出 更好的问题。

别象机关枪似的一次性“扫射”所有的帮助通道，那就象大嚷大叫并使人不快。一个一个地来。

弄清楚你的主题！最典型的错误之一是在某种致立于跨Unix和Windows平台的语言、库或工具的论坛中提关于操作系统程序接口的问题。如果你不 明白为什么这是大错，最好在搞清楚概念前什么也别问。

一般来说，在仔细挑选的公共论坛中提问比在私有论坛中提同样的问题更容易得到有用的回复。有许多理由支持这一点，一是看潜在的回复者有多少，二是看论坛的参与者有多少，Hacker更愿回答能启发多数人的问题。

可以理解，老练的Hacker和一些流行软件的作者正在收到超出他们承受能力的不当消息。就象那根多出来就可以压垮骆驼背的稻草一样，你的 加入也可能会使情况走向极端──已经好几次了，一些流行软件的作者退出了对其软件的支持，因为伴随而来的涌向其私人邮箱的大量无用消息变得无法 忍受。
面向新手的网页论坛和IRC通常响应最快

本地的用户组织或者你所用的Linux发行版也许正在宣传新手取得帮助的网页论坛或IRC(互联网中继聊天) (在非英语国家，新手论坛很可能还是邮件列表)，这些 地 方 是开始提问的好去处，尤其是当你觉得遇到的也许只是相对简单或者一般的问题时。经过宣传的IRC通道是个公开邀请提问的地方，通常可以得到实时的回复。

事实上，如果出问题的程序来自某发行版(这很常见)，在程序的项目论坛或列表提问前最好先在发行版的论坛或列表中问问，(否则)项目的Hacker可能仅仅 回复“用我们的代码”

在任何网页论坛张贴之前，先看看是否有搜索功能。如果有，就试试用问题的几个关键词搜索一下，也许就有帮助。如果在此之前你已做过全面的网页搜索 (你应该这样做)，还是再搜索一下论坛，搜索引擎最近也许还没有索引此论坛的全部内容。

通过网页论坛或IRC频道提供项目的用户支持有增长的趋势，电子邮件交流则更多地为项目开发保留。先在网页论坛或IRC中寻求与项目相关的帮 助。
第二步，使用项目邮件列表

当某项目存在开发者邮件列表时，即使你确信谁能最好地回答问题，也要向列表而不是其中的个体提问。检查项目的文档和主页，找到项目的邮件列表并使 用它。采用这种策略有几个好理由：

任何向单个开发者提的足够好的问题也将对整个项目组有益。相反，如果你认为自己的问题对整个项目组来说太愚蠢，这也不能成为打扰 单个开发者的理由。

向列表提问可以平衡开发者的负担，单个开发者(特别是项目领导)也许太忙以至于无法回答你的问题。

大多数邮件列表有历史文档并被搜索引擎索引，其它人可以通过网页搜索找到你的问题和答案而不用再次在邮件列表中发问。

如果某些问题经常被问到，开发者可以利用此信息改进文档或软件本身以使其更清楚。如果只是私下提问，就没有人能看到最常见问题的完整 场景。

如果一个项目既有“用户”也有“开发者”(或“Hacker”)邮件列表或网页论坛，而你又不摆弄那些代码，向“用户”列表或论坛提问。不要假设自己在开发 者列表中会受欢 迎，那些人多半会遭受你的噪音干扰。

然尔，如果你确信你的问题不一般，而且在“用户” 列表或论坛中几天都没有回复，可以试试“开发者”列表或论坛。建议你在张贴前最好先暗暗地观察几天以了解那的行事方式(事实上这是参与任何私有或半私有列表的好主意)

如果你找不到一个项目的邮件列表，而只能查到项目维护者的地址，只管向其发信。即便在这种情况下，也别假设(项目)邮件列表不存在。在你的电子邮 件中陈述你已 经试过但没有找到合适的邮件列表，也提及你不反对将自己的邮件转发给他人(许多人认为，即使没什么秘密，私人电子邮件也不应该被公开。通过允许将你的电子邮件转发他人给了相应人员处置你邮件的选择)。
使用明确而有意义的主题

在邮件列表、新闻组或网页论坛中，主题是你在五十个或更少的字符以内吸引有资格的专家注意的黄金机会，不要用诸如“请帮我”(更别提大写的“请帮我！！！！”，这种主题的消息会被条件反射式地删掉)之类的唠叨浪费机会。不要用你痛苦的深度来打动我们，相反，要在这点空间中使用超级简明扼要的问题 描述。

使用主题的好惯例是“对象──偏差”(式的描述)，许多技术支持组织就是这样做的。在“对象”部分指明是哪一个或哪一组东西有问题，在“偏差”部分 则描述与期望行为不一致的地方。

愚蠢：
救命啊！我的笔记本视频工作不正常！

明智：
XFree86 4.1扭曲鼠标光标，某显卡MV1005型号的芯片组

更明智：
使用某显卡MV1005型号芯片组的XFree86 4.1的鼠标光标被扭曲

编写“对象──偏差”式描述的过程有助于你更具体地组织你的问题。是什么被影响了？仅仅是鼠标光标或者还有其它图形？只在XFree86中出现？或 只是在其4.1版中？是针对某显卡？或者只是其MV1005型号的芯片组？一个Hacker只需描一眼就能够立即明白什么是你遇到的问题，什么是你自己的问题。

更一般地，想象一下在只显示主题的文档索引中查找。让你的主题更好地反映问题，可以使下一个搜索类似问题的人能够在文档中直接找到答案的线索而不用再次张贴提问。

如果你想在回复中提问，确保改变主题以表明你是在问一个问题，一个主题象“re: 测试”或“re: 新臭虫”的消息不太可能引起足够的注意。同 时，将回复中与新主题不甚相关的引用内容尽量删除

对于列表消息，不要直接点击回复(按钮)来开始一个新的线索，这将限制你的观众。有些邮件阅读程序，比如mutt，允许用户按线索排序并通过折叠线 索来隐藏消息，这样做的人永远看不到你发的消息。

仅仅改变主题还不够。mutt和其它邮件阅读程序还要检查主题以外的其它邮件头信息，以便为其指定线索，所以宁可发一个全新的邮件。

在网页论坛，因为消息与特定的线索紧密结合并且通常在线索之外不可见，好的提问方式略有不同，通过回复提问并不要紧(一些论坛甚至不允许在 回复中出现分离的主题，而且这样做了基本上没有人会去看)。不过通过回复提问本身就是令人怀疑的做法，因为它们只会被正在查看该 线索的人读到。所以，除非你只想在该线索当前活跃的人群中提问，还是另起炉灶比较好。
使之更易回复

以“请向……回复”来结束问题多半会使你得不到回答。如果你觉得花几秒钟在邮件客户端设置一下回复地址都麻烦，我们也觉得花几秒钟 考虑你的问题更麻烦。如果你的邮件客户端程序不支持这样做，换个好点的。如果是操作系统不支持所有这种邮件客户端程序，也换个好点的。

在网页论坛，要求通过电子邮件回复是完全无礼的，除非你确信回复的信息也许是机密的(而且有人会为了某种未知的原因只让你而不是整个论坛知道答 案)。如果 你只是想 在有人回复线索时得到电子邮件提醒，可以要求论坛发送。几乎所有论坛都提供诸如“留意本线索”、“有回复发送邮件”的功能。
使用清晰、语法与拼写正确的语句

经验告诉我们，粗心与草率的作者通常也粗心与草率地思考和编程(我敢打赌)。为这些粗心与草率的思考者回答问题没有什么好处，我们宁可将 时间花在其它地方。

清楚、完整地表达你的问题非常重要。如果你觉得这样做麻烦，我们也觉得注意(你的问题)麻烦。花点额外的精力斟酌一下字句，用不着太僵硬与正式──事实 上，Hacker文化很看重能准确地使用非正式、俚语和幽默的语句。但它必须很准确，而且有迹象表明你是在思考和关 注问题。

正确地拼写、使用标点和大小写，不要将“its”混淆为“it's”，“loose”搞成“lose”或者将“discrete”弄成 “discreet”。不要全部用大写，这会被看成无礼的大声嚷嚷 (全部小写也好不到哪去，因为不易阅读。Alan Cox[注：著名Hacker，Linux内核的重要参与者]也许可以这样做，但你不行 )。

一般而言，如果你写得象个半文盲似的傻子，多半得不到理睬。如果象个小孩似地乱写乱画那绝对是在找死，可以肯定没人会理你(或者最多 是给你一大堆指责与挖苦)。

如果在非母语论坛中提问，你的拼写与语法错误会得到有限的宽容，但懒惰完全不会被容忍(是的，我们通常看得出其中的差别)。同时，除非你知道回复者 使用 的语言，请使用 英语书写。繁忙的Hacker一般会直接删除用他们看不懂语言写的消息。在互联网上英语是工作语言，用英语书写可以将你的问题不被 阅读就被直接删除的可能降到最低。

fayisan

使用易懂的格式发送问题

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

使用文本而不是HTML(超文本标注语言) ( 关闭HTML 并不难)

使用MIME(多用途互联网邮件扩展)附件通常没有问题，前提是真正有内容(譬如附带的源文件或补丁)，而不仅仅是邮件客户端程序 生 成的模板(譬如只是消息内容的拷贝)。

不要发送整段只是单行句子但多次折回的邮件(这使得回复部分内容非常困难)。设想你的读者是在80个字符宽的文本终端阅读邮件， 设置你的行折回点小于80列。

但是，也不要用 任何固定列折回数据(譬如直接传送的日 志文件或会话记录)。数据应该原样包含，使回复者确信他们看到的与你看到的东西一样。

在英语论坛中，不要使用'Quoted-Printable' MIME编码发送消息。这种编码对于张贴非ASCII语言可能是必须的，但很多邮件代理程序并不支持。当它们分断时，那些文本中四处散布 的 “=20”符号既难看也分散注意力。

永远不要指 望Hacker们阅读使用封闭的专用格式编写的文档，诸如微软公司的Word或Excel文件等，大多数Hacker对此的反应就象有人将还在冒热气的猪 粪倒在你门口时你的反应一样。即使他们能够处理，他们也很厌恶这么做。

如果你从使用视窗的电脑发送电子邮件，关闭微软愚蠢的“聪明引用”功能，以免在你的邮件中到处散布垃圾字符。

在网页论坛，勿滥用“表情符号”和“html”功能(当它们提供时)。一两个表情符号通常没有问题，但花哨的彩色文本倾向于使人认为 你是个无能之辈。过滥地使用表情符号、色彩和字体会使你看来象个傻笑的小姑娘。这通常不是个好主意，除非你只是对性而不是有用的回复更有兴趣。

如果你使用图形用户界面的邮件客户端程序(如网景公司的Messenger、微软公司的Outlook或者其它类似的)，注意它们的缺省配置不一 定满足这些要求。大多数这类程序有基于菜单的“查看源码”命令，用它来检查发送文件夹中的消息，以确保发送的是没有多余杂质的纯文本文件。
描述问题应准确且有内容

仔细、清楚地描述问题的症状

描述问题发生的环境(主机，操作系统，应用程序，任何相关的)，提供销售商的发行版和版本号(如：“Fedora Core 2”、“Slackware 9.1”等)

描述提问前做过的研究及其理解。

描述提问前为确定问题而采取的诊断步骤。

描述最近对计算机或软件配置的任何相关改变。

尽最大努力预测Hacker会提到的问题，并提前备好答案。

Simon Tatham写过一篇叫 如何有效地报告Bug 的文章，我强烈推荐各位阅读。
多不等于准确

你应该(写得)准确且有内容，简单地将一大堆代码或数据“倾倒”在求助消息中达不到目的。如果你有一个很大且复杂的测试样例让程序崩溃，尝 试将其裁剪得越小越好。

至少有三个理由支持这点。第一，让别人看到你在努力简化问题使你更有可能得到回复。第二，简化问题使你更有可能得到有用的回复。第三，在提纯臭虫 报告的过程中，你可能自己就找到了解决问题的方法或权宜之计。
别动辄声称找到臭虫

当你在一个软件中遇到问题，除非你非 常、非常的有根据，不要动辄声称找到了臭虫。提示：除非你能提供解决问题的源代码补丁，或者对前一版本的回归测 试 表现出不正确的行为，否则你都多半不够完全确信。对于网页和文档也如此，如果你(声称)发现了文档的“臭虫”，你应该能提供相应位置的替代文本。

记住，还有许多其它用户未经历你遇到的问题，否则你在阅读文档或网页搜索时就应该发现了(你在报怨前已经做了这些，是吧？)。这也意味着很有可能是你弄错了而不是软件本身有问 题。

编写软件的人通常非常辛苦地使它尽可能完美。如果你声称找到了臭虫，也就暗示他们做错了什么，而这几乎总会使人不快──即使你是对的， 在主题中嚷嚷“臭虫”也是特别不老练的。

提问时，即使你私下非常确信已经发现一个真正的臭虫，最好写得象是你做 错了什么。如果真的有臭虫，你会在回复中看到这点。这么做的话，如果真有虫子，维护者就会向你道歉，这总比你弄 砸了然后欠别人一个道歉要强。
低声下气不能代替自己应做之事

有些人明白他们不应该粗鲁或傲慢地行事并要求得到答复，但他们退到相反的低声下气的极端，“我知道我只是个什么也不是、什么也不懂的失败者， 但……”。这既使人困扰也没有帮助，当伴随着对实际问题含糊的描述时还特别令人反感。

别用低级灵长类动物的策略浪费大家的时间，相反，尽量清楚地表述背景事实和你的问题，这比低声下气更好地摆正了你的位置。

有时，网页论坛设有单独的初学者提问区域，如果你真的认为遇到了初浅的问题，到那去就是了，但一样别低声下气。

fayisan

描述问题症状而不是猜测

告诉Hacker你认为是什么导致了问题是没有用的(如果你的诊断理论是了不起的东西，你还会向他人咨询求助吗？)。所以，确保只是告诉他们问题的原始 症状，而不是你的解释和理论，让他们来解释和诊断。如果你认为陈述你的猜测很重要，清楚地说明这只是你的猜测并描述为什么它们不起作用。

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

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

刚出问题之前发生的事情通常包含有解决问题最有效的线索。所以，记录中应准确地描述你及电脑在崩溃之前都做了些什么。在命令行处理的 情况下，有会话日志(如运行脚本工具生成的)并引用相关的若干(如20)行记录会非常有帮助。

如果崩溃的程序有诊断选项(如-v详述选项)，仔细考虑选择这些能在记录中增加排错信息的选项。

如果你的记录很长(如超过四段)，也许在开头简述问题随后按时间先后罗列详细过程更有用。这样做，Hacker在读你的记录时就知道该查哪些内容了。
描述目的而不是步骤

如果你想弄清楚如何做某事(而不是报告一个臭虫)，在开头就描述你的目标，此后才描述为此采取的措施所遇到的问题。

经常有这种情况，寻求技术帮助的人在脑袋里有个更高层面的目标，他们在自以为能达到目标的特定道路上被卡住了，然后跑来问该怎么走，但没有意识到这条路本身有问题，结果要费很大的劲才能通过。
愚蠢：

我怎样才能让某图形程序的颜色拾取器取得十六进制的RGB值？
明智：

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

第二种提法是明智的，它使得建议采用更合适的工具完成任务的回复成为可能。
别要求私下回复

Hacker们认为问题的解决过程应该公开、透明，此过程中如果更有才能的人注意到不完整或者不当之处，最初的回复才能够、也应该被更正。同时，作为回复者也因为能力和学识被其它同行看到而得到某种回报。

当你要求私下回复时，此过程和回报都被中止。别这样做，让回复者来决定是否私下回答──如果他 真这么做了，通常是因为他认为问题编写太差或者太肤浅 以 至于对其它人无意义。

对这条规则存在一条有限的例外，如果你确信提问可能会导致大量雷同的回复时，那么“给我发电子邮件，我将为小组归纳这些回复”将是神奇的句子。试图将邮件列表或新闻组从洪水般雷同的回复中解救出来是非常有礼貌的──但你应信守诺言。
问题应明晰

漫无边际的问题通常也被视为没有明确限制的时间无底洞。最有可能给你有用答案的人通常也是最忙的人(假如只是因为他们承担了大多数工作的话)，这些人对于没 有限制的时间无底洞极其反感，所以他们也倾向于讨厌那些漫无边际的问题。

如果你明确了想让回复者做的事(如指点方向、发送代码、检查补丁或其它)，你更有可能得到有用的回复。这可以使他们集中精力并间接地设定了他们为帮助你需要花费的时间和精力上限，这很好。

要想理解专家生活的世界，可以这样设想：那里有丰富的专长资源但稀缺的响应时间。你暗中要求他们奉献的时间越少，你越有可能从这些真正懂行也真正很忙的专家那里得到回答。

所以限定你的问题以使专家回答时需要付出的时间最少──这通常还与简化问题不一样。举个例，“请问可否指点一下哪有好一点的X解释？”通常要 比“请解释一下X”明智。如果你有什么代码不运行了，通常请别人看看哪有问题比叫他们帮你改正更明智。
别张贴家庭作业

Hacker们善于发现“家庭作业”式的问题。我们大多数人已经做了自己的家庭作业，那是该你做的，以便从其经历中学习。问一 下提示没有关系，但不是要求完整的解决方案。

如果你怀疑自己碰到了一个家庭作业式的问题，但仍然无法解决，尝试在用户组论坛或(作为最后一招)在项目的“用户”邮件列表或论坛中提问。尽管Hacker们会看出来，一些高级用户也许仍会给你提示。
删除无意义的问题

抵制在求助消息末尾加上诸如“有人能帮我吗？”或“有没有答案？”之类在语义上无任何意义东西的诱惑。第一，如果问题描述还不完整，这些附 加的东西最多也只能是多余的。第二，因为它们是多余的，Hacker们会认为这些东西烦人──就很有可能用逻辑上无误但打发人的回复，诸如“是的，你可以得到帮助”和“不，没有给你的帮助”

一般来说，避免提“是或否”类型的问题，除非你想得到 “是或否”类型的回答。

fayisan

不要刻意标明问题紧急

这是你自己的问题，不要我们的。宣称“紧急”极有可能事与愿违：大多数Hacker会直接删除这种消息，他们认为这是无礼和自私地企图得到即时与特殊的关 照。

有一点点局部的例外，如果你是在一些知名度很高、会使Hacker们激动的地方使用程序，也许值得这样去做。在这种情况下，如果你有期限压力，也很有礼貌 地提到这点，人们也许会有足够的兴趣快一点回答。

当然，这是非常冒险的，因为Hacker们对什么是令人激动的标准多半与你的不同。譬如从国际空间站这样张贴没有问题，但代表感觉良好的慈善或政治原 因这样做几乎肯定不行。事实上，张贴诸如“紧急：帮我救救这个毛绒绒的小海豹！”肯定会被Hacker回避或光火，即使他们认为毛绒绒的小海豹很重要。

如果你觉得这不可思议，再把剩下的内容多读几遍，直到弄清楚了再发贴。
礼貌总是无害的

礼貌一点，使用“请”和“谢谢你的关注”或者“谢谢你的意见”，让别人明白你感谢他们无偿花时间帮助你。

坦率地说，这一点没有语法正确、文字清晰、准确、有内容和避免使用专用格式重要(同时也不能替代它们)。Hacker们一般宁可读有点唐突但技术鲜明的臭 虫报告，而不是那种礼貌但含糊的报告。(如果这点让你不解，记住我们是按问题能教我们些什么来评价一个问题的)

然尔，如果你已经谈清楚了技术问题，客气一点肯定会增加你得到有用回复的机会。

(我们必须指出，本文唯一受到一些老Hacker认真反对的地方是以前曾经推荐过的“提前谢了”，一些Hacker认为这隐含着事后不用再感谢任何人的暗示。我们的 建议是先说 “提前谢了”，事后再对回复者表示感谢。或者换种方式表达，譬如用“谢谢你的关注”或“谢谢你的意见”)。
问题解决后追加一条简要说明

问题解决后向所有帮助过的人追加一条消息，让他们知道问题是如何解决的并再次感谢。如果问题在邮件列表或新闻组中受到广泛关注，在那里追加此消息比 较恰当。

最理想的方式是向最初提问的线索回复此消息并在主题包含“已解决”、“已搞定”或其它同样意思的明显标记。在人来人往的邮件列表里，一个看见线索 “问题X”和“问题X-已解决”的潜在回复者就明白不用再浪费时间了(除非他个人觉得“问题X”有趣)，因此可以用此时间去解决其它问题。

你追加的消息用不着太长太复杂，一条简单的“你好──是网线坏了！谢谢大家──比尔”就比什么都没有要强。事实上，除 非解决问题的技术真正高深，一条简短而亲切的总结比长篇大论要好。说明是什么行动解决了问题，用不着重演整个排错的故事。

对于有深度的问题，张贴排错历史的摘要是适当的。描述问题的最终状态，说明是什么解决了问题，在此之后才指明可以避免的弯路。应避免的 弯路部分应放在正确的解决方案和其它总结材料之后，而不要将此消息搞成侦探推理小说。列出那些帮助过你的名字，那样你会交到朋友的。

除了有礼貌、有内容以外，这种类型的追帖将帮助其他人在邮件列表、新闻组或论坛文档中搜索到真正解决你问题的方案，从而也让他们受益。

除上述而外，此类追帖还让每位参与协助的人因问题的解决而产生一种满足感。如果你自己 不是技术专家或Hacker，相信我们，这种感觉对于你寻求帮助的老手和专家非常重要。问题叙述到最后不知所终总是令人沮丧的，Hacker们痒 痒地渴望看到它们被解决。“挠痒痒”为你挣到的好报将对你下次再次张贴提问非常非常的有帮助。

考虑一下怎样才能避免其他人将来也遇到类似的问题，问问自己编一份文档或FAQ补丁有没有帮助，如果有的话就将补丁发给维护者。

在Hacker中，这种行为实际上比传统的礼貌更重要，也是你善待他人而赢得声誉的方式，这是非常有价值的财富。
如何解读回答RTFM和STFW：如何知道你已完全搞砸

有一个古老而神圣的传统：如果你收到了“RTFM”的回复，发信人认为你应该去“读读该死的手册”。他多半是对的，去读一下吧。

RTFM有个年轻的亲戚，如果你收到“STFW”的回复，发信人认为你应该“搜搜该死的网络”。他多半也是对的，去搜一下吧。(更温和一点的说法是 “Google 是你的朋友！”)

在网页论坛，你也可能被要求去搜索论坛的文档。事实上，有人甚至可能热心地为你提供以前解决此问题的线索。但不要依赖这种好心，提问前应先搜索 一下文 档。

通常，叫你搜索的人已经打开了能解决你问题的手册或网页，正在一边看一边敲键盘。这些回复意味着他认为：第一，你要的信息很容易找到。第二，自已找 要比别人喂到嘴里能学得更多。

你不应该觉得这样就被冒犯了，按Hacker的标准，他没有不理你就是在向你表示某种尊敬，你反而应该感谢他热切地想帮助你。

fayisan

如果还不明白

如果你看不懂回复，不要马上回发一个要求说明的消息，先试试那些最初提问时用过的同样工具(手册、FAQ，网页、懂行的朋友等)试着搞懂回 复。如果还是需要说明，展现你已经明白的。

譬如，假如我告诉你：“听起来象是某输入项有问题，你需要清除它”，接着是个不好的回帖：“什么是某输入项？”。 而这是一个好的跟帖：“是 的， 我读了手册，某输入项只在-z和-p开关中被提到，但都没有提及清除某选项，你指的是哪一个还是我弄错了什么？”
对待无礼

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

你如果觉得被冒犯，努力平静地反应。如果有人真的做了过格的事，邮件列表或新闻组或论坛中的前辈多半会招呼他。如果这没有发生而你却发火了，那么你发火对象的言语 可能在Hacker社区中看起来是正常的，而你将 被视为有错的一方，这将伤害到你获取信息或帮助的机会。

另一方面，你会偶而真的碰到无礼和无聊的言行。与上述相反，对真正的冒犯者狠狠地打击、用犀利的语言将其驳得体无完肤都是可以 接受的。然尔，在行事之前一定要非常非常的有根据。纠正无礼的言论与开始一场毫无意义的口水战仅一线之隔，Hacker们自己莽撞地越线情况并不鲜见。如果你是新 手或外来者，避开这种莽撞的机会不高。如果你想得到的是信息而不是消磨时光，这时最好不要把手放在键盘上以免冒险。

(有些人断言很多Hacker都有轻度的自闭症或阿斯伯格综合症，一定缺少平滑人类社会“正常”交往所需的脑电路。这既可能是真也可能是假。如果你自己不是Hacker，兴许你认为我们脑袋有问题还能帮助你应付我们的古怪行为。只管这么干好了，我们不在乎。我们喜欢我们现在这个样子，并且一般都对 临床诊断有相当的怀疑。)

在下一节，我们会谈到另一个问题，当你行为不当时会受到的“冒犯”
别象个失败者那样反应

在Hacker社区的论坛中有那么几次你会搞砸──以本文详述或类似的方式。你会被示众是如何搞砸的，也许言语中还会带点颜色。

这种事发生以后，你能做的最糟的事莫过于哀嚎你的遭遇、宣称被口头攻击、要求道歉、高声尖叫、憋闷气、威胁诉诸法律、向其雇主报怨、忘了关马桶盖等等。相反，你该这样去做：

熬过去，这很正常。事实上，它是有益健康与恰当的。

社区的标准不会自己维持，它们是通过参与者积极而公开地执行来维持的。不要哭嚎所有的 批评都应该通过私下的邮件传送，这不是事情运作的方式。当有人批评你的 一些主张或者其看法不同时，坚持声称个人被侮辱也毫无用处，这些都是失败者的态度。

也有其它的Hacker论坛，受太高礼节要求的误导，要求参与者禁止张贴任何对别人帖子挑毛病的消息，并被告知“如果你不想帮助用户就闭嘴”。有思路的参与者纷纷离开的结果只会使它们变成了毫无意义的唠叨与无用的技术论坛。

是夸张的“友谊”(以上述方式)还是有用？挑一个。

记住：当Hacker说你搞砸了，并且(无论多么刺耳地)告诉你别再这样做时，他正在为关心你和他的社区而行动。对他而言，不理你并将你从他的生活中滤除要 容易得 多。如果你无法做到感谢，至少要有点尊严，别大声哀嚎，也别因为自己是个有戏剧性超级敏感的灵魂和自以为有资格的新来者，就指望别人象对待脆弱的洋娃娃那样对你。

有时候，即使你没有搞砸(或者只是别人想象你搞砸了)， 有些人会无缘无故地攻击你本人。在这种情况下，报怨倒是真的会把问题搞砸。

这些找茬者要么是什么也不懂但自以为是专家的不中用家伙，要么就是测试你是否真会搞砸的心理学家。其它读者要么不理睬，要么用自己的方式对付他们。 这些找茬者在给自己找麻烦，这点你不用操心。

也别让自己卷入口水战，大多数口水战最好不要理睬──当然是在你核实它们只是口水战、没有指出你搞砸的地方，而且没有巧妙地将问题真正的答案藏于其 中 (这也 是 可能的)之后。

fayisan

提问禁忌

下面是些典型的愚蠢问题和Hacker不回答它们时的想法。
问： 我到哪可以找到程序或X资源？
问： 我怎样用X做Y？
问： 如何配置我的shell提示？
问： 我可以用Bass-o-matic文件转换工具将AcmeCorp文档转为TeX格式 吗？
问： 我的{程序、配置、SQL语句}不运行了
问： 我的视窗电脑出问题了，你能帮忙吗？
问： 我的程序不运行了，我认为系统工具X有问题
问： 我安装Linux或X遇到困难，你能帮忙吗？
问： 我如何才能破解超级用户口令/盗取频道操作员的特权/查看某人的电子邮件？

问：        
我到哪可以找到程序或X资源？
答：        
在我找到它的同样地方，笨旦──在网页搜索引擎上。上帝啊，难道还有人不知道如何使用 Google 吗？
问：        
我怎样用X做Y？
答：        
如果你想做的是Y，提问时别给出可能并不恰当的方法。这种问题说明提问者不但对X完全无知，也对要解决的Y问题糊涂，还被特定形势禁 锢了思维。等他们把问题弄 好再说。
问：        
如何配置我的shell提示？
答：        
如果你有足够的智慧提这个问题，你也该有足够的智慧去 RTFM， 然后自己去找。
问：        
我可以用Bass-o-matic文件转换工具将AcmeCorp文档转为TeX格 式吗？
答：        
试试就知道了。如果你试过，你既知道答案，又不用浪费我的时间了。
问：        
我的{程序、配置、SQL语句}不运行了
答：        
这不是一个问题，我也没有兴趣去猜你有什么问题──我有更要紧的事要做。看到这种东西，我的反应一般如下：
•你还有什么补充吗？
•噢，太糟了，希望你能搞定。
•这跟我究竟有什么关系？
问：        
我的视窗电脑出问题了，你能帮忙吗？
答：        
是的，把视窗垃圾删了，装个象Linux或BSD的开源操作系统吧。

注意：如果程序有官方的视窗版或与视窗有交互(如Samba)，你可以问与视窗电脑相关的问题，只是别 对问题是由视窗操作系统而不是程序本身造成的回复感 到惊讶，因 为视窗一般来说太差，这种说法一般都成立。
问：        
我的程序不运行了，我认为系统工具X有问题
答：        
你完全有可能是第一个注意到被成千上万用户反复使用的系统调用与库文件有明显缺陷的人，更有可能的是你完全没有根据。不同凡响的说法需 要不同凡响的证据， 当你这样 声称时，你必须有清楚而详尽的缺陷说明文档作后盾。
问：        
我安装Linux或X遇到问题，你能帮忙吗？
答：        
不行，我需要亲手操作你的电脑才能帮你排错，去向当地的Linux用户组寻求方便的帮助(你可以在 这里 找到用户组列表)

注意：在为某一Linux发行版服务的邮件列表或论坛或本地用户组织中提关于安装该发行版的问题也许是恰当的。此时，应描述问题的准确细节。在此之前，先用 “linux”和所有被怀 疑的硬件(为关键词)仔细搜索。
问：        
我如何才能破解超级用户口令/盗取频道操作员的特权/查看某人的电子邮件？
答：        
想做这种事情说明你是个卑劣的家伙，想让Hacker教你做这种事情说明你是个白痴。

fayisan

好问题与坏问题

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

愚蠢：我在哪能找到关于Foonly Flurbamatic设备的东西？
这个问题在乞求得到 STFW 式的回复。

明智：我用Google搜索过“Foonly Flurbamatic 2600”，但没有找到什么有用的，有谁知道在哪能找到这种设备的编程信息？
这个人已经搜索过网络了，而且听起来他可能真的遇到了问题。

愚蠢：我不能编译某项目的源代码，它为什么这么破？
他假设是别人搞砸了，太自大了。

明智：某项目的源代码不能在某Linux 6.2版下编译。我读了常见问题文档，但其中没有与某Linux相关的问题。这是编译时的记录，我做错了什么吗？
他指明了运行环境，读了FAQ，列出了错误，也没有假设问题是别人的过错，这家伙值得注意。

愚蠢：我的主板有问题，谁能帮我？
某Hacker对此的反应可能是：“是的，还需要帮你拍背和换尿布吗？”，然后是敲下删除键。

明智：我在S2464主板上试过X、Y和 Z，当它们都失败后，又试了A、B和C。注意我试C时的奇怪症状，显然某某东西正在做某某事情，这不是期望的。通常 在Athlon MP主板上导致某某事情的原因是什么？有谁知道我还能再试点什么以确定问题？
相反地，这个人看来值得回答。他展现了解决问题的能力而不是坐等天上掉馅饼。

在最后那个问题中，注意“给我一个回复”与“请帮我看看我还能再做点什么测试以得到启发”之间细微但重要的差别。

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

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

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

Hacker们在某种方面是非常不留情面的精英分子。我想他是对的，如果我表现得象个不劳而获的寄生虫，不管我是谁都会被忽略或斥责。他建议将整个事件作为 对其它人提问的指导直接导致了本文的编写。
如果没有回复

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

一般来说，直接将问题再张贴一次不好，这会被视为毫无意义的骚扰。

还有其它资源可以寻求帮助，通常是在一些面向新手的资源中。

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

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

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

fayisan

如何更好地回答问题

态度和善一点。问题带来的压力常使人显得无礼或愚蠢，其实并不是这样。

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

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

如果帮不了忙，别妨 碍。不要在具体步骤上开玩笑，那样也许会毁了用户的安装──有些可怜的呆瓜会把它当成真的指令。

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

尽管对那些懒虫报怨一声RTFM是正当的，指出文档的位置(即使只是建议做个Google关键词搜索)会更好。

如果你决意回答，给 出好的答案。当别人正使用错误的工具或不当的方法时别建议笨拙的权宜之计，应推荐更好的工具，重新组织问题。

帮助你的社区从问题中 学习。当回复一个好问题时，问问自己 “如何修改相关文件或FAQ文档以免再次解答同样的问题？”，接着再向文档维护者发一份补丁。

如果你的确是在研究一番后才做出的回答，展现你的技巧而不是直接端出结果。毕竟“授人以鱼，不如授人以渔”。


能看到这里的朋友，相信，你以后在网络这个虚拟社会中能够得到更多！
台湾版的翻译中有很多问题，我整理的时候，就调侃自己:现在这样的快餐文化，能有几个人能静下心读完这篇文章的，能读完的那几个人应该和文中的成功者不远了吧！？看来你就是那几个人，希望你在我们甲鱼的坛子里多捞点好东西，同时，也介绍更多的朋友到这里来，多多支持我们的甲鱼！他已经不是小甲鱼了，还要养小甲鱼:lol:。
还有，请尊重那些给你们带来点点滴滴的鱼油，不要吝惜你的评分，你的鼓励往往能使他们在坛子里更加活跃！而受益的往往又是你们！

swsm

也不要太酷！！！呵呵呵！

破灬王

这前面看的有点不懂 觉得没什么用！ 后来还是静下心来看完了，有些地方看不懂。
看玩我得到的启发就是： 遇到错误尽量自己去解决。
感谢楼主的分享！
我不太会说话，请多多包含！

765643729

我认为新手不懂就问,不能说错,也不能说完全正确,至少你可以先百度一下吧,查查资料吧,思考一下,动动手
就说我们学校的同学吧,程序报错了,他根本就不想一下,不检查一下,报错就来问你,结果一看不是字母打错,就是少打个符号之类的错误遇见的最多,你说谁愿意天天帮人去玩找茬的游戏,就算解决了,下次还会再犯,这样自然不会乐意去教他,然后他还不高兴,这年头伸手党为何这么厉害,被我们惯坏了吧

所以还是要自己尝试解决问题,实在不能解决才问,至少问的问题也要有点水平的问题吧

fayisan

我认为新手不懂就问,不能说错,也不能说完全正确,至少你可以先百度一下吧,查查资料吧,思考一下,动动手
就说我们学校的同学吧,程序报错了,他根本就不想一下,不检查一下,报错就来问你,结果一看不是字母打错,就是少打个符号之类的错误遇见的最多,你说谁愿意天天帮人去玩找茬的游戏,就算解决了,下次还会再犯,这样自然不会乐意去教他,然后他还不高兴,这年头伸手党为何这么厉害,被我们惯坏了吧

所以还是要自己尝试解决问题,实在不能解决才问,至少问的问题也要有点水平的问题吧

BINGO!{:2_31:}