XY问题

这是什么？

XY问题是问你尝试的解决方案，而不是你实际遇到的问题。这导致了大量时间和精力的浪费，无论是寻求帮助的人，还是提供帮助的人。

• 用户想做X。
• 用户不会做X，但认为只要能做到Y就能摸索出解决方案。
• 用户也不会做Y。
• 用户请求帮助Y。
• 还有人试图帮助用户解决Y，但因为Y似乎是个奇怪的问题，所以感到困惑。
• 经过大量互动和浪费时间，最终明确用户真正想要的是X的帮助，而Y甚至不是X的合适解决方案。

问题在于人们陷入了他们认为的解决方案，无法退一步完整解释问题。

该怎么办？

• 无论尝试什么方案，都要包含更广泛的背景信息。
• 如果有人问更多信息，请提供详细信息。
• 如果你已经排除了其他解决方案，请分享你排除的原因。这会让你更了解自己的需求。

记住，如果你的诊断理论是准确的，你就不会寻求帮助了，对吧？

no hello

想象一下别人接通你的电话时，你问 ：__“在吗？”__，然后等待对方回应…🤦‍♀️

❌ 不要这样做

请注意，这个场景中基思本可以提前几分钟得到答案，也不必让蒂姆等待，而蒂姆本来可以立刻开始思考这个问题。

人们这样做通常是出于礼貌，避免像面对面或者打电话时候那样唐突地直接提出请求。但现在已经是 2022年了，聊天方式也和以前完全不同。对于绝大多数人来说，打字比说话慢得多。所以尽管你的初衷是好的，而实际上你只是在让对方等待 你说出自己问题，这是非常没有效率的（某种意义上有些烦人）。

类似的场景有：

• “你好，在吗？”
• “在，有事直接问。”
• “你有时间吗？”
• “有”
• “忙吗？”
• 等等

请直接问问题！ 😫

如果你觉得很直接地说 “嗨” 并问一个问题有些唐突，可以适当地在你的消息前面加上一些寒暄。

例如：

• “嗨老铁，你咋样了？还有你知道那个事儿什么时候截止吗？”
• “还可以，咱们可以抽空聊聊。: )”
• “行，如果你不忙，能帮忙更新一下 NFR 吗？”
• 等等

这也许看起来很繁琐，但在你得到开头的寒暄的回复之前问你关心的问题，也能够做到 延时沟通。如果对方不在，而你在他们回来之前就离开了，他们仍然可以回答你的问题，而不只是盯着“在吗？”感到不知所措。

当你做到了这些，大家都会开心！🎉

 An informational website about why you should ask questions directly instead of asking to ask

不要问「有没有懂的人」，有问题直接问

在聊天群里，时不时会有人突然冒出来问一句：

Foobar123:

有人会 Java 吗？

这样提问并不好。这个人想问的其实是：

Foobar123:

有人会 Java 吗？愿意来解决一下我的问题吗？其实我也不知道是不是 Java 的问题。哦对了，不会 Java 的人说不定也可以解决我的问题哦？

你或许没想到，你的这个问题要求太高了，即使别人懂你说的东西，可能也不会搭理你。

你想让别人承担责任、付出精力。你还质疑别人有没有自信很懂这个东西。不仅如此，其他能解答问题的人也被你拒之门外了。举例来说，我本人就回答过很多问题，这些问题有关我不会的语言、没用过的库，只不过它们是程序员的通用知识罢了。

也可以这样理解上面的提问：

Foobar123:

我有一个 Java 的问题，如果群里有人能解答，我再解释问题是什么，否则我都懒得表述。

这也太懒了。你连解决问题的第一步都不想做，我们凭什么帮你？

解决方法很简单，直接说明你的问题就行了。别人只是偶尔看一眼群里的消息，看到你问「有没有懂的人」可能直接就忽略了，但是看到你详细说明的问题之后，说不定就感兴趣了，这样才会有解答。

总之，不要问「有人会 Java 吗」，正确的做法是直接说明你的 Java 问题和相关信息。

How-To-Ask-Questions-The-Smart-Way

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

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

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

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

在提问之前

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

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

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

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

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

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

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

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

聪明问题：X.org 6.8.1 的鼠标指针会变形，某牌显卡 MV1005 芯片组。

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

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

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

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

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

蠢问题

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

聪明问题

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

描述目标而不是过程

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

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

蠢问题

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

聪明问题

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

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

不该问的问题

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

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

问题：我怎样用 X 做 Y？

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

问题：我可以用 Bass-o-matic 文件转换工具将 AcmeCorp 文件转换为 TeX 格式吗？

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

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

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

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

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

FGA：只有在你想要“是”或“否”答案时才问是/否。

您来到本页面是因为您通过以下表单之一提问

• 有人知道吗......？
• 有人能......？
• 有可能......？

然后当得到合乎逻辑的“是”或“否”答案时，我感到惊讶。

这是对这种惊讶的常见回答。

只有当你想要“是”或“否”时才问是/否答案的问题 回答。如果你不想用“是”或“否”作为答案，那你应该这样做 我问了另一个问题。

别问，有人知道吗......？除非你是真的，否则会有问题 想知道是否有人知道。

别问别人......？除非你真的想问 想知道是否有人能做到。

如果你想知道别的，就问问答案是谁的问题 你真正想要的。

例如：

如果你想知道如何在Win32中捕获控制台I/O， 别问

有人知道如何在Win32中捕获主机I/O吗？

或

有人能帮我在Win32中捕获控制台I/O吗？

这两个问题的答案要么是“是”，要么是“不是”。无论是谁 要么知道如何在Win32中捕获控制台I/O，要么就没有。要么 世界上有人可以帮你在Win32中捕获主机I/O，或者 没人能。

相反，问那个你真正想要答案的问题：

我如何在Win32中捕获控制台的I/O？