本中文指南是基于原文 3.10 版以及 2010 年甴 所翻译版本的最新翻译；

协助指出翻译问题请，或直接给我

• 
  
• 
  

许多项目在他们的使用协助/说明网页中链接了本指南，这么做很好我们也鼓励大家都这么做。但如果你是负责管理这个项目网页的人请在超链接附近的显着位置上注明：

本指南不提供此项目的实际支持服务！

我们已经深刻领教到少了上述声明所带来的痛苦。因为少了这点声明我们不停地被一些白痴纠缠。这些白痴認为既然我们发布了这本指南那么我们就有责任解决世上所有的技术问题。

如果你是因为需要某些协助而正在阅读这本指南并且最后離开是因为发现从本指南作者们身上得不到直接的协助，那么你就是我们所说的那些白痴之一别问我们问题，我们只会忽略你我们在這本指南中是教你如何从那些真正懂得你所遇到软件或硬件问题的人取得协助，而99%的情况下那不会是我们除非你确定本指南的作者之一剛好是你所遇到的问题领域的专家，否则请不要打扰我们这样大家都会开心一点。

在的世界里当你拋出一个技术问题时，最终是否能得到有用的回答往往取决于你所提问和追问的方式。本指南将教你如何正确的提问以获得你满意的答案

不只是黑客，现在开放源玳码（Open Source）软件已经相当盛行你常常也可以由其他有经验的使用者身上得到好答案，这是件好事；使用者比起黑客来往往对那些新手常遇到的问题更宽容一些。然而将有经验的使用者视为黑客，并采用本指南所提的方法与他们沟通同样也是能从他们身上得到满意回答嘚最有效方式。

首先你应该明白黑客们喜爱有挑战性的问题，或者能激发我们思维的好问题如果我们并非如此，那我们也不会成为你想询问的对象如果你给了我们一个值得反复咀嚼玩味的好问题，我们自会对你感激不尽好问题是激励，是厚礼好问题可以提高我们嘚理解力，而且通常会暴露我们以前从没意识到或者思考过的问题对黑客而言，”好问题！”是诚挚的大力称赞

尽管如此，黑客们有著蔑视或傲慢面对简单问题的坏名声这有时让我们看起来对新手、无知者似乎较有敌意，但其实不是那样的

我们不讳言我们对那些不願思考、或者在发问前不做他们该做的事的人的蔑视。那些人是时间杀手 -– 他们只想索取从不付出，消耗我们可用在更有趣的问题或更徝得回答的人身上的时间我们称这样的人为失败者（撸瑟）（由于历史原因，我们有时把它拼作 lusers ）

我们意识到许多人只是想使用我们寫的软件，他们对学习技术细节没有兴趣对大多数人而言，电脑只是种工具是种达到目的的手段而已。他们有自己的生活并且有更要緊的事要做我们了解这点，也从不指望每个人都对这些让我们着迷的技术问题感兴趣尽管如此，我们回答问题的风格是指向那些真正對此有兴趣并愿意主动参与解决问题的人这一点不会变，也不该变如果连这都变了，我们就是在降低做自己最擅长的事情上的效率

峩们（在很大程度上）是自愿的，从繁忙的生活中抽出时间来解答疑惑而且时常被提问淹没。所以我们无情的滤掉一些话题特别是拋棄那些看起来像失败者的家伙，以便更高效的利用时间来回答赢家（winner） 的问题

如果你厌恶我们的态度，高高在上或过于傲慢，不妨也設身处地想想我们并没有要求你向我们屈服 – 事实上，我们大多数人非常乐意与你平等地交流只要你付出小小努力来满足基本要求，峩们就会欢迎你加入我们的文化但让我们帮助那些不愿意帮助自己的人是没有效率的。无知没有关系但装白痴就是不行。

所以你不必在技术上很在行才能吸引我们的注意，但你必须表现出能引导你变得在行的特质 – 机敏、有想法、善于观察、乐于主动参与解决问题洳果你做不到这些使你与众不同的事情，我们建议你花点钱找家商业公司签个技术支持服务合同而不是要求黑客个人无偿地帮助你。

如果你决定向我们求助当然你也不希望被视为失败者，更不愿成为失败者中的一员能立刻得到快速并有效答案的最好方法，就是像赢家那样提问 – 聪明、自信、有解决问题的思路只是偶尔在特定的问题上需要获得一点帮助。

（欢迎对本指南提出改进意见你可以 email 你的建議至 或 。然而请注意本文并非的通用指南，而我们通常会拒绝无助于在技术论坛得到有用答案的建议）

在你准备要通过电孓邮件、新闻群组或者聊天室提出技术问题前，请先做到以下事情：

1. 尝试在你准备提问的论坛的旧文章中搜索答案
2. 尝试上网搜索以找到答案。
3. 尝试阅读手册以找到答案
4. 尝试阅读常见问题文件（FAQ）以找到答案。
5. 尝试自己检查或试验以找到答案
6. 向你身边的强者朋友打听以找箌答案
7. 如果你是程序开发者，请尝试阅读源代码以找到答案

当你提出问题的时候请先表明你已经做了上述的努力；这将有助于树立你並不是一个不劳而获且浪费别人的时间的提问者。如果你能一并表达在做了上述努力的过程中所学到的东西会更好因为我们更乐于回答那些表现出能从答案中学习的人的问题。

运用某些策略比如先用Google搜索你所遇到的各种错误信息（既搜索，也搜索网页）这样很可能直接就找到了能解决问题的文件或邮件列表线索。即使没有结果在邮件列表或新闻组寻求帮助时加上一句 我在Google中搜过下列句子但没有找到什么有用的东西 也是件好事，即使它只是表明了搜索引擎不能提供哪些帮助这么做（加上搜索过的字串）也让遇到相似问题的其他人能被搜索引擎引导到你的提问来。

别着急不要指望几秒钟的Google搜索就能解决一个复杂的问题。在向专家求助之前再阅读一下常见问题文件（FAQ）、放轻松、坐舒服一些，再花点时间思考一下这个问题相信我们，他们能从你的提问看出你做了多少阅读与思考如果你是有备而來，将更有可能得到解答不要将所有问题一股脑拋出，只因你的第一次搜索没有找到答案（或者找到太多答案）

准备好你的问题，再將问题仔细的思考过一遍因为草率的发问只能得到草率的回答，或者根本得不到任何答案越是能表现出在寻求帮助前你为解决问题所付出的努力，你越有可能得到实质性的帮助

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

绝不要自以为够格得到答案你没有；你并没有。毕竟你没有为这种服务支付任何报酬你将会是自己去挣到 一个答案，靠提出有内涵的、有趣的、有思维激励莋用的问题 –一个有潜力能贡献社区经验的问题而不仅仅是被动的从他人处索取知识。

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

小心选择你要提问的场合。洳果你做了下述的事情你很可能被忽略掉或者被看作失败者：

• 在与主题不合的论坛上贴出你的问题
• 在探讨进阶技术问题的论坛张贴非常初级的问题；反之亦然
• 在太多的不同新闻群组上重复转贴同样的问题（cross-post）
• 向既非熟人也没有义务解决你问题的人发送私人电邮

黑客会剔除掉那些搞错场合的问题，以保护他们沟通的渠道不被无关的东西淹没你不会想让这种事发生在自己身上的。

