高效技术求助指南：如何提问才能获得优质解答

我订阅了许多GitHub项目，加入了多个公共邮件列表，并关注了一些论坛，这些平台经常收到技术求助请求。这些请求的质量参差不齐，因此我写下这篇文章，说明我希望在求助请求中看到的内容，并尝试解释原因。

本文大多是从我在空闲时间免费回答问题角度出发的——这些时间本可用于其他有趣的事情。我很乐意这样做，因为许多人也为我做了同样的事，而且如果是为了我编写的工具，我希望人们使用它。话虽如此，以正确方式提出的问题让我更愿意投入精力回答，而不是敷衍了事然后去陪孩子玩耍。

研究

提问

如果你必须提问，最糟糕的请求风格（不幸的是相当常见）是：

应用程序无法工作，请帮助我。

就这样，没有更多信息，什么都没有。这种类型的请求几乎毫无用处，因为帮助者没有任何信息可以继续，问题可能从电脑未插电到应用程序中的错误。

然后我们向上提升到类似这样的请求：

应用程序无法工作，我收到这个错误…，请帮助我。

这至少提供了一些上下文，但通常不知道应用程序是如何运行的、运行环境以及其他有用的信息，仍然很难诊断问题。花费大量时间提供建议，假设是Linux环境，结果却是Windows，或者发现使用的Python版本在4年前就已停止支持，这真的令人沮丧。

跳过几个请求，我们终于得到类似这样的内容：

我在Debian Jessie上运行应用程序的X版本。我使用Python版本x.x。当我使用以下命令运行它…时，我收到这个错误…。如果我删除X参数，那么一切正常。我尝试以普通用户和root身份运行，没有区别。

这里我们有了更容易回答的内容，因为帮助者可以提取以下信息并进行处理：

运行的应用程序版本——这避免了浪费时间调试旧版本应用程序的问题
给出了操作系统——应用程序在不同操作系统上表现不同
给出了Python版本——再次帮助防止浪费时间测试不同版本或调试由过时解释器或编译器引起的问题
包含了命令和参数——这使得可以重现导致问题的确切情况
错误消息——这告诉帮助者出了什么问题以及可能在哪里失败
表明需要帮助的人已尝试找到问题原因的一些迹象

有了所有这些信息，帮助者更容易理解发生了什么，并在必要时复制问题。他们对问题发生环境的了解越多，就越不需要猜测或来回请求更多信息。

通过包含当参数更改时应用程序工作正常，以及他们尝试以普通用户和root身份运行，这表明该人已尝试自助，并减轻了帮助者的一些调试负担。显示用户已经付出了一些努力总是让我更愿意帮助。这也让我对对方的技术能力有所了解，这在反问问题时更容易。这并不意味着我优先帮助有技能的人，我优先帮助那些表现出尝试过的人，无论水平如何。

许多较大的项目都有自己的提交错误指南，例如Mozilla的期望。始终检查这些，因为问题通常会被忽略，除非它们格式正确并包含必要的信息。

不应包含的内容

对我来说最烦人的是在报告中包含大量不必要的输出。有时可能需要完整输出，但如果你包含超过约20行的输出，你可能包含了不必要的信息。错误通常发生在输出的末尾，因此请通读并查看是否能看出事情从正确开始失败的地方。如果你不确定，或者你认为所有输出都是必需的，那么将其放入文件中并托管在某处，Pastebin通常是个好地方。然后帮助者可以在需要时查看，但论坛/邮件不会被数十行不需要的内容堵塞。

还值得检查你发布的内容，确保没有在发布的内容中包含任何个人信息。我曾经尝试帮助某人调试DVWA的问题，他在错误报告中发布了面向公众安装的链接。当指出尽管更改了管理员用户的密码，但他没有更改任何其他密码，并且让服务器完全开放攻击时，他很快将其取下。

如果你发布图像，请确保任何模糊处理不能轻易撤销。有许多实例，人们使用MS Paint在某物上涂鸦一条红线以模糊它，但留下足够的显示，以至于稍加努力仍然可以阅读。如果你是笔测试员，并询问测试中遇到的问题，泄露这样的信息可能违反你的NDA，并可能让你陷入客户麻烦，或者至少当有人指出你所做的事情时感到非常尴尬。

反馈

在过程结束时，留下一些反馈说明发生了什么。显然你希望错误被修复，反馈可能是这样的：

我们找到了问题，它是由…引起的，并通过做…修复了。

但如果未修复，则反馈尝试了什么以及你将错误留在什么状态。这为其他发现问题的人提供了一个起点，意味着他们不必重复你尝试的所有事情。

说谢谢

最后，记住你的礼貌。特别是对于免费工具，回答你问题的人通常是免费投入时间的，所以简单的“谢谢”通常是他们唯一的奖励，让他们觉得投入时间是值得的。花时间与某人一起解决问题后，他们只是走开，这可能会非常令人沮丧。

结论

不要害怕寻求帮助，只需确保你尽可能做好。总会有一些人无论问题问得多好都会消极回应，但一个问得好的问题更可能让好人站在你这边并参与进来，而不是因为他们有更好的事情要做而忽略问题。