How To Ask Questions The Smart Way —— 从“会提问”到“会协作、会排障、会使用 AI”

基于 Eric S. Raymond 与 Rick Moen 的经典文章《How To Ask Questions The Smart Way》进行独立的中文现代化解读。原文版本 3.10，2014 年修订。

一、这篇文章到底在讲什么

《How To Ask Questions The Smart Way》通常被中文互联网称为《提问的智慧》。它最早服务于 Unix、Linux、开源软件和网络论坛文化，核心观点非常简单：

它真正反对的并不是“新手提问”，而是把自己的排查工作全部转移给别人。例如：

服务器挂了，怎么办？
为什么这个代码不能运行？
这个报错怎么解决？
求大佬帮忙，在线等，很急！

这些问题的问题不是“太简单”，而是缺少可以让别人开始推理的信息。

二、提问之前：先把问题搞清楚

1. 先搜索，但不要把“搜索过”当成目的

原文非常强调搜索互联网和阅读文档。这个原则今天仍然成立，但方式已经变化。

过去主要是 Google、Bing、邮件列表、论坛和文档；今天还包括 GitHub Issues、官方文档、源码、Stack Overflow、Reddit、Discord，以及 AI 助手。

真正有价值的动作不是“我搜过了”，而是：

• 确认官方文档有没有明确说明；
• 确认问题是否已有 Issue 或讨论；
• 搜索完整错误信息，而不是只搜索“怎么解决”；
• 尝试找到可以复现的最小案例；
• 让 AI 帮你解释错误、整理线索和设计排查步骤；
• 最后用实际环境验证答案，而不是直接复制。

2. 不要把自己的猜测当成事实

例如：

我的 SSH 连不上，是不是防火墙把 9809 端口封了？

更好的方式是：

Ubuntu 24.04。
sshd -T 显示 Port 9809。
但 ss -lntp | grep ssh 仍然显示 22。
重启后仍然如此。
以下是 sshd -T、ss -lntp 和 systemctl status ssh 的结果……

第二种提问给出了可验证事实，回答者可以据此推理。

三、去哪里提问

原文花了相当篇幅讨论 Usenet、邮件列表、IRC 和 Web 论坛。这些渠道今天仍有历史价值，但现代开发环境已经发生明显变化。

四、一个高质量技术问题应该包含什么

可以把一个好问题压缩成 7 个元素：

1. 目标：你原本想实现什么？
2. 环境：系统、软件、版本、运行方式。
3. 现象：实际发生了什么。
4. 预期：你认为应该发生什么。
5. 尝试：你已经做过什么。
6. 证据：错误信息、日志、命令输出、截图、最小代码。
7. 问题：你希望别人帮你确认哪一个具体点。

一个典型结构

【环境】
Ubuntu 24.04
OpenSSH 版本：……

【目标】
希望 SSH 只监听 9809。

【现象】
sshd -T 显示 Port 9809，
但 ss -lntp 仍然显示 22。

【已经尝试】
1. 修改 /etc/ssh/sshd_config
2. systemctl restart ssh
3. 检查 sshd -T
4. 检查监听端口

【证据】
……完整相关输出……

【问题】
为什么配置解析结果是 9809，
实际监听却仍然是 22？

这类问题通常比“Ubuntu SSH 端口修改后还是 22，求助”更容易获得有效答案。

五、描述事实，不要先替别人下结论

这是原文最值得保留的原则之一。

例如不要直接写：

MySQL 把内存吃光了。

除非你已经通过监控数据证明了这一点。否则更准确的是：

服务器 4 GB RAM。
MySQL 进程 RSS 约 2.8 GB。
在过去 30 分钟内内存使用率从 55% 上升到 94%。
同时出现 OOM killer 日志。

第一句话是结论；第二种描述提供的是证据。

六、排障时应该提供哪些信息

对于服务器、网络和软件故障，建议至少提供：

• 操作系统及版本；
• 软件/框架及版本；
• 部署方式，例如 Docker、systemd、PM2、Kubernetes 等；
• 问题首次出现的大致时间；
• 最近做过什么变更；
• 准确错误信息；
• 相关日志；
• 可以稳定复现还是偶发；
• 已经尝试过哪些操作，以及结果；
• 是否存在多个环境，以及问题是否只发生在其中一个环境。

七、代码问题怎么问

代码问题最常见的错误是贴几千行代码，然后问“哪里错了”。