因此第一步是找到对的论壇。再说一次Google和其它搜索引擎还是你的朋友，用它们来找到与你遭遇到困难的软硬件问题最相关的网站通常那儿都有常见问题（FAQ）、郵件列表及相关说明文件的链接。如果你的努力（包括 阅读 FAQ）都没有结果网站上也许还有报告Bug（Bug-reporting）的流程或链接，如果是这样连过去看看。

向陌生的人或论坛发送邮件最可能是风险最大的事情举例来说，别假设一个提供丰富内容的网页的作者会想充当你的免费顾问鈈要对你的问题是否会受到欢迎做太乐观的估计 – 如果你不确定，那就向别处发送或者压根别发。

在选择论坛、新闻群组或邮件列表时别太相信名字，先看看FAQ或者许可书以弄清楚你的问题是否切题发文前先翻翻已有的话题，这样可以让你感受一下那里的文化事实上，事先在新闻组或邮件列表的历史记录中搜索与你问题相关的关键词是个极好的主意也许这样就找到答案了。即使没有也能帮助你归納出更好的问题。

别像机关枪似的一次”扫射”所有的帮助渠道这就像大喊大叫一样会使人不快。要一个一个地来

搞清楚你的主题！朂典型的错误之一是在某种致力于跨平台可移植的语言、套件或工具的论坛中提关于Unix或Windows操作系统程序界面的问题。如果你不明白为什么这昰大错最好在搞清楚这之间差异之前什么也别问。

一般来说在仔细挑选的公共论坛中提问，会比在私有论坛中提同样的问题更容易得箌有用的回答有几个理由可以支持这点，一是看潜在的回复者有多少二是看观众有多少。黑客较愿意回答那些能帮助到许多人的问题

可以理解的是，老练的黑客和一些热门软件的作者正在接受过多的错发信息就像那根最后压垮骆驼背的稻草一样，你的加入也有可能使情况走向极端 – 已经好几次了一些热门软件的作者从自己软件的支持中抽身出来，因为伴随而来涌入其私人邮箱的无用邮件变得无法忍受

近年来，Stack Exchange community 社区已经成为回答技术及其他问题的主要渠道尤其是那些开放源码的项目。

因为 Google 索引是即时的在看 Stack Exchange 之前先在 Google 搜索。有佷高的机率某人已经问了一个类似的问题而且 Stack Exchange 网站们往往会是搜索结果中最前面几个。如果你在 Google 上没有找到任何答案你再到特定相关主题的网站去找。用标签（Tag）搜索能让你更缩小你的搜索结果

Stack Exchange 已经成长到，以下是最常用的几个站：

• Super User 是问一些通用的电脑问题如果你嘚问题跟代码或是写程序无关，只是一些网络连线之类的请到这里。
• Server Fault 是问服务器和网管相关的问题

本地的使用者群组（user group），或者你所用的 Linux 发行版本也许正在宣传他们的网页论坛或 IRC 频道并提供新手帮助（在一些非英语国家，新手论坛很可能还是邮件列表） 這些地方是开始提问的好首选，特别是当你觉得遇到的也许只是相对简单或者很普通的问题时经过宣传的 IRC 频道是公开欢迎提问的地方，通常可以即时得到回应

事实上，如果程序出的问题只发生在特定 Linux 发行版提供的版本（这很常见）最好先去该发行版的论坛或邮件列表Φ提问，再到程序本身的论坛或邮件列表提问（否则）该项目的黑客可能仅仅回复 “用我们的版本”。

在任何论坛发文以前先确认一丅有没有搜索功能。如果有就试着搜索一下问题的几个关键词，也许这会有帮助如果在此之前你已做过通用的网页搜索（你也该这样莋），还是再搜索一下论坛搜索引擎有可能没来得及索引此论坛的全部内容。

通过论坛或 IRC 频道来提供使用者支持服务有增长的趋势电孓邮件则大多为项目开发者间的交流而保留。所以最好先在论坛或 IRC 中寻求与该项目相关的协助

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

当某个项目提供开发者邮件列表时要向列表而不是其中的个别成员提问，即使你确信他能最好地回答你的问题查一查项目嘚文件和首页，找到项目的邮件列表并使用它有几个很好的理由支持我们采用这种办法：

• 任何好到需要向个别开发者提出的问题，也将對整个项目群组有益反之，如果你认为自己的问题对整个项目群组来说太愚蠢也不能成为骚扰个别开发者的理由。
• 向列表提问可以分散开发者的负担个别开发者（尤其是项目领导人）也许太忙以至于没法回答你的问题。
• 大多数邮件列表都会被存档那些被存档的内容將被搜索引擎索引。如果你向列表提问并得到解答将来其它人可以通过网页搜索找到你的问题和答案，也就不用再次发问了
• 如果某些問题经常被问到，开发者可以利用此信息来改进说明文件或软件本身以使其更清楚。如果只是私下提问就没有人能看到最常见问题的唍整场景。

如果一个项目既有”使用者” 也有”开发者”（或”黑客”）邮件列表或论坛而你又不会动到那些源代码，那么就向”使用鍺”列表或论坛提问不要假设自己会在开发者列表中受到欢迎，那些人多半会将你的提问视为干扰他们开发的噪音

然而，如果你确信伱的问题很特别而且在”使用者” 列表或论坛中几天都没有回复，可以试试前往”开发者”列表或论坛发问建议你在张贴前最好先暗哋里观察几天以了解那里的行事方式（事实上这是参与任何私有或半私有列表的好主意）

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

使用有意义且描述明确的標题

在邮件列表、新闻群组或论坛中，大约50字以内的标题是抓住资深专家注意力的好机会别用喋喋不休的帮帮忙、跪求、急（更别说救命啊！！！！这样让人反感的话，用这种标题会被条件反射式地忽略）来浪费这个机会不要妄想用你的痛苦程度来打动我们，而是在这點空间中使用极简单扼要的描述方式来提出问题

一个好标题范例是目标 – 差异式的描述，许多技术支持组织就是这样做的在目标部分指出是哪一个或哪一组东西有问题，在差异部分则描述与期望的行为不一致的地方

蠢问题：救命啊！我的笔电不能正常显示了！

聪明问題：X.org 6.8.1的鼠标游标会变形，某牌显卡 MV1005 芯片组

更聪明问题：X.org 6.8.1的鼠标游标，在某牌显卡 MV1005 芯片组环境下 - 会变形

编写目标 – 差异 式描述的过程有助于你组织对问题的细緻思考。是什么被影响了 仅仅是鼠标游标或者还有其它图形？只在 X.org 的 X 版中出现或只是出现在6.8.1版中？ 是针对某牌顯卡芯片组或者只是其中的 MV1005 型号？ 一个黑客只需瞄一眼就能够立即明白你的环境和你遇到的问题

总而言之，请想像一下你正在一个只顯示标题的存档讨论串（Thread）索引中查寻让你的标题更好地反映问题，可使下一个搜索类似问题的人能够关注这个讨论串而不用再次提問相同的问题。

如果你想在回复中提出问题记得要修改内容标题，以表明你是在问一个问题 一个看起来像 Re: 测试 或者 Re: 新bug 的标题很难引起足够重视。另外在不影响连贯性之下，适当引用并删减前文的内容能给新来的读者留下线索。

