对初学者：智慧地提问

约 12253 字大约 41 分钟

2025-10-13

引言

这篇文章，主要是写给所有正在入门，或还未入门编程的人的。正如标题所说，我希望这篇文章可以助你在初学编程时就掌握如何正确地提出问题，从而提高解决问题的效率和你自己的 debug 能力。

当然，如果你在阅读本文过程中遇到了疑惑想要提问，也请类比本文的方法先尝试自行解决，而不是一股脑将所有问题倾泻给他人。这对于多数人来说只会是负担。

此外，本文受 Eric S. Raymond, Rick Moen 的提问的智慧 How To Ask Questions The Smart Way (英文原文) 一文启发，后文也会有很多内容直接或间接来自这篇文章。你不妨把本文看作《提问的智慧》 2025 edition。虽然《提问的智慧》比较直言直语，但我还是挺推荐你去看看的 👀 。

简体中文翻译版：https://github.com/ryanhanwu/How-To-Ask-Questions-The-Smart-Way/blob/main/README-zh_CN.md

〇、为什么你要智慧地提问

很简单。每个人的时间和精力都是有限的。在一个开放的交流平台上，包括但不限于各类论坛、网站和各个交流群中，多数情况下回答问题的人都没有直接从你那里得到什么好处（比如报酬），无偿为你解答。而一个有价值的提问可以增加社区经验，也能让回答者有所裨益，而不是拜拜浪费时间。

因此你要智慧地提问。

一、在提问之前 —— 获取提问所需的信息

——这一部分将会着重说明，你可以从哪些渠道获取信息。

如果你的程序出了岔子，永远不要直接向他人求助：

“我的 xxx 程序报错了，有谁知道怎么改吗？”

这种提问没有容纳任何信息，拿去拜佛或许还能求个答案。

所以，你应该在 提问前 就通过下列渠道搜集足够详实的资料。

0. 重中之重，你的代码

巧妇难为无米之炊，巧（程序）员难为无（代）码之 de（bug）。

向他人求助时，95% 以上的情况对方并不知道你所处的具体情况、你代码的具体实现以及你的思路是什么。如果你不给代码，没人知道到底是你的编程环境出问题了、算法写错了还是看错作业题目了。

假设你真的很懒，至少你应该把你认为出问题的那段贴出来。比如一个完整的函数和调用这个函数的上下文。

注意

如果你的代码很长，不要把它们全部以纯文本的形式发过去。比如直接粘到微信群聊里。这很容易淹没其他消息。

你可以：

截取出问题的部分。
保存成一个文件，然后再丢群里。
把全部代码上传到 GitHub 仓库（或其他什么 git 仓库）然后把仓库链接丢给对面。

你需要根据实际情况选择使用何种方式。

总结：话不在多而在精

提示

另附如何快速发送所有代码：

省流：Ctrl A Ctrl C Ctrl V

当光标（工字形）在代码编辑区域内时，同时按下键盘上的 Ctrl A 两个键，此时所有代码都会被选中
按下 Ctrl C ，此时所有的代码会被复制到系统的剪贴板中。
- Tips：多按几次，以防第一次没有按上。
进入微信/邮箱/浏览器等，点一下文本框区域，按下 Ctrl V，剪贴板中的代码被复制到文本框中。

1. 你最忠实的“伙伴” —— 终端 / 命令行 / 控制台

对于初学者而言，多数情况下你都可以在这三者中拿到程序的输出——不论是你期望的正确结果，还是报错信息和调用堆栈。请你找到它们，并附在提问中。

对在线评测系统（OJ）使用者

大多数 OJ 都会在结果页提供编译结果和程序运行的报错。

你也应该提供如上图所展现的所有信息。~~如果平台没有提供那就算了。~~

2. “你应该往上翻翻 ”

在提问前，除了解你的代码（程序）的基本情况以外，你最应该先在微信/QQ 相关群聊里翻一下聊天记录。 尤其是你还没有看过的消息！！！

在大学编程作业这个情境下，这一条尤为重要。因为，不少同学在同时做同样的题，有很大的概率产生相似甚至完全一样的问题。因此如果你没有翻看之前的聊天记录就直接提问，很有可能问到刚刚已经回答过一遍的问题。

而如果一个问题刚被提出来没多久就又被提起来一次，从答者的角度来看，这是十分令人厌烦的行为 —— 就好像面对面聊天，你刚刚长篇大论但是听者却走神了。没有人希望自己的言论被忽视，不论是在现实还是在网上。因此，重复的提问大概只会得到一个没好气的回复，告诉你去看看聊天记录。

3. 人不能不会使用搜索引擎

你可以使用：必应谷歌

警告

因为百度实在太烂甚至会产生后果所以我不推荐任何人任何时候使用此搜索引擎

当你的程序遇到问题的时候，你应该去网上看看。带上你的代码和报错，去~~诗和远方~~必应和谷歌找找吧。

哪些网站的信息往往更准确？

如何确认自己能否访问国际互联网？

