3

我在这边逛了好久,发现有好多人不会问问题啊...

大部分都是信息不全, 缺乏上下文

比如这个 http://segmentfault.com/q/1010000000528467

我记得 @依云 的个人签名就是在说这个.

还有傻瓜问题太多, google下就有.

我刚接触这行时,身边有高手,遇到问题,我第一时间就是想到他, 结果人家让我去google. 那时,很多论坛的置顶贴都有一篇文章 "提问的智慧".

从此,我很少提问题. 主要是,我相信 1, 我不是第一个吃螃蟹的人, 2, 我google用得好

当我找不到答案时,我才上SO发问.

提问时, 我总是设身处地地想: 我的问题够清晰够明了吗,对方能一目了然吗? 实在不行,我还会举个example.

我英语不好,所以我总是把我已尝试的代码和网上找的各种方法列出来, 告诉他们我想要达到的目的.

如果有错误信息,我会列出来, 甚至截图.

最后, 我还会,抱歉如果我的提供信息不全, 欢迎请求更多信息.


你们又是如何提问的,能分享下经验吗?

1

和你差不多.因为别人没有回答问题的义务,所以问题要写的清楚易懂,不能让人家想半天你的问题是什么意思,而且要挑出重点来说,不能一个简单的问题结果用一堆废话来说明.

tailnode · 2014年06月02日

2

等我攒够200经验了,我就把那些不合格的问题全踩一下。

eccstartup · 2014年06月02日

展开评论

10个回答

7

关于如何提问,至少SF缺乏一点对用户的引导。

比如StackOverflow:http://stackoverflow.com/questions/ask/advice
在用户初次提问时至少给出了一些建议,并且列出了很多关于如何提问的参考文章:

  1. http://msmvps.com/blogs/jon_skeet/archive/2010/08/29/writing-the-perfect-question.aspx
  2. http://catb.org/esr/faqs/smart-questions.html
  3. http://slash7.com/2006/12/22/vampires/
  4. http://support.microsoft.com/kb/555375

另外知乎在用户提问时,先作一次搜索,提醒用户是否是一个重复的问题,这一设计也不错。

那些过于新手的基础问题倒还容易接受,描述不清楚的问题也多有改进的余地,
但最令人奇怪的是这一类的语气:

  1. 求XXX,求DEMO,求代码 —— 是不是还要帖张裸照求答案?
  2. 与上面相反的另一极端情形,「详细点,写个小demo」有点近乎命令的语气:http://segmentfault.com/q/1010000000455161
  3. 求大神指导、大牛请进、智商高的请进 —— 这类标题太多了:http://segmentfault.com/search?q=%E5%A4%A7%E7%A5%9E
  4. 还有类似的这种标题:「我都不好意思来提这个问题,但为了弄明白,还是请大家帮帮我吧」 http://segmentfault.com/q/1010000000528435
  5. 以及【急,在线等答案!】恨不得高亮加粗没人回答就自己顶这种论坛提问风格。

SF【关于提问】的帮助文档藏的那么深到哪里去找?
而每次提问时都显示一个不起眼的【提问/回答指南】则又显得多余。
至于引导信息的改进方法,我想已经不用多说了。

2

个人做法:
1.提问前先尽可能的自己分析问题,若经过分析仍无法解决;就可以通过搜索引擎寻找,很多问题虽然搜索引擎的结果没有直接答案,但是通过分析总结可以得到解决。另外对于搜索引擎的使用,也是需要又技巧的;
2.上述方法仍没有解决,再去提问。我对认为提问时应该的做法是:
* 提问的标题应该简洁明了,切中问题核心;
* 描述清楚问题出现的背景、期望出现的结果、当前的结果,贴上出现错误的代码段以及错误信息;
* 对问题描述尽量客观,不要掺杂个人主观情绪;

1

个人不成熟的看法,先说不用提问的东东

  • 用法不对造成。对于用法的问题,还是先看官方文档,审查一些自己的调用API是否正确。
  • DEBUG信息的利用。能把 debug 错误信息复制之后扔给google 就能解决的问题,基本上可以不用问了。(题主说的 不是第一个人吃螃蟹的情景)。

