type
status
date
slug
summary
tags
category
icon
password
这里开始“一生一芯”之旅，首先要学会提问，懂得如何科学地提问，并写800字读后感。
📝 一、阅读内容
（一）《提问的智慧》
一些摘要
- 那些人是时间杀手 —— 他们只想索取，从不付出，消耗我们可用在更有趣的问题或更值得回答的人身上的时间。
- 变得在行的特质 —— 机敏、有想法、善于观察、乐于主动参与解决问题。
- 在你准备通过电子邮件、新闻群组或者聊天室提出技术问题前，请先做到以下事情：
- 尝试在你准备提问的论坛的旧文章中搜索答案。
- 尝试上网搜索以找到答案。
- 尝试阅读手册以找到答案。
- 尝试阅读常见问题文件（FAQ）以找到答案。
- 尝试自己检查或试验以找到答案。
- 向你身边的强者朋友打听以找到答案。
- 如果你是程序开发者，请尝试阅读源代码以找到答案。
- 在邮件列表或新闻组寻求帮助时加上一句
我在 Google 中搜过下列句子但没有找到什么有用的东西也是件好事。
- 你没有为这种服务支付任何报酬，你将会是自己去挣到一个答案。
- 慎选提问的论坛。
- 向陌生的人或论坛发送邮件最可能是风险最大的事情。
- 别像机关枪似的一次“扫射”所有的帮助渠道。
- 一般来说，在仔细挑选的公共论坛中提问，会比在私有论坛中提同样的问题更容易得到有用的回答。黑客较愿意回答那些能帮助到许多人的问题。
- 在 Stack Exchange 的 Stack Overflow 问。
- 搜索后再发帖（为代码添加格式，并且添加相关的标签（特别是编程语言、操作系统或库/包的名称）。
- 当有人要求你提供更多相关信息时，请编辑你的贴子来补充它们[译注：而不是发一个回帖或回答！]）
- 当某个项目提供开发者邮件列表时，要向列表而不是其中的个别成员提问。
- 如果你确信你的问题很特别，而且在“用户”列表或论坛中几天都没有回复，可以试试前往“开发者”列表或论坛发问。建议你在张贴前最好先暗地里观察几天以了解那里的行事方式。
- 如果你找不到一个项目的邮件列表，而只能查到项目维护者的电子邮件地址，尽管向他发信。
- 50 字以内的标题，一个好标题范例是
目标 —— 差异式的描述。
- 如果你想在回复中提出问题，记得要修改内容标题，以表明你是在问一个问题， 一个看起来像
Re: 测试或者Re: 新 bug的标题很难引起足够重视。除非你只想在该讨论串当前活跃的人群中提问，不然还是另起炉灶比较好。
- 在论坛，要求通过电子邮件回复是非常无礼的，除非你认为回复的信息可能比较敏感
- 准确的语言表达（提示潜在回复者你有潜在的语言困难是很好的）
- English is not my native language; please excuse typing errors.
- If you speak $LANGUAGE, please email/PM me; I may need assistance translating my question.
- I am familiar with the technical terms, but some slang expressions and idioms are difficult for me.
- I've posted my question in $LANGUAGE and English. I'll be glad to translate responses, if you only use one or the other.
- 精确地描述问题并言之有物
- 仔细、清楚地描述你的问题或 Bug 的症状。
- 描述问题发生的环境（机器配置、操作系统、应用程序、以及相关的信息），提供经销商的发行版和版本号（如：
Fedora Core 4、Slackware 9.1等）。 - 描述在提问前你是怎样去研究和理解这个问题的。
- 描述在提问前为确定问题而采取的诊断步骤。
- 描述最近做过什么可能相关的硬件或软件变更。
- 尽可能地提供一个可以
重现这个问题的可控环境的方法。
尽量去揣测一个黑客会怎样反问你，在你提问之前先将黑客们可能提出的问题回答一遍。
- 编写软件的人总是非常辛苦地使它尽可能完美。如果你声称找到了 Bug，也就是在质疑他们的能力，即使你是对的，也有可能会冒犯到其中某部分人。当你在标题中嚷嚷着有
Bug时，这尤其严重。即使你私下非常确信已经发现一个真正的 Bug，最好写得像是你做错了什么。
- 描述目标而不是过程
- 即使你很急也不要在标题写
紧急，这是你的问题，不是我们的。
- 礼多人不怪。
- 问题解决后，向所有帮助过你的人发个说明，让他们知道问题是怎样解决的，并再一次向他们表示感谢。
- 如何有效地报告 Bug
- bug报告的首要目的是让程序员亲眼看到错误。如果您不能亲自做给他们看，给他们能使程序出错的详细的操作步骤。
- 如果首要目的不能达成，程序员不能看到程序出错。这就需要bug报告的第二个目的来描述程序的什么地方出毛病了。详细的描述每一件事情：您看到了什么，您想看到什么，把错误消息记下来，尤其是“错误消息号”。
- 当您的计算机做了什么您料想不到的事，不要动！在您平静下来之前什么都别做。不要做您认为不安全的事。
- 尽量试着自己“诊断”程序出错的原因（如果您认为自己可以的话）。即使做出了“诊断”，您仍然应该报告“症状”。
- 如果程序员需要，请准备好额外的信息。如果他们不需要，就不会问您要。他们不会故意为难自己。您手头上一定要有程序的版本号，它很可能是必需品。
- 表述清楚，确保您的意思不能被曲解。
- 总的来说，最重要的是要做到精确。程序员喜欢精确
RTFM（Read The Fucking Manual）和STFW（Search The Fucking Web）
（二）《别像弱智一样提问》
一些摘要
- 避免xy-problem，引申问题Y可能并不是X问题的一个合适的解决方法，因此要学会提问。
- 记住，给别人的条件越多，你的问题解决越快。因为这不是解密游戏。
- 请问一个关于
什么的问题。 - 我想要达到
什么样效果，但是我这样做出现了什么样的问题。 - 报错日志是
这样的。（要学会画关键字） - 我尝试过
什么方法来解决。 - 我尝试搜索过了
什么关键字，在里面找到了这些 URL的回答，尝试了还是没有解决问题。 - 我用的是
什么操作系统，版本号是多少。 - 我用的是
什么软件，版本号是多少。 - 谢谢
🤗 二、800字读后感
随着我们进入信息爆炸的时代，各个领域对我们的知识提出了更高的要求。各类学习资料充斥在互联网上供我们学习借鉴，互联网同时也将人际关系网扁平化，让我们更容易地和各类人物进行链接。
然而在自我学习的过程中，总是会遇到各种各样的问题，这不得不迫使我们寻求帮助。在这个知识付费的时代，对于他人而言，帮你是情分，不帮是本分。“上帝只渡自渡者”，首先重要的是自己寻找问题的答案。我们自己需要养成一些独立解决问题的特质，过渡依赖他人的帮助往往是温水煮青蛙，所以要刻意训练自己独立解决问题的能力。通过STFW、RTFM和RTFSC通常能解决大部分的问题。
但是自己的能力总是有限的，当面对一个棘手的问题时，除了向内探索以外，我们还可以适当地向外寻求帮助。这时候，能提出好的问题显得至关重要。好的问题通常是详细的、以目标为导向的，并且加入自己尝试的过程。愚蠢的问题往往会浪费双方的时间，效率极低，还把大家搞得都不愉快。提出好的问题，考验的不只是一个人的智商，更重要的是体现了一个人的情商。因此学会向贵人正确提问和实时反馈是十分重要的。
我在生活中也有提问和被提问的经历。之前对他人提问往往没有一个清晰的思路，并且明显感觉到人家的回答往往不是自己想要的答案。在成为研究生，并有自己的导师之后，发现以前的做法完全没有效率。因此我上研究生后学到的最重要的课之一即是：提问时，要先找到可能的解决方法，让导师做“选择题”而不是“简答题”。有一次发现导师遇到技术上的难题时也是这样用“选择题”的形式问我们的。另外在和朋友相处过程中，往往因为相互熟络而忘记“正确提问”的规则。不过在被朋友问无脑问题时，能反应过来自己先搜索一下答案的人，容易收获我对其的好感。还有就是在行业交流群中，往往有人要偷偷私加群主解决所谓的问题，而群主就在群里说明有问题发在群里而不是私聊，这样大家都可以学习交流，我觉得做得很正确。
总之，学会提好问可以提高大家的效率，构建一个好的交流学习的互联网环境。它不仅是一种科学的方法，更是人际交往，为人处世的一种体现。
📎 参考文章
- 作者:Sherilyn
- 链接:https://notion-next-green-nine-96.vercel.app//article/2024/04/30/cbcc9de5-6831-48ce-9870-4e61d44b73c5
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。