在浏览器地址栏输入 https://google.com，如果不能访问，那么你大概率就不能访问国际互联网。

提示

下面的部分网站需要能够访问国际互联网才能有比较流畅的体验。

指名道姓：

GitHub
python 官网
Stack Overflow
...

如果编程语言有它的官网（如 Python ArkTS 等），你一般可以在官网找到详细的文档。
w3schools https://www.w3schools.com/
- 这是一个免费教程，内容极其丰富，墙裂推荐
- 唯一缺点是全英文，需要一定语言功底
w3school 中文镜像 https://www.w3school.com.cn/
- 在 W3School，你可以找到你所需要的所有的网站建设教程。当然也有 C C++ Python 等语言的学习资源。
如果你正在研究开源项目，去 GitHub 仓库页仔细查看 README.md；查看仓库的 issue 、wiki 、discussion 都是很不错的选择。
菜鸟教程 https://www.runoob.com/cprogramming/c-tutorial.html
- 是一个很全面的开发教程网站，你可以在这里找到几乎所有开发语言的基础技术教程
- 但是比较简明，有些内容不够详实
- 推荐用作语法速查手册以及语言导览
博客园 https://www.cnblogs.com/
- 博客园是一个面向开发者的知识分享社区。自创建以来，博客园一直致力并专注于为开发者打造一个纯净的技术交流社区，推动并帮助开发者通过互联网分享知识
- 这是个 blog 的集合站，正如它的名字。上面的博主们多是经验丰富的开发者，内容原创性高、质量相对好。
稀土掘金 https://juejin.cn/
- 掘金是面向全球中文开发者的技术内容分享与交流平台。相对博客园来说创立时间要晚一些，类似开发特化的知乎。
腾讯云 & 阿里云开发者社区 https://cloud.tencent.com/developer https://developer.aliyun.com/
- 这两个社区分别来自腾讯云和阿里云，内容不是特别多但是质量也还可以。
CSDN https://www.csdn.net/
- 缺点：网站比较杂乱，会有比较多广告和收费项；部分文章不付钱看不了；文章抄袭比较严重；不好好排版的博主有点多，阅读体验不太好；
- 但是不排除有些文章确实很好。
其他技术社区，如 Stack Overflow 。
- 说明：其实 Stack Overflow 帖子质量是相当不错的，但是主要集中于开源项目的讨论，而不是初学时候遇到的各类问题。再加上这东西大陆访问速度和可用性不太好，所以对于初学来说不是特别推荐。

4. 教材不是用来垫桌脚的

对于学生，应当都会拿到一批教材，其中有可能包含编程相关的教材。如果你没有，也可以去淘一本。当然，在线的教程也很好！

你应该先大致定位出你的问题在哪，并根据目录查找对应正文（或在线教程）。

~~虽然在国内，大学教材平均水平比较一般，但是也不应该一点都不看。至少先翻开看看写得到底咋样。水平实在太烂可以去搜搜哪些教程写得比较好。~~

校者注：教材就是用来垫桌角的。

大部分你能买到的教材的编排就是一坨。我认为程序作为一个反馈极强的工科，可能更需要的是先对计算机有一个初步的把握然后去查文档搜教程，而不是按照顺序啃教程。教材对于前者显然没啥正向作用，对于后者也不够方便。

编者附注：已阅。准了。

5. 为何不看看神奇的 FAQ

通常，在一些技术文档中会有这么个词 —— FAQ 。它是 Frequently Asked Question 的英文缩写。中文译为：常见问题。

这是别人做好的错题本，没理由不抄作业。也许你的错误并不常见，但是看 FAQ 可以帮助你减少这些错误，不是吗？

6. 大人，时代变了 —— 善用 AI 工具

说实在的，现在 AI 工具已经能够在很多领域超越大部分人类了。“道之所存，师之所存也”又何尝不能迁移至 AI 身上呢？问就完了。

往往，这些 AI 足够解决大多数问题了。

提示

向 AI 提问时，你也需要发送前 4 条所要求的相关信息。不然 AI 很可能不能解决你的问题。

7. GFW相关

什么是GFW？「伟大的火墙」。此系统可以一定程度上限制你访问的网站，如你无法在内地访问twitter等，而很多境外网站访问的体验一言难尽都可以很大程度上归功于这个玩意。

注意

中国政府(内地)没有公开指出这个系统的存在，也就是说它并不是非常乐意让此物公之于众，所以大肆谈论这个系统可能不是非常好的主意。由于中国政府(内地)不能/难以管控境外的信息和舆论，而这些信息和舆论如果在中国广泛传播会对中国政府的执政产生不小的困扰，且不利于大中华区互联网生态的建成，因此中国政府对此进行了一些限制。

需要注意的是，由于简体中文互联网的舆论管控，它与国际互联网在内容上有较大的差异，可能会对新的国际互联网来访者造成一定的影响。在此推荐以学业为重，没有必要做一些没有成效的事。学者张维为曾说过「只要你自信怎么表达都可以」，我想这才应当是努力的方向。

