如何在网络上提问？
如何提问？
主题原则
细化到提问里，这里给出一个提问的过程，请在提问时候严格遵守以下五个流程，熟悉后只要思路不变，
可以有无数的提问方法（这里就限制死了，请按照这个格式填表格的形式来提问）：
-
描述你的需求、做这个需求的原因（什么是需求？做这个需求能得到什么？）
-
描述你的实现思路（想怎么做这个事情）
-
描述具体的实现过程（相对于思路更细节更具体的东西）
-
描述遇到的问题，得到的一切反馈（在编程中可以理解为各种信息，正确的、错误的）
-
所有涉及的最基本的具体信息（编程中就是所有代码）
五步原则在编程提问中的解释：
- 描述你的需求、做这个需求的原因（什么是需求？做这个需求能得到什么？）
你的做法可能是错误的，给出原因可以帮助他人发现你南辕北辙的解决方案。你的需求可能是错误的，给出原因可以帮助他人发现你错误的需求。
- 为什么要描述你的实现思路（想怎么做这个事情）
描述思路有助于他人搞懂你你正在做的事情、搞懂你遇到的问题,你解决问题的思路可能是错的，描述清楚有助于发现错误，也有助于帮助他人理解你的角度
- 为什么要描述具体的实现过程（相对于思路更细节更具体的东西）
描述实现过程有助于帮助他人理解你的具体问题
- 为什么要描述遇到的问题，得到的一切反馈（在编程中可以理解为各种信息，正确的、错误的）
对具体信息的描述可以帮助他人分析具体问题，所以要给出错误的具体、完整的信息，而不是残缺的截图或者零散的几句描述，这样起不到任何作用
- 为什么要贴出最基本的信息（编程中就是所有代码）
如果不尽量给出完整、简化、可运行、可重现的代码，他人很难定位具体问题，也就无从解决问题了.
正确案例与错误案例
错误示例：
很抱歉打扰你……万分感谢！本人某985机械本硕，研究生做的都是偏软件的(二次开发.工业软件开发)自己在学前端后端之类的东西……
好好学编程的东西以后进互联网能行吗……会不会因为是机械学院的把我fail了?
正确示例：
0、客套之类的
1、想做前端开发，因为钱很多，我喜欢编程，我觉得性价比比机械高，认真学习编程可以进入互联网行业做开发/测试/运维工程师么？
2、我想实现的思路是：
根据在某些网站上的求职信息，发现应该掌握知识A、B、C、D、E、F、G
3、实现的过程是：
A:学习某某本书籍、看某某开源库、自己动手做XXX
B:学习某某本书籍、看某某开源库、自己动手做XXX
C:学习某某本书籍、看某某开源库、自己动手做XXX
·······
4、遇到的问题和反馈信息：
在XXX过程中我遇到了XXX的问题，得到的XXX信息是XXX
在XXX过程中我遇到了XXX的问题，得到的XXX信息是XXX
在XXX过程中我遇到了XXX的问题，得到的XXX信息是XXX
5、最基本的信息：
我是某某高效某某专业的XXX
之前做过XXX
拿过XXX数学竞赛奖
英语能力XXXX
这五步过程中你要想做出得到人认真答复的提问，需要准备很多的工作，使用搜索引擎查阅相关的信息，
去找一些专业人士请教一些基本的知识等等等等，只有这样才能得到有效的建议。而不是简单随口的问一句。
如何在论坛提问？什么是“最短代码-错误重现”提问方式？
帖子标题=帖子内容的提炼 让他人看了标题就能大概知道是否能帮助你。切勿使用“求助、急、帮忙、新手、高手、在线等”等无任何意义的词语。
帖子正文部分应包含以下内容：
１． 粘贴一个简单的程序程序代码，并且让别人可以直接复制运行（尽量避免使用附件，Simulink模型除外）；
２． 贴出你的错误或警告信息（特别重要），以及你已经尝试过的方法、步骤（必要的时候，可以上传一些截图）；
３． 如果你使用了非MATLAB自带的工具箱函数，请打包(zip或者rar)上传你所使用的第三方函数（包）；
４． 写上你使用的是哪个MATLAB版本（如：64位R2012a等），以及操作系统（如：32位XP系统、64位Windows 7系统等）。
参考网址：https://github.com/tvvocold/How-To-Ask-Questions-The-Smart-Way
提问的智慧
提问前
在通过电邮、新闻组或论坛提技术问题以前，做以下事情：
- 尝试在你准备提问论坛的历史文档中搜索答案
- 尝试搜索互联网以找到答案
- 尝试阅读手册以找到答案
- 尝试阅读常见问题（FAQ)文档以找到答案
- 尝试自己检查或试验以找到答案
- 尝试请教懂行的朋友以找到答案
- 如果你是程序员，尝试阅读源代码以找到答案
提问时，请先表明你已做了上述事情，这将有助于建立你不是寄生虫与浪费别人时间的印象。最好再表述你从中学到的东西，
我们喜欢回答那些表现出能从答案中学习的人。
认真地思考，准备好你的问题。轻率的提问只能得到轻率的回答，或者压根没有。
在提问时，你越是表现出在此前做过思考与努力去解决自己的问题，你越有可能得到真正的帮助.
表明你有能力也乐意参与问题的解决是个很好的开端。“有没有人能指个方向？”，我这还差点什么？”，“我应该查哪个网站？”，
通常要比 “请给出我可以用的完整步骤”更容易得到回复，因为你表明了只要有人能指个方向，你就很乐意完成剩下的过程。
提问时
- 仔细挑选论坛
主题相关！ - 面向新手的论坛和互联网中继聊天（IRC）通常响应最快.
- 使用有意义且明确的主题.
使用主题的好惯例是“对象──偏差”（式的描述），许多技术支持组织就是这样做的。
在“对象”部分指明是哪一个或哪一组东西有问题，在“偏差”部分则描述与期望的行为不一致的地方。 - 使问题容易回复
回复问题不需要打开邮箱等交流工具，而是顺手就可以回复。 - 用清晰、语法、拼写正确的语句书写
问题要表达清楚，面对面提问最好先写在纸上。 - 通用语言
如果在非母语论坛提问，你的拼写与语法错误会得到有限的宽容，
但懒惰完全不会被容忍（是的，我们通常看得出其中的差别）。同时，除非你知道回复者使用的语言，请使用英语书写。 - 使用易于读取且标准的文件格式发送问题
提问的问题内容
描述问题应准确且有内容
- 仔细、清楚地描述问题的症状
- 描述问题发生的环境(主机、操作系统、应用程序，任何相关的)，提供销售商的发行版和版本号（如：“Fedora Core 7”、“Slackware 9.1”等）
- 描述提问前做过的研究及其理解。
- 描述提问前为确定问题而采取的诊断步骤。
- 描述最近对计算机或软件配置的任何相关改变。
- 如果可能，提供在可控环境下重现问题的方法。
- 尽最大努力预测黑客会提到的问题，并提前备好答案。
如果你认为是代码有问题，向黑客提供在可控环境下重现问题的方法尤其重要。当你这么做时，得到有用且及时回复的可能性将大大增加。
你应该（写得）精炼且有内容，简单地将一大堆代码或数据罗列在求助消息中达不到目的。
如果你有一个很大且复杂的测试样例让程序崩溃，尝试将其裁剪得越小越好。
编写软件的人总是非常辛苦地使它尽可能完美。如果你声称找到了臭虫，
也就置疑了他们的能力，即使你是对的，也有可能会使其中的部分人感到不快。
描述问题症状而不是猜测
告诉黑客是什么导致了问题是没用的（如果你的诊断理论是了不起的东西，你还会向别人咨询求助吗？）。
所以，确保只是告诉他们问题的原始症状，而不是你的解释和理论，让他们来解释和诊断。
如果你认为陈述自己的猜测很重要，应清楚地说明这只是你的猜测并描述为什么它们不起作用。
按时间先后罗列问题症状
刚出问题之前发生的事情通常包含有解决问题最有效的线索。所以，记录中应准确地描述你、电脑和软件在崩溃前都做了什么。
在命令行处理的情况下，有会话日志（如运行脚本工具生成的）并引用相关的若干（如20）行记录会非常有帮助。
描述目标而不是过程
如果你想弄清楚如何做某事（而不是报告一个臭虫），在开头就描述你的目标，然后才陈述遇到问题的特定步骤。
经常出现这种情况，寻求技术帮助的人在脑袋里有个更高层次的目标，
他们在自以为能达到目标的特定道路上被卡住了，然后跑来问该怎么走，但没有意识到这条路本身有问题，结果要费很大的劲才能通过。
要想理解专家生活的世界，可以这样设想：那里有丰富的专长资源但稀缺的响应时间。你暗中要求他们奉献的时间越少，
你越有可能从这些真正懂行也真正很忙的专家那里得到解答。
所以限定你的问题以使专家回答时需要付出的时间最少──这通常与简化问题还不太一样。举个例，“请问可否指点一下哪有好一点的 X 解释？
”通常要比“请解释一下 X”明智。如果你的代码不运行了，通常请别人看看哪有问题比叫他们帮你改正更明智。
最精确描述代码问题的方法是提供一个能展示问题的最小测试样例。什么是最小测试样例？
它是对问题的展现，只需要刚好能够重现非预期行为的代码即可。如何生成一个最小测试样例？
如果你知道哪一行或哪一段代码会产生问题，将其复制并提供刚好够用的外围支撑代码以构成一个完整的样例
（够用是指源码刚好能被编译器、解释器或任何处理它的程序所接受）。
如果你不能将问题缩小到特定的段落，复制源码并去除那些与问题无关的代码段。你能提供的最小测试样例越小越好（参见 量不在多，精炼则灵 ）。
一般来说，避免提“是或否”类型的问题，除非你想得到 “是或否”类型的回答。
礼貌总是有益的
礼貌一点，使用 请 和 谢谢你的关注 或者 谢谢你的关照，让别人明白你感谢他们无偿花时间帮助你。
我们必须指出，本文唯一受到一些老黑客认真反对的地方是以前曾经推荐过的“提前谢了”，一些黑客认为这隐含着事后不用再感谢任何人的暗示。
我们的建议是要么先说 提前谢了，事后 再 对回复者表示感谢，要么换种方式表达，譬如用 谢谢你的关注 或 谢谢你的关照.
问题解决后向所有帮助过的人追加一条消息，让他们知道问题是如何解决的并再次感谢。
如果问题在邮件列表或新闻组中受到广泛关注，在那里追加此消息比较恰当。
考虑一下怎样才能避免他人将来也遇到类似的问题，问问自己编一份文档或 FAQ 补丁会不会有帮助，如果是的话就将补丁发给维护者。
好问题与坏问题
同样的问题两种提法，一种愚蠢，另一种明智。
愚蠢：我在哪能找到关于 Foonly Flurbamatic 设备的东西？
这个问题在乞求得到 “搜搜该死的网络”（STFW） 式的回复。
明智： 我用谷歌搜索过“Foonly Flurbamatic 2600”，但没有找到什么有用的，有谁知道在哪能找到这种设备的编程信息？
这个人已经搜索过网络了，而且听起来他可能真的遇到了问题。
愚蠢： 我不能编译某项目的源代码，它为什么这么破？
提问者假设是别人搞砸了，太自大了。
明智： 某项目的源代码不能在某 Linux 6.2 版下编译。我读了常见问题文档，但其中没有与某 Linux 相关的内容。这是编译时的记录，我做错了什么吗？
提问者已经指明了运行环境，读了常见问题文档（FAQ），列出了错误，也没有假设问题是别人的过错，这家伙值得注意。
愚蠢： 我的主板有问题，谁能帮我？
某黑客对此的反应可能是：“是的，还需要帮你拍背和换尿布吗？”，然后是敲下删除键。
明智： 我在 S2464 主板上试过 X、Y 和 Z，当它们都失败后，又试了 A、B 和 C。注意我试 C 时的奇怪症状，显然某某东西正在做某某事情，这不是期望的行为。通常在 Athlon MP 主板上导致某某事情的原因是什么？有谁知道我还能再试点什么以确定问题？
相反地，这个人看来值得回答。他或她展现了解决问题的能力而不是坐等天上掉馅饼。
在最后那个问题中，注意“给我一个回答”与“请帮我看看我还能再做点什么测试以得到启发”之间细微但重要的差别。
如何更好地回答
态度和善一点。问题带来的压力常使人显得无礼或愚蠢，其实并不是这样。
对初犯者私下回复。 对那些坦诚犯错之人没有必要当众羞辱，一个真正的新手也许连怎么搜索或在哪找 FAQ 都不知道。
**如果你不确定，一定要说出来！ 一个听起来权威的错误回复比没有还要糟，别因为听起来象个专家好玩就给别人乱指路。**要谦虚和诚实，给提问者与同行都树个好榜样。
如果帮不了忙，别妨碍。 不要在具体步骤上开玩笑，那样也许会毁了用户的安装──有些可怜的呆瓜会把它当成真的指令。
探索性的反问以引出更多的细节。 如果你做得好，提问者可以学到点东西──你也可以。试试将很差的问题转变成好问题，别忘了我们都曾是新手。
尽管对那些懒虫报怨一声“读读该死的手册”（RTFM）是正当的，指出文档的位置（即使只是建议做个谷歌关键词搜索）会更好
如果你决意回答，给出好的答案。 当别人正在用错误的工具或方法时别建议笨拙的权宜之计，应推荐更好的工具，重新组织问题。
请回答真正的问题！如果提问者已经做了自己该做的研究，并且说明尝试过 X，Y，Z，A，B 与 C 都没有得到想要的結果，
那么回复 试试 A 或 B 或者给出一个内容为 试一下 X，Y，Z，A，B 或 C 的链接将极其无益！
帮助你的社区从中学习。当回复一个好问题时，问问自己 如何修改相关文件或 FAQ 文档以免再次解答同样的问题？，接着再向文档维护者发一份补丁。
如果你是在研究一番后才做出的回答，展现你的技巧而不是直接端出结果。毕竟“授人以鱼，不如授人以渔”。
参考文章：https://www.chiark.greenend.org.uk/~sgtatham/bugs-cn.html
如何有效地报告 Bug
简单地说，报告bug的目的是为了让程序员看到程序的错误。您可以亲自示范，也可以给出能导致程序出错的、详尽的操作步骤。
在bug报告里，要设法搞清什么是事实（例如：“我在电脑旁”和“XX出现了”）什么是推测（例如：“我想问题可能是出在……”）。
如果愿意的话，您可以省去推测，但是千万别省略事实。
如果您不是报告bug，而是寻求帮助，您应该说明您曾经到哪里找过答案，（例如：我看了第四章和第五章的第二节，但我找不到解决的办法。）
这会使程序员了解用户喜欢到哪里去找答案，从而使程序员把帮助文档做得更容易使用。
报告bug的最好的方法之一是“演示”给程序员看。让程序员站在电脑前，
运行他们的程序，指出程序的错误。让他们看着您启动电脑、运行程序、如何进行操作以及程序对您的输入有何反应。
他们对自己写的软件了如指掌，他们知道哪些地方不会出问题，而哪些地方最可能出问题。他们本能地知道应该注意什么。在程序真的出错之前，
他们可能已经注意到某些地方不对劲，这些都会给他们一些线索。他们会观察程序测试中的每一个细节，并且选出他们认为有用的信息。
精确的描述您看到了什么。告诉他们为什么您觉得自己所看到的是错误的，
最好再告诉他们，您认为自己应该看到什么。如果您只是说：“程序出错了”，那您很可能漏掉了非常重要的信息。
如果您看到了错误消息，一定要仔细、准确的告诉程序员，这确实很重要。在这种情况下，程序员只要修正错误，而不用去找错误。
他们需要知道是什么出问题了，系统所报的错误消息正好帮助了他们。
如果您没有更好的方法记住这些消息，就把它们写下来。只报告“程序出了一个错”是毫无意义的，除非您把错误消息一块报上来。
当一个错误或bug发生的时候，您可能会做许多事情。但是大多数人会使事情变的更糟。当程序出毛病的时候，立刻停止正在做的任何操作。
不要按任何健。仔细地看一下屏幕，注意那些不正常的地方，记住它或者写下来。然后慎重地点击“确定” 或“取消”，选择一个最安全的。
学着养成一种条件反射——**一旦电脑出了问题，先不要动。**要想摆脱这个问题，关掉受影响的程序或者重新启动计算机都不好，
一个解决问题的好办法是让问题再次产生。程序员们喜欢可以被重现的问题，快乐的程序员可以更快而且更有效率的修复bug。
做程序员也是一样。即便您自己的“诊断”有时真的有帮助，也要只说“症状”。“诊断”是可说可不说的，
但是“症状”一定要说。同样，在bug报告里面附上一份针对bug而做出修改的源代码是有用处的，但它并不能替代bug报告本身。
最重要的是：程序员想要确定他们正在处理的是一个真正的“间歇性错误”呢，还是一个在另一类特定的计算机上才出现的错误。
他们想知道有关您计算机的许多细节，以便了解您的机器与他们的有什么不同。
有许多细节都依仗特定的程序，但是有一件东西您一定要提供——版本号。程序的版本、操作系统的版本以及与问题有关的程序的版本。
问题描述
- 精确。
如果做相同的事情有两种方法，请说明您用的是哪一种。例如：“我选择了‘载入’”，可能意味着“我用鼠标点击‘载入’”或“我按下了‘ALT+L’”，
说清楚您用了哪种方法，有时候这也有关系。 - 详细。
信息宁多毋少！如果您说了很多，程序员可以略去一部分，可是如果您说的太少，他们就不得不回过头再去问您一些问题。
有一次我收到了一份bug报告只有一句话，每一次我问他更多事情时，他每次的回复都是一句话，于是我花了几个星期的时间才得到了有用的信息。 - 慎用代词。
诸如“它”，“窗体”这些词，当它们指代不清晰的时候不要用。来看看这句话：“我运行了FooApp，
它弹出一个警告窗口，我试着关掉它，它就崩溃了。”这种表述并不清晰，用户究竟关掉了哪个窗口？是警告窗口还是整个FooApp程序？
您可以这样说，“我运行FooApp程序时弹出一个警告窗口，我试着关闭警告窗口，FooApp崩溃了。”这样虽然罗嗦点，但是很清晰不容易产生误解。 - 检查。
重新读一遍您写的bug报告，您觉得它是否清晰？如果您列出了一系列能导致程序出错的操作，那么照着做一遍，看看您是不是漏写了一步。
官方小结
bug报告的首要目的是让程序员亲眼看到错误。如果您不能亲自做给他们看，给他们能使程序出错的详细的操作步骤。
如果首要目的不能达成，程序员不能看到程序出错。这就需要bug报告的第二个目的来描述程序的什么地方出毛病了。详细的描述每一件事情：您看到了什么，您想看到什么，把错误消息记下来，尤其是“错误消息号”。
当您的计算机做了什么您料想不到的事，不要动！在您平静下来之前什么都别做。不要做您认为不安全的事。
尽量试着自己“诊断”程序出错的原因（如果您认为自己可以的话）。即使做出了“诊断”，您仍然应该报告“症状”。
如果程序员需要，请准备好额外的信息。如果他们不需要，就不会问您要。他们不会故意为难自己。您手头上一定要有程序的版本号，它很可能是必需品。
表述清楚，确保您的意思不能被曲解。
总的来说，最重要的是要做到精确。程序员喜欢精确。