1.5 提问的智慧

一、先搜索，再提问

1.1 为什么先搜索

在我们遇到问题之前，大概率已经有人遇到过同样的问题，并且得到了回答。直接搜索往往比提问更快，「自己找到答案」的过程本身就是学习。

1.2 搜索的顺序

遇到问题时，可以按下面的梯度逐级查找：

每一步花的时间不超过 10 分钟，都没找到答案再进入下一步。多数问题在前三步就能解决。

1.3 搜索技巧

搜索技巧的完整说明见 1.3 浏览器 中的「搜索运算符」，这里强调几点：

二、提问的结构

搜索了、试过了，还是没解决，这时候才需要向人提问。但「怎么问」同样有讲究。

2.1 好问题 vs 坏问题

先看两个对比，直观感受差距：

问题在哪：

• 「在吗」是无效信息，浪费别人时间
• 没说是什么语言、什么环境、什么报错
• 截图看不到关键信息（完整代码、完整报错）
• 「急」不是别人优先帮我们的理由

void remove(Node* head, int val) {
    while（head != val） {  // 这里报错
        head = head->next;
    }
}

好在哪里：一句话说清目标、环境、问题，给出完整报错，贴了相关代码，说了自己的理解和已尝试的办法，让回答者一眼就知道问题在哪。

2.2 提问的标准模板

把上面的好问题提炼成模板，以后提问照着填：

【背景】我在做什么，用了什么技术栈 / 版本
【目标】我期望达到什么效果
【现状】实际发生了什么，完整报错是什么
【复现】怎样能重新触发这个问题（最小步骤）
【代码】最小可复现代码（贴在代码块里，不要截图）
【已尝试】我搜过什么、试过什么、为什么不 work
【理解】我目前对问题的猜测

三、最小可复现示例

模板里的「最小可复现代码」不是从项目中随意截取一段代码，而是一个经过验证、能让他人独立重现问题的示例。Stack Overflow 当前使用 Minimal, Reproducible Example（MRE）；我们也可能在旧资料中看到 MCVE 或 MWE 等名称。

3.1 MRE 的三个要求

3.2 制作步骤

1. 复制问题代码到一个新的最小目录，不要直接破坏原项目。
2. 记录运行环境、依赖版本和完整命令。
3. 逐步删除无关功能，每次删除后重新确认问题仍然存在。
4. 用固定、非敏感的输入替代数据库、网络服务和个人文件。
5. 从全新目录或另一台设备再次执行，确认步骤没有依赖隐藏状态。

3.3 用代码块，不要截图

代码截图无法复制、搜索或直接运行，也不利于屏幕阅读器。代码、配置和日志应使用带语言标识的代码块；只有界面布局、图形渲染等无法用文本表达的问题才需要截图。

```cpp
#include <iostream>

int main() {
    std::cout << "hello";
    return 0;
}
```

3.4 橡皮鸭调试法

在动手制作 MRE 之前，还有一个更轻量的小技巧值得先试：找一只「橡皮鸭」，把问题讲一遍。

最早的来源可以追溯到《程序员修炼之道》（The Pragmatic Programmer）一书，作者以此讽刺程序员对 bug 的困惑往往在自己「开口解释」的过程中就消失了：

为什么会有效？「讲出来」和「在脑子里想」是两回事：大脑很容易「脑补」掉自己不确定的部分，而开口说话时，每一行都必须被明确地说出来，任何不严谨的假设都会暴露。

四、提问的礼仪

结构对了、代码够精简，还差最后一步：在对的地方、用对的态度提问。

4.1 选择合适的场合

4.2 标题要具体

在论坛或邮件里提问，标题是别人决定是否点进来的第一道门。

好标题包含：技术栈 + 问题现象 + 关键错误，让人一眼判断自己能不能帮上忙。

4.3 不做「伸手党」

「伸手党」指那些只想索取、不愿自己动手的人。典型表现：

• 直接发题目要求别人给答案
• 伸手要源码、要笔记、要破解软件
• 问「有没有 xxx 教程」（搜索引擎一搜就有）
• 收到答案后从不反馈、从不道谢

4.4 回应答案

