Andrew Clarke 在 How To Be A Good Guru 一文中提到了 How to Answer
Questions the Smart Way 这个有趣的话题, 并且模仿 提问的智慧 给出了"回答
的智慧"的 10 条准则。来看一下这 10 条(翻译了一下，并适当的作了一点注释
):

1. Don't answer questions to which you don't know the answer( 不回答自己
不知道答案的问题)

2. Explain yourself (解释给自己)
如果自己是提问者，你的回答是否能让自己明白?

3. Give as little assistance as necessary (尽可能的给最少的帮助)
有的时候启发性的回答更为有效.

4. Show your workings (展示你的做法)

5. Use humour judiciously (明智地使用幽默)
有的时候因为不同语境/语言的问题，你的俏皮话可能会让提问者更加困惑。

6. If you can't say something nice don't say anything at all(如果你不能
说出有用的内容，就别说)

7. Avoid jargon, baffling acronyms and idiolects (避免行话、令人困惑的缩
写词、习惯用语)

8. Never never never just respond with RTFM. Not ever.(永远永远永远不要
回复 RTFM)
这里的 RTFM 代表"Read The Fucking Manual", "去读该死的手册". 另外一个常
见的是: STFW --Search The Fucking Web, "搜索该死的网络"，或者友好一点的
 "Google 一下". 对于中文论坛上，我觉得还有一个尽量不要说 "RPWT" --人品问
题

9. Meditate on eternity (永远的深思熟虑)
回答的问题，可能在不久以后会被别人搜索到，看到，甚至是被你将来的老板看到
。一个欠缺思索的回答无疑会降低你在其他技术人员心目中的形象。

10. Keep your newbie mind (保持自己的"新手"思维)
学无止境

保持谦卑。回答并不意味着你是"给予", 可能你也在学习. 不要认为回答了一些问
题自己就成了 Guru 了.

上述 10 条应该建立在《提问的智慧》的基础上。

Andrew Clarke 的这篇文章是针对 DBA 来说的，不过对其他领域的技术人员也有
借鉴意义。提问、回答都是一门艺术.

提问的智慧
内容

  译文
  弃权申明
  引言
  提问前
  提问时
    仔细挑选论坛
    面向新手的网页论坛和IRC通常响应最快
    第二步，使用项目邮件列表
    使用明确而有意义的主题
    使之更易回复
    使用清晰、语法与拼写正确的语句
    使用易懂的格式发送问题
    描述问题应准确且有内容
    多不等于准确
    别动辄声称找到臭虫
    低声下气不能代替自己应做之事
    描述问题症状而不是猜测
    按时间先后罗列问题症状
    描述目的而不是步骤
    别要求私下回复
    问题应明晰
    别张贴家庭作业
    删除无意义的问题
    不要刻意标明问题紧急
    礼貌总是无害的
    问题解决后追加一条简要说明
  如何解读回答
    RTFM与STFW：如何知道你已完全搞砸
    如果还不明白.
    对待无礼
  别象个失败者那样反应
  提问禁忌
  好问题与坏问题
  如果没有回复
  如何更好地回答问题
  相关资源
  鸣谢

                        ---------------------

* 译文