更好的方法是提供最小可复现示例（Minimal Reproducible Example，MRE）：

• 删掉与问题无关的业务代码；
• 保留能够复现问题的最小代码；
• 说明输入；
• 说明实际输出；
• 说明期望输出；
• 说明运行环境和版本。

如果问题与依赖有关，应明确锁定版本。例如：

Node.js 22.x
Next.js 16.x
React 19.x
Windows 11
npm 11.x

八、2026 年：AI 已经改变了“提问前先搜索”

这是原文最需要现代化的一部分。

原文形成于互联网搜索和论坛仍是主要知识入口的时代。现在，AI 助手已经成为很多开发者的第一层排障工具。

AI 不是“免提问”的理由

很多人会直接把：

报错了，帮我解决。

扔给 AI。

这同样是低质量问题。AI 再强，也无法从不存在的信息中推断真实环境。

更好的 AI 提问方式

目标：
我想让 Nginx 将 /old/* 301 到 /new/*。

环境：
Ubuntu 24.04
Nginx 1.26
Cloudflare 在前面做代理。

现象：
访问 /old/test 后没有跳转，而是返回 404。

已经尝试：
……

配置：
……

实际响应：
HTTP/1.1 404 Not Found

请先分析最可能的原因，
再给出验证命令，不要直接假设配置一定有问题。

这种方式不仅适用于 AI，也适用于人类同事。

九、原文哪些内容已经明显过时

尤其需要修正的一点：不要把“不会提问”道德化

老式技术社区有时会把低质量提问者描述得非常难听。这种文化在早期极客社区具有一定历史背景，但今天并不适合作为团队协作规范。

新人可能不知道应该提供哪些信息。好的工程师应该做的是引导对方补齐信息，而不是羞辱对方。

十、2026 年推荐使用的现代提问模板

软件 Bug

【目标】
我想实现……

【环境】
OS：
Runtime：
Framework：
Version：

【问题】
实际发生了……

【预期】
我希望……

【复现步骤】
1.
2.
3.

【错误信息】
……

【已经尝试】
1.
2.
3.

【相关代码/配置】
……

【我的判断】
我怀疑……，但没有确认。

【具体问题】
我想确认为什么……以及应该如何验证。

服务器故障

主机：
OS：
服务：
版本：

故障时间：
最近变更：

现象：
……

相关命令：
……

日志：
……

当前状态：
……

已经排查：
……

希望确认：
……

向 AI 提问

背景：
……

目标：
……

环境：
……

事实：
……

已尝试：
……

证据：
……

请：
1. 列出最可能的原因；
2. 给出验证顺序；
3. 每一步说明预期结果；
4. 根据验证结果决定下一步；
5. 不要把未经验证的假设当成事实。

十一、如果你是回答问题的人

《提问的智慧》主要教育提问者，但现代技术协作还需要反过来思考：回答者也有责任。

• 不要因为问题简单就嘲讽提问者；
• 发现关键信息缺失时，明确告诉对方缺什么；
• 区分“确定结论”和“可能原因”；
• 给出验证方法，而不是只给一个猜测；
• 涉及生产环境时提醒风险；
• 涉及安全信息时提醒脱敏；
• 如果答案依赖版本，要明确版本范围；
• 如果不确定，就说“不确定”，不要编造。

十二、最终原则

如果把整篇经典文章压缩成今天真正实用的 10 条，可以记住：

1. 先说目标。你究竟想实现什么？
2. 给环境。版本往往决定答案。
3. 讲事实。不要把猜测包装成结论。
4. 给证据。日志、错误、命令输出比“感觉”重要。
5. 说你试过什么。避免别人重复你的实验。
6. 提供最小复现。代码越少，问题越容易定位。
7. 问题要具体。明确你希望别人判断什么。
8. 先搜索和使用 AI，但必须验证。
9. 保护敏感信息。公开日志前必须脱敏。
10. 不要羞辱新手。高质量社区的目标是解决问题并沉淀知识。

参考资料

• Eric S. Raymond / Rick Moen：《How To Ask Questions The Smart Way》，原文 3.10，2014 年版本。
• 原文：https://www.catb.org/~esr/faqs/smart-questions.html
• 原文目录包含 Introduction、Before You Ask、When You Ask、How To Interpret Answers、Questions Not To Ask、Good and Bad Questions 等部分。
• 目前网络上也存在基于原文 3.10 的简体中文译本；本文没有直接复制这些译文，而是重新组织并加入现代场景解读。