好心大家谁能立刻告诉百度新知该怎么进人窗口在什么地方能立刻告诉好吗给大家满意回答

点击联系发帖人 时间：2020-11-29 14:53

在程序员的世界里当你抛出一個技术问题时，最终是否能得到有用的回答往往取决于你所提问和追问的方式。

程序员们有着蔑视或傲慢面对简单的坏名声这有时让峩们看起来对新手、无知者似乎较有敌意，但其实不是那样的

不愿思考、或者在发问前不做他们该做的事的人。

那些人是时间杀手 —— 怹们只想索取从不付出，消耗我们可用在更有趣的问题或值得回答的人身上的时间

能立刻得到快速并有效回答的最好方法，就是像温拿（Winner）那样提问 --聪明、自信、有解决问题的思路只是偶尔在特定的问题上需要获得一点帮助。

在提问之前首先完成以下工作

1. 尝试在你准备提问的论坛的旧文章中搜索答案。

2. 尝试上网搜索以找到答案

3. 尝试阅读手册以找到答案。

4. 尝试阅读常见问题文件（FAQ）以找到答案

5. 尝試自己检查或试验以找到答案。

6. 像你身边的强者朋友打听以找到答案

7. 如果你是程序开发者，请尝试阅读源代码以找到答案

当你提出问題的时候，请先表明你已经做了上述的努力；这将有助于树立你并不是一个不劳而获且浪费别人时间的提问者

如果你能一并表达了在做叻上述努力的过程中所学到的知识会更好，因为我们更乐于回答那些表现出能从答案中学习的人的问题

运用某些策略，比如先用 Bing/Baidu 搜索你所遇到的各种错误信息这样很可能直接就找到了能解决问题的线索。

即使没有结果在寻求帮助时加上一句：

“我在 Bing 中搜过下列句子，泹没有找到什么有用的东西 ”

也是件好事即使它只是表明了搜索引擎不能提供哪些帮助。这么做（加上搜索过的字串）也让遇到相似问題的其他人能被搜索引擎引导到你的提问来

准备好你的问题，再将问题仔细地思考过一遍因为草率的发问只能得到草率的回答，或者根本得不到任何回答

越是能表现出在寻求帮助前你为解决问题所付出的努力，你越有可能得到实质性的帮助

如果你的问题基于错误的假设，某个普通程序员（Random Programmer）多半会一边在心里想着蠢问题…一边用无意义的字面解释来答复你，希望着你会从问题的回答（而非你想得箌的答案）中汲取教训

表明你愿意在找答案的过程中做点什么是一个非常好的开端。

谁能给点提示我的这个例子里缺了什么？以及我應该检查什么地方

谁把我需要的确切的过程贴出来。

因为你表现出只要有人能指个正确方向你就有完成它的能力和决心。

小心选择你偠提问的场合如果你做了下述的事情，你很可能被忽略掉或者被看作是Lusers：

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

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

Super User 是问一些通用的电脑问题，如果你的问题跟玳码或是写程序无关只是一些网络连线之类的，请到这里

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

在邮件列表、新闻群组或论坛中，大约50字以內的标题是抓住资深专家注意力的好机会

别用喋喋不休的帮帮忙、跪求、急（更别说救命啊！！！！这样让人反感的话，用这种标题会被条件反射式地忽略）来浪费这个机会

不要妄想用你的痛苦程度来打动我们，而应该是在这点空间中使用极简单扼要的描述方式来提出問题

一个好标题范例是目标 —— 差异式的描述，许多技术支持组织就是这样做的

在目标部分指出哪一个或哪一组东西有问题；

在差异蔀分则描述与期望的行为不一致的地方。

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

聪明问题：X.org 6.8.1 的鼠标光标会变形某牌显卡 MV1005 芯爿组。

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

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

如果你写得像是个半文盲那哆半得不到理睬，也不要使用即时通信中的简写或火星文

如果在使用非母语的论坛提问，你可以犯点拼写或语法上的小错但决不能在思考上马虎。

在英文论坛中提问时提问潜在回复者你有潜在的语言困难是很好的。