我个人会问一些比较侧重经验的问题。简单说就是某个东西的高效使用,常规部署,系统设计等方面。这些只有前辈通过实战总结,跳坑无数才得来的经验。自己再跳一次坑感觉太浪费了。

至于提问的形式,题意明白就行。至少说明问题的产生,自己的处理方式,期待的解决效果,必要的时候帖出代码和 debug 信息。

1

@Joe 的链接很好,已收藏

个人观点,要提问,首先要学会如何描述自己的问题。
很多人提问 “为什么XXX功能不好使”, 完全不知道你怎么配置的,怎么看?
还有 “为什么这段代码有问题”, 就两行,没上下文,如何脑补?

想要让别人帮忙找问题,至少要让别人“理论上” 可以重现吧

1

好的提问跟写论文一样:
提出问题,分析问题(遇到的瓶颈),(希望大家帮你)解决问题。

1

以下内容引自 SegmentFault 官方帮助文档的【关于提问】版块 http://segmentfault.com/faq#aboutq

提问时该注意哪些事项?

  1. 提问前,先确定是
    a. 自己无法独立解决,已经做过很多尝试
    b. 搜索引擎没有满意答案(google 起码过三四页)
    c. 本站站内搜索不到满意答案
    自己解决问题的独立性一定要培养出来,多做尝试以避免其他人在你的问题上可能浪费的时间,同时请不要轻易放弃 Google。

  2. 提问时,尽量按我们的提示来提问,以快速高效地得到解答
    a. 简要并突出主旨的标题,不要使用无意义的“求助高手”之类的词汇,否则可能会被认为恶意问题而删帖;
    b. 正例:“一个函数在 setTimeout 里调用自身会造成递归吗?”——突出关键词的标题
    c. 反例:“小白求教语言问题,高手请进教”——这个问题本身范围很大,过于模糊

  3. 尽量清楚地描述问题
    a. 要善于利用编辑器,有良好的排版以提高可读性(参考 VI. Markdown 编辑器语法指南
    b. 同时可以根据其他用户的评论内容,对自己的提问「修改」完善
    c. 问题描述,尽可能提供问题所需的主要配置文件及程序源代码
    明确错误提示信息,如果可以,直接上错误码更好。

  4. 尽量使用网站提供的功能,让你的问题对他人有价值 —— 使用 tag 准确地标记你的问题,可以让你的问题更快的被人关注,而且也更好地被搜索定位。

提问时应该避免哪些方向性问题?

  1. 避免大而空的问题。
    a. 如“XX语言的未来发展如何”之类的,可以先去新手问答板块看看;
    b. 而“XX语言在设计和性能上有哪些优势”就是一个比较具体化的问题,但这类讨论性的问题可以先表明自己的观点。

  2. 主观色彩太明确的问题。
    a. 比如“XX语言真让人不爽”,这可能会引发口水战;

  3. 尽量避免可能引发长篇论战的提问,应以具体化问题解决为基准。

以上是网站原有的帮助文档,接下来是我自己的一些补充。

不说优秀的,一个正确的技术问题的提问方式,应该是:

问题的标题:内容要明确,包含需求解的问题关键信息。

内容上:

有问题引入。即问题产生的背景,相关的环境、配置,以及必要的代码和截图,何种情况下产生了哪些问题;

有自己的尝试、分析过程。即你对遇到的相关问题都做了哪些解决工作,还有哪些没做,明确的信息有助于回答者更有效的理解和解决你的问题。

最后是“那这个问题该怎么解决?”。诚恳但不奉承的求解语气。

当然提问的前提是你已经 Google 过了还没解决方案。不要因为自己的懒而去浪费别人的时间。

0

高质量的问题与高质量的解答一样精彩。

0

这里只是补充一下《提问的智慧》的中文译文:
https://github.com/oldratlee/translations/blob/master/how-to-ask-questions-the-smart-way/README.md

这篇译文:

  • 补译更新到了 最新的原文

  • 校正了翻译

  • 优化了排版

撰写答案