线上课 #18：研究性学习开题仪式 & 如何科学地提问

type

status

date

slug

summary

研究性学习开题仪式

Research-Based Learning Opening Ceremony

研究性学习中，不仅需要学习很多新知识，在新环境中使用新工具

还需要锻炼出独立解决问题的意识和能力

更重要的是，完成观念和心态上的转变

研究性学习不是传统意义上的课程大作业

课堂上老师会告诉你所有细节

研究性学习中你需要主动从相关资料/代码中找到重要的信息

你遇到的所有问题（除了框架代码自身错误），都是在锻炼你的能力

没有人会帮你手把手解决所有问题

独立解决这些问题，是对你最大的训练

网上已经有很多教学

如何科学地提问

How to Ask Questions Scientifically

绪言

易错概念区分：

Hacker（黑客）：技术高超的程序员。

Cracker（溃客）：对计算机系统及网络进行恶意破坏的人。

对于开源软件的问题，问熟练用户 ~= 问黑客，用户对新手问题更宽容

黑客喜爱的问题：有挑战性、能激发思维

黑客的坏名声：看上去蔑视简单问题、对新手较有敌意

时间杀手：不愿思考，发问前不做他们该做的事

许多使用者只是想使用、对学习技术细节没有兴趣 → 黑客是认可的

有兴趣愿意积极解决问题 → 黑客可以适当调整回答问题的风格

否则：在最擅长的事情上降低效率

如果你厌恶黑客的态度，高高在上，或过于傲慢，不妨也设身处地想想，他们并没有要求你向他们屈服。

提问前

自主尝试寻找答案

阅读官方手册/文档：查看相关软件或技术的官方手册/文档。

官方文档详细记录了关于软件的部署、运行、接口等信息，关于软件一切问题的答案以官方文档为准，其它的信息有可能是错误的（尤其是大语言模型生成的回复），但官方文档是开发者撰写的，它一定是正确的。

阅读常见问题文件（FAQ）：常见问题文件通常包含大多数用户会遇到的问题及其解决方法。

FAQ 通常包含在手册/文档内。

搜索引擎：通过搜索引擎在互联网上寻找解决方案。

最好的搜索引擎是 Google，其次是 Bing 国际版和其它国际搜索引擎。

StackOverflow 是一个高质量技术问答社区。

不要把时间浪费在百度、知乎、CSDN 这种平台上，它们不仅充斥着广告、付费，还很难获取高质量的内容。它们不适合帮助解决技术问题。

搜索论坛的旧文章：检查你准备提问的论坛，查找是否已有类似的问题和答案。

以 QQ 群为例，你应该先去看群公告。

自己检查或试验：通过实际操作来排除问题。

想想可能的原因，尝试自己解决。

查看源代码：如果你是程序开发者，阅读源代码可能会帮助你找到答案。

询问有经验的朋友：向你周围的技术高手请教。

提问时

表明你已做过努力

在提问时，明确表示你已经进行了上述的搜索和调查。这表明你不是一个浪费他人时间的提问者。

如果可能的话，分享你在寻找答案过程中学到的东西。这样可以提高问题的质量，增加获得帮助的机会。

能公开提问就别私信提问

不要强迫回复者通过邮件回答，使用论坛的追踪和提醒功能。

黑客们认为问题的解决过程应该公开、透明，正如软件代码应该开源一样。此过程中如果更有经验的人注意到不完整或者不当之处，最初的回复才能够、也应该被纠正。同时，作为提供帮助者可以得到一些奖励，奖励就是他的能力和学识被其他同行看到。

当你要求私下回复时，这个过程和奖励都被中止。别这样做，让回复者来决定是否私下回答——如果他真这么做了，通常是因为他认为问题编写太差或者太肤浅，以至于不可能使其他人产生兴趣。

非母语提问

如果在使用非母语的论坛提问，你可以犯点拼写和语法上的小错，但决不能在思考上马虎（我们通常能弄清两者的区别）。同时，除非你知道回复者使用的语言，否则请使用英语书写。繁忙的黑客一般会直接删除用他们看不懂的语言写的消息。在网络上英语是通用语言，用英语书写可以将你的问题在尚未被阅读就被直接删除的可能性降到最低。

English is not my native language, please excuse typing errors.

