to-questionnaire

name	to-questionnaire
description	把你无法独自回答的决策转化为一份问卷，交给别人来填写。
disable-model-invocation	true

把用户无法独自回答的问题变成一份问卷——一份 Markdown 文档，收件人可以异步填写，或在会议上一起完成。收件人掌握着用户缺乏的知识；问卷负责把知识从他们那里"挖"出来。

盘问的是发送，而不是主题。 只采访用户关于发送的问题——这是他们总能回答的：发给谁，需要什么回来。文档中的问题则瞄准差距——收件人知道什么、用户需要什么之间的鸿沟。

1. 发给谁？ 用一次交流问清收件人的角色、专业领域和与用户的关系。这决定了问卷的语气和需要携带多少上下文。完成标志：你知道收件人是谁，以及他们知道什么用户不知道的。

2. 你需要什么回来？ 用一次交流问清用户独自无法解决、需要从这个人身上获得的具体决策或事实。完成标志：你有一个具体的清单，列出用户必须带走的能力或决策。

3. 撰写问卷。 针对第 1-2 步的差距起草问题，遵循下面的文档结构。写入当前目录下的 to-questionnaire-<slug>.md（slug 来自主题），报告路径。完成标志：文件存在，且用户在第二步中提到的每一项都被问题覆盖。

文档结构

将文档定位为一份发现问卷：用户缺乏上下文，收件人掌握着它。按重要性排序——异步意味着你可能只有一次机会——超过几个问题后，用 ## 标题按主题分组。使用下面的模板撰写。

<问卷标题>

目的： 这份问卷存在的原因和它所承载的决策。

来自： <用户> — 致： <收件人> — 你的回答将用于： <去向>

上下文

一段话，为不在用户头脑中的收件人提供背景。足够让他们给出好的回答，但不要写成一页。

如何回答

截止日期和大致耗时。部分回答和"我不知道"也是有用的——任何不确定的东西请标注出来，不要跳过。

<主题标题>

每个主题一个 ## 章节。每个章节下是问题，最重要的问题优先。每个问题只包含一个概念——永远不要复合——在问题下方直接留出回答空间，只在问题可能被误解或导致敷衍回答时，加一行说明"为什么这很重要"。

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

为什么这很重要：决定了我们是现在就为突增流量做准备，还是推迟到以后处理。

其他？

一个收尾的兜底问题：我们没问到但你应该告诉我们的？