如何一定程度上绕过GFW的限制？

使用穿墙软件
使用翻墙软件

请联系你周围的同学获取相关资源。

8. 当找到了一些线索

暂时不要提问 。根据你已经搜索到的信息，不妨再试着修改几次代码，说不定就能发现是某处因为粗心而错。

相信你自己能够独立解决问题。

问题已经解决了？

如果你严格按照上面的步骤执行，我相信多数问题都已经得到了很好的解决。若果真如此，那么恭喜你，你已经具备了一定的自学与探究能力，迈出了走向成熟开发者最重要的一步。

二、当你提问时 —— 清楚且得体地发布信息

经过上面的步骤，你还是没有解决问题，那你可以考虑找个地方提问了。

你现在应该至少掌握如下信息：

源码，输入，输出，报错等（这些是核心内容，尽可能避免缺省）
在出现问题、搜索资料后你又做了哪些尝试与改动

1. 让别人清晰理解你的问题

显然这是你需要的。这不仅仅是一个语言能力层次的问题，同样也是一个态度问题。抱着随便的心态请求帮助，貌似并不合适，对吧。正如原文所说：

准备好你的问题，再将问题仔细地思考过一遍，因为草率的发问只能得到草率的回答，或者根本得不到任何答案。越是能表现出在寻求帮助前你为解决问题所付出的努力，你越有可能得到实质性的帮助。
—— 提问的智慧

原文这一段适用于几乎所有情况，不论是向同学提问，还是向技术大牛提问。不论如何，既然已经在线上沟通，你拥有反复修改消息的能力。善用它，让提问变得更有价值。

下面是一些你可以参考的标准，稍微打磨一下你的提问。

说人话

显然现在是一个 流行语和烂梗 到处飞的时代。我们不排斥它们，但厌恶滥用流行语及烂梗的人。在合适的范围内，一段提问中用上那么几处不影响理解的梗，反而让你的提问显得更有意思。 ~~比如这篇文章，虽用了不少流行语，但并不会造成很大的理解障碍~~

大量缩写（尤其是不明缩写，例如 xbkds）是令人厌烦的。如果你要使用缩写，那么它在社群应能被广泛接受。至少要确保社群中其他人能看懂。比如，使用类似的格式标注一下：

我的 ghedu (GitHub Education) 申请又没过。ghedu的申请页上我填写了这些信息。我尝试过方法1 方法2 方法... ，但是都没啥屌用，全都寄了。有申请ghedu的诀窍没？
请注意
这个例子比较好地说明了提问时应该带上什么内容。在非开发领域提问时，这样做也有助于得到一份有帮助的答案。

此外， 小心地遣词造句 是一个很好的习惯。是时候展现你的语文和英语水平了！如前文所说，你的提问没必要很正式。但是这不意味着你可以毫不用心地随便写写。

如果你需要把你的问题发送到国际论坛，请使用英语发帖。在国际互联网上，英语是通用语言。如果你担心你英文不过关，大可以用翻译器或者 AI 代劳翻译。或者，你也可以写一个双语帖子。

务必确保你的英文语法和拼写是正确的。

我们从经验中发现，粗心的提问者通常也会粗心地写程序与思考（我敢打包票）。回答粗心大意者的问题很不值得，我们宁愿把时间耗在别处。
正确的拼写、标点符号和大小写是很重要的。一般来说，如果你觉得这样做很麻烦，不想在乎这些，那我们也觉得麻烦，不想在乎你的提问。花点额外的精力斟酌一下字句，用不着太僵硬与正式 —— 事实上，开发者文化很看重能准确地使用非正式、俚语和幽默的语句。但它必须很准确，而且有迹象表明你是在思考和关注问题。
正确地拼写、使用标点和大小写，不要将its混淆为it's， loose 搞成 lose 或者将 discrete 弄成 discreet 。不要全部用大写，这会被视为无礼的大声嚷嚷（全部小写也好不到哪去，因为不易阅读。）。
更白话的说，如果你写得像是个小白，那多半得不到理睬。也不要使用即时通信中的简写或火星文，如将 的 简化为 d 会使你看起来像一个为了少打几个键而省字的小白。
—— 提问的智慧 · 使用清晰、正确、精准且合乎语法的语句

规范美观的代码

即使是初学者，我依然推荐先让代码好看、好读。

你需要这个 —— 格式化。这个概念不同于硬盘、U盘的格式化（这个是抹除所有数据）。在代码领域，*格式化* 通常指规范代码格式。

下面的两段代码直观地展示了格式化的威力。经过格式化的代码可以更加易读，也会让你看起来更专业。这两点无疑都会大大增加代码阅读者对你的好感。

没有格式化前 🥵