精确地描述问题并言之有物

仔细、清楚地描述你的问题或 Bug 的症状。

描述问题发生的环境（机器配置、操作系统、应用程序、以及相关的信息）提供经销商的发行版和版本号（如 Fedora Core 4、Slackware 9.1 等）

描述在提问前你是怎样去研究和理解这个问题的。

描述在提问前为确定问题而采取的诊断步骤。

描述最近做过什么可能相关的硬件或软件变更。

尽可能地提供一个可以重现这个问题的可控环境的方法。

表现出你为简化问题付出了努力，这可以使你得到回答的机会增加。

简化问题使你更有可能得到有用的答案。

在精炼你的 bug 报告的过程中，你很可能就自己找到了解决方法或权宜之计。

别动辄声称找到 Bug

提供解决问题的源代码补丁，或者提供回归测试信息来表明前一版本中行为不正确。

编写软件的人总是非常辛苦地使它尽可能完美。如果你声称找到了 Bug，也就是在质疑他们的能力，即使你是对的。

提问时，即使你私下非常确信已经发现一个真正的 Bug，最好写得像是你做错了什么，如果真的有 Bug，你会在对方的回复中看到这点。

低声下气不能代替你的功课

有些人明白他们不该粗鲁或傲慢的提问并要求得到答复，但他们选择另一个极端——低声下气。

我知道我只是个可怜的新手，一个失败者，但……

这是原始灵长类动物的把戏，既使人困扰，也没有用，尤其是伴随着与实际问题含糊不清的描述时更令人反感。

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

所有的诊断专家都来自密苏里州。

出自美国国会议员 Willard D. Vandiver 在 1899 年时的讲话：“我来自一个出产玉米，棉花，牛蒡和民主党人的国家，滔滔雄辩既不能说服我，也不会让我满意。我来自密苏里州，你必须让我看看。”

描述目标而非过程

如果你想弄清楚如何做某事（而不是报告一个 Bug），在开头就描述你的目标，然后才陈述重现你所卡住的特定步骤。经常寻求技术帮助的人在心中有个更高层次的目标，而他们在自以为能达到目标的特定道路上被卡住了，然后跑去问该怎么走，但没有意识到这条路本身就有问题。结果要费很大的劲才能搞定。

即使你很急也别在标题写紧急

这是你的问题，不是黑客的。宣称紧急极有可能事与愿违。

大多数黑客会直接删除无礼和自私地企图即时引起关注的问题。更严重的是，紧急这个字（或是其它企图引起关注的标题）通常会被垃圾信过滤器过滤掉——你希望能看到你问题的人可能永远也看不到。

提问后

分析答复

STFW - Search The ~~Fxxking~~Friendly Web

只要我用的工具是大众的，我几乎不可能是世界上第一个遇到问题的

网上一定有人遇到过相同/类似问题，我应该搜一下看看他们怎么解决

RTFM - Read The ~~Fxxking~~Friendly Manual

只要我用的工具是大众的，应该有手册记录这个工具的所有细节

如果我想了解它的某个问题，我应该去搜索手册的描述

RTFSC - Read The ~~Fxxking~~Friendly Source Code

只要我获得了项目代码，理论上我就可以知晓它的一切行为

如果我想了解它具体是如何工作的，我应该去读一下（关键）代码

如果你在提问后收到了这些答复，其背后的含义是：

你想要的答案很容易找到，你很应该自己去获取

相比于我直接告诉你答案，你自己获取答案能学到更多

问题解决后

向所有帮助过你的人发个说明，让他们知道问题是怎样解决的，并再次向他们表示感谢。

列出那些帮助过你的名字，会让你交到更多朋友。

思考一下怎样才能避免他人将来也遇到类似的问题，比如写一份文档或加个常见问题（FAQ）会不会有帮助，如果是的话就将它们发给维护者。

总结

提问能反映出你的学习态度：主动尝试 vs. 被动依赖

不是所有问题都值得问

你以为自己热爱学习？不，别人只觉得你是伸手党

开源社区中的一个真实案例：

新手的提问：两个不同的安装包有什么区别？我是新手。

开发者的回答：自己上网找答案。在开源社区中不应该随便问这种配置问题，除非你有明确的证据证明代码或者文档有缺陷。