关于提问与回答
在「如何请求到他人的帮助来解决问题」上已经有许多优秀的指导文章，但在如何有效的帮助他人上似乎还是少了那么点东西。
授人予鱼不如…?
「帮助他人」自然算不上是什么难事，至少相比如何高效的提问来说是非常简单的了。但能够并不就代表着高效，很多时间我试着去帮助其他人解答他们的问题——无论难易或是问题给予的信息有多少，我总是将答案说的尽可能详细，想着以这样的方式来解决问题。
不得不承认这种方法有时相当有效，只需要告诉对方「啊，先这样，然后那样」他们的问题就被解决掉了。但是随着时间推移，我在社区里解答过的问题越来越多，渐渐的我感到疲倦。这种手把手的解答方式当然非常有效，但对方能得到什么，我们持续的输出知识又能得到什么？带着这样的想法，我开始不把话说的那么详细。
举个例子。
以下是在另一个群内发生的，相同的问题不同的答案：
我觉得我成功让对方思考了一番，而不只是我在唱独角戏。
所以说，有时候解决问题应当是引导提问的人寻找思考的方向，而不只是告诉他答案。正所谓 授人以魚不如授人以漁
问句应使用问号而不是句号
如果提问者的态度令人发指，自然应该拒绝它。
就我所在的圈子里而言，我经常能见到一些人是这样问问题的:
遇到这样的提问者，我通常会猜测两种人。
- 语音输入用户
- 日常聊天说什么话末尾都要用个句号，连问句和感叹句都不放过的人
当然，语音输入用户没有做错任何事情。我无法理解的是第二种人，为什么日常聊天什么都得带个句号呢？对句号的执念是如此的深…
当然，以上是我的个人吐槽，若有冒犯请多见谅。本段的重点不在于用问号还是句号，而是提问的态度。没有任何人有义务在社区里为了各自的问题来逐一解答，大家的时间都很有限，所以正确的提问方式（而不只是态度）尤其重要。试想一下如果遇到了这样的问题：
那么如何解决？一不知道用的是什么权限组插件，二不知道他是要干什么，这样的问题必须要有人来进一步引导才能解决，然而他甚至可能已经在群发这种问题，根本看不到你的反问。
由此，纠正错误的提问方式尤其重要，每个人都应该学会如何正确的提一个问题来尽可能快的得到帮助，对你好也对我好。
正如上文所说，*在「如何请求到他人的帮助来解决问题」上已经有许多优秀的指导文章*，但直接把这玩意扔出去多半也没有什么人会看。
但我们有别的做法。
还有一种是“问题类型收费表”，把最差的问法放最贵，最好的问法放免费，这也不失为一种巧妙的做法。
唯有问问题的人学着去问问题，解决问题的人才能把时间花在真正有用的地方上。
不要太多厨师
这句话其实出自英语里的 too many cooks in the kitchen，意思是这里有太多的人工作在同一件事情上，而这样会导致不好的结果。
正如上文的一个反例：
自由讨论当然好，但不适用于解决问题上，其实也很可能会演化成情绪倾泻的垃圾桶，每个人都在坚持自己的意见，甚至可能还会出现人身攻击。
当然，这种极端情况是后话而且并不多见。但一个问题确实不应该有太多的人上去解答，尤其是比较泛的问题。如果你已经看到有别的”厨师”正在解决这个问题，那么你只要纠正他的说法就好，而不是他说一套你也要跟着说一套，那样只会让提问的人更加混乱
「我 TM 到底听谁的」
找出真正的问题
有一种问题，我们管它叫做 Y 问题，为什么呢？
因为 Y 问题是 X 问题的一个分支，解决了 Y 问题自然可以解决 X 问题，但不代表必须解决 Y 问题才能解决 X 问题。
这就是 XY-Problem ，大家都经常犯的错误。如果你遇到了一些比较不合理的需求，不妨问一问提问者「你的原始需求是啥啊」，或许你会得到一个新的看问题的视野。
举个例子:
「Q：有没有什么插件可以替换任意 GUI 里面的文本啊，我只找到替换聊天信息的」
「A: 你要替换什么文本？」
「Q：XX 插件的菜单里面都是英文的，我想通过替换来翻译一下」
「A: 直接在 plugins\XXX\gui.yml 里面改就好了，用不着找那种插件，况且也没有。」
除了 X-Y 问题，也可能是提问者表述不清，适当引导即可。
说了这么多，其实核心只有两件事情：
- 引导——有时我们要引导提问者而不只是给他答案，但不代表所有的问题都需要引导。
- 态度——如果提问者的态度令人发指，你应该恰当的指出他的错误。
End.