译文: 捷克语 丹麦语 爱沙尼亚语 法语 德语 希伯来语 匈牙利语 意大利语 日语
波兰语 俄语 西班牙语 瑞典语 土耳其语.  如果你想复制、镜像、翻译或引用本
文，请参阅我的复制须知(http://www.catb.org/%7Eesr/copying.html).

* 弃权申明

许多项目的网站在如何取得帮助的部分链接了本文，这没有关系，也是我们想要的。
但如果你是该项目生成此链接的网管，请在链接附近显著位置注明“我们不是此
项目的服务部！”

我们已经遭受没有此说明带来的痛苦，不断受到一些白痴的骚扰。他们认为既然我
们发表了此文，那么我们就有责任解决世上所有技术问题！

如果你因为需要帮助阅读了本文，然后带着可以直接从作者那取得帮助的印象离开，
你就不幸成了那些白痴之一。不要向我们提问，我们不会理睬的。我们在这只是给
你说明如何从那些真正懂得你软硬件问题的人那里取得帮助的方法，99%的时间我
们不会是那些人。除非你确信此文作者是你遇到问题方面的专家，请不要打扰，这
样大家都更开心一点。

* 引言

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

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

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

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

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

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

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

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

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

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

(欢迎对本文指正，可以将建议发至 esr@thyrsus.com 。请注意，本文不想成为一
般性的 网络礼仪 指南，我一般会拒绝那些与引出技术论坛中有用的回复不特别相
关的建议)

* 提问前

在通过电子邮件、新闻组或网页论坛提技术问题之前，做以下事情：
  尝试搜索互联网以找到答案
  尝试阅读手册以找到答案
  尝试阅读FAQ(常见问题)文档以找到答案
  尝试自己检查或试验以找到答案
  尝试请教懂行的朋友以找到答案
  如果你是程序员，尝试阅读源代码以找到答案

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

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

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

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

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

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

* 提问时

** 仔细挑选论坛

要对在哪提问留心，如果你做了下述事情，多半会被一笔勾销或被看成“失败者”：
  张贴与论坛主题完全无关的问题
  在面向高级技术问题的论坛上提非常初浅的问题，或者反之。
  在太多不同的新闻组同时交叉张贴
  给既非熟人也没有义务解决你问题的个人张贴你私人的电子邮件

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

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

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

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

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

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

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

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

** 面向新手的网页论坛和IRC通常响应最快

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

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

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

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

** 第二步，使用项目邮件列表

当某项目存在开发者邮件列表时，即使你确信谁能最好地回答问题，也要向列表而
不是其中的个体提问。检查项目的文档和主页，找到项目的邮件列表并使用它。采
用这种策略有几个好理由：
    任何向单个开发者提的足够好的问题也将对整个项目组有益。相反，如果你认为
自己的问题对整个项目组来说太愚蠢，这也不能成为打扰单个开发者的理由。
    向列表提问可以平衡开发者的负担，单个开发者(特别是项目领导)也许太忙以
至于无法回答你的问题。
    大多数邮件列表有历史文档并被搜索引擎索引，其它人可以通过网页搜索找到
你的问题和答案而不用再次在邮件列表中发问。
    如果某些问题经常被问到，开发者可以利用此信息改进文档或软件本身以使其
更清楚。如果只是私下提问，就没有人能看到最常见问题的完整场景。

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

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

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

** 使用明确而有意义的主题

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

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

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

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

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

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

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

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

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

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

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

** 使之更易回复

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

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

** 使用清晰、语法与拼写正确的语句

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

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

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

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

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

** 使用易懂的格式发送问题

如果你人为地将问题搞得难以阅读，它多半会被忽略，人们更愿读易懂的问题，所以：
    使用文本而不是HTML(超文本标注语言) ( 关闭HTML 并不难)
    使用MIME(多用途互联网邮件扩展)附件通常没有问题，前提是真正有内容(譬
如附带的源文件或补丁)，而不仅仅是邮件客户端程序生成的模板(譬如只是消息内
容的拷贝)。
    不要发送整段只是单行句子但多次折回的邮件(这使得回复部分内容非常困难)。
设想你的读者是在80个字符宽的文本终端阅读邮件，设置你的行折回点小于80列。
    但是，也不要用任何固定列折回数据(譬如直接传送的日志文件或会话记录)。
数据应该原样包含，使回复者确信他们看到的与你看到的东西一样。
    在英语论坛中，不要使用'Quoted-Printable'
    MIME编码发送消息。这种编码对于张贴非ASCII语言可能是必须的，但很多邮
件代理程序并不支持。当它们分断时，那些文本中四处散布的
    “=20”符号既难看也分散注意力。
    永远不要指望黑客们阅读使用封闭的专用格式编写的文档，诸如微软公司的
Word或Excel文件等，大多数黑客对此的反应就象有人将还在冒热气的猪粪倒在你
门口时你的反应一样。即使他们能够处理，他们也很厌恶这么做。
    如果你从使用视窗的电脑发送电子邮件，关闭微软愚蠢的“聪明引用”功能，
以免在你的邮件中到处散布垃圾字符。
    在网页论坛，勿滥用“表情符号”和“html”功能(当它们提供时)。一两个表
情符号通常没有问题，但花哨的彩色文本倾向于使人认为你是个无能之辈。过滥地
使用表情符号、色彩和字体会使你看来象个傻笑的小姑娘。这通常不是个好主意，
除非你只是对性而不是有用的回复更有兴趣。

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

** 描述问题应准确且有内容

    仔细、清楚地描述问题的症状
    描述问题发生的环境(主机，操作系统，应用程序，任何相关的)，提供销售商
的发行版和版本号(如：“Fedora Core 2”、“Slackware 9.1”等)
    描述提问前做过的研究及其理解。
    描述提问前为确定问题而采取的诊断步骤。
    描述最近对计算机或软件配置的任何相关改变。

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

Simon Tatham写过一篇叫 如何有效报告臭虫 的文章，我强烈推荐各位阅读。

** 多不等于准确

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

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

** 别动辄声称找到臭虫

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

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

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

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

** 低声下气不能代替自己应做之事

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

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

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

** 描述问题症状而不是猜测

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

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

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

** 按时间先后罗列症状

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

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

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

** 描述目的而不是步骤

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

经常有这种情况，寻求技术帮助的人在脑袋里有个更高层面的目标，他们在自以为
能达到目标的特定道路上被卡住了，然后跑来问该怎么走，但没有意识到这条路本
身有问题，结果要费很大的劲才能通过。
  愚蠢：
        我怎样才能让某图形程序的颜色拾取器取得十六进制的RGB值？
  明智：
        我正试图用自己选定数值的颜色替换一幅图片的颜色表，我现在唯一知道
的方法是编辑每个表槽，但却无法让某图形程序的颜色拾取器取得十六进制的RGB值。

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

** 别要求私下回复

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

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

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

** 问题应明晰

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

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

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

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

** 别张贴家庭作业

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

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

** 删除无意义的问题

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

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

** 不要刻意标明问题紧急

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

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

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

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

** 礼貌总是无害的

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

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

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

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

** 问题解决后追加一条简要说明

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

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

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

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

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

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

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

在黑客中，这种行为实际上比传统的礼貌更重要，也是你善待他人而赢得声誉的方
式，这是非常有价值的财富。

* 如何解读回答

** RTFM和STFW：如何知道你已完全搞砸

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

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

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

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

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

** 如果还不明白

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

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

** 对待无礼

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

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

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

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

在下一节，我们会谈到另一个问题，当你行为不当时会受到的“冒犯”

* 别象个失败者那样反应

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

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

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

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

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

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

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

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

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

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

* 提问禁忌

下面是些典型的愚蠢问题和黑客不回答它们时的想法。
问：我到哪可以找到程序或X资源？
答：在我找到它的同样地方，笨旦──在网页搜索引擎上。上帝啊，难道还有人不
知道如何使用 Google 吗？

问：我怎样用X做Y？
答：如果你想做的是Y，提问时别给出可能并不恰当的方法。这种问题说明提问者
不但对X完全无知，也对要解决的Y问题糊涂，还被特定形势禁锢了思维。等他们把
问题弄好再说。

问：如何配置我的shell提示？
答：如果你有足够的智慧提这个问题，你也该有足够的智慧去 RTFM，然后自己去找。

问：我可以用Bass-o-matic文件转换工具将AcmeCorp文档转为TeX格式吗？
答：试试就知道了。如果你试过，你既知道答案，又不用浪费我的时间了。

问：我的{程序、配置、SQL语句}不运行了
答：这不是一个问题，我也没有兴趣去猜你有什么问题──我有更要紧的事要做。
看到这种东西，我的反应一般如下：你还有什么补充吗？噢，太糟了，希望你能搞
定。这跟我究竟有什么关系？

问：我的视窗电脑出问题了，你能帮忙吗？
答：是的，把视窗垃圾删了，装个象Linux或BSD的开源操作系统吧。注意：如果程
序有官方的视窗版或与视窗有交互(如Samba)，你可以问与视窗电脑相关的问题，
只是别对问题是由视窗操作系统而不是程序本身造成的回复感到惊讶，因为视窗一
般来说太差，这种说法一般都成立。

问：我的程序不运行了，我认为系统工具X有问题
答：你完全有可能是第一个注意到被成千上万用户反复使用的系统调用与库文件有
明显缺陷的人，更有可能的是你完全没有根据。不同凡响的说法需要不同凡响的证
据，当你这样声称时，你必须有清楚而详尽的缺陷说明文档作后盾。

问：我安装Linux或X遇到问题，你能帮忙吗？
答：不行，我需要亲手操作你的电脑才能帮你排错，去向当地的Linux用户组寻求
方便的帮助(你可以在 这里 找到用户组列表)注意：在为某一Linux发行版服务的
邮件列表或论坛或本地用户组织中提关于安装该发行版的问题也许是恰当的。此时，
应描述问题的准确细节。在此之前，先用 “linux”和所有被怀疑的硬件(为关键
词)仔细搜索。

问：我如何才能破解超级用户口令/盗取频道操作员的特权/查看某人的电子邮件？
答：想做这种事情说明你是个卑劣的家伙，想让黑客教你做这种事情说明你是个白痴。

* 好问题与坏问题

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

  愚蠢：我在哪能找到关于Foonly Flurbamatic设备的东西？

  这个问题在乞求得到 STFW 式的回复。

  明智：我用Google搜索过“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内核邮件列表的成员谈
到，他认为并不是因为我的名字在列表上，而是因为我正确的提问方式才得到了答
案。

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

* 如果没有回复

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

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

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

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

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

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

* 如何更好地回答问题

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

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

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

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

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

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

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

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

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

* 相关资源

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

当你发布软件或补丁时，尝试按 软件发布实践 指南进行。

* 鸣谢

Evelyn Mitchell 贡献了一些愚蠢问题样例并启发了编写“如何更好地回答问题”
这一节，Mikhail Ramendik 贡献了一些特别有价值的建议和改进。