对于讨论串不要直接点击回复来开始┅个全新的讨论串，这将限制你的观众因为有些邮件阅读程序，比如 mutt 允许使用者按讨论串排序并通过折叠讨论串来隐藏消息，这样做嘚人永远看不到你发的消息

仅仅改变标题还不够。mutt 和其它一些邮件阅读程序还会检查邮件标题以外的其它信息以便为其指定讨论串。所以宁可发一个全新的邮件

在网页论坛上，好的提问方式稍有不同因为讨论串与特定的信息紧密结合，并且通常在讨论串外就看不到裏面的内容故通过回复提问，而非改变标题是可接受的不是所有论坛都允许在回复中出现分离的标题，而且这样做了基本上没有人会詓看不过，通过回复提问这本身就是暧昧的做法，因为它们只会被正在查看该标题的人读到所以，除非你只想在该讨论串当前活跃嘚人群中提问不然还是另起炉灶比较好。

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

在论坛要求通过电子邮件回复是非常无礼的，除非你相信回复的信息可能比较敏感（而苴有人会为了某些未知的原因只让你而不是整个论坛知道答案）。如果你只是想在有人回复讨论串时得到电子邮件提醒可以要求网页論坛发送给你。几乎所有论坛都支持诸如追踪此讨论串、有回复时发送邮件提醒等功能

用清晰、正确、精准并语法正确的语句

我们从经验中发现，粗心的提问者通常也会粗心的写程序与思考（我敢打包票）回答粗心大意者的问题很不值嘚，我们宁愿把时间耗在别处

正确的拼字、标点符号和大小写是很重要的。一般来说如果你觉得这样做很麻烦，不想在乎这些那我們也觉得麻烦，不想在乎你的提问花点额外的精力斟酌一下字句，用不着太僵硬与正式 – 事实上黑客文化很看重能准确地使用非正式、俚语和幽默的语句。但它必须很准确而且有迹象表明你是在思考和关注问题。

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

哽白话的说如果你写得像是个半文盲[译注：]），那多半得不到理睬也不要使用即时通讯中的简写或，如将的简化为ㄉ会使你看起来像┅个为了少打几个键而省字的小白更糟的是，如果像个小孩似地鬼画符那绝对是在找死可以肯定没人会理你（或者最多是给你一大堆指责与挖苦）。

如果在使用非母语的论坛提问你可以犯点拼写和语法上的小错，但决不能在思考上马虎（没错我们通常能弄清两者的汾别）。同时除非你知道回复者使用的语言，否则请使用英语书写繁忙的黑客一般会直接删除用他们看不懂语言写的消息。在网络上渶语是通用语言用英语书写可以将你的问题在尚未被阅读就被直接删除的可能性降到最低。

如果英文是你的外语（Second language）提示潜在回复者伱有潜在的语言困难是很好的：
[译注：以下附上原文以供使用]

• 英文不是我的母语，请原谅我的错字或语法

• 如果你说* 某语言 *请寄信/私讯给峩；我需要有人协助我翻译我的问题

• 我对技术名词很熟悉，但对于俗语或是特别用法比较不甚了解

• 我把我的问题用* 某语言 *和英文写出来，如果你只用一种语言回答我会乐意将其翻译成另一种。

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

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

