高效沟通：先说清楚 X，别只问 Y

程序员常说 “Talk is cheap, show me the code”。但真实工作里，很多时间并没有花在写代码上，而是花在弄清楚到底要写什么上：需求评审里来回确认，群聊里反复追问，排查问题时绕了一大圈才发现大家说的根本不是同一件事。

左耳朵耗子（陈皓）在《左耳听风》专栏的「高效沟通」系列中，把沟通当成一门可以训练的技术，总结了逻辑、信息、维度、共同四个关键点。其中「信息」部分专门提到了一个在技术圈非常经典的沟通陷阱：X/Y 问题。

这篇文章以 X/Y 问题为主线，结合专栏的思路，整理一套日常可用的沟通方法。

1. 什么是 X/Y 问题

维基百科对它的定义是：

提问者试图解决问题 X，但预先认为某个方案 Y 是可行的，于是只询问如何实现 Y，而不说明 X 是什么，导致提问者和回答者都花费了大量时间精力去解决 Y 问题，而实际上 Y 并不是一个合适的解决方案。

拆开来看，整个过程通常是这样的：

1. 我想解决问题 X；
2. 我自己想到了一个方案，这个方案需要先做到 Y；
3. 我卡在了 Y 上，于是去问别人「Y 怎么做」；
4. 对方很热心地帮我研究 Y，甚至 Y 也解决了；
5. 最后发现 Y 根本不是解决 X 的好办法，或者解决 Y 之后又冒出新的 Y’。

结果是双方都很累，问题却没解决。更糟的是，X 被 Y 掩盖住了，可能还会引入次生问题。

1.1 一个经典例子

xyproblem.info 上有一个流传很广的例子：

提问者：怎么取一个字符串的最后三个字符？

回答者：str.slice(-3) 就行。

提问者：好的……但是 photo.jpeg 这种文件名好像不对。

回答者：你到底想干什么？

提问者：我想拿到文件的扩展名。

这里：

• X：获取文件扩展名；
• Y：取字符串最后三个字符。

扩展名不一定是三个字符，也可能没有扩展名，或者有 .tar.gz 这种多段后缀。如果一开始就说「我想拿到文件扩展名」，回答者会直接推荐 path.extname() 之类的现成方法，几秒钟就结束了。

1.2 《提问的智慧》里的例子

Eric S. Raymond 在《提问的智慧》中有一节叫「描述目标而不是过程」，给的例子是：

• 蠢问题：我怎样才能从某绘图程序的颜色选择器中取得十六进制的 RGB 值？
• 聪明问题：我正试着用自己选定的色码替换一幅图片的色码，我现在知道的唯一方法是编辑每个色码区块，但却无法从某绘图程序的颜色选择器取得十六进制的 RGB 值。

第二种问法把目标（替换色码）和当前卡住的步骤（取 RGB 值）都讲清楚了。这样对方既可以回答你卡住的那一步，也可以直接告诉你「换个工具，一步就能批量替换」。

1.3 工作中常见的 X/Y 问题

X/Y 问题并不只出现在技术问答里，日常工作中也很常见：

最后一个例子尤其典型：直接满足 Y，表面上问题「解决」了，实际上是把真正的故障藏了起来。

2. 为什么会出现 X/Y 问题

X/Y 问题很少是因为提问者笨，更多是下面几个原因：

• 过早锁定方案：人在思考时会很自然地跳到「怎么做」，然后忘了回头确认「为什么这么做」。
• 怕暴露自己不懂：觉得说出完整背景会显得自己方案很幼稚，于是只问一个很具体的小问题。
• 以为对方不需要背景：觉得「我只是问个小技巧，说那么多干嘛」。
• 知识的诅咒：自己脑子里已经有完整上下文，就默认对方也有。

对回答者来说，也有一个对应的陷阱：只回答被问的问题。尤其在被催着要答案时，很容易直接给出 Y 的解法，而不去追问 X。

3. 如何避免 X/Y 问题

3.1 作为提问者：先讲目标，再讲卡点

提问时可以按下面的顺序组织信息：

1. 我的目标是什么（X）；
2. 我目前的方案是什么，为什么选它（Y）；
3. 我卡在了哪里，已经尝试过什么；
4. 期望的结果和实际的结果分别是什么。

可以直接套用这个模板：

1
2
3
4
5
6

【目标】我想要……（最终要达成的效果）
【背景】环境/版本/约束条件是……
【当前方案】我打算通过……来实现，因为……
【卡点】在……这一步遇到了……（报错信息、截图、复现步骤）
【已尝试】我试过……，结果是……
【问题】想请教：……；如果方向本身有问题，也欢迎直接指出

最后一句很重要。主动告诉对方「方向错了可以直接说」，等于邀请对方帮你检查 Y 是否合理。

3.2 作为回答者：多问一句「为什么」

当别人来问一个具体的 Y 时，可以先问：

