- 文章
- 如何：聪明地提问
2008年4月10日（最后更新：2008年5月9日）
如何：聪明地提问
评分：4.3/5（68票）
Eric Steven Raymond 的作品节选
引言 在编程世界里，你得到的技术问题答案的好坏，与你提问的方式和你开发答案的难度同等重要。
首先要明白的是，程序员其实喜欢有挑战性的问题以及关于这些问题的好且发人深省的提问。如果我们不喜欢，我们就不会在这里。
程序员常常被认为对简单的问题表现出敌意或傲慢。有时看起来我们对新手和不懂的人会本能地粗鲁。但事实并非如此。
提问之前 提问之前，请先做以下事情：
1.尝试在你打算发帖的论坛的存档中搜索答案。
2.尝试在网上搜索答案。
3.尝试通过阅读手册找到答案。
4.尝试通过阅读常见问题解答（FAQ）找到答案。
5.尝试通过检查或实验找到答案。
6.尝试通过询问一位有经验的朋友来找到答案。
准备好你的问题。仔细思考。听起来仓促的问题只会得到仓促的回答，甚至没有回答。
提问时 仔细选择你的论坛 在选择提问的论坛时要谨慎。如果你这样做，你很可能会被忽略：
•将你的问题发布到不相关的论坛
•将一个非常基础的问题发布到预期会收到高级技术问题的论坛，反之亦然
使用有意义、具体的标题 标题是你吸引合格专家注意力的黄金机会。不要浪费在“请帮帮我”之类的废话上；不要试图用你痛苦的深度给我们留下深刻印象；而是用这个空间来简洁地描述问题。
更普遍地说，想象一下查看一个问题存档的索引，只显示主题行。让你的主题行充分反映你的问题，以便下一个搜索类似问题的人能够顺着线索找到答案，而不是再次发布问题。
使用清晰、语法正确、拼写准确的语言写作
清晰、准确地表达你的问题非常重要。花额外的精力来润色你的语言。不必僵硬或正式，但必须精确。
不要全部使用大写字母 typing in all caps；这会被解读为喊叫，并被认为是不礼貌的。
如果你写得像个半文盲的笨蛋，你很可能会被忽视。所以不要使用即时通讯的快捷方式。
关于你的问题要精确且信息丰富 •仔细清晰地描述你的问题的症状。
•描述问题发生的运行环境（机器、操作系统、应用程序等）。
•描述你在提问之前为理解问题所做的研究。
•描述你在提问之前为确定问题所在而采取的诊断步骤。
尽你所能预测回应者会问的问题，并在你的求助请求中预先回答它们。
数量不等于精确性 你需要精确且信息丰富。简单地将大量代码或数据转储到帮助请求中并不能达到这个目的。如果你有一个大的、复杂的测试用例导致程序崩溃，尽量将其修剪并使其尽可能小。
这至少有三个原因是有用的。一：你投入精力简化问题，更有可能得到回答；二：简化问题更有可能得到有用的回答；三：在完善你的 bug 报告的过程中，你可能会自己开发出一个修复程序或解决方法。
描述问题的症状，而不是你的猜测 告诉程序员你认为是什么导致了你的问题是没有用的。所以，请确保你告诉他们的是错误的原始症状，而不是你的解释和理论。让他们进行解释和诊断。如果你觉得陈述你的猜测很重要，请清楚地将其标记为猜测，并说明为什么那个答案对你不起作用。
描述目标，而不是步骤
如果你想弄清楚如何做某事，首先要描述目标。然后才描述你在此过程中遇到的具体阻碍。
通常，需要技术帮助的人心里都有一个高层次的目标，但被他们认为是通往目标的特定路径所困扰。他们来寻求步骤方面的帮助，但没有意识到这条路径是错误的。要克服这一点可能需要付出巨大的努力。
明确你的问题 开放式问题往往被视为耗时过多的开放式问题。最有可能给你有用答案的人也是最忙的人（仅仅因为他们自己承担了最多的工作）。这样的人对耗时过多的开放式问题很敏感，因此他们倾向于对开放式问题很敏感。
如果你明确你想让回复者做什么（提供线索、发送代码等），你更有可能得到有用的回复。这将集中他们的精力，并间接限制回复者必须为你提供帮助的时间和精力。
提问代码时 不要要求别人调试你的损坏代码，却不给任何关于他们应该搜索什么问题的提示。发布几百行代码，然后说“它不起作用”，你会被忽视。发布十几行代码，说“在第 7 行之后，我期望看到，但发生了 ”，这样得到回应的可能性更大。
如果你只是想进行代码审查，请提前说明，并务必提及你认为可能需要特别审查的领域以及原因。
不要发布家庭作业问题 程序员很擅长识别家庭作业问题；我们大多数人都做过。这些问题是为了让你自己解决，以便你从中学习。可以寻求提示，但不能寻求完整的解决方案。
跟进一个关于解决方案的简短说明 问题解决后，向所有帮助过你的人发送一条消息；让他们知道结果如何，并再次感谢他们的帮助。
你的后续不需要冗长而复杂；一句简单的“你好，原来是网络线缆出了问题！谢谢大家。- Bill”总比什么都没有好。
事实上，除非解决方案具有真正的技术深度，否则一个简短而甜蜜的总结比冗长的论文更好。说明解决了问题的操作，但你不需要重述整个故障排除过程。
除了礼貌和信息丰富之外，这种后续行动还能帮助其他搜索邮件列表/新闻组/论坛存档的人确切地知道哪个解决方案帮助了你，从而可能帮助到他们。
最后但同样重要的是，这种后续行动有助于所有帮助过的人对问题有一个令人满意的了结感。那些最终不了了之的问题叙述令人沮丧；程序员渴望看到它们得到解决。你通过挠痒痒而赢得的良好意愿，下次提问时会对你非常有帮助。
如何解读答案 如果你不明白…… 如果你不明白答案，不要立即反弹要求澄清。使用你用来尝试回答最初问题相同的工具（手册、FAQ、网络、有经验的朋友）来理解答案。然后，如果你仍然需要澄清，请展示你学到的东西。
如果你得不到答案 如果你得不到答案，请不要认为我们无能为力是针对你个人的。有时，被问及的群组的成员可能根本不知道答案。没有回应不等于被忽视，尽管从外面很难区分。
总的来说，简单地重复发布你的问题是个坏主意。这会被视为毫无意义的烦扰。要有耐心：拥有你答案的人可能在不同的时区，还在睡觉。或者，你的问题从一开始就没有组织好。
如何以有帮助的方式回答问题
要温和。 与问题相关的压力会使人显得粗鲁或愚蠢，即使他们不是。
回复初犯者私下进行。 对于可能犯了无心之失的人，没有必要公开羞辱。一个真正的新手可能不知道如何搜索存档，或者 FAQ 存储在哪里或张贴在哪里。
如果你不确定，就说出来！ 一个错误的但听起来权威的答案比没有答案还要糟糕。不要仅仅因为听起来像专家很有趣而将任何人引向错误的道路。保持谦虚和诚实；为提问者和你的同行树立一个好榜样。
如果你帮不了忙，就不要妨碍。 不要拿可能破坏用户设置的程序开玩笑——那个可怜的家伙可能会把这些当作指示。
提出探索性问题以获取更多细节。 如果你在这方面很擅长，提问者会学到东西——你可能也会。试着将坏问题变成好问题；记住，我们曾经都是新手。
虽然有时对懒惰的家伙回复“去读手册”（RTFM）是可以理解的，但指向文档（即使只是建议去谷歌搜索关键词）会更好。
如果你要回答问题，就要提供有价值的信息。 当有人使用错误的工具或方法时，不要建议蹩脚的变通方法。推荐好的工具。重新组织问题。
引言 在编程世界里，你得到的技术问题答案的好坏，与你提问的方式和你开发答案的难度同等重要。
首先要明白的是，程序员其实喜欢有挑战性的问题以及关于这些问题的好且发人深省的提问。如果我们不喜欢，我们就不会在这里。
程序员常常被认为对简单的问题表现出敌意或傲慢。有时看起来我们对新手和不懂的人会本能地粗鲁。但事实并非如此。
提问之前 提问之前，请先做以下事情：
1.尝试在你打算发帖的论坛的存档中搜索答案。
2.尝试在网上搜索答案。
3.尝试通过阅读手册找到答案。
4.尝试通过阅读常见问题解答（FAQ）找到答案。
5.尝试通过检查或实验找到答案。
6.尝试通过询问一位有经验的朋友来找到答案。
准备好你的问题。仔细思考。听起来仓促的问题只会得到仓促的回答，甚至没有回答。
提问时 仔细选择你的论坛 在选择提问的论坛时要谨慎。如果你这样做，你很可能会被忽略：
•将你的问题发布到不相关的论坛
•将一个非常基础的问题发布到预期会收到高级技术问题的论坛，反之亦然
使用有意义、具体的标题 标题是你吸引合格专家注意力的黄金机会。不要浪费在“请帮帮我”之类的废话上；不要试图用你痛苦的深度给我们留下深刻印象；而是用这个空间来简洁地描述问题。
更普遍地说，想象一下查看一个问题存档的索引，只显示主题行。让你的主题行充分反映你的问题，以便下一个搜索类似问题的人能够顺着线索找到答案，而不是再次发布问题。
使用清晰、语法正确、拼写准确的语言写作
清晰、准确地表达你的问题非常重要。花额外的精力来润色你的语言。不必僵硬或正式，但必须精确。
不要全部使用大写字母 typing in all caps；这会被解读为喊叫，并被认为是不礼貌的。
如果你写得像个半文盲的笨蛋，你很可能会被忽视。所以不要使用即时通讯的快捷方式。
关于你的问题要精确且信息丰富 •仔细清晰地描述你的问题的症状。
•描述问题发生的运行环境（机器、操作系统、应用程序等）。
•描述你在提问之前为理解问题所做的研究。
•描述你在提问之前为确定问题所在而采取的诊断步骤。
尽你所能预测回应者会问的问题，并在你的求助请求中预先回答它们。
数量不等于精确性 你需要精确且信息丰富。简单地将大量代码或数据转储到帮助请求中并不能达到这个目的。如果你有一个大的、复杂的测试用例导致程序崩溃，尽量将其修剪并使其尽可能小。
这至少有三个原因是有用的。一：你投入精力简化问题，更有可能得到回答；二：简化问题更有可能得到有用的回答；三：在完善你的 bug 报告的过程中，你可能会自己开发出一个修复程序或解决方法。
描述问题的症状，而不是你的猜测 告诉程序员你认为是什么导致了你的问题是没有用的。所以，请确保你告诉他们的是错误的原始症状，而不是你的解释和理论。让他们进行解释和诊断。如果你觉得陈述你的猜测很重要，请清楚地将其标记为猜测，并说明为什么那个答案对你不起作用。
描述目标，而不是步骤
如果你想弄清楚如何做某事，首先要描述目标。然后才描述你在此过程中遇到的具体阻碍。
通常，需要技术帮助的人心里都有一个高层次的目标，但被他们认为是通往目标的特定路径所困扰。他们来寻求步骤方面的帮助，但没有意识到这条路径是错误的。要克服这一点可能需要付出巨大的努力。
明确你的问题 开放式问题往往被视为耗时过多的开放式问题。最有可能给你有用答案的人也是最忙的人（仅仅因为他们自己承担了最多的工作）。这样的人对耗时过多的开放式问题很敏感，因此他们倾向于对开放式问题很敏感。
如果你明确你想让回复者做什么（提供线索、发送代码等），你更有可能得到有用的回复。这将集中他们的精力，并间接限制回复者必须为你提供帮助的时间和精力。
提问代码时 不要要求别人调试你的损坏代码，却不给任何关于他们应该搜索什么问题的提示。发布几百行代码，然后说“它不起作用”，你会被忽视。发布十几行代码，说“在第 7 行之后，我期望看到
如果你只是想进行代码审查，请提前说明，并务必提及你认为可能需要特别审查的领域以及原因。
不要发布家庭作业问题 程序员很擅长识别家庭作业问题；我们大多数人都做过。这些问题是为了让你自己解决，以便你从中学习。可以寻求提示，但不能寻求完整的解决方案。
跟进一个关于解决方案的简短说明 问题解决后，向所有帮助过你的人发送一条消息；让他们知道结果如何，并再次感谢他们的帮助。
你的后续不需要冗长而复杂；一句简单的“你好，原来是网络线缆出了问题！谢谢大家。- Bill”总比什么都没有好。
事实上，除非解决方案具有真正的技术深度，否则一个简短而甜蜜的总结比冗长的论文更好。说明解决了问题的操作，但你不需要重述整个故障排除过程。
除了礼貌和信息丰富之外，这种后续行动还能帮助其他搜索邮件列表/新闻组/论坛存档的人确切地知道哪个解决方案帮助了你，从而可能帮助到他们。
最后但同样重要的是，这种后续行动有助于所有帮助过的人对问题有一个令人满意的了结感。那些最终不了了之的问题叙述令人沮丧；程序员渴望看到它们得到解决。你通过挠痒痒而赢得的良好意愿，下次提问时会对你非常有帮助。
如何解读答案 如果你不明白…… 如果你不明白答案，不要立即反弹要求澄清。使用你用来尝试回答最初问题相同的工具（手册、FAQ、网络、有经验的朋友）来理解答案。然后，如果你仍然需要澄清，请展示你学到的东西。
如果你得不到答案 如果你得不到答案，请不要认为我们无能为力是针对你个人的。有时，被问及的群组的成员可能根本不知道答案。没有回应不等于被忽视，尽管从外面很难区分。
总的来说，简单地重复发布你的问题是个坏主意。这会被视为毫无意义的烦扰。要有耐心：拥有你答案的人可能在不同的时区，还在睡觉。或者，你的问题从一开始就没有组织好。
如何以有帮助的方式回答问题
要温和。 与问题相关的压力会使人显得粗鲁或愚蠢，即使他们不是。
回复初犯者私下进行。 对于可能犯了无心之失的人，没有必要公开羞辱。一个真正的新手可能不知道如何搜索存档，或者 FAQ 存储在哪里或张贴在哪里。
如果你不确定，就说出来！ 一个错误的但听起来权威的答案比没有答案还要糟糕。不要仅仅因为听起来像专家很有趣而将任何人引向错误的道路。保持谦虚和诚实；为提问者和你的同行树立一个好榜样。
如果你帮不了忙，就不要妨碍。 不要拿可能破坏用户设置的程序开玩笑——那个可怜的家伙可能会把这些当作指示。
提出探索性问题以获取更多细节。 如果你在这方面很擅长，提问者会学到东西——你可能也会。试着将坏问题变成好问题；记住，我们曾经都是新手。
虽然有时对懒惰的家伙回复“去读手册”（RTFM）是可以理解的，但指向文档（即使只是建议去谷歌搜索关键词）会更好。
如果你要回答问题，就要提供有价值的信息。 当有人使用错误的工具或方法时，不要建议蹩脚的变通方法。推荐好的工具。重新组织问题。