技术写作与文档2017arxiv.org
在 Stack Overflow 上写出好问题的循证指南
Evidence-Based Guidelines for Writing Questions on Stack Overflow
导读
这篇论文基于证据总结在 Stack Overflow 上如何写出好问题；评论则延伸到社区规则、问题边界和搜索排名等现实经验。对写作者来说，它提醒我们“提问也是一种写作”：好问题要具体、简洁、可复现、格式规范，并先理解读者与社区标准。
可以直接用的写作要点
- 01
提问前先搜索，避免重复；把问题缩到一个具体细节，别用“怎么修”这类模糊问法。
- 02
开头就让读者在 30 秒内看懂核心问题；如果读半天还抓不到重点，读者会直接跳过。
- 03
提供足够细节让别人能复现问题，但别假设读者有你的上下文、远程权限或脑中信息。
- 04
用规范语言、标点和分段，保持礼貌简洁；大段无标点、全大写或像垃圾信息都会劝退读者。
HN 评论精选
好问题要守社区规则、具体简洁可复现，并且格式规范到不劝退读者。
我见过不少被踩或被关闭的问题，常因提问者以为网站应适应自己，而忘了自己是别人网站上的客人。SO 不是你的个人支持台，别人没有义务按你的条件帮你。做客就守规则：不离题；先搜再问、别重复；问具体问题（“怎么修”不算具体）；礼貌；别发垃圾。写代码问题时：把问题缩到具体细节并简洁——如果我读不完问题、30 秒内没有答案思路，就跳过；给足细节让别人能复现，别假设我有你电脑的远程权限或知道你脑中所想；用英语、标点、大小写；十行无大写无句号的文字我跳过，大写锁死也跳过；非母语者我会尽力理解，但语言障碍会让我很快跳过。
bmitch3020查看英文原文
I've seen my share of downvoted and closed questions from others, and often it comes down to users expecting the site to adapt to their needs rather than realizing they are a guest on someone else's site. SO doesn't exist to be your personal support site where others are obligated to help you on your terms. When you're a guest, you follow their rules. And their rules are fairly simple: - Stay on topic - Don't duplicate existing questions (look before you ask) - Ask a specific question ("how do I fix it?" is not a specific question) - Be polite (no one is getting paid to answer your question) - Don't be a spammer (and avoid looking like a spammer) With coding questions, it really helps to: - Reduce the problem to a specific detail and be concise, if I haven't finished reading the question and have an idea of the answer in 30 seconds, I move on. - Provide enough detail that someone else could reproduce your issue. So many people assume I have remote access to their laptop, not to mention what they are thinking inside their head. - Write it in English, with punctuation, and capitalization. If there's a 10 line block of text without a single capital letter or period, I move on. Same goes for anyone with their capslock key stuck in the on position. I try my best to understand non-native English speakers, because I sure can't talk in their language, but sadly when there's a language barrier, I move on fairly quickly.
提问边界往往模糊，写作者要理解受众标准与问题类型，不能只追求“正确”而忽略社区可接受性。
版主总能从 SO 指南里找到依据关闭任何他们想关的问题。定义严谨、写得清楚、只有一个正确答案的问题？被拒：RTFM（去看手册）。有多个正确答案、但几乎肯定有“最佳答案”、SO 社区显然最适合判断的问题？被拒：主观、基于观点。我没有怨气——我曾参与 SO（5 万声望，且是最高发帖/声望比之一）——我只是觉得很难在那条狭窄直道上航行。
doug1001查看英文原文
a mod can close find support in the SO guidelines to close any question they wish. a tightly defined, clearly written question with a single correct anwswer? Rejected: RTFM a question with more than one correct answer (but which almost certainly has a "best answer" which a community like SO is in the obvious best position to judge)? Rejected: subjective; opinion-based no axe to grind here--i used to participate in SO (50K rep, and one of the highest rep-to-post ratios)--i honestly just find it too difficult to navigate that narrow straight
社区质量判断与搜索可发现性会错位，标题和问题措辞会影响长期可发现性。
我遇到 SO 多半是谷歌高排结果，指向他们关闭或抱怨“不够好”的问题。我觉得好笑：问题对社区不够好，却好到能被搜索引擎榨取排名。它有用，但我怀疑其主要目的之一是吸走并集中 SEO 氧气。他们甚至仍对其他网站高相关链接 nofollow，以免稀释自己作为几乎任何编程查询相关结果的位置。编辑：谷歌几秒后发现 nofollow 方面已有努力，情况很微妙。但我当前体验是频繁落到 SEO 很好却“坏”的问题。
menacingly查看英文原文
My main encounters with SO are top google results that point to questions they closed or complained about as somehow inadequate. I love that the questions are not "good enough" for the community, but still good enough to milk for search placement. It's a useful place, but I have to wonder if its main purpose was to suck up all the available SEO oxygen and concentrate it. I think they even still nofollow the highly relevant links to other sites, because not doing so would dilute their position as the relevant result for virtually any programming query. EDIT: After a few seconds of googling, it looks like there has been effort on the nofollow front since I last checked. That's cool. I can see that it's nuanced. Still, my current experience with arriving at a "bad" question with great SEO is super frequent
同类还值得读
编写更好文档的框架
A Framework for Writing Better Documentation
这是 Divio 的文档写作框架，把技术文档按「读者的目标」分成四类：教程（学习导向）、操作指南（问题导向）、参考（信息导向）、解释（理解导向）。
技术写作与文档2021 · 637 分 · 76 评4 条写作要点编辑精选写好一份设计文档
Writing a good design document
这篇 HN 帖子标题为《Writing a good design document》，主题是如何写好一份设计文档；对写作者来说，它值得作为技术写作和结构化说明文的参照。
技术写作与文档2025 · 581 分 · 147 评3 条写作要点编辑精选技术写作课程
Technical Writing Courses
这是 Google 官方免费技术写作课程（两门），讲受众定义、主动语态、短句、文档结构等基础方法。
技术写作与文档2020 · 571 分 · 73 评4 条写作要点编辑精选写出更好的错误信息
Write better error messages
这篇帖子讨论如何写出更好的错误信息，评论补充了开发者场景下的具体做法和真实反面案例。
技术写作与文档2022 · 566 分 · 253 评4 条写作要点编辑精选写一本技术书的经济账
The Economics of Writing a Technical Book
一位技术书作者拆解写书的真实经济账：版税收入往往远低于投入的时间成本。
技术写作与文档2018 · 519 分 · 149 评4 条写作要点编辑精选