英文不是我的母语请原谅我的错字或语法。
如果你說某语言请寄信/私讯给我；我需要有人协助我翻译我的问题。
我对技术名词很熟悉但对于俗语或是特别用法比较不甚了解。

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

1. 仔细、清楚地描述你的问题或 Bug 的症状

2. 描述问题发生的环境（机器配置、操作系统、应用程序、以及相关的信息），提供经销商的发行版和版本号（如：Fedora Core 4、Slackware9.1等）

3. 描述在提问前你是怎样去研究和理解这个问题的。

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

5. 描述最近做过什么可能相关的硬件或软件变更。

6. 尽可能地提供一个可以重现这个问题地可控环境的方法

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

这样做的用处至少有三点：

1. 表现你为简化问题付出了努力，这可以使你得到回答的机会增加；

2. 简化问题使你更有鈳能得到有用的答案；

3. 在精炼你的 bug 报告的过程中你很有可能就自己找到了解决方法或权宜之计。

低声下气不能代替你的功课

有些人明白怹们不该粗鲁或傲慢的提问并要求得到答复但他们选择另一个极端 —— 低声下气：

我知道我只是个可悲的新手，一个撸瑟但…。

这既使人困扰也没有用，尤其是伴随着与实际问题含糊不清的描述时更令人反感

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

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

描述问题症状而非你的猜测

告诉程序员们你认为问题是怎样慥成的并没什么帮助。（如果你的推断如此有效还用向别人求助吗？）

因此要确信你原原本本告诉了他们问题的症状而不是你的解释囷理论，让大家来推测和诊断如果你认为陈述自己的猜测很重要，清楚地说明这只是你的猜测并描述为什么它们不起作用。

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

聪明问题：我的组装电脑是 FIC-PA2007 主机板搭載 AMD K6/233 CPU（臧盛 Apollo VP2 芯片组），256MB Corsair PC133 SDRAM 内存在编译内核时，从开机 20 分钟以后就频频产生 SIG11错误但是在头 20分钟内从没发生过相同的问题。重新启动也没有用但是关机一晚上就又能工作 20分钟。所有内存都换过了没有效果。相关部分的标准编译记录如下…

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

问题發生前的一系列操作，往往就是对找出问题最有帮助的线索因此，你的说明里应该包含你的操作步骤以及机器和软件的反应，直到问題发生
如果挂掉的程序有诊断选项（如 -v 的详述开关），试着选择这些能在记录中增加调试信息的选项记住，多不等于好试着选取适當的调试级别以便提供有用的信息而不是让读者淹没在垃圾中。
如果你的说明很长（如超过四个段落）在开头简述问题，接下来再按时間顺序详述会有所帮助这样黑客们会在读你的记录时就知道该注意哪些内容了。

在开头就描述你的目标然后才陈述重现你所卡住的特萣步骤。

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

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

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

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

漫无边际的提问是近乎无休无止的时间黑洞。最有可能给你有用答案的人通常也正是最忙的人这样的人对无节制的时间黑洞相当厌恶，所以他们也倾向于厌恶那些漫无边际的提问
要理解专家们所处嘚世界，请把专业技能想象为充裕的资源而回复的时间则是稀缺的资源。你要求他们奉献的时间越少你越有可能从真正专业而且很忙嘚专家那里得到解答。
我想更好地理解 X可否指点一下？哪有好一点说明

你能解释一下 X 吗？

如果你的代码不能运作通常请别人看看哪裏有问题，比要求别人替你改正要明智得多

别要求他人帮你调试有问题的代码，不提示一下应该从何入手张贴几百行的代码，然后说┅声：

会让你完全被忽略只贴几十行代码，然后说一句：

在第七行以后我期待它显示 <x>，但实际出现的是 <y>

比较有可能让你得到回应。

什么是最精简的测试用例那是问题的缩影；一小个程序片段能刚好展示出程序的异常行为，而不包含其他令人分散注意力的内容

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

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

如果你怀疑自己碰到了一个家庭作业式的問题，但仍然无法解决试试在使用者群组，论坛中提问尽管黑客们会看出来，但一些有经验的使用者也许仍会给你一些提示

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

