提问的资料
在博主的学习过程中，不仅会问别人问题，同时也常常被别人提问。渐渐地博主发现问题与问题之间可谓是天差地别，好问题可以引起双方的共同进步与思考，而一个差问题只会浪费别人的时间与生命。例如博主所碰到的奇葩问题记录如下：
- 贴出一张充满摩尔纹但没有任何代码，只有SyntaxError: invalid syntax提示的照片并问为什么报错
- 未表明操作目的的情况下，对我说“把你的git代码发我”、“一行一行的”
- 没有任何称呼或感谢，多次“XX资料发我一下”、“XX东西怎么弄”以及“帮我弄一下XX”
- 多次提问“XX是什么软件”、“XX操作怎么进行”等可以在google等直接找到答案的问题
- “有人会用Python吗？”，“有人电脑上有Python吗？”
这是我为什么要写这篇博客的原因，也是为什么提问被称为一门艺术的原因。当然，网络上早有对于提问的方法分析以及说明，所以这里列出相关的网页与博客。这些网页中也充满了提问的方式方法，可以用作参考与学习。
How To Ask Questions The Smart Way(注：本指南不提供此项目的实际支持服务！)
该书详细描述了应该如何进行有意义、精简有效的提问方式。博主认为作为网上较详细的、成体系的提问材料，值得反复阅读。所以此处也贴出中文版仓库以供参考。
当然，此仓库也有它的对立面，向我们展示了傻问题往往是怎样的。
同时，有一些优秀的博主或网站也总结了相关的提问方式，此处列出以供参考。
我的提问流程
这里也贴出我的提问流程以供参考。实际上，我在提问过程中的顺序是这样的
- 检查报错信息、构建日志、改动的文件路径等
- google、bing、Deepseek、ChatGPT等搜索报错信息以及解决方法
- 在相关论坛中查看是否有旧文章中提到解决方式
- 尝试复现错误，确定由哪一步引起的错误
- 尝试复现MWE（Minimal Work Example，最小工作示例）
- 在相关群组内提供报错信息以及MWE进行提问
实际上，60%的问题能在第二步解决，35%的问题可以在第3、4步解决。这样最终需要麻烦别人提问或操作的问题不足5%。这样不仅能提升自己对于问题的解决能力，减少对于别人的依赖。
阅读记录
该项目How To Ask Questions The Smart Way是我三年前见过的，且是互联网上详细介绍了提问与回答的要点的文章。所以博主强烈建议反复阅读，同时博主也记录了一些笔记进行参考与补充。当然，所做的笔记也继承了原文直白与一针见血的风格，如您感到任何不适，请立即退出。
提问前
在某个问题提问前，请先进行自己的一些思考与整理。你会发现大部分问题可以在你自己思考和整理的过程中解决。即使不能解决，你也可以在调试过程中获得大量调试方法与经验，同时也能对问题进行更详细地描述。
所有人（包括你的老师、同学、学弟学妹）没有任何义务花费他们的时间在你的问题上。“自助者，天助之”这句话在此尤为适用，在论坛或者群组中提问往往是非付费行为，也就意味着你没有花费任何金钱。而如果你不能再花费时间正确有效地整理问题内容与可能的解决方案，那无异于别人的时间杀手（原文中称作“loser”，我更乐意称之为“懒蛋”）。
所以，在提问前需要对问题进行一些整理与搜索。整理的过程可以参考博主的提问流程或原文中提到的办法对问题进行加工。请你用尽一切可能会解决问题的办法，Google也好、问老师也好，而不是毫无思考的发问。原文中对于提问题的定位是这样写的。
WARNING绝不要自以为够格得到答案，你没有；你并没有。毕竟你没有为这种服务支付任何报酬。你将会是自己去挣到一个答案，靠提出有内涵的、有趣的、有思维激励作用的问题 —— 一个有潜力能贡献社区经验的问题，而不仅仅是被动的从他人处索取知识。
然后，你需要根据问题的特性来选择提问的平台或者方式。如果你的问题非常紧急且重要，博主还是推荐进行知识付费，毕竟专业的人可以更好更快地解决你的问题。如果你的问题只是简单的技术问题，那么你应该根据你问题的性质来进行分类提问或发布，入门问题与高级问题应当区分开来，使用问题可以与软件问题区分开来。如果对应论坛中没有找到对应板块，那么请尽量在标题中注明是属于哪一类的问题。同时，如果你的帖子或者问题回复量不佳，请慎重在不同的群组中转发你的问题。
在提问的时候，请选择对应的论坛或者频道。不要在一个有着固定主题的群组或者频道中请教与与该主题毫无关系的问题。这样做不仅得到答案的可能微乎其微，同时也会招致厌恶。你可以在该网站上All Sites - Stack Exchange寻找特定的主题来提问你的问题。也可以使用标签来进行选择你的问题。
-
Super User 是问一些通用的电脑问题，如果你的问题跟代码或是写程序无关，只是一些网络连线之类的，请到这里。
-
Stack Overflow 是问写程序有关的问题。
-
Server Fault 是问服务器和网管相关的问题。
提问时
有意义且描述明确的标题
在群组或者论坛中。不要使用“救救我”、“帮帮我”、“求求大佬”等毫无意义的词语，这些词语除了侵占你对于问题简明扼要的描述之外没有任何作用。提问的论坛或者群组并不是比谁更痛苦的急诊科室。相反，这些地方是真正能考验一个人在遇到困难时能否先准确地进行描述的地方，它更像是一场计时的考试。如何能让读者在一定时间内被你的问题吸引，有想法与思路才是你应该尝试去做的事情。
文中提出一种 “目标-差异”式的描述。在目标中指出是哪一个或者哪一组东西有问题；而在差异部分提出与预期行为不一致的地方。这里列出一个原文中举的例子。
蠢问题：救命！急急急！我的电脑不能正常显示了
聪明的问题：X.org 6.8.1 的鼠标光标会变形，某牌显卡 MV1005 芯片组。
更聪明问题：X.org 6.8.1 的鼠标光标，在某牌显卡 MV1005 芯片组环境下 - 会变形。
这种“目标-差异”式的描述可以有效展示你的思考。例如是什么被影响了？ 仅仅是鼠标光标或者还有其它图形？只在 X.org 的 X 版中出现？或只是出现在 6.8.1 版中？ 是针对某牌显卡芯片组？或者只是其中的 MV1005 型号？
精确地描述问题
精确简洁地描述标题很重要，同时精确地描述问题也很重要。尽管你在写程序或者其他事情上有些马虎，但是请详细检查你的问题描述并确保它们的准确性。一个粗心大意者的问题往往是在浪费被提问者的时间。
低声下气不能代替你的工作
很多人也知道他们不能用傲慢的态度去提问并要求得到答复，所以他们走向了另一个极端——低声下气地逃课。在某些简单的问题前面加上“我是个小白”、“我是个新手”等等毫无意义的话语。企图让回答你问题的人对你多些耐心从而耐心地指导你。实际上，你的问题是否能得到更好的答复与你是否是个新手毫无关系，这就像告诉别人“我今天不想工作，你帮我把工作做完吧。”一样毫无意义。
所以不要使用这种简单的把戏浪费彼此的时间。你更应该将时间与精力放在更多次地尝试去调整代码，反复地打磨问题的形式与可能的原因。在论坛或者群组中反复更新你的思考与尝试，尽可能清晰地描述你的问题，这比低声下气地在群组或者论坛上告诉别人你是个小白有用的多。
其实不仅是在问问题的时候，博主发现在不少低年级的学弟学妹身上也会出现这种情况，比如面对学长学姐“过分的”礼貌（或者可以称之为胆怯）。在交流的时候，相比于礼貌与胆怯，我们往往更需要一种互相尊重的平等交流的环境。“不会就干，不会就学”才是我们应该面对学长学姐或者老师的态度，而不是用一句“我不懂”或者“我没学过”等敷衍了事，这种话绝对不能代替应该做的调研和思考。
应有的礼貌与问题的后续
当然，在问问题中礼貌也是必须的。这表明了你对对方愿意花时间在解决你的问题上的感谢。当然这点没有一个简明扼要的技术报告来的重要。但是它往往比傲慢自大的问题更有概率得到回复（详见博主开头提出的几个示例）。
此外，在提问中预先道谢和在事后表示感谢同样重要。在问题解决后，可以向所有帮助过你的人发个简短的说明，让他们知道问题是怎样得到解决的，他们的建议在其中起到了什么样的效果，是否有更好的建议能够应用于这个问题中。这不仅是对你自己的一种提升，也是对回答你问题的人的一种提升。
当然，如果你是在论坛中发布的这个问题。你可以在标题中重新加上“已修正”或者“已解决”等字样。这样在群组与博客中别人就不用花费时间来进行阅读并尝试解决你已经解决的问题。如果解决的方式很简单，可以直接贴出解决问题的说明；如果解决方式很复杂，可以按照“清晰的问题-解决方案-需要注意的事项”这个顺序对问题进行总结与说明。当然，问题后续可以补充上所有帮助过你的人的名称，这种类型的补充可以让那些帮助过你的人获得满足感，从而使你下次更可能获得帮助。
RTFM与STFW
关于RTFM与STFW这两条能解决60%的问题的神秘咒语，博主这里将原文贴出来以供参考。
有一个古老而神圣的传统：如果你收到
RTFM （Read The Fucking Manual）的回应，回答者认为你应该去读他妈的手册。当然，基本上他是对的，你应该去读一读。
RTFM 有一个年轻的亲戚。如果你收到
STFW（Search The Fucking Web）的回应，回答者认为你应该到他妈的网上搜索。那人多半也是对的，去搜索一下吧。（更温和一点的说法是 Google 是你的朋友！）
在论坛，你也可能被要求去爬爬论坛的旧文。事实上，有人甚至可能热心地为你提供以前解决此问题的讨论串。但不要依赖这种关照，提问前应该先搜索一下旧文。
通常，用这两句之一回答你的人会给你一份包含你需要内容的手册或者一个网址，而且他们打这些字的时候也正在读着。这些答复意味着回答者认为
-
你需要的信息非常容易获得；
-
你自己去搜索这些信息比灌给你，能让你学到更多。
你不应该因此不爽；依照黑客的标准，他已经表示了对你一定程度的关注，而没有对你的要求视而不见。你应该对他祖母般的慈祥表示感谢。
好问题还是蠢问题
相信看完上面的总结，你也已经对提问的方式有一定了解了，这里博主再举出一些原文中提到或者博主补充的问题的例子与对比，希望可以对你有一定启发。
Stupid Q：哪里有学习Python/机器学习/深度学习的资料？
A: STFW
Clever Q：我在Google与搜索了如何入门机器学习/深度学习，但是没有找到一个适合新手的，能否给我推荐几个适合入门的资料？
A：他已经尝试自己去搜索了，只是可能需要一些筛选
Stupid Q：我从LaTeX工作室找来的XX项目代码没办法进行编译，这个项目写的不行吧
A：菜就多练
Clever Q：我从LaTeX工作室找来的项目代码在编译时一直提示某某错误，我已经尝试了XeLaTeX编译以及pdfLaTeX编译，但是仍然报错。我的编译链没有问题，其他项目可以正常运行。是否是我没有安装一些宏包或者版本限制的问题。这是我的最小工作实例以及编译日志文件。
A：看起来这并不是系统导致的问题，难道是这个项目真的有一些不足？我可以根据他的MWE以及log文件尝试去帮他解决一下这个问题。
Stupid Q：我的主机板有问题了，谁来帮我？
A：好的，还要帮你拍拍背和换尿布吗？，然后按下删除键
Clever Q：我在 S2464 主机板上试过了 X 、 Y 和 Z ，但没什么作用，我又试了 A 、 B 和 C 。请注意当我尝试 C 时的奇怪现象。显然 florbish 正在 grommicking，但结果出人意料。通常在 Athlon MP 主机板上引起 grommicking 的原因是什么？有谁知道接下来我该做些什么测试才能找出问题？
A：他已经尝试了多种方法而且确定了问题的根本，只是不知道可能的原因以及接下来需要的测试。需要我简单提示或者帮助他一下就能避免他继续进行无用尝试。
如何回答问题
当然，我们不可能一只扮演提问者的角色，我们也会扮演回答者的角色去回答一些问题。那么如何扮演一个合格的回答者呢，原文中其实也给出了一些答案，博主这里结合自身也进行一些补充。
和善的态度是交朋友的第一步
虽然上述关于提问的方式中有些说法过于直白，但是你仍然应该保持一个与人交流的平等态度与提问者进行交流。问问题只是因为他们碰到了不懂的地方，并不代表他们理解能力或者智力有问题。
不确定的答案请及时指出
如果你对你的答案不确定，请及时指出：一个听起来权威的错答案并比没有答案更让人烦恼。这往往会使提出问题的人反复尝试这个错答案并怀疑自己。如果你是为了打肿脸冒充专家的话，那你也是一个充满傲慢、对知识没有丝毫敬畏的人。
不要在实际设置与步骤上开玩笑
博主见过太多以rmrf指令开玩笑的所谓高知人群了。他们别人告诉这个指令可以解决问题，而当提问者运行后又嘲笑他们没有电脑常识并不负任何责任。这种人和告诉别人把手伸进绞肉机可以剪指甲一样，属于又蠢又坏的类型。同时也违背了这个指令最初创造出来的初衷。
适当的反问
当你有时间且认为这个问题很有意思的时候，你可以适当设置一些反问并将一个蠢问题变成一个好问题。这有利于提问者思考方式的逐渐进步
提出好工具，而不是用锤子砍树
当你意识到别人正在使用一些不那么方便或者完全错误的方法或者工具时，请及时告诉他并重新界定问题。而不是纠结于如何使用锤子砍树并研究怎么才能砍得又快又好。
授人以渔的回答办法
很多时候，如果你是经过一定研究或者反复试错才得出的答案。不妨在你的结果后面附上你的思考思路，思考时的一些技巧与尝试往往比一个简单的答案更加有意义。
Some information may be outdated