#include <stdio.h>
int main() { 
    int year;
    float money,rate,total; /* 本金 月利率 本利合计*/
    printf("Input money and year =?");
    scanf("%f  %d",&money,&year);/* 输入本金和年 */
    switch(year){
    case 1:rate=0.0032;  /* 根据年限定利率 */
        break;
    case 2:rate=0.0041;
        break;
    case 3:rate=0.005;
        break;
    case 5:rate=0.0055;
        break;
    case 8:rate=0.0065;
        break;
    default:rate=0.0;}
    total = money+money*rate*12*year;
    printf(" Total = %.2f\n",total);
}

格式化之后 😉

#include <stdio.h>
int main()
{
    int year;
    float money, rate, total; /* 本金 月利率 本利合计*/
    printf("Input money and year =?");
    scanf("%f  %d", &money, &year); /* 输入本金和年 */
    switch (year)
    {
    case 1:
        rate = 0.0032; /* 根据年限定利率 */
        break;
    case 2:
        rate = 0.0041;
        break;
    case 3:
        rate = 0.005;
        break;
    case 5:
        rate = 0.0055;
        break;
    case 8:
        rate = 0.0065;
        break;
    default:
        rate = 0.0;
    }
    total = money + money * rate * 12 * year;
    printf(" Total = %.2f\n", total);
}

具体的格式化方法请读者自行搜索。你可以按照如下格式搜索：你写代码用的软件格式化代码 (etc. VSCode 格式化代码)。

如果你使用 VSCode ，那么默认的格式化快捷键是 Alt Shift F 。你可能需要遵循指引配置格式化插件。如果遇到问题，也请按照本指南，自行排查后再询问他人。

截图是个好东西

对，截图毋庸置疑地比手机拍屏要好。你可以节省掏出手机拍照的时间、得到没有阴影和屏幕反光的照片、让你的提问看起来更加专业，然后让回答者更乐意解答你的问题。

所以如果条件允许，避免使用手机拍屏的方式传达信息。

对于 Windows 系统，系统自带的截图快捷键是 Win Shift S 。框选截图区域后，这张图片会直接被复制到系统剪贴板中。你可以直接在微信 QQ 等软件的聊天框中按下 Ctrl V 将图片粘贴至输入框。按下回车键 Enter ⏎ 以发送。

对于 MacOS 系统，自带的截图不是很好用。我推荐你上网搜搜有没有什么好用的截图软件。或者，如果你愿意倒腾，也可以修改系统设置，让自带截图工具没那么难用。

精确描述并言之有物

本节内容截取自提问的智慧 · 精确地描述问题并言之有物

仔细、清楚地描述你的问题或 Bug 的症状。
描述问题发生的环境（机器配置、操作系统、应用程序、以及相关的信息），提供经销商的发行版和版本号（如：Fedora Core 4、Slackware 9.1等）。
描述在提问前你是怎样去研究和理解这个问题的。
描述在提问前为确定问题而采取的诊断步骤。
描述最近做过什么可能相关的硬件或软件变更。
尽可能地提供一个可以重现这个问题的可控环境的方法。

以上几点中，当你报告的是你认为可能在代码中的问题时，给开发者一个可以重现你的问题的环境尤其重要。当你这么做时，你得到有效的回答的机会和速度都会大大的提升。

Simon Tatham 写过一篇名为《如何有效地报告Bug》的出色文章。强力推荐你也读一读。

话不在多而在精

本节内容截取自提问的智慧 · 话不在多而在精

你需要提供精确有内容的信息。这并不是要求你简单的把成堆的出错代码或者资料完全转录到你的提问中。如果你有庞大而复杂的测试样例能重现程序挂掉的情境，尽量将它剪裁得越小越好。

这样做的用处至少有三点。第一，表现出你为简化问题付出了努力，这可以使你得到回答的机会增加；第二，简化问题使你更有可能得到有用的答案；第三，在精炼你的 bug 报告的过程中，你很可能就自己找到了解决方法或权宜之计。

按发生时间先后列出问题症状

本节内容截取自提问的智慧 · 按发生时间先后列出问题症状

问题发生前的一系列操作，往往就是对找出问题最有帮助的线索。因此，你的说明里应该包含你的操作步骤，以及机器和软件的反应，直到问题发生。在命令行处理的情况下，提供一段操作记录（例如运行脚本工具所生成的），并引用相关的若干行（如 20 行）记录会非常有帮助。

如果挂掉的程序有诊断选项（如 -v 的详述开关），试着选择这些能在记录中增加调试信息的选项。记住，多 不等于 好 。试着选取适当的调试级别以便提供有用的信息而不是让读者淹没在垃圾中。

如果你的说明很长（如超过四个段落），在开头简述问题，接下来再按时间顺序详述会有所帮助。这样开发者们在读你的记录时就知道该注意哪些内容了。

2. 让他人觉得你值得被回复 —— 至少不要冒犯他人

本节内容编排自提问的智慧

别动辄声称找到 Bug

当你在使用软件中遇到问题，除非你非常、非常的有根据，不要动辄声称找到了 Bug。提示：除非你能提供解决问题的源代码补丁，或者提供回归测试来表明前一版本中行为不正确，否则你都多半不够完全确信。这同样适用在网页和文件，如果你（声称）发现了文件的 Bug ，你应该能提供相应位置的修正或替代文件。

