to-questionnairelisted

把一个用户无法独自回答的东西变成一份**问题单（questionnaire）**——一份 Markdown 文档，他们交给一个人异步填写，或在一个会议上一起填写。接收者拥有用户缺乏的知识；问题单把它从他们那里挖出来。 **拷问投递，而不是主题。** 只就_投递_访谈用户，这他们总能回答：发给谁，以及他们需要拿回什么。文档中的问题随后瞄准**缺口**——接收者所知与用户所需之间的差距。 1. **要发给谁？** 在一次交流中问接收者的角色、专业背景，以及与用户的关系。这确定问题单的语气和它必须携带多少上下文。当你知道接收者是谁、他们知道什么用户不知道的东西时，就完成了。 2. **你需要拿回什么？** 在一次交流中问用户无法独自解决、需要从这个人的具体决策或事实。当你有了一个具体的清单，列出用户必须带走的能力或决策时，就完成了。 3. **写问题单。** 起草针对第 1–2 步缺口的问题，遵循下面的文档结构。把它写到当前目录的 `to-questionnaire-<slug>.md`（slug 取自主题），并报告路径。当文件存在且第 2 步用户点名的每一项都被一个问题覆盖时，就完成了。 ## 文档结构 把文档构建为**发现式问题单**：用户缺乏上下文，接收者拥有它。问题按最重要的排前面——异步意味着你可能只有一次机会——一旦主题超过几个，就按主题归到 `##` 标题下。使用下面的模板编写。 <questionnaire-template> # <问题单标题> **目的：** 这份问题单为什么存在，以及它承载的决策。 **来自：** <用户> — **发给：** <接收者> — **你的回答将如何被使用：** <它们去往哪里> ## 上下文 一段话，为不在用户脑子里的人定位。足以回答好问题，而不是一页。 ## 如何回答 截止时间和大致工作量。部分回答和"我不知道"是有用的——标注任何你不确定的内容，而不是跳过它。 ## <主题标题> 每个主题一个 `##` 部分。在下面放它的提问，最重要的排前面。每个问题是一个想法——绝不复合——答案存根直接放在下面，只有在问题可能被误读或招来敷衍回答的地方，才加一行_这为什么重要_。 <question-example> ### 系统在发布时预期承受多大的负载？ _这为什么重要：它决定我们现在是否要为突发流量做配置���还是推迟。_ > </question-example> ## 还有别的吗？ 一个收尾的兜底问题：有什么我们没问但你应该让我们知道的？ </questionnaire-template>