提问的智慧.docx
《提问的智慧.docx》由会员分享，可在线阅读，更多相关《提问的智慧.docx（26页珍藏版）》请在冰点文库上搜索。
提问的智慧
弃权申明
许多项目的网站在如何取得帮助的部分链接了本文，这没有关系，也是我们想要的。
但如果你是该项目生成此链接的网管，请在链接附近显著位置注明“我们不是此项目的服务部！
”
我们已经遭受没有此说明带来的痛苦，不断受到一些白痴的骚扰。
他们认为既然我们发表了此文，那么我们就有责任解决世上所有技术问题！
如果你因为需要帮助阅读了本文，然后带着可以直接从作者那取得帮助的印象离开，你就不幸成了那些白痴之一。
不要向我们提问，我们不会理睬的。
我们在这只是给你说明如何从那些真正懂得你软硬件问题的人那里取得帮助的方法，99%的时间我们不会是那些人。
除非你确信此文作者是你遇到问题方面的专家，请不要打扰，这样大家都更开心一点。
引言
在黑客的世界，你所提技术问题的回答很大程度上取决于你提问的方式与解决此问题的难度，本文将教你如何提问才更有可能得到满意的答复。
开源程序的使用已经很广，你通常可以从其它更有经验的用户而不是黑客那里得到回答。
这是好事，他们一般对新手常有的毛病更容忍一点。
然尔，使用我们介绍的方法象对待黑客那样对待这些有经验的用户，通常能最有效地得到问题的解答。
第一件需要明白的事是黑客喜欢难题和激发思考的好问题。
假如不是这样，我们也不会写本文了。
如果你能提出一个有趣的问题让我们咀嚼玩味，我们会感激你。
好的问题是种激励与礼物，帮助我们发展认知，揭示没有注意或想过的问题。
在黑客中，“好问题！
”是非常真挚的赞许。
除此而外，黑客有遇到简单问题就表现出敌视或傲慢的名声，有时候我们看起来还对新手和愚蠢的家伙有条件反射式的无礼，但并不真正是这样。
我们只是毫无歉意地敌视那些提问前不愿思考、不做自己该做之事的人。
这种人就象时间无底洞──他们只知道获取，不愿意付出，他们浪费了时间，这些时间本可用于其它更值得回答的人和更有趣的问题。
我们将这种人叫做“失败者（loser）”（由于历史原因，我们有时将“loser”拼为“lusers"）
我们注意到许多人只想用我们写的软件，他们对学习技术细节没有兴趣。
对大多数人而言，计算机只是种工具，是种达到目的的手段。
他们要生活并且有更要紧的事要做，我们承认这点，也从不指望每个人都对这些让我们着迷的技术问题感兴趣。
不过，我们回答问题的风格是为了适应那些真正对此有兴趣并愿意主动参与问题解决的人，这一点不会变，也不该变。
如果这都变了，我们就会在自己能做得最好的事情上不再那么犀利。
我们（多数）是自愿者，从自己繁忙的生活中抽时间来回答问题，有时会力不从心。
因此，我们会无情地滤除问题，特别是那些看起来象是失败者的，以便更有效地把回答问题的时间留给那些“胜利者”
如果你认为这种态度令人憎恶、以施惠者自居或傲慢自大，请检查你的假设，我们并未要求你屈服──事实上，假如你做了该做的努力使之成为可能，我们中的大多数人非常乐意平等地与你交流并欢迎你接纳我们的文化。
试图去帮助那些不愿自救的人对我们简直没有效率，不懂没有关系，但愚蠢地行事不行。
所以，你不必在技术上很在行才能吸引我们的注意，但你必须表现出能引导你在行的姿态──机敏、思考、善于观察、乐于主动参与问题的解决。
如果你做不到这些使你与众不同的事情，我们建议你付钱跟别人签商业服务合同，而不是要求黑客无偿帮助。
如果你决定向我们求助，你不会想成为一名失败者，你也不想被看成一个失败者。
得到快速有效回复的最好方法是使提问者看起来象个聪明、自信的人，并且暗示只是碰巧在某一特别问题上需要帮助。
（欢迎对本文指正，可以将建议发至esr@。
请注意，本文不想成为一般性的网络礼仪指南，我一般会拒绝那些与引出技术论坛中有用的回复不特别相关的建议）
提问前
在通过电子邮件、新闻组或网页论坛提技术问题之前，做以下事情：
尝试搜索互联网以找到答案
尝试阅读手册以找到答案
尝试阅读FAQ（常见问题）文档以找到答案
尝试自己检查或试验以找到答案
尝试请教懂行的朋友以找到答案
如果你是程序员，尝试阅读源代码以找到答案
提问时，请先表述你已经做了上述事情，这将有助于建立你不是寄生虫与浪费别人时间的印象。
最好再表述你从中学到的东西，我们喜欢回答那些表现出能从答案中学习的人。
使用某些策略，比如用Google搜索你遇到的错误提示（既搜索网页也查查讨论组），可能就直接找到了解决问题的文档或邮件列表线索。
即使没有结果，在电子邮件或新闻组张贴问题时提一句“我在Google中查过下列句子但没有找到什么有用的东西”也是件好事。
准备你的问题，彻底地思考。
轻率的提问只能得到轻率的回答，或者压根没有。
在提问时，越是表现出做过思考并在努力解决问题，你越有可能得到实际帮助。
注意别提错问题。
如果提问基于错误的假设，某黑客多半会一边想”愚蠢的问题……“，一边用按照问题字面的无用答案回复你，并且希望这种只是得到字面回答而不是真正所需的经历给你一个教训。
永远不要假设你有资格得到解答。
你没有这种资格，毕竟你没有为此服务付费。
如果你能够提出有内容、有趣和激励思考的问题──那种毫无疑问能够向社区贡献经验而不仅仅是消极地要求从别人那获取知识的问题，你将“挣到”答案。
另一方面，表明你能够也乐意参与问题的解决是个很好的开端。
“有没有人能指个方向？
”、“我这还漏点什么？
”、“我应该查哪些网站？
”通常要比“请给出我可以用的完整步骤”更容易得到回复，因为你表明了只要有人能指个方向你就很乐意完成剩下的过程。
提问时
仔细挑选论坛
要对在哪提问留心，如果你做了下述事情，多半会被一笔勾销或被看成“失败者”：
张贴与论坛主题完全无关的问题
在面向高级技术问题的论坛上提非常初浅的问题，或者反之。
在太多不同的新闻组同时交叉张贴
给既非熟人也没有义务解决你问题的个人张贴你私人的电子邮件
为保护通信的渠道不被无关的东西淹没，黑客会除掉那些没有找对地方的问题，你不会想有这种经历的。
所以第一步是找对论坛，Google与其它搜索引擎还是你的朋友，可以用它们搜索与你遇到困难的软硬件问题最相关的项目的网站。
那里通常都有项目的FAQ列表、邮件列表及其文档的链接。
如果你的努力（包括阅读FAQ）都没有结果，这些邮件列表就是最后能取得帮助的地方。
项目的网站也许还有报告臭虫的流程或链接，如果是这样，去看看。
向陌生的人或论坛发送邮件极有可能是在冒险。
譬如，不要假设一个富含信息的网页的编写者想充当你的免费顾问，不要对你的问题是否会受到欢迎做乐观的估计──如果你不确定，向别处发或者根本别发。
在选择网页论坛、新闻组或邮件列表时，不要太相信名字，先看看FAQ或者许可书以明确你的问题是否与其主题相关。
张贴前先翻翻已有的帖子可以帮助你感受一下那里行事的方式。
事实上，张贴之前在新闻组或邮件列表中搜索与你问题相关的关键词是个很好的主意，也许就找到答案了。
即使没有，也能帮助你整理出更好的问题。
别象机关枪似的一次性“扫射”所有的帮助通道，那就象大嚷大叫并使人不快。
一个一个地来。
弄清楚你的主题！
最典型的错误之一是在某种致立于跨Unix和Windows平台的语言、库或工具的论坛中提关于操作系统程序接口的问题。
如果你不明白为什么这是大错，最好在搞清楚概念前什么也别问。
一般来说，在仔细挑选的公共论坛中提问比在私有论坛中提同样的问题更容易得到有用的回复。
有许多理由支持这一点，一是看潜在的回复者有多少，二是看论坛的参与者有多少，黑客更愿回答能启发多数人的问题。
1111
可以理解，老练的黑客和一些流行软件的作者正在收到超出他们承受能力的不当消息。
就象那根多出来就可以压垮骆驼背的稻草一样，你的加入也可能会使情况走向极端──已经好几次了，一些流行软件的作者退出了对其软件的支持，因为伴随而来的涌向其私人邮箱的大量无用消息变得无法忍受。
面向新手的网页论坛和IRC通常响应最快
本地的用户组织或者你所用的Linux发行版也许正在宣传新手取得帮助的网页论坛或IRC（互联网中继聊天）（在非英语国家，新手论坛很可能还是邮件列表），这些地方是开始提问的好去处，尤其是当你觉得遇到的也许只是相对简单或者一般的问题时。
经过宣传的IRC通道是个公开邀请提问的地方，通常可以得到实时的回复。
事实上，如果出问题的程序来自某发行版（这很常见），在程序的项目论坛或列表提问前最好先在发行版的论坛或列表中问问，（否则）项目的黑客可能仅仅回复“用我们的代码”
在任何网页论坛张贴之前，先看看是否有搜索功能。
如果有，就试试用问题的几个关键词搜索一下，也许就有帮助。
如果在此之前你已做过全面的网页搜索（你应该这样做），还是再搜索一下论坛，搜索引擎最近也许还没有索引此论坛的全部内容。
通过网页论坛或IRC频道提供项目的用户支持有增长的趋势，电子邮件交流则更多地为项目开发保留。
先在网页论坛或IRC中寻求与项目相关的帮助。
第二步，使用项目邮件列表
当某项目存在开发者邮件列表时，即使你确信谁能最好地回答问题，也要向列表而不是其中的个体提问。
检查项目的文档和主页，找到项目的邮件列表并使用它。
采用这种策略有几个好理由：
任何向单个开发者提的足够好的问题也将对整个项目组有益。
相反，如果你认为自己的问题对整个项目组来说太愚蠢，这也不能成为打扰单个开发者的理由。
向列表提问可以平衡开发者的负担，单个开发者（特别是项目领导）也许太忙以至于无法回答你的问题。
大多数邮件列表有历史文档并被搜索引擎索引，其它人可以通过网页搜索找到你的问题和答案而不用再次在邮件列表中发问。
如果某些问题经常被问到，开发者可以利用此信息改进文档或软件本身以使其更清楚。
如果只是私下提问，就没有人能看到最常见问题的完整场景。
如果一个项目既有“用户”也有“开发者”（或“黑客”）邮件列表或网页论坛，而你又不摆弄那些代码，向“用户”列表或论坛提问。
不要假设自己在开发者列表中会受欢迎，那些人多半会遭受你的噪音干扰。
然尔，如果你确信你的问题不一般，而且在“用户”列表或论坛中几天都没有回复，可以试试“开发者”列表或论坛。
建议你在张贴前最好先暗暗地观察几天以了解那的行事方式（事实上这是参与任何私有或半私有列表的好主意）
如果你找不到一个项目的邮件列表，而只能查到项目维护者的地址，只管向其发信。
即便在这种情况下，也别假设（项目）邮件列表不存在。
在你的电子邮件中陈述你已经试过但没有找到合适的邮件列表，也提及你不反对将自己的邮件转发给他人（许多人认为，即使没什么秘密，私人电子邮件也不应该被公开。
通过允许将你的电子邮件转发他人给了相应人员处置你邮件的选择）。
使用明确而有意义的主题
在邮件列表、新闻组或网页论坛中，主题是你在五十个或更少的字符以内吸引有资格的专家注意的黄金机会，不要用诸如“请帮我”（更别提大写的“请帮我！
！
！
！
”，这种主题的消息会被条件反射式地删掉）之类的唠叨浪费机会。
不要用你痛苦的深度来打动我们，相反，要在这点空间中使用超级简明扼要的问题描述。
使用主题的好惯例是“对象──偏差”（式的描述），许多技术支持组织就是这样做的。
在“对象”部分指明是哪一个或哪一组东西有问题，在“偏差”部分则描述与期望行为不一致的地方。
愚蠢：
救命啊！
我的笔记本视频工作不正常！
明智：
XFree864.1扭曲鼠标光标，某显卡MV1005型号的芯片组
更明智：
使用某显卡MV1005型号芯片组的XFree864.1的鼠标光标被扭曲
编写“对象──偏差”式描述的过程有助于你更具体地组织你的问题。
是什么被影响了？
仅仅是鼠标光标或者还有其它图形？
只在XFree86中出现？
或只是在其4.1版中？
是针对某显卡？
或者只是其MV1005型号的芯片组？
一个黑客只需描一眼就能够立即明白什么是你遇到的问题，什么是你自己的问题。
更一般地，想象一下在只显示主题的文档索引中查找。
让你的主题更好地反映问题，可以使下一个搜索类似问题的人能够在文档中直接找到答案的线索而不用再次张贴提问。
如果你想在回复中提问，确保改变主题以表明你是在问一个问题，一个主题象“re:
测试”或“re:
新臭虫”的消息不太可能引起足够的注意。
同时，将回复中与新主题不甚相关的引用内容尽量删除
对于列表消息，不要直接点击回复（按钮）来开始一个新的线索，这将限制你的观众。
有些邮件阅读程序，比如mutt，允许用户按线索排序并通过折叠线索来隐藏消息，这样做的人永远看不到你发的消息。
仅仅改变主题还不够。
mutt和其它邮件阅读程序还要检查主题以外的其它邮件头信息，以便为其指定线索，所以宁可发一个全新的邮件。
在网页论坛，因为消息与特定的线索紧密结合并且通常在线索之外不可见，好的提问方式略有不同，通过回复提问并不要紧（一些论坛甚至不允许在回复中出现分离的主题，而且这样做了基本上没有人会去看）。
不过通过回复提问本身就是令人怀疑的做法，因为它们只会被正在查看该线索的人读到。
所以，除非你只想在该线索当前活跃的人群中提问，还是另起炉灶比较好。
使之更易回复
以“请向……回复”来结束问题多半会使你得不到回答。
如果你觉得花几秒钟在邮件客户端设置一下回复地址都麻烦，我们也觉得花几秒钟考虑你的问题更麻烦。
如果你的邮件客户端程序不支持这样做，换个好点的。
如果是操作系统不支持所有这种邮件客户端程序，也换个好点的。
在网页论坛，要求通过电子邮件回复是完全无礼的，除非你确信回复的信息也许是机密的（而且有人会为了某种未知的原因只让你而不是整个论坛知道答案）。
如果你只是想在有人回复线索时得到电子邮件提醒，可以要求论坛发送。
几乎所有论坛都提供诸如“留意本线索”、“有回复发送邮件”的功能。
使用清晰、语法与拼写正确的语句
经验告诉我们，粗心与草率的作者通常也粗心与草率地思考和编程（我敢打赌）。
为这些粗心与草率的思考者回答问题没有什么好处，我们宁可将时间花在其它地方。
清楚、完整地表达你的问题非常重要。
如果你觉得这样做麻烦，我们也觉得注意（你的问题）麻烦。
花点额外的精力斟酌一下字句，用不着太僵硬与正式──事实上，黑客文化很看重能准确地使用非正式、俚语和幽默的语句。
但它必须很准确，而且有迹象表明你是在思考和关注问题。
正确地拼写、使用标点和大小写，不要将“its”混淆为“it's”，“loose”搞成“lose”或者将“discrete”弄成“discreet”。
不要全部用大写，这会被看成无礼的大声嚷嚷（全部小写也好不到哪去，因为不易阅读。
AlanCox[注：
著名黑客，Linux内核的重要参与者]也许可以这样做，但你不行）。
一般而言，如果你写得象个半文盲似的傻子，多半得不到理睬。
如果象个小孩似地乱写乱画那绝对是在找死，可以肯定没人会理你（或者最多是给你一大堆指责与挖苦）。
如果在非母语论坛中提问，你的拼写与语法错误会得到有限的宽容，但懒惰完全不会被容忍（是的，我们通常看得出其中的差别）。
同时，除非你知道回复者使用的语言，请使用英语书写。
繁忙的黑客一般会直接删除用他们看不懂语言写的消息。
在互联网上英语是工作语言，用英语书写可以将你的问题不被阅读就被直接删除的可能降到最低。
使用易懂的格式发送问题
如果你人为地将问题搞得难以阅读，它多半会被忽略，人们更愿读易懂的问题，所以：
使用文本而不是HTML（超文本标注语言）（关闭HTML并不难）
使用MIME（多用途互联网邮件扩展）附件通常没有问题，前提是真正有内容（譬如附带的源文件或补丁），而不仅仅是邮件客户端程序生成的模板（譬如只是消息内容的拷贝）。
不要发送整段只是单行句子但多次折回的邮件（这使得回复部分内容非常困难）。
设想你的读者是在80个字符宽的文本终端阅读邮件，设置你的行折回点小于80列。
但是，也不要用任何固定列折回数据（譬如直接传送的日志文件或会话记录）。
数据应该原样包含，使回复者确信他们看到的与你看到的东西一样。
在英语论坛中，不要使用'Quoted-Printable'MIME编码发送消息。
这种编码对于张贴非ASCII语言可能是必须的，但很多邮件代理程序并不支持。
当它们分断时，那些文本中四处散布的“=20”符号既难看也分散注意力。
永远不要指望黑客们阅读使用封闭的专用格式编写的文档，诸如微软公司的Word或Excel文件等，大多数黑客对此的反应就象有人将还在冒热气的猪粪倒在你门口时你的反应一样。
即使他们能够处理，他们也很厌恶这么做。
如果你从使用视窗的电脑发送电子邮件，关闭微软愚蠢的“聪明引用”功能，以免在你的邮件中到处散布垃圾字符。
在网页论坛，勿滥用“表情符号”和“html”功能（当它们提供时）。
一两个表情符号通常没有问题，但花哨的彩色文本倾向于使人认为你是个无能之辈。
过滥地使用表情符号、色彩和字体会使你看来象个傻笑的小姑娘。
这通常不是个好主意，除非你只是对性而不是有用的回复更有兴趣。
如果你使用图形用户界面的邮件客户端程序（如网景公司的Messenger、微软公司的Outlook或者其它类似的），注意它们的缺省配置不一定满足这些要求。
大多数这类程序有基于菜单的“查看源码”命令，用它来检查发送文件夹中的消息，以确保发送的是没有多余杂质的纯文本文件。
描述问题应准确且有内容
仔细、清楚地描述问题的症状
描述问题发生的环境（主机，操作系统，应用程序，任何相关的），提供销售商的发行版和版本号（如：
“FedoraCore2”、“Slackware9.1”等）
描述提问前做过的研究及其理解。
描述提问前为确定问题而采取的诊断步骤。
描述最近对计算机或软件配置的任何相关改变。
尽最大努力预测黑客会提到的问题，并提前备好答案。
SimonTatham写过一篇叫如何有效报告臭虫的文章，我强烈推荐各位阅读。
多不等于准确
你应该（写得）准确且有内容，简单地将一大堆代码或数据“倾倒”在求助消息中达不到目的。
如果你有一个很大且复杂的测试样例让程序崩溃，尝试将其裁剪得越小越好。
至少有三个理由支持这点。
第一，让别人看到你在努力简化问题使你更有可能得到回复。
第二，简化问题使你更有可能得到有用的回复。
第三，在提纯臭虫报告的过程中，你可能自己就找到了解决问题的方法或权宜之计。
别动辄声称找到臭虫
当你在一个软件中遇到问题，除非你非常、非常的有根据，不要动辄声称找到了臭虫。
提示：
除非你能提供解决问题的源代码补丁，或者对前一版本的回归测试表现出不正确的行为，否则你都多半不够完全确信。
对于网页和文档也如此，如果你（声称）发现了文档的“臭虫”，你应该能提供相应位置的替代文本。
记住，还有许多其它用户未经历你遇到的问题，否则你在阅读文档或网页搜索时就应该发现了（你在报怨前已经做了这些，是吧？
）。
这也意味着很有可能是你弄错了而不是软件本身有问题。
编写软件的人通常非常辛苦地使它尽可能完美。
如果你声称找到了臭虫，也就暗示他们做错了什么，而这几乎总会使人不快──即使你是对的，在主题中嚷嚷“臭虫”也是特别不老练的。
提问时，即使你私下非常确信已经发现一个真正的臭虫，最好写得象是你做错了什么。
如果真的有臭虫，你会在回复中看到这点。
这么做的话，如果真有虫子，维护者就会向你道歉，这总比你弄砸了然后欠别人一个道歉要强。
低声下气不能代替自己应做之事
有些人明白他们不应该粗鲁或傲慢地行事并要求得到答复，但他们退到相反的低声下气的极端，“我知道我只是个什么也不是、什么也不懂的失败者，但……”。
这既使人困扰也没有帮助，当伴随着对实际问题含糊的描述时还特别令人反感。
别用低级灵长类动物的策略浪费大家的时间，相反，尽量清楚地表述背景事实和你的问题，这比低声下气更好地摆正了你的位置。
有时，网页论坛设有单独的初学者提问区域，如果你真的认为遇到了初浅的问题，到那去就是了，但一样别低声下气。
描述问题症状而不是猜测
告诉黑客你认为是什么导致了问题是没有用的（如果你的诊断理论是了不起的东西，你还会向他人咨询求助吗？
）。
所以，确保只是告诉他们问题的原始症状，而不是你的解释和理论，让他们来解释和诊断。
如果你认为陈述你的猜测很重要，清楚地说明这只是你的猜测并描述为什么它们不起作用。
愚蠢：
我在编译内核时接连遇到SIG11错误，怀疑主板上的某根电路丝断了，找到它们的最好办法是什么？
明智：
我组装的电脑（K6/233CPU、FIC-PA2007主板（威盛ApolloVP2芯片组）、CorsairPC133SDRAM256Mb内存）最近在开机20分钟左右、做内核编译时频繁地报SIG11错，但在头20分钟内从不出问题。
重启动不会复位时钟，但整夜关机会。
更换所有内存未解决问题，相关的典型编译会话日志附后。
按时间先后罗列症状
刚出问题之前发生的事情通常包含有解决问题最有效的线索。
所以，记录中应准确地描述你及电脑在崩溃之前都做了些什么。
在命令行处理的情况下，有会话日志（如运行脚本工具生成的）并引用相关的若干（如20）行记录会非常有帮助。
如果崩溃的程序有诊断选项（如-v详述选项），仔细考虑选择这些能在记录中增加排错信息的选项。
如果你的记录很长（如超过四段），也许在开头简述问题随后按时间先后罗列详细过程更有用。
这样做，黑客在读你的记录时就知道该查哪些内容了。
描述目的而不是步骤
如果你想弄清楚如何做某事（而不是报告一个臭虫），在开头就描述你的目标，此后才描述为此采取的措施所遇到的问题。
经常有这种情况，寻求技术帮助的人在脑袋里有个更高层面的目标，他们在自以为能达到目标的特定道路上被卡住了，然后跑来问该怎么走，但没有意识到这条路本身有问题，结果要费很大的劲才能通过。
愚蠢：
我怎样才能让某图形程序的颜色拾取器取得十六进制的RGB值？
明智：
我正试图用自己选定数值的颜色替换一幅图片的颜色表，我现在唯一知道的方法是编辑每个表槽，但却无法让某图形程序的颜色拾取器取得十六进制的RGB值。
第二种提法是明智的，它使得建议采用更合适的工具完成任务的回复成为可能。
别要求私下回复
黑客们认为问题的解决过程应该公开、透明，此过程中如果更有才能的人注意到不完整或者不当之处，最初的回复才能够、也应该被更正。
同时，作为回复者也因为能力和学识被其它同行看到而得到某种回报。
当你要求私下回复时，此过程和回报都被中止。
别这样做，让回复者来决定是否私下回答──如果他真这么做了，通常是因为他认为问题编写太差或者太肤浅以至于对其它人无意义。
对这条规则存在一条有限的例外，如果你确信提问可能会导致大量雷同的回复时，那么“给我发电子邮件，我将为小组归纳这些回复”将是神奇的句子。
试图将邮件列表或新闻组从洪水般雷同的回复中解救出来是非常有礼貌的──但你应信守诺言。
问题应明晰
漫无边际的问题通常也被视为没有明确限制的时间无底洞。
最有可能给你有用答案的人通常也是最忙的人（假如只是因为他们承担了大多数工作的话），这些人对于没有限制的时间无底洞极其反感，所以他们也倾向于讨厌那些漫无边际的问题。
如果你明确了想让回复者做的事（如指点方向、发送代码、检查补丁或其它），你更有可能得到有用的回复。
这可以使他们集中精力并间接地设定了他们为帮助你需要花费的时间和精力上限，这很好。
要想理解专家生活的世界，可以这样设想：
那里有丰富的专长资源但稀缺的响应时间。
你暗中要求他们奉献的时间越少，你越有可能从这些真正懂行也真正很忙的专家那里得到回答。
所以限定你的问题以使专家回答时需要付出的时间最少──这通常还与简化问题不一样。
举个例，“请问可否指点一下哪有好一点的X解释？
”通常要比“请解释一下X”明智。
如果你有什么代码不运行了，通常请别人看看哪有问题比叫他们帮你改正更明智。
别
升级会员 