请记得，还有其他许多用户没遇到你发现的问题，否则你在阅读文件或搜索网页时就应该发现了（你在抱怨前已经做了这些，是吧？）。这也意味着很有可能是你弄错了而不是软件本身有问题。

编写软件的人总是非常辛苦地使它尽可能完美。如果你声称找到了 Bug，也就是在质疑他们的能力，即使你是对的，也有可能会冒犯到其中某部分人。当你在标题中嚷嚷着有 Bug 时，这尤其严重。

提问时，即使你私下非常确信已经发现一个真正的 Bug，最好写得像是你做错了什么。[编者注：就是要说得委婉一些] 如果真的有 Bug，你会在回复中看到这点。这样做的话，如果真有 Bug，维护者就会向你道歉，这总比你惹恼别人然后欠别人一个道歉要好一点。

低声下气不能代替你应该干的活

有些人明白他们不该粗鲁或傲慢的提问并要求得到答复，但他们选择另一个极端 —— 低声下气： 我知道我只是个可悲的新手，一个失败者，但... 。这既使人困扰，也没有用，尤其是伴随着与实际问题含糊不清的描述时更令人反感。

别用原始灵长类动物的把戏[编者注：示弱与自我贬低]来浪费你我的时间。取而代之的是，尽可能清楚地描述背景条件和你的问题情况。这比低声下气更好地定位了你的位置。

有时网页论坛会设有专为新手提问的版面，如果你真的认为遇到了初学者的问题，到那去就是了，但一样别那么低声下气。

去掉无意义的提问句

避免用无意义的话结束提问，例如 有人能帮我吗？ 或者 这有答案吗？ 。

首先：如果你对问题的描述不是很好，这样问更是画蛇添足。

其次：由于这样问是画蛇添足，开发者们会很厌烦你 —— 而且通常会用逻辑上正确，但毫无意义的回答来表示他们的蔑视，例如：没错，有人能帮你或者不，没答案。

一般来说，避免用 是或否、对或错、有或没有 类型的问句，除非你想得到是或否类型的回答。

即使你很急也不要在标题写 `紧急`

~~我知道你很急但是你先别急。~~

这是你的问题，不是我们的。宣称 紧急 极有可能事与愿违：大多数开发者会直接删除无礼和自私地企图即时引起关注的问题。更严重的是，紧急 这个字（或是其他企图引起关注的标题）通常会被垃圾信过滤器过滤掉 —— 你希望能看到你问题的人可能永远也看不到。

有半个例外的情况是，如果你是在一些很高调，会使开发者们兴奋的地方，也许值得这样去做。在这种情况下，如果你有时间压力，也很有礼貌地提到这点，人们也许会有兴趣回答快一点。

当然，这风险很大，因为开发者们兴奋的点多半与你的不同。譬如从 NASA 国际空间站（International Space Station）发这样的标题没有问题，但用自我感觉良好的慈善行为或政治原因发肯定不行。事实上，张贴诸如紧急：帮我救救这个毛茸茸的小海豹！肯定让你被开发者忽略或惹恼他们，即使他们认为毛茸茸的小海豹很重要。

如果你觉得这点很不可思议，最好再把这份指南剩下的内容多读几遍，直到你弄懂了再发文。

礼多人不怪，而且有时还很有帮助

彬彬有礼，多用请和谢谢您的关注，或谢谢你的关照。让大家都知道你对他们花时间免费提供帮助心存感激。

坦白说，这一点并没有比使用清晰、正确、精准且合乎语法和避免使用专用格式重要（也不能取而代之）。开发者们一般宁可读有点唐突但技术上鲜明的 Bug 报告，而不是那种有礼但含糊的报告。（如果这点让你不解，记住我们是按问题能教给我们什么来评价问题的价值的）

然而，如果你有一串的问题待解决，客气一点肯定会增加你得到有用回应的机会。

（我们注意到，自从本指南发布后，从资深开发者那里得到的唯一严重缺陷反馈，就是对预先道谢这一条。一些开发者觉得先谢了意味着事后就不用再感谢任何人的暗示。我们的建议是要么先说先谢了，然后事后再对回复者表示感谢，或者换种方式表达感激，譬如用谢谢你的关注或谢谢你的关照。）

3. 合适的提问能帮你更快地找到问题

本节内容编排自提问的智慧

描述目标而不是过程

如果你想弄清楚如何做某事（而不是报告一个 Bug），在开头就描述你的目标，然后才陈述重现你所卡住的特定步骤。

经常寻求技术帮助的人在心中有个更高层次的目标，而他们在自以为能达到目标的特定道路上被卡住了，然后跑来问该怎么走，但没有意识到这条路本身就有问题。结果要费很大的劲才能搞定。

聪明问题 2

我正试着用替换一幅图片的色码（color table）成自己选定的色码，我现在知道的唯一方法是编辑每个色码区块（table slot），但却无法从某绘图程序的颜色选择器取得十六进制的 RGB 值。