得到回答后：

五、提问中的常见误区

掌握了正确的提问方法，还得知道哪些坑不能踩。下面三种是最常见的提问误区，看起来是小问题，实际上会让我们的问题石沉大海。

5.1 XY 问题

「XY 问题」是指：我们想解决 X，我们觉得方法 Y 能解决，于是我们问「怎么做 Y」，但 Y 其实是错的思路，真正该问的是 X。

例如：我们问「怎么用正则提取 HTML 里的所有 <div>」，但真正目标是「解析 HTML 并取得所有 div 的内容」。前者用正则极易出错，后者用 HTML 解析库一行代码即可完成。

避免 XY 问题的办法：提问时同时说明「我想做什么（X）」和「我打算怎么做（Y）」，让回答者有机会指出更优解。

5.2 「不 work」式提问

「不 work」式提问只说“不 work”这个现象，不带任何上下文，等于把排查责任全推给回答者，好像别人欠我们一个解释。更好的说法是「我期望 A，实际得到 B，差距可能在哪里」，把问题描述清楚，而不是要别人替我们 debug。

5.3 一问多题

一次问五六个不相关的问题，会让回答者望而却步。一次只问一个核心问题，解决了再问下一个。

六、向 AI 提问

到目前为止讨论的都是「向人提问」，但如今我们还有一个全年无休的「回答者」——AI 助手。好消息是，上面的原则几乎全部适用；坏消息是，AI 有 AI 自己的坑——不过其中不少已经被更强的新模型填平了。

6.1 AI 也是「回答者」

AI 助手（ChatGPT、Claude 等）也是「回答者」，同样适用上面的原则。给 AI 提问时：

6.2 能力与注意力的边界

AI 助手的能力更新得很快。过去常见的短板——知识有截止时间、默认不能上网、算术容易出错、上下文很短——在如今的主流模型中大多已经逐渐解决：内置联网搜索、更大的上下文窗口和更强的推理能力，都已成为或正在成为标配。先看这些曾经的短板如今怎么样了：

短板在填平，但还有两条边界始终需要我们自己把握：幻觉（见 6.3）与注意力稀释。先说注意力：即使信息都在上下文窗口内，对话越长、内容越多，模型对每一个细节的关注度就越低——尤其是夹在中间位置的早期内容，往往最容易「被忽略」。

和 AI 聊久了，我们会遇到一个「客服腔」的梗：它开篇总要先来一段安抚，把注意力最集中的位置让给承诺——

“我会稳稳妥妥地接住你，详细地、认真地、逐条地为你分析问题，并给你最合适解决方案！”

“我会认真地、仔细地帮你分析这个问题。”

“我的看法是完全可行的，我们来一步步解决。”

“请放心的交给我，我会一步步给你解决的方案。”

一个信息量都没有，但每次看到还是忍不住会心一笑——跳过它，直接看后面的正题就好。

6.3 幻觉：一本正经地胡说八道

「幻觉」（Hallucination）指模型生成出看似合理、实则子虚乌有的内容。更强的模型降低了幻觉的出现频率，但并没有根除它——因为模型的任务是「续写最像样的文字」，而不是查证事实：当信息不在训练数据中时，它不一定会说「不知道」，而是可能编一个听上去很专业的答案。

典型表现：

6.4 给 AI 的好提示词示例

我在学 C++ 数据结构，刚接触链表。
环境：g++ 15.2, Windows 11。
我写了一个反转单链表的函数，但输出不对（原样输出）。
代码如下：
[贴代码]

请帮我：
1. 指出 bug 在哪
2. 解释为什么会导致原样输出
3. 给出修正后的代码

七、TODO 清单

• 遇到问题时，按「报错信息 → 搜索引擎 → AI 助手 → 官方文档 → 社区 → 人」的顺序排查一次
• 把最近遇到的某个问题，用标准模板改写成一份完整提问
• 制作一个可独立复现的 MRE，并在全新目录中验证一遍
• 在课程群或社区，帮朋友回答一个我们会的问题
• 把本节内容讲给一位朋友听，互相检查提问中的常见误区😉

八、值得我们思考的问题