• 「你最终想实现什么效果？」
• 「这个是为了解决什么问题？」
• 「如果这一步做成了，下一步打算做什么？」

几个值得警惕的信号：

• 问题本身很奇怪，正常人很少会有这种需求；
• 问题非常具体但缺少上下文，比如「怎么关闭某个校验」；
• 对方给的方案明显绕远路，或者需要很多 hack；
• 你给了答案之后，对方又带着一个新的类似问题回来。

追问的时候要注意语气。「你为什么要这么做？」听起来像质疑，「你最终想达到什么效果？我看看有没有更简单的办法」听起来就是在帮忙。

当然也要把握分寸：如果对方已经说明了背景，并且有明确理由坚持方案 Y，那就尊重对方的判断，直接回答 Y。

4. 高效沟通的四个关键技术

X/Y 问题只是沟通中「信息」层面的一个陷阱。左耳朵耗子在专栏中把沟通技术归纳为四个方面，结合起来看会更完整。

4.1 逻辑：分清因果和前提

专栏里举过一个例子：某产品统计发现约 40% 的用户视频下载到一半就取消了，团队想模仿「前 90% 嗖地过去，最后 10% 才是真实进度」的进度条来提升体验。

他们的逻辑是：用户看到已经下载了 90%，会愿意多等一会儿。但仔细分析，这个方案的前置条件是用进度条欺骗用户，而用户放弃下载的原因并没有被分析清楚：是下载太慢？是文件太大？还是根本不需要下载完整视频？如果原因没找准，换个进度条并不能留住用户。

这其实也是一个 X/Y 问题：X 是「提升下载完成率」，Y 是「让进度条看起来更快」。

沟通中要经常问自己：

• 这两件事之间真的有因果关系，还是只是相关？
• 这个结论成立的前提是什么？前提本身成立吗？
• 是充分条件还是必要条件？

4.2 信息：完整、准确、不带预设

这正是 X/Y 问题所在的层面。高效沟通需要信息：

• 完整：目标、背景、约束、现状都要讲；
• 准确：用数据和事实，而不是「好像」「大概」「很多用户」；
• 不带预设：先说问题，再说方案，不要把自己的方案当成问题本身抛出来。

一个简单的自检方法：把你的问题发给一个完全不了解背景的同事，他能不能看懂你想干什么？

4.3 维度：低维度反驳，高维度说服

专栏中有一句话很值得记住：

在和人争论时，如果要反驳，那一定是低维度反驳，越细节越好。而在说服对方时，则要在高维度说服对方，越宏观越好，比如从公司的大目标出发。

这和 X/Y 问题也有联系：

• X 往往在更高的维度：它关乎目标、业务价值和用户体验；
• Y 往往在更低的维度：它关乎具体实现细节。

当双方在 Y 上争执不下时，不妨把讨论拉回到 X：「我们其实都想解决的是……，那哪种方案更好？」一旦目标对齐，细节上的分歧通常会容易很多。

4.4 共同：找到共识再谈分歧

专栏把这一点总结为共情、共享、共利、共识以及换位思考。

沟通不是为了赢，而是为了一起把事情做成。在讨论方案之前，先确认双方对 X 的理解一致：

• 我们要解决的问题是同一个吗？
• 我们对成功的定义是一样的吗？
• 对方的约束和顾虑是什么？

很多看似激烈的争论，最后发现只是双方对 X 的理解不一样。

5. 一份沟通前的检查清单

发消息、提问或者开会之前，可以花半分钟过一遍：

• 我有没有说清楚最终目标（X），而不只是我想到的做法（Y）？
• 对方需要的背景和约束我都给了吗？
• 我描述的是事实和数据，还是主观感受？
• 我的推理链条里，因果关系是否成立？
• 我有没有给对方质疑方案的空间？
• 如果对方完全不了解背景，能一次看懂吗？

作为回答者：

• 我理解对方真正想解决的问题了吗？
• 这个问题是不是有点奇怪，值得追问一句？
• 除了回答 Y，有没有更直接解决 X 的办法？

6. 小结

高效沟通的核心，不在于口才有多好，而在于让双方尽快对齐到同一个问题上。

X/Y 问题之所以常见，是因为人很自然地会把「我想到的办法」当成「我要解决的问题」。避免它的方法其实很简单：

• 提问时：先说 X，再说 Y；
• 回答时：先问 X，再答 Y。

在 AI 助手越来越普及的今天，这一点同样适用。向大模型提问时，如果只问「怎么做 Y」，它通常也会很认真地帮你把 Y 做出来，哪怕 Y 是一条弯路。把目标和背景讲清楚，往往比反复调整提示词更有效。

参考资料

• 左耳听风 · 104 | 高效沟通：沟通技术 —— 陈皓（左耳朵耗子）
• XY 问题 - 维基百科
• The XY Problem
• How To Ask Questions The Smart Way（提问的智慧） —— Eric S. Raymond
• What is the XY problem? - Meta Stack Exchange