第二种提问法比较聪明，你可能得到像是 建议采用另一个更合适的工具 的回复。

描述问题症状而非你的猜测

告诉开发者们你认为问题是怎样造成的并没什么帮助。（如果你的推断如此有效，还用向别人求助吗？），因此要确信你原原本本告诉了他们问题的症状，而不是你的解释和理论；让开发者们来推测和诊断。如果你认为陈述自己的猜测很重要，清楚地说明这只是你的猜测，并描述为什么它们不起作用。

蠢问题 1

我在编译内核时接连遇到 SIG11 错误，我怀疑某条飞线搭在主板的走线上了，这种情况应该怎样检查最好？

聪明问题 1

我的组装电脑是 FIC-PA2007 主机板搭载 AMD K6/233 CPU（威盛 Apollo VP2 芯片组）， 256MB Corsair PC133 SDRAM 内存，在编译内核时，从开机 20 分钟以后就频频产生 SIG11 错误，但是在头 20 分钟内从没发生过相同的问题。重新启动也没有用，但是关机一晚上就又能工作 20 分钟。所有内存都换过了，没有效果。相关部分的标准编译记录如下…

由于以上这点似乎让许多人觉得难以配合，这里有句话可以提醒你：所有的诊断专家都来自密苏里州。 美国国务院的官方座右铭则是：让我看看（出自国会议员 Willard D. Vandiver 在 1899 年时的讲话： 我来自一个出产玉米，棉花，牛蒡和民主党人的国家，滔滔雄辩既不能说服我，也不会让我满意。我来自密苏里州，你必须让我看看。）针对诊断者而言，这并不是一种怀疑，而只是一种真实而有用的需求，以便让他们看到的是与你看到的原始证据尽可能一致的东西，而不是你的猜测与归纳的结论。

所以，大方地展示给我们看吧！

4. 选择合适的提问渠道

多数时候你可以通过以下渠道提问：

如果你是学生，那大概有一个课程群聊。
- 在这里，你可以直接向老师提问，也可以问到同学，是一个相对融洽的环境。如果要在这里提问，务必先翻一翻过往聊天记录有没有类似情况。
  提示
  有一个简单的标准来判断你是否应该立刻提问：如果这个群里还有未读消息，那你首要任务是翻看这些新消息而不是再给别人发好几条更新的消息。
a. 即时通讯软件（IM，Instant Message）的私聊，包括但不限于微信、QQ、TIM 和 B站私信
b. 私发邮件
- 不要贸然使用这两个渠道。对一个完全陌生的人发去私聊，是不太礼貌的做法。
  尤其是向一个不认识你的人询问类似“如何解压缩”这种最基本的电脑操作。这只会显得你毫无独立解决问题的能力。开发者们关注的是自己的软件在不同平台上兼容性如何、性能怎样、稳定性好不好，而不是教一个素不相识者电脑基础。
  如果你正在使用某位开发者的软件，更不要在出问题时首先通过私聊质问“为什么你的软件不能正常运行”。这非常非常不礼貌，而且大概率得不到什么回应。你或许应该首先再去把软件相关文档通读一遍。若真是软件开发者的锅，也请不要用这样的语言指出对方的错误。参照别动辄声称找到 Bug 这一节。
- 何时可以私聊？
  - 你和对方很熟；
  - 你要提的问题对社区没有什么贡献，比如你的问题很偏门；
  - 你确定你的问题值得对方花时间为你一对一解答；
  - 如果你找遍了各大论坛都没有相关讨论区，而只能找到开发者的联系方式，那没啥办法，私聊就行。
技术论坛
- 在任何论坛发文以前，先确认一下有没有搜索功能。如果有，就试着搜索一下问题的几个关键词，也许这会有帮助。如果在此之前你已做过通用的网页搜索（你也该这样做），还是再搜索一下论坛，搜索引擎有可能没来得及索引此论坛的全部内容。
  —— 提问的智慧 · 网站和 IRC 论坛
  虽然已经有了十余年的历史，但如今这段原文仍然适用。

三、如何解读回复

RTFM、STFW 和它们的新亲戚：如何知道你已完全搞砸了

《提问的智慧》如是说

有一个古老而神圣的传统：如果你收到 RTFM（Read The Fucking Manual） 的回应，回答者认为你应该去读他妈的手册。当然，基本上他是对的，你应该去读一读。

RTFM 有一个年轻的亲戚。如果你收到 STFW（Search The Fucking Web） 的回应，回答者认为你应该到他妈的网上搜索。那人多半也是对的，去搜索一下吧。（更温和一点的说法是 Google 是你的朋友！）

而到了如今，我想这两位还有别的亲戚。

CTFH —— Check The Fucking (Chat) History 。如果你收到这个，回答者认为你应该翻一翻他妈的聊天记录。

ATFC —— Ask The Fucking Chatbot 。你知道的。你应该去问一问他妈的 AI 大模型。更温和一些的说法是豆包 / Deepseek / 通义千问 / Kimi 是你的朋友。