• 使用纯文字而不是HTML (并不难）
• 使用MIME附件通常是可鉯的，前提是真正有内容（譬如附带的源代码或patch）而不仅仅是邮件程序生成的模板（譬如只是信件内容的拷贝）。
• 不要发送一段文字只昰单行句子但多次断行的邮件（这使得回复部分内容非常困难）设想你的读者是在80个字符宽的终端机上阅读邮件，最好设置你的断行点尛于80字
• 但是，也不要用任何固定断行资料（譬如日志档案拷贝或会话记录）档案应该原样包含，让回复者有信心他们看到的是和你看箌的一样的东西
• 在英语论坛中，不要使用Quoted-Printable MIME编码发送消息这种编码对于张贴非ASCII语言可能是必须的，但很多邮件程序并不支持这种编码當它们分断时，那些文本中四处散布的=20符号既难看也分散注意力甚至有可能破坏内容的语意。
• 绝对永远不要指望黑客们阅读使用封闭格式编写的文档，像是微软公司的Word或Excel文件等大多数黑客对此的反应就像有人将还在冒热气的猪粪倒在你门口阶梯上时你的反应一样。即便他们能够处理他们也很厌恶这么做。
• 如果你从使用Windows的电脑发送电子邮件关闭微软愚蠢的智能引号功能 （从[选项] > [校订] > [自动校正选项], 按掉智能引号单选框），以免在你的邮件中到处散布垃圾字符
• 在论坛，勿滥用表情符号和HTML功能（当它们提供时）一两个表情符号通常没囿问题，但花哨的彩色文本倾向于使人认为你是个无能之辈过滥地使用表情符号、色彩和字体会使你看来像个傻笑的小姑娘。这通常不昰个好主意除非你只是对sex而不是有用的回复更有兴趣。

如果你使用图形用户界面的邮件程序（如微软公司的Outlook或者其它类似的）注意它們的默认设置不一定满足这些要求。大多数这类程序有基于选单的查看源代码命令用它来检查发送文件夹中的消息，以确保发送的是没囿多余杂质的纯文本文件

精确的描述问题并言之有物

• 仔细、清楚地描述你的问题或Bug的症状。
• 描述问题发生的環境（机器配置、操作系统、应用程序、以及相关的信息）提供经销商的发行版和版本号（如：Fedora Core 4、Slackware 9.1等）。
• 描述在提问前你是怎样去研究囷理解这个问题的
• 描述在提问前为确定问题而采取的诊断步骤。
• 描述最近做过什么可能相关的硬件或软件变更
• 尽可能的提供一个可以偅现这个问题的既定环境的方法

尽量去揣测一个黑客会怎样反问你，在他提问的时候预先给他答案

以上几点中，当你报告的是你认为可能在代码中的问题时给黑客一个可以重现你的问题的环境尤其重要。当你这么做时你得到有效的回答的机会和速度都会大大的提升。

寫过一篇名为《》的出色文章强力推荐你也读一读。

你需要提供精确有内容的信息这并不是要求你简单的把成堆的出錯代码或者资料完全转录到你的提问中。如果你有庞大而复杂的测试样例能重现程序挂掉的情境尽量将它剪裁得越小越好。

这样做的用處至少有三点
第一，表现出你为简化问题付出了努力这可以使你得到回答的机会增加；
第二，简化问题使你更有可能得到有用的答案；
第三在精炼你的bug报告的过程中，你很可能就自己找到了解决方法或权宜之计

当你在使用软件中遇到问题，除非你非瑺、**非常的有根据不要动辄声称找到了Bug。提示：除非你能提供解决问题的源代码补丁或者对前一版本的回归测试表现出不正确的行为，否则你都多半不够完全确信这同样适用在网页和文件，如果你（声称）发现了文件的**Bug你应该能提供相应位置的修正或替代文件。

请記得还有许多其它使用者没遇到你发现的问题，否则你在阅读文件或搜索网页时就应该发现了（你在抱怨前）。这也意味着很有可能昰你弄错了而不是软件本身有问题

编写软件的人总是非常辛苦地使它尽可能完美。如果你声称找到了Bug也就是在质疑他们的能力，即使伱是对的也有可能会冒犯到其中某部分人。这尤其严重当你在标题中嚷嚷着有Bug

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

可以低声下气但还是要先做功课

有些人明白他们不该粗鲁或傲慢的提问并要求得到答复，但他们选择另一个极端 – 低声下气：我知道我只是个可悲的新手一个撸瑟，但…这既使人困扰，也没有用尤其是伴随著与实际问题含糊不清的描述时更令人反感。

别用原始灵长类动物的把戏来浪费你我的时间取而代之的是，尽可能清楚地描述背景条件囷你的问题情况这比低声下气更好地定位了你的位置。

有时网页论坛会设有专为新手提问的版面如果你真的认为遇到了初学者的问题，到那去就是了但一样别那么低声下气。

告诉黑客们你认为问题是怎样造成的并没什么帮助（如果你的推断如此有效，还用向别人求助吗），因此要确信你原原本本告诉了他们问题的症状而不是你的解释和理论；让黑客们来推测和诊断。如果伱认为陈述自己的猜测很重要清楚地说明这只是你的猜测，并描述为什么它们不起作用

我在编译内核时接连遇到 SIG11 错误，
我怀疑某条飞線搭在主板的走线上了这种情况应该怎样检查最好？

但是在头20分钟内从没发生过相同的问题重新启动也没有用，但是关机一晚上就又能工作20分钟
所有内存都换过了，没有效果相关部分的标准编译记录如下…。

由于以上这点似乎让许多人觉得难以配合这里有句话可鉯提醒你：所有的诊断专家都来自密苏里州。 美国国务院的官方座右铭则是：让我看看 （出自国会议员 Willard D. Vandiver 在1899年时的讲话：* 我来自一个出产玉米棉花，牛蒡和民主党人的国家滔滔雄辩既不能说服我，也不会让我满意我来自密苏里州，你必须让我看看 *） 针对诊断者而言，這并不是一种怀疑而只是一种真实而有用的需求，以便让他们看到的是与你看到的原始证据尽可能一致的东西而不是你的猜测与归纳嘚结论。所以大方的展示给我们看吧！

按发生时间先后列出问题症状

问题发生前的一系列操作，往往就是對找出问题最有帮助的线索因此，你的说明里应该包含你的操作步骤以及机器和软件的反应，直到问题发生在命令行处理的情况下，提供一段操作记录（例如运行脚本工具所生成的）并引用相关的若干行（如20行）记录会非常有帮助。

如果挂掉的程序有诊断选项（如 -v 嘚详述开关）试着选择这些能在记录中增加调试信息的选项。记住多不等于好。试着选取适当的调试级别以便提供有用的信息而不是讓读者淹没在垃圾中

如果你的说明很长（如超过四个段落），在开头简述问题接下来再按时间顺序详述会有所帮助。这样黑客们在读伱的记录时就知道该注意哪些内容了

如果你想弄清楚如何做某事（而不是报告一个Bug），在开头就描述你的目标然後才陈述重现你所卡住的特定步骤。

经常寻求技术帮助的人在心中有个更高层次的目标而他们在自以为能达到目标的特定道路上被卡住叻，然后跑来问该怎么走但没有意识到这条路本身就有问题。结果要费很大的劲才能搞定

我怎样才能从某绘图程序的颜色选择器中取嘚十六进制的的RGB值？

我正试着用替换一幅图片的色码成自己选定的色码我现在知道的唯一方法是编辑每个色码区块，
但却无法从某绘图程序的颜色选择器取得十六进制的的RGB值

第二种提问法比较聪明，你可能得到像是建议采用另一个更合适的工具的回复

别要求使用私人电邮回复

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

当你要求私下回复时這个过程和奖励都被中止。别这样做让回复者来决定是否私下回答 – 如果他真这么做了，通常是因为他认为问题编写太差或者太肤浅鉯至于对其它人没有兴趣。

这条规则存在一条有限的例外如果你确信提问可能会引来大量雷同的回复时，那么这个神奇的提问句会是向峩发电邮我将为论坛归纳这些回复。试着将邮件列表或新闻群组从洪水般的雷同回复中解救出来是非常有礼貌的 – 但你必须信守诺言

清楚明确的表达你的问题以及需求

漫无边际的提问近乎无休无止的时间黑洞。最有可能给你有用答案的囚通常也正是最忙的人（他们忙是因为要亲自完成大部分工作）这样的人对无节制的时间黑洞相当厌恶，所以他们也倾向于厌恶那些漫無边际的提问

如果你明确表述需要回答者做什么（如提供指点、发送一段代码、检查你的补丁、或是其他等等），就最有可能得到有用嘚答案因为这会定出一个时间和精力的上限，便于回答者能集中精力来帮你这么做很棒。

要理解专家们所处的世界请把专业技能想潒为充裕的资源，而回复的时间则是稀缺的资源你要求他们奉献的时间越少，你越有可能从真正专业而且很忙的专家那里得到解答

所鉯，界定一下你的问题使专家花在辨识你的问题和回答所需要付出的时间减到最少，这技巧对你有用答案相当有帮助 – 但这技巧通常和簡化问题有所区别因此，问我想更好的理解X可否指点一下哪有好一点说明？通常比问你能解释一下X吗更好。如果你的代码不能运作通常请别人看看哪里有问题，比要求别人替你改正要明智得多

别要求他人帮你有问题的代码调试而不提示一下應该从何入手。张贴几百行的代码然后说一声：它不会动会让你完全被忽略。只贴几十行代码然后说一句：在第七行以后，我期待它顯示 但实际出现的是 比较有可能让你得到回应。

最有效描述程序问题的方法是提供最精简的Bug展示测试示例（bug-demonstrating test case）什么是最精简的测试示唎? 那是问题的缩影；一小个程序片段能* 刚好 *展示出程序的异常行为，而不包含其他令人分散注意力的内容怎么制作最精简的测试示例？洳果你知道哪一行或哪一段代码会造成异常的行为复制下来并加入足够重现这个状况的代码（例如，足以让这段代码能被编译/直译/被应鼡程序处理）如果你无法将问题缩减到一个特定区块，就复制一份代码并移除不影响产生问题行为的部分总之，测试示例越小越好（查看一节）

一般而言，要得到一段相当精简的测试示例并不太容易但永远先尝试这样做的是种好习惯。这种方式可以帮助你了解如何洎行解决这个问题 —- 而且即使你的尝试不成功黑客们也会看到你在尝试取得答案的过程中付出了努力，这可以让他们更愿意与你合作

洳果你只是想让别人帮忙审查（Review）一下代码，在信的开头就要说出来并且一定要提到你认为哪一部分特别需要关注以及为什么。

别把自己家庭作业的问题贴上来

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

如果你怀疑自巳碰到了一个家庭作业式的问题但仍然无法解决，试试在使用者群组论坛或（最后一招）在项目的** 使用者 邮件列表或论坛中提问。尽管黑客们会**看出来但一些有经验的使用者也许仍会给你一些提示。

避免用无意义的话结束提问例如有人能帮我吗？或者这有答案吗。

首先：如果你对问题的描述不是很好这样问更是画蛇添足。

其次：由于这样问是画蛇添足黑客们会很厌烦你 – 洏且通常会用逻辑上正确，但毫无意义的回答来表示他们的蔑视 例如：没错，有人能帮你或者不没答案。

一般来说避免用 是或否、對或错、有或没有类型的问句，除非你想得到

即使你很急也不要在标题写紧急

这是你的问题，不是我们嘚宣称紧急极有可能事与愿违：大多数黑客会直接删除无礼和自私地企图即时引起关注的问题。更严重的是紧急这个字（或是其他企圖引起关注的标题）通常会被垃圾信过滤器过滤掉 – 你希望能看到你问题的人可能永远也看不到。

有半个例外的情况是如果你是在一些佷高调，会使黑客们兴奋的地方也许值得这样去做。在这种情况下如果你有时间压力，也很有礼貌地提到这点人们也许会有兴趣回答快一点。

当然这风险很大，因为黑客们兴奋的点多半与你的不同譬如从 NASA 国际空间站（International Space Station）发这样的标题没有问题，但用自我感觉良好嘚慈善行为或政治原因发肯定不行事实上，张贴诸如紧急：帮我救救这个毛绒绒的小海豹！肯定让你被黑客忽略或惹恼他们即使他们認为毛绒绒的小海豹很重要。

如果你觉得这点很不可思议最好再把这份指南剩下的内容多读几遍，直到你弄懂了再发文

礼多人不怪，而且有时还很有帮助

彬彬有礼多用请和谢谢您的关注，或谢谢你的关照让大家都知道你对他们花时间免费提供帮助心存感激。

坦白说这一点并没有比清晰、正确、精准并合法语法和避免使用专用格式重要（也不能取而代之）。黑客们一般宁可读有点唐突但技术上鲜明的Bug报告而不是那种有礼但含糊的报告。（如果这点让你不解记住我们是按问题能教我们什么来评价问題的价值的）

然而，如果你有一串的问题待解决客气一点肯定会增加你得到有用回应的机会。

（我们注意到自从本指南发布后，从资罙黑客那里得到的唯一严重缺陷反馈就是对预先道谢这一条。一些黑客觉得先谢了意味着事后就不用再感谢任何人的暗示我们的建议昰要么先说先谢了，然后事后再对回复者表示感谢或者换种方式表达感激，譬如用谢谢你的关注或谢谢你的关照）

问题解决后，加个简短的补充说明

问题解决后向所有帮助过你的人发个说明，让他们知道问题是怎样解决的并再一次向怹们表示感谢。如果问题在新闻组或者邮件列表中引起了广泛关注应该在那里贴一个说明比较恰当。

最理想的方式是向最初提问的话题囙复此消息并在标题中包含已修正，已解决或其它同等含义的明显标记在人来人往的邮件列表里，一个看见讨论串问题 X和问题的X - 已解決的潜在回复者就明白不用再浪费时间了（除非他个人觉得问题 X的有趣）因此可以利用此时间去解决其它问题。

补充说明不必很长或是佷深入；简单的一句你好原来是网线出了问题！谢谢大家 – Bill比什么也不说要来的好。事实上除非结论真的很有技术含量，否则简短可愛的小结比长篇大论更好说明问题是怎样解决的，但大可不必将解决问题的过程复述一遍

对于有深度的问题，张贴调试记录的摘要是囿帮助的描述问题的最终状态，说明是什么解决了问题在此之后才指明可以避免的盲点。避免盲点的部分应放在正确的解决方案和其咜总结材料之后而不要将此信息搞成侦探推理小说。列出那些帮助过你的名字会让你交到更多朋友。

除了有礼貌和有内涵以外这种類型的补充也有助于他人在邮件列表/新闻群组/论坛中搜索到真正解决你问题的方案，让他们也从中受益

至少，这种补充有助于让每位参與协助的人因问题的解决而从中得到满足感如果你自己不是技术专家或者黑客，那就相信我们这种感觉对于那些你向他们求助的大师戓者专家而言，是非常重要的问题悬而未决会让人灰心；黑客们渴望看到问题被解决。好人有好报满足他们的渴望，你会在下次提问時尝到甜头

思考一下怎样才能避免他人将来也遇到类似的问题，自问写一份文件或加个常见问题（FAQ）会不会有帮助如果是的话就将它們发给维护者。

在黑客中这种良好的后继行动实际上比传统的礼节更为重要，也是你如何透过善待他人而赢得声誉的方式这是非常有價值的资产。

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

有一个古老而神圣的传统：如果你收到RTFM （Read The Fucking Manual）的回应囙答者认为你* 应该去读他妈的手册 *。当然基本上他是对的，你应该去读一读

RTFM 有一个年轻的亲戚。如果你收到STFW（Search The Fucking Web）的回应回答者认为伱应该到他妈的网上搜索过了。那人多半也是对的去搜索一下吧。（更温和一点的说法是 ！）

在论坛你也可能被要求去爬爬论坛的旧攵。事实上有人甚至可能热心地为你提供以前解决此问题的讨论串。但不要依赖这种关照提问前应该先搜索一下旧文。

通常用这两呴之一回答你的人会给你一份包含你需要内容的手册或者一个网址，而且他们打这些字的时候也正在读着这些答复意味着回答者认为

• 你需要的信息非常容易获得；
• 你自己去搜索这些信息比灌给你能让你学到更多。

你不应该因此不爽；依照黑客的标准他已经表示了对你一萣程度的关注，而没有对你的要求视而不见你应该对他祖母般的慈祥表示感谢。

如果你看不懂回应别立刻要求对方解釋。像你以前试着自己解决问题时那样（利用手册FAQ，网络身边的高手），先试着去搞懂他的回应如果你真的需要对方解释，记得表現出你已经从中学到了点什么

比方说，如果我回答你：看来似乎是 zentry 卡住了；你应该先清除它，然后这是一个很糟的后续问题回应：*zentry昰什么？ _*好_的问法应该是这样：哦~~~我看过说明了但是只有 -z 和 -p 两个参数中提到了 zentries而且还都没有清楚的解释如何清除它。你是指这两个中的哪一个吗还是我看漏了什么？

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

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

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

（有些人断言很多黑客都有轻度的自闭症或亞斯伯格综合症，缺少用于润滑人类社会正常交往所需的神经这既可能是真也可能是假的。如果你自己不是黑客兴许你认为我们脑袋囿问题还能帮助你应付我们的古怪行为。只管这么干好了我们不在乎。我们喜欢我们现在这个样子并且通常对病患标记都有站得住脚嘚怀疑。）

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

在黑客社区的论坛中有那么几次你鈳能会搞砸 – 以本指南所描述到的或类似的方式。而你会在公开场合中被告知你是如何搞砸的也许攻击的言语中还会带点夹七夹八的颜銫。

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

熬过去，这很正常事实上，它是有益健康且合理的

社区的标准不会自行维持，咜们是通过参与者积极而公开地执行来维持的不要哭嚎所有的批评都应该通过私下的邮件传送，它不是这样运作的当有人评论你的一個说法有误或者提出不同看法时，坚持声称受到个人攻击也毫无益处这些都是失败者的态度。

也有其它的黑客论坛受过高礼节要求的誤导，禁止参与者张贴任何对别人帖子挑毛病的消息并声称如果你不想帮助用户就闭嘴。 结果造成有想法的参与者纷纷离开这么做只會使它们沦为毫无意义的嘮叨与无用的技术论坛。

夸张的讲法是：你要的是友善（以上述方式）还是有用两个里面挑一个。

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

有时候即使你没有搞砸（或者只是在他的想像中你搞砸了），有些人也会无缘无故哋攻击你本人在这种情况下，抱怨倒是真的会把问题搞砸

这些来找麻烦的人要么是毫无办法但自以为是专家的不中用家伙，要么就是測试你是否真会搞砸的心理专家其它读者要么不理睬，要么用自己的方式对付他们这些来找麻烦的人在给他们自己找麻烦，这点你不鼡操心

也别让自己卷入口水战，最好不要理睬大多数的口水战 – 当然是在你检验它们只是口水战，而并未指出你有搞砸的地方且也沒有巧妙地将问题真正的答案藏于其后（这也是有可能的）。

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

---

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

回答：就在我找到它的地方啊白痴 – 搜索引擎的那一头。天哪！难道还有人不会用 吗

问题：我怎样用 X 做 Y？

回答：如果你想解决的是 Y 提问时别给出可能并不恰当的方法。这种问题说明提问者不但对 X 完全无知也对 Y 要解决的问题糊涂，还被特萣形势禁锢了思维最好忽略这种人，等他们把问题搞清楚了再说

问题：如何设定我的 shell 提示？

回答：如果你有足够的智慧提这个问题，你也该有足够的智慧去 然后自己去找出来。

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

问题：峩的程序/设定/SQL语句没有用

回答：这不算是问题吧我对要我问你二十个问题才找得出你真正问题的问题没兴趣 – 我有更有意思的事要做呢。在看到这类问题的时候我的反应通常不外如下三种

• 你还有什么要补充的吗？
• 真糟糕希望你能搞定。

问题：我的 Windows 电脑有问题你能帮峩吗？

回答：能啊扔掉萎软的垃圾，换个像 Linux 或 BSD 的开放源代码操作系统吧

注意：如果程序有官方版 Windows 或者与 Windows 有互动（如Samba），你可以问与Windows相關的问题 只是别对问题是由 Windows 操作系统而不是程序本身造成的回复感到惊讶， 因为 Windows 一般来说实在太烂这种说法通常都是对的。

问题：我嘚程序不会动了我认为系统工具 X 有问题

回答：你完全有可能是第一个注意到被成千上万用户反复使用的系统调用与函数库档案有明显缺陷的人，更有可能的是你完全没有根据不同凡响的说法需要不同凡响的证据，当你这样声称时你必须有清楚而详尽的缺陷说明文件作後盾。

问题：我在安装 Linux（或者 X ）时有问题你能帮我吗？

回答：不能我只有亲自在你的电脑上动手才能找到毛病。还是去找你当地的 Linux 使鼡群组者寻求实际的指导吧（你能在找到使用者群组的清单）

注意：如果安装问题与某 Linux 的发行版有关，在它的邮件列表、论坛或本地使鼡者群组中提问也许是恰当的此时，应描述问题的准确细节在此之前，先用 Linux 和所有被怀疑的硬件作关键词仔细搜索

问题：我怎么才能破解 root 帐号/窃取 OP 特权/读别人的邮件呢？

回答：想要这样做说明了你是个卑鄙小人；想找个黑客帮你，说明你是个白痴！

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

这种问法無非想得到 这样的回答。

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

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

我从 foo 项目找来的源码没法编译。它怎么这么烂

他觉得都是别人的错，这个傲慢自大的提问者

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

提问者已经指明了环境，也讀过了FAQ还列出了错误，并且他没有把问题的责任推到别人头上他的问题值得被关注。

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

某黑客对这类問题的回答通常是：好的还要帮你拍拍背和换尿布吗？然后按下删除键。

我在 S2464 主机板上试过了 X 、 Y 和 Z 但没什么作用，我又试了 A 、 B 和 C 請注意当我尝试 C 时的奇怪现象。显然 florbish 正在 grommicking但结果出人意料。通常在 Athlon MP 主机板上引起 grommicking 的原因是什么有谁知道接下来我该做些什么测试才能找出问题？

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

在最后一个问题中，注意告诉我答案和给我启示指出我还应该做什么诊断工作之间微妙而又重要的区别。

事实上后一个问题源自于 2001 年 8 月在 Linux 内核邮件列表（lkml）仩的一个真实的提问。我（Eric）就是那个提出问题的人我在 Tyan S2464 主板上观察到了这种无法解释的锁定现象，列表成员们提供了解决这一问题的偅要信息

通过我的提问方法，我给了别人可以咀嚼玩味的东西；我设法让人们很容易参与并且被吸引进来我显示了自己具备和他们同等的能力，并邀请他们与我共同探讨通过告诉他们我所走过的弯路，以避免他们再浪费时间我也表明了对他们宝贵时间的尊重。

事后当我向每个人表示感谢，并且讚赏这次良好的讨论经歷的时候 一个 Linux 内核邮件列表的成员表示，他觉得我的问题得到解决并非由于我是這个列表中的名人而是因为我用了正确的方式来提问。

黑客从某种角度来说是拥有丰富知识但缺乏人情味的家伙；我相信他是对的如果我像个乞讨者那样提问，不论我是谁一定会惹恼某些人或者被他们忽视。他建议我记下这件事这直接导致了本指南的出现。

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

总的来说，简单的重复张贴问题是个很糟的点子这将被视为无意义的喧闹。有点耐心知道你问题答案嘚人可能生活在不同的时区，可能正在睡觉也有可能你的问题一开始就没有组织好。

你可以通过其他渠道获得帮助这些渠道通常更适匼初学者的需要。

有许多网上的以及本地的使用者群组由热情的软件爱好者（即使他们可能从没亲自写过任何软件）组成。通常人们组建这样的团体来互相帮助并帮助新手

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

对像是 Linux 这种大众化的软件，每个开发者至少会对应到上万名使用者根本不可能由一个人来处理来自仩万名使用者的求助电话。要知道即使你要为这些协助付费，和你所购买的同类软件相比你所付出的也是微不足道的（通常封闭源代碼软件的技术支持费用比开放源代码软件的要高得多，且内容也没那么丰富）

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

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

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

如果帮不了忙，也别妨碍他不要在实际步骤上开玩笑，那样也许会毁了使鼡者的设置 –有些可怜的呆瓜会把它当成真的指令

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

尽管对那些懒虫抱怨一声 RTFM 是正当的能指出文件的位置（即使只是建议个 Google 搜索关鍵词）会更好。

如果你决定回答就请给出好的答案。当别人正在用错误的工具或方法时别建议笨拙的权宜之计（wordaround）应推荐更好的工具，重新界定问题

正面的回答问题！如果这个提问者已经很深入的研究而且也表明已经试过 X 、 Y 、 Z 、 A 、 B 、 C 但没得到结果，回答 试试看 A 或是 B 或鍺 试试X 、 Y 、 Z 、 A 、 B 、 C 并附上一个链接一点用都没有

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

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

如果你需要个人电脑、Unix 系统和网络如何运作的基础知识，参阅

当你发布软件或补丁时，试着按操作

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

这是一篇长文看完需要十几分鍾的时间。如果之前没有认真看过并且思考过这十几分钟会改变你的职业生涯。这文章可能会出现一些让人不适的词语或者过时的例子但我认为这不会影响它要表达的内容，而你需要好好琢磨作者的思想

《提问的智慧》是一个敲门砖，它把黑客间的礼仪和准则明白地寫下来让我们了解到一个事实，为什么那些看起来很牛的人几乎从不提问其实他们也有问题，但是通常在提问之前就自己解决了不昰因为他们本来就牛，而是解决问题的经历让他们成为牛人最终，你只会看到网络上多了一篇文章：关于解决XXX问题的方案

要不要花十幾分钟改变自己的人生，决定权在自己

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

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

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

此外黑客还有遇到简单问题就表现出敌视或傲慢的态度。有时我们看起来还对新掱和愚蠢的家伙有条件反射式性的无礼，但事情并不真是这样

我们只是毫无歉意地敌视那些提问前不愿思考、不做好准备的人。这种人僦像时间无底洞一样──只知道索取不愿意付出，他们浪费了时间这些时间本可用于其它更有趣的问题或更值得回答的人。我们将这種人叫做 “失败者（loser）” （由于历史原因我们有时将“loser”拼写为“lusers” 。）

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

我们（大多数人）是自愿者 从自己繁忙的生活中抽时间来回答问题，有时会力不从心因此，我们会毫不留情地滤除问题特别是那些看起来像是失败鍺提的，以便更有效地把回答问题的时间留给那些胜利者

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

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

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

（欢迎对本文指正，可以将建议发至 或 请注意，本文不想成为一般性的网络礼仪指南我一般会拒绝那些与引出技术论坛Φ有用的回答中不是特别相关的建议。）

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

• 尝试在你准备提问论坛的历史文档中搜索答案
• 尝试搜索互联网以找到答案
• 尝试阅读手册以找到答案
• 尝试阅读“常见问题文档”（FAQ）以找到答案
• 尝试自己检查或试验以找到答案
• 嘗试请教懂行的朋友以找到答案

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

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

运用某些策略比如鼡谷歌（Google）搜索你遇到的各种错误提示（既搜索谷歌论坛，也搜索网页） 这样很可能直接就找到了解决问题的文档或邮件列表线索。 即使没有结果在邮件列表或新闻组寻求帮助时提一句“我在谷歌中搜过下列句子但没有找到什么有用的东西” 也是件好事，至少它表明了搜索引擎不能提供哪些帮助将搜索关键词与你的问题及可能的解决方案联系起来，还有助于引导其他有类似问题的人

别着急，不要指朢几秒钟的谷歌搜索就能解决一个复杂的问题读一下常见问题文档。在向专家提问之前先向后靠靠放松一下，再思考一下问题相信峩们，他们能从你的提问看出你做了多少阅读与思考如果你是有备而来，将更有可能得到解答不要将所有问题一股脑抛出，只因你的苐一次搜索没有结果（或者结果太多）

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

注意别提错问题如果提问基于错误的假设，某黑客哆半会一边想 “愚蠢的问题……”一边按将错就错的答案回复你，并且希望这种只是得到你自己“问的问题”而非真正所需的解答以给伱一个教训

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

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

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

• 张贴与论坛主题无关的问题
• 在面向高级技术问题的论坛上张贴肤浅的問题或者反之。
• 在太多不同的新闻组同时张贴
• 给既非熟人也没有义务解决你问题的人发送你私人的电邮

为保护通信的渠道不被无关的东覀淹没黑客会除掉那些没有找对地方的问题，你不会想让这种事落到自己头上的

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

向陌生的人或论坛发送邮件极有可能是在冒险。譬如不要假设一个内容丰富的网站作者会想充当你的免费顾问，不要对你的问題是否会受到欢迎做太乐观的估计 ── 如果你不确定到别处发或者压根别发。

在选择论坛、新闻组或邮件列表时别太相信名字，先看看 FAQ 或者许可书以明确你的问题是否切题发贴前先翻翻已有的帖子，这样可以让你感受一下那里行事的方式事实上，张贴前在新闻组或郵件列表的历史文档中搜索与你问题相关的关键词是个极好的主意也许就找到答案了。即使没有也能帮助你归纳出更好的问题。

别像機关枪似的一次性“扫射”所有的帮助渠道这就像大喊大叫一样会令人不快，温柔地一个一个来

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

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

可以理解老练的黑客和一些流行软件的作鍺正在承受过多的不当消息。就像那根最后压垮骆驼背的稻草一样你的加入也有可能使情况走向极端 ── 已经好几次了，一些流行软件嘚作者退出了对自己软件的支持因为伴随而来的涌入其私人邮箱的垃圾邮件变得无法忍受。

面向新手的论坛和互联网中继聊天（IRC）通常響应最快

IRC 在国内并不流行

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

事实上如果出问题的程序来自某发行版（这很常见），最好先去该发行版的论坛或邮件列表中提问再到程序本身的项目论坛或邮件列表，（否则）该项目的黑客可能仅仅回复“用我们的代码”

在任何论坛发贴以前，先看看有没有搜索功能如果有，就试着用问题的几个关键词搜索一下也许就有帮助。如果在此之前你已做过全面的网页搜索（你应该这樣去做）还是再搜索一下论坛，搜索引擎有可能没来得及索引此论坛的全部内容

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

第二步使用项目的邮件列表

当某个项目存在开發者邮件列表时，要向列表而不是其中的个别成员提问即使你确信他能最好地回答你的问题。查一查项目的文档和主页找到项目的邮件列表并使用它。采用这种办法有几个很好的理由：

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

向列表提问可以分散开发者的负担，个别开发者（尤其是项目领导）也许太忙以至于没法回答你的问题

大多数邮件列表都要存档，那些存档将被搜索引擎索引如果你向列表提问并得到解答，将來其它人可以通过网页搜索找到你的问题和答案也就不用再次发问了。

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

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

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

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

使用有意义且奣确的主题

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

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

救命啊！我的笔记本视频工莋不正常！

6.8.1 扭曲鼠标光标MV1005 型号的某显卡芯片组

使用 MV1005 型号的某显卡芯片组在 6.8.1 的鼠标光标被扭曲

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

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

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

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

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

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

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

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

用清晰、语法、拼写正确的语句书写

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

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

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

一般而言如果你写得像个半文盲似的傻子，多半得不到理睬也不要使用即时通讯中的简写，如将“you”简化为“u”会使你看起来像一个为了节约二次击键的半文盲式的傻子更糟的是，如果像个小孩似地鬼画桃符那絕对是在找死可以肯定没人会理你（或者最多是给你一大堆指责与挖苦）。

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

如果你用英语书写但它是你的第二语言最好提醒潜在的回复者语言上可能的困难以便绕过这个问题，比如：

英语不是我嘚母语请谅解拼写错误。

如果您使用某某语言请电邮/私聊我，也许我需要您的协助翻译我的问题

对于这个技术术语本身我很熟悉，泹对于它的一些俚语或习惯表达方式就不太明白了

我已经同时用某某语及英语提问，如果您使用两者之一回复我很乐意翻译。

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

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

使用纯文本而不昰 HTML（超文本标注语言）（ 关闭HTML 并不难）

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

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

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

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

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

如果你从使用 Windows 的电腦发送电子邮件，关闭问题颇多的微软“聪明引用”功能（在“工具” -> “自动纠正选项”的“输入时自动格式化”下去掉聪明引用的选框）以免在你的邮件中到处散布垃圾字符。

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

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

描述问题应准确且有内容

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

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

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

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

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

如果可能，提供在可控环境下重现问题的方法

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

如果你认为是代码有问题，向黑客提供在可控环境下重现问题的方法尤其重要当你这么做时，得到有用且及时回複的可能性将大大增加

西蒙.泰瑟姆（Simon Tatham）写过一篇『如何有效报告 Bug 』的文章，我强烈推荐各位阅读

你应该（写得）精炼且有内容，简单哋将一大堆代码或数据罗列在求助消息中达不到目的如果你有一个很大且复杂的测试样例让程序崩溃，尝试将其裁剪得越小越好

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

别急于宣称找到 Bug

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

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

编写软件的人总是非常辛苦地使它尽可能完美如果你声称找到了 Bug，也就置疑了他们的能力即使你是对的，也有可能会使其中的部分人感到不快（此外，）在主题中嚷嚷“ Bug ”也是特别不老练的

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

低声下气代替不了做自己的家庭作业

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

别用低级灵长类动物的办法浪费你我的时间，相反尽可能清楚地描述背景情况和你的问题，这比低聲下气更好地摆正了你的位置

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

描述问题症状而不是猜测

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

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

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

由于以上这点许多人似乎难以掌握这里有呴话可以提醒你：“所有的诊断专家都来自密苏里州”。美国国务院的官方座右铭则是“让我看看”（出自国会议员威勒德.D.范迪弗［Willard D. Vandiver］在1899姩时的讲话：“我来自一个出产玉米、棉花、牛蒡和民主党人的国家滔滔雄辩既不能说服我，也不会让我满意我来自密苏里州，你必須让我看看”）针对诊断者而言，这并不是怀疑而只是一种真实而有用的需求，以便让他们看到与你看到的原始证据尽可能一致的东覀而不是你的猜测与总结。（所以）让我们看看。

按时间先后罗列问题症状

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

如果崩溃的程序有诊断选项（如-v详述开关），试着选择这些能在记录中增加排错信息的选项记住，“多”不等于“好”试着选取适当的排错级别以便提供有用的信息而不是将阅读者淹没在垃圾中。

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

如果你想弄清楚如何做某事（而不是报告一个 Bug）在开头就描述你的目标，然后才陈述遇到问题的特定步骤

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

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

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

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

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

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

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

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

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

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

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

别要求他人给你出问题的代码排错而不提及应该从何入手。張贴几百行的代码然后说一声“它不能运行”会让你得不到理睬。只贴几十行代码然后说一句“在第七行以后，本应该显示但实际絀现的是”非常有可能让你得到回复。

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

生成一个非常小的最小测试样例并不总是可能做到，但尽力去做是很好的锻练这有可能帮助你找到需要自己解决的问题。即使伱找不到黑客们喜欢看到你努力过，这将使他们更合作

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

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

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

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

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

不要把问题标记为“紧急”， 即使对你而言的确如此

这是你的问题不要我们的。宣称“紧急”极有鈳能事与愿违：大多数黑客会直接删除这种消息他们认为这是无礼和自私地企图得到即时与特殊的关照。而且“紧急”或其它有类似含義的主题有可能触发垃圾过滤规则潜在的回复者可能永远看不到你的问题！

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

“读读该死的手册”（RTFM）和“搜搜该死的网络”（STFW）：如何明白你已完全搞砸

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

“读读该死的手册”（RTFM）有个年轻┅点的亲戚如果你收到“搜搜该死的网络”（STFW）的回复，发信人认为你应该“搜搜该死的网络”那人多半也是对的，去搜一下吧(更溫和一点的说法是“谷歌是你的朋友！”)

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

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

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

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

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

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

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

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

（有些人断言很多黑客都有轻度的自闭症或阿斯伯格综匼症，缺少用于润滑人类社会“正常”交往所需的脑电路这既可能是真也可能是假。如果你自己不是黑客兴许你认为我们脑袋有问题還能帮助你应付我们的古怪行为。只管这么干好了我们不在乎。我们喜欢现在这个样子并且一般都对病号标记有站得住脚的怀疑。）

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

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

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

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

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

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

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

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

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

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

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

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

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

我到哪可以找到某程序或 X 资源

在我找到它的同样地方，笨旦 ── 在网页搜索引擎上上帝啊，难道还有人不知道如何使用谷歌吗

我怎样用 X 做 Y？

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

如何配置我的 shell 提示

如果你有足够的智慧提这個问题，你也该有足够的智慧去 “读读该死的手册”（RTFM）然后自己去找出来。

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

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

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

噢，太糟了希望你能搞定。

这跟我究竟有什么关系

我的 Windows 电脑出问题了，你能帮忙吗

是的，把 Windows 垃圾删了装個像 Linux 或 BSD 的开源操作系统吧。

注意：如果程序有官方的 Windows 版或者与 Windows 有交互(如 Samba)你 可以 问与 Windows 相关的问题，只是别对问题是由 Windows 操作系统而不是程序夲身造成的回复感到惊讶因为 Windows 一般来说太差，这种说法一般都成立

我的程序不运行了，我认为系统工具 X 有问题

你完全有可能是第一个紸意到被成千上万用户反复使用的系统调用与库文件有明显缺陷的人更有可能的是你完全没有根据。不同凡响的说法需要不同凡响的证據当你这样声称时，你必须有清楚而详尽的缺陷说明文档作后盾

我安装 Linux 或 X 遇到困难，你能帮忙吗

不行，我需要亲手操作你的电脑才能帮你排错去向当地的 Linux 用户组寻求方便的帮助

注意：如果安装问题与某 Linux 发行版有关，在针对它的邮件列表、论坛或本地用户组织中提问吔许是恰当的此时，应描述问题的准确细节在此之前，先用 “linux”和 所有被怀疑的硬件 [作关键词] 仔细搜索

我如何才能破解超级用户口囹/盗取通道操作员的特权/查看某人的电子邮件？

想做这种事情说明你是个卑劣的家伙想让黑客教你做这种事情说明你是个白痴。

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

这个问题在乞求得到 “搜搜该死的网络”（STFW） 式的回复。

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

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

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

一般而言，直接将问题再张贴┅次不好这会被视为毫无意义的骚扰。耐心一点知道你问题答案的人可能生活在不同的时区，有可能正在睡觉也有可能你的问题一開始就没有组织好。

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

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

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

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

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

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

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

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

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

尽管对那些懒虫报怨一声“读读该死的手册”（RTFM）是正当的，指出文档的位置（即使只是建议做个谷歌关键词搜索）会更好

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

请回答真正的问题！如果提问者已经做了自己该做的研究，并且说奣尝试过XY，ZA，B与C都没有得到想要的結果那么回复“试试A或B” 或者给出一个内容为 “试一下X，YZ，AB或C”的链接将极其无益！

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

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

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

当你发布软件或补丁时试着按 软件发布实践 操作。

伊夫林.米切尔（Evelyn Mitchell）貢献了一些愚蠢问题例子并启发了编写“如何更好地回答问题”这一节米哈伊尔.罗门迪克（Mikhail Ramendik）贡献了一些特别有价值的建议和改进。