好问题的艺术

Source: Dev.to

概览

“没有愚蠢的问题。”

这是技术圈里常见的一句话。初衷是好的：我们希望营造心理安全，让新人更容易求助。但虽然提问的动机可能没有错，提问的方式却常常不够恰当。这并不是因为问题本身简单，而是因为背后的思考不完整。

我最近在一个 DevOps 社区的聊天中再次体会到这一点。有人求助于一个卡住的查询——没有提供上下文、没有说明约束条件，也没有交代最终目标。大家要求澄清细节，但后续的追问并没有带来实质性信息。最终，这个讨论串就这样冷却了。

真正导致该讨论串失效的，并不是知识的缺乏，而是思考的分配出现了问题。

转移负荷

我们倾向于把问题视为简单的信息请求。但实际上，它们是 认知负荷 的转移。

当你提出一个模糊的问题时，你并不仅仅在寻求答案。你是在让听者重建你的思维模型，猜测你缺失的约束，并从头探索解空间。你让他们去完成你尚未完成的工作。

一个结构良好的问题已经承担了这些工作的重量。一个结构不佳的问题则把全部工作转嫁给听者。这就是为什么模糊的问题会让人感觉“低努力”。

实践中的区别

你在排查问题时最能明显感受到这种摩擦。

高负载问题

“我的部署无法工作。它在我的机器上可以运行，但在生产环境中失败。有什么想法是什么原因吗？”

没有意义的回答方式。回答者被迫进行猜测。到底在部署什么？部署到哪里？“无法工作”到底指的是什么？

低负载问题

“我正在将一个容器化服务部署到 Kubernetes。Pod 启动后约 30 秒崩溃。日志显示数据库连接超时。该数据库可以从同一命名空间的其他 Pod 访问。我还应该检查什么？”

这个问题尊重了回答者的时间。它包含了观察到的行为、约束条件以及已排除的可能性。即使回答者不知道答案，也知道下一步该去哪里查找。

XY 陷阱

制定一个好问题很困难，因为它迫使你在真正理解问题之前先面对问题的形态。它还能帮助你避免 XY Problem——即询问如何修复你尝试的解决方案（Y），而不是询问实际的根本问题（X）。

例如，你可能会问如何延长连接超时（Y），而真实的问题是你的服务依赖的数据库尚未准备好（X）。

要提出一个好问题，你必须退一步，定义（X）的实际情况：

• 到底是什么失败了？
• 我实际上想要实现什么结果？
• 我有哪些假设？

回答这些问题会迫使你思考。而有趣的事情就在此时发生：准备问题的过程常常会让问题自行消失。

工程师们经常会有这种体验。你开始写 bug 报告时意识到这是一个竞争条件；你给资深工程师起草消息时在写到一半就解决了它。答案并不是来自外部，而是因为你被迫把混乱理清结构后自然出现的。

The AI Parallel

对问题的这种严谨定义正是现代工具对我们的要求。

大型语言模型的兴起强有力地给我们上了这一课。它们称之为 prompt engineering（提示工程），但实际上不过是严谨的提问。如果你给 ChatGPT 一个模糊的提示，你会得到幻觉式的回答。如果你向资深工程师提出模糊的问题，你会收到一封带有“？”的会议邀请拒绝。

在即时 AI 与答案泛滥的时代，提问的质量变得尤为重要。清晰带来洞见；混乱只会产生噪音。

预发送测试

在向同事、论坛或 AI 提出技术问题之前——先用这个过滤器检查一下。如果你无法回答以下问题，说明问题还不够成熟。

• 上下文： 这段代码运行在哪里？与能够正常工作的环境有什么不同？
• 目标： 我真正想要的结果是什么（而不是我当前尝试的方法）？
• 失败： 哪些可观察到的行为表明它已经出错？
• 尝试： 我已经排除了哪些解释？

把问题视为思考的最终产物，而不是在思考之前就提出的东西。当你能够清晰地描述自己已知与所需之间的差距时，通常已经离答案成功了一半。好问题不是对答案的请求，而是已经完成工作的证据。