《提问的智慧》总结道：

通常，用这两句[编者注：现在是四句了]之一回答你的人会给你一份包含你需要内容的手册或者一个网址，而且他们打这些字的时候也正在读着。这些答复意味着回答者认为：

你需要的信息非常容易获得；
你自己去搜索这些信息比灌给你，能让你学到更多。

也就是说，一旦你收到了类似的回复，那一定是你在提问之前没有做好自己的工作。你应该按照第一节（在提问之前 —— 获取提问所需的信息）的指示重新写一份提问。

如果还是搞不懂

《提问的智慧》原文

如果你看不懂回应，别立刻要求对方解释。像你以前试着自己解决问题时那样（利用手册，FAQ，网络，身边的高手），先试着去搞懂他的回应。如果你真的需要对方解释，记得表现出你已经从中学到了点什么。

比方说，如果我回答你：看来似乎是 zentry 卡住了；你应该先清除它。，然后，这是一个很糟的后续问题回应：zentry 是什么？好的问法应该是这样：哦~~~我看过说明了但是只有 -z 和 -p 两个参数中提到了 zentries，而且还都没有清楚的解释如何清除它。你是指这两个中的哪一个吗？还是我看漏了什么？

简要来说，你最好先 RTFM 、 STFW 、 CTFH 或 ASFC 自己研究研究再说。

不该问的问题

本节内容编自《提问的智慧 · 不该问的问题》一节

这一节具体形成时间较难考证，但是到 2025 年，至少有 10 年历史。可笑的是，时至今日，这些问题在互联网上仍屡见不鲜。

这十年间技术有了突飞猛进的进展，可人们自主解决问题的能力貌似却开了倒车。

所以参考一下前人的智慧，避免无效的提问。这对你我都好。

以下是几个经典蠢问题，以及黑客没回答时心中所想的：

问题：我能在哪找到 X 程序或 X 资源？

问题：我怎样用 X 做 Y？

问题：如何设定我的 shell 提示？

问题：我可以用 Bass-o-matic 文件转换工具将 AcmeCorp 文件转换为 TeX 格式吗？

问题：我的程序/设定/SQL 语句没有用

问题：我的 Windows 电脑有问题，你能帮我吗？

问题：我的程序不会动了，我认为系统工具 X 有问题

问题：我在安装 Linux（或者 X ）时有问题，你能帮我吗？

问题：我怎么才能破解 root 帐号/窃取 OP 特权/读别人的邮件呢？

问题：我能在哪找到 X 程序或 X 资源？

回答：就在我找到它的地方啊，白痴 —— 搜索引擎的那一头。天哪！难道还有人不会用 Google 吗？

编者注

对于无法访问国际互联网的人，你可以试试必应。

问题：我怎样用 X 做 Y？

回答：如果你想解决的是 Y ，提问时别给出可能并不恰当的方法。这种问题说明提问者不但对 X 完全无知，也对 Y 要解决的问题糊涂，还被特定形势禁锢了思维。最好忽略这种人，等他们把问题搞清楚了再说。

问题：如何设定我的 shell 提示？？

回答：如果你有足够的智慧提这个问题，你也该有足够的智慧去 RTFM，然后自己去找出来。

问题：我可以用 Bass-o-matic 文件转换工具将 AcmeCorp 文件转换为 TeX 格式吗？

回答：试试看就知道了。如果你试过，你就知道了答案，就不用浪费我的时间了。

问题：我的 {程序/设定/SQL 语句} 没有用

回答：这不算是问题吧，我对要我问你二十个问题才找得出你真正问题的问题没兴趣 —— 我有更有意思的事要做呢。在看到这类问题的时候，我的反应通常不外如下三种

你还有什么要补充的吗？
真糟糕，希望你能搞定。
这关我屁事？

问题：我的 Windows 电脑有问题，你能帮我吗？

回答：能啊，扔掉微软的垃圾，换个像 Linux 或 BSD 的开源操作系统吧。

注意：如果程序有官方版 Windows 或者与 Windows 有互动（如 Samba）你可以问与 Windows 相关的问题，只是别对问题是由 Windows 操作系统而不是程序本身造成的回复感到惊讶，因为 Windows 一般来说实在太烂，这种说法通常都是对的。

问题：我的程序不会动了，我认为系统工具 X 有问题

回答：你完全有可能是第一个注意到被成千上万用户反复使用的系统调用与函数库文件有明显缺陷的人，更有可能的是你完全没有根据。不同凡响的说法需要不同凡响的证据，当你这样声称时，你必须有清楚而详尽的缺陷说明文件作后盾。

问题：我在安装 Linux（或者 X ）时有问题，你能帮我吗？

回答：不能，我只有亲自在你的电脑上动手才能找到毛病。还是去找你当地的 Linux 使用群组者寻求实际的指导吧（你能在这儿找到用户群组的清单）。

编者注

