to-questionnaire

name	to-questionnaire
description	将一个用户无法独立回答的决策整理成问卷，交给其他人填写。
disable-model-invocation	true

把用户无法独立回答的事项整理成一份 questionnaire——一份 Markdown 文档，用户可以异步交给某个人填写，也可以在会议中共同完成。接收者掌握用户缺少的知识；questionnaire 的作用是把这些知识提取出来。

围绕发送过程访谈，不要围绕主题本身访谈。 只询问用户一定能够回答的发送信息：问卷要交给谁，以及用户希望从对方那里得到什么。文档中的问题随后瞄准接收者所知与用户所需之间的 gap。

1. 问卷要交给谁？ 在一次交流中询问接收者的角色、专业背景，以及他们与用户的关系。这些信息决定问卷的语气，以及文档需要携带多少上下文。完成条件：你已经知道接收者是谁，以及他们掌握哪些用户不了解的知识。

2. 你希望得到什么？ 在一次交流中询问用户无法独立解决、必须从此人处获得的具体决策或事实。完成条件：已经得到一份明确清单，列出用户完成问卷后必须能够采取的行动或作出的决策。

3. 编写问卷。 根据步骤 1–2 所确定的 gap 起草问题，并遵循下文的文档结构。将文件写到当前目录中的 to-questionnaire-<slug>.md（slug 根据主题生成），并报告保存路径。完成条件：文件已经存在，而且步骤 2 中用户列出的每项需求都由至少一个问题覆盖。

文档结构

将文档定位为 discovery questionnaire：用户缺少上下文，接收者掌握这些上下文。按重要程度从高到低排列问题——异步交流可能只有一次回复机会。问题超过少量几条后，按主题放在不同的 ## 标题下。使用下面的模板。

<问卷标题>

目的： 说明为什么需要这份问卷，以及哪些决策取决于回答结果。

发起人： <用户> — 接收者： <接收者> — 回答用途： <回答将用于何处>

背景

用一个段落帮助未参与前期讨论的接收者理解情境。信息应足以支持高质量回答，无需写成整页说明。

填写方式

说明截止时间和大致所需时间。部分回答和“我不知道”同样有价值；不确定的内容请明确标注，不要直接略过。

<主题标题>

每个主题使用一个 ## 章节，问题按重要程度排列。每个问题只询问一件事，不能把多个问题合在一起。问题下方直接留出回答位置；只有问题可能被误解或得到敷衍回答时，才补充一行_为什么这件事重要_。

### 系统上线时预计需要承受多大负载？

为什么这件事重要：答案决定我们现在就为突发流量配置容量，还是推迟处理。

还有其他需要补充的吗？

以一个开放问题收尾：是否还有问卷未覆盖、但我们应该了解的事项？