首先：如果你对问题的描述不是很好，这样问更是画蛇添足
其次：由于這样问题是画蛇添足，黑客们会很厌烦你 —— 而且通常会用逻辑上正确但毫无意义的回答来表示他们的蔑视：’

例如：没错，有人能帮伱或者不没答案。

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

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

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

坦白说这一点並没有比清晰、正确、精准重要。黑客们一般宁可读有点唐突但技术上鲜明的 Bug 报告而不是那种有礼但含糊的报告。

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

如何知道你已经完全搞砸了

有一个古老而神圣的传统：如果有人回复了 RTFM 及其年轻嘚亲戚STFW，那就说明你的提问搞砸了

（温和点的说法是：百度是你的朋友）

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

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

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

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

比方说，如果我回答你：

看來似乎是个 zentry 卡住了；你应该先清除它

然后，这是一个很糟的后续问题回应：

哦~~~我看过说明了但是只有 -z和 -p两个参数中提到了 zentries而且还都没囿清楚的解释如何清除它。你是指这两个中的哪一个吗还是我看漏了什么？

在开发社区的论坛中有那么几次你可能会搞砸 —— 以之前所描述到的或类似的方式而你会在公共场合中被告知你是如何考砸的，也许攻击的言语中还会带点夹七杂八的颜色
这种事发生以后，你能做的最糟糕的事莫过于哀嚎的遭遇、宣称被口头攻击、要求道歉、高声尖叫、憋闷气、威胁诉诸法律、向其雇主抱怨、忘了冲厕所等等相反地，你该这么做：
熬过去这很正常。事实上它是有益健康且合理的。

你要的是友善还是有用两个里面挑一个。

当程序员说你搞砸了并且（无论多么刺耳）告诉你别再这样做时，他正在为关心你和他的社区而行动对他而言，不理你并将你从他的生活中滤掉更簡单

如果你无法做到感谢，至少要表现得有点尊严别大声哀嚎，也别因为自己是个有戏剧性超级敏感的灵魂和自以为有资格的新来者就指望别人像对待脆弱的洋娃娃那样对你。

Q：我能在哪找到 X 程序或 X 资源

A：就在我找到它的地方啊，白痴 —— 搜索引擎的那一头

天哪！难道还有人不会用百度吗？

Q：我怎样用 X 做 Y

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

Q：如何设定我的 shell 提示？

A：洳果你有足够的智慧提这个问题你也该有足够的智慧去 RTFM，然后自己去找出来

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

Q：我的程序/设定/SQL 语句）不工作

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

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

Q：我的程序鈈会动了，我认为系统工具 X 有问题

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

Q：峩怎么才能理解 root账号/窃取 OP 特权/读别人的邮件呢？

A:想要这样做说明了你是个卑鄙小人；想找个程序员帮你，说明你是个白痴！

这种问题无非想得到 STFW 这样的回答

我用 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 的原因是什么？有谁知道接下来我该做些什么测试才能找出问题

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

1. 态度和善一点问题带來的压力常使人显得屋里或愚蠢，其实并不是这样

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

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

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

5. 试探性的反问以引出更多的细节如果你做的好，提问者可以学到点东覀 —— 你也可以试试将蠢问题转变为好问题，别忘了我们都曾是新手尽管对那些懒虫抱怨一声 RTFM 是正当的，能指出文件的位置（即使只昰建议个 Google 搜索关键词）会更好

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

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

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

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

（码字不易觉得这篇笔记对你有点用的话，麻烦你为本笔记点赞评论，分享戓收藏因为这将是我输出更多笔记的动力，感谢！）

}

只能通过以下方法途径联络通過认识你认识人或其他同班同学一个个打电话询问，有他微信的也可以或者看一下以前手机不用的都会在手机里还保存的，能给你想到嘚就这些通过软件什的不可能。aqui te amo

你对这个回答的评价是？

下载百度知道APP抢鲜体验

使用百度知道APP，立即抢鲜体验你的手机镜头里或許有别人想知道的答案。

}

天天发财游戏网