超越 XY 问题：为什么你不应该直接回答第一个问题

当用户提出技术问题时，大多数工程师的本能反应是尽可能快、准确地提供答案。我们将响应速度视为生产力的体现。然而，对于那些为其他工程师构建工具的人来说，这种本能可能会错失良机。

在像 Perfetto（一个性能调试工具）这样高复杂度的工具语境下，对一个“奇怪”问题的直接回答往往只能解决表象，却让潜在的困惑依然存在。通过抵制住回答问题第一个版本的冲动，开发者可以发现用户心智模型中的关键空白，识别产品缺陷，并避免构建不必要的功能。

超越 XY 问题

许多人都熟悉“XY 问题”，即用户询问的是他们尝试的解决方案（X）而不是实际的问题（Y）。解决 XY 问题的传统方法是解开谜题：弄清楚用户实际想表达的意思，提供正确的答案，然后继续下一步。

但存在更深层次的参与方式。不要将用户的问题视为一个待解的谜题，而要将其视为一个切入点。产生“错误”问题的困惑其实是一种信号。当开发者探索这一信号时，对话就变成了一个双向学习的过程：用户获得了对工具更好的心智模型，而开发者则能更清晰地了解产品在哪些地方令人困惑或存在不足。

诊断提问

并非所有问题都需要深入探讨。常规查询和文档缺失最好通过快速提供链接来处理。而“不回答第一个问题”的策略应保留给那些感觉不寻常的要求。要确定一个问题是否值得进行更深入的对话，请考虑以下标准：

普遍性： 我以前见过这个吗？如果它不常见，那么值得慢下来思考一下。
合理性： 考虑到工具的用途，这个请求听起来逻辑合理吗？如果不合理，用户为什么要问这个？
架构契合度： 用户是否在无意识中与工具的架构作斗争？

一旦识别出差异，目标是在不显得傲慢的前提下揭示缺失的上下文。一个有效的表达方式是：“你当前问题的答案是 X，但因为原因 Y，这听起来是个相当奇怪的要求。你能告诉我更多关于你试图解决的更广泛问题的细节吗？”

当用户误解了设计哲学

通常，用户会带着对工具“应该”如何工作的预设观念来使用工具。在性能工程领域，这通常表现为将高保真追踪（trace）视为通用的指标收集系统。虽然你可以从 trace 中计算出任何指标，但与专门的指标系统相比，这样做既耗费资源又低效。

当用户要求的某个功能与工具的核心哲学相悖时，这正是教学的机会。例如，用户经常询问如何将大型 Perfetto traces 分割成多个文件。通过询问他们为什么要分割 trace，通常会发现他们只是想可视化特定感兴趣的时段。实际的解决方案并不是一个“分割”功能，而是一个“周期性 trace 快照”功能——这个功能已经存在，但并不符合用户最初的心智模型。

利用用户摩擦来引导产品演进

这种方法也是产品开发的一个强大过滤器。在基础软件中，错误地实现一个功能带来的成本很高。通过延迟实现用户请求的功能，并观察多个用户是否在都在为同一个问题而苦恼，开发者可以找到需求的“本质”。

过早实现功能的危险

实现一个基于第一个请求的功能可能会导致严重的的技术债。Perfetto 中的即时 UI 定制化（ad-hoc UI customization）就是一个典型的案例。用户抱怨 UI 难以定制，于是团队实现了它。这导致了一个扩展性噩梦，扩展性问题随之而来，即每个新功能都必须与每一个现有的定制化功能进行交互。经过一年的重构工作才意识到，真正的需求是用于个性化设置的 plugin API，而不是原始的 UI 修改。

战略性延迟的价值

相反，等待实现某个功能——例如 traces 的“合并”功能——可以让团队深入理解问题空间。通过提供变通方法（workarounds）并观察请求的模式，团队在充分理解核心需求后，才构建出了一个可维护的版本。

平衡引导与专业精神

虽然这种策略很强大，但如果应用不当，可能会被视为居高临下。为了避免“Stack Overflow 效应”——即用户在得到帮助之前被告知他们的问题是错误的——必须遵循一些准则：

首先提供直接的答案： 在询问上下文之前，始终先给出直接的答案（X）。这证明了你是在提供帮助，而不是在阻碍他人。
了解你的领域： 仅在你拥有深厚专业知识的领域应用此策略。如果你自己都不完全理解问题空间，你就无法引导用户的心智模型。
宽容待人： 如果用户显然是其领域的专家，请谨慎挑战他们的做法。假设他们对于特定的请求是有理由的。
尊重用户的判断： 如果用户提出异议，请尊重他们的判断。目标是进行一场尊重的讨论，而不是强行将其转化为特定的工作流。

通过从“立即响应”的冲动中退后一小步，开发者可以将一个简单的支持工单转化为用户和产品双方的战略资产。