由于现在邮件这种在线交流方式已经逐渐淡出大众视野，知道用户群组的更是少之又少，所以可能不太适合到那地方去找。

对于大学生而言，你应该可以找到一些技术类社团，那里面肯定会有几个 Linux 爱好者。你可以去找他们问问。

比如说，如果你在百丽宫上学，你可以找~~神秘的~~网络开拓者协会下的电脑诊所或 Linux User Group （虽然也是所谓 用户群组 ，但其实这是个 QQ 群）。

注意：如果安装问题与某 Linux 的发行版有关，在它的邮件列表、论坛或本地用户群组中提问也许是恰当的。此时，应描述问题的准确细节。在此之前，先用 Linux 和所有被怀疑的硬件作关键词仔细搜索。

问题：我怎么才能破解 root 帐号/窃取 OP 特权/读别人的邮件呢？

回答：想要这样做，说明了你是个卑鄙小人；想找个黑客帮你，说明你是个白痴！

好问题与蠢问题

这一节也同样来自《提问的智慧 · 好问题与蠢问题》

最后，我将透过举一些例子，来说明怎样聪明的提问；同一个问题的两种问法被放在一起，一种是愚蠢的，另一种才是明智的。

蠢问题：

我可以在哪儿找到关于 Foonly Flurbamatic 的资料？

这种问法无非想得到 STFW 这样的回答。

聪明问题：

我用 Google 搜索过 "Foonly Flurbamatic 2600"，但是没找到有用的结果。谁知道上哪儿去找对这种设备编程的资料？

这个问题已经 STFW 过了，看起来他真的遇到了麻烦。

蠢问题：

我从 foo 项目找来的源码没法编译。它怎么这么烂？

他觉得都是别人的错，这个傲慢自大的提问者。

聪明问题：

foo 项目代码在 Nulix 6.2 版下无法编译通过。我读过了 FAQ，但里面没有提到跟 Nulix 有关的问题。这是我编译过程的记录，我有什么做的不对的地方吗？

提问者已经指明了环境，也读过了 FAQ，还列出了错误，并且他没有把问题的责任推到别人头上，他的问题值得被关注。

蠢问题：

我的主机板有问题了，谁来帮我？

某黑客对这类问题的回答通常是：好的，还要帮你拍拍背和换尿布吗？，然后按下删除键。

聪明问题：

我在 S2464 主机板上试过了 X 、 Y 和 Z ，但没什么作用，我又试了 A 、 B 和 C 。请注意当我尝试 C 时的奇怪现象。显然 florbish 正在 grommicking，但结果出人意料。通常在 Athlon MP 主机板上引起 grommicking 的原因是什么？有谁知道接下来我该做些什么测试才能找出问题？

这个家伙，从另一个角度来看，值得去回答他。他表现出了解决问题的能力，而不是坐等天上掉答案。

在最后一个问题中，注意告诉我答案和给我启示，指出我还应该做什么诊断工作之间微妙而又重要的区别。

事实上，后一个问题源自于 2001 年 8 月在 Linux 内核邮件列表（lkml）上的一个真实的提问。我（Eric）就是那个提出问题的人。我在 Tyan S2464 主板上观察到了这种无法解释的锁定现象，列表成员们提供了解决这一问题的重要信息。

通过我的提问方法，我给了别人可以咀嚼玩味的东西；我设法让人们很容易参与并且被吸引进来。我显示了自己具备和他们同等的能力，并邀请他们与我共同探讨。通过告诉他们我所走过的弯路，以避免他们再浪费时间，我也表明了对他们宝贵时间的尊重。

事后，当我向每个人表示感谢，并且赞赏这次良好的讨论经历的时候，一个 Linux 内核邮件列表的成员表示，他觉得我的问题得到解决并非由于我是这个列表中的名人，而是因为我用了正确的方式来提问。

黑客从某种角度来说是拥有丰富知识但缺乏人情味的家伙；我相信他是对的，如果我像个乞讨者那样提问，不论我是谁，一定会惹恼某些人或者被他们忽视。他建议我记下这件事，这直接导致了本指南的出现。

鸣谢

再一次感谢 Eric S. Raymond, Rick Moen 所编写的 How To Ask Questions The Smart Way 以及为原文做中文翻译的所有贡献者。

感谢 yellowbutton 对本文的校编工作。这很好地修正了编者（我）没注意到的一些问题。

更新日志

2025/10/16 23:34

查看所有更新日志

518ed-docs: 智慧地提问一篇加版权信息于 2025/10/16
ef62b-docs: 智慧地提问 v1于 2025/10/16
dcd53-更一版于 2025/10/14
f6d50-docs: 写稿ing于 2025/10/14
eef08-docs: 统一格式，稍作更改于 2025/10/13
3934d-docs: update于 2025/10/13
01272-增加了gfw部分，小修小改了一些东西于 2025/10/13
90672-docs: 新的文档，面向初学者。第一次提交于 2025/10/13

版权所有

版权归属：modenicheng

许可证：MIT