to-questionnaire

name	to-questionnaire
description	把一个你无法完全回答的决策变成一份问卷，交给别人填写。
disable-model-invocation	true

把用户无法独自回答的东西，变成一份问卷——一份 Markdown 文档，交给某个人异步填写，或者双方在会议上一起填。收件人掌握着用户所缺的知识；问卷把它从他们身上引出来。

拷问“这次发送”，而不是主题。 只就发送一事拷问用户，这是他们始终能回答的：发给谁，以及需要拿回什么。文档里的问题随后瞄准收件人所知与用户所需之间的缺口。

1. 它发给谁？ 在一次交流中，问清收件人的角色、专长以及与用户的关系。这确定了问卷的语气，以及它必须携带多少上下文。当你知道收件人是谁、以及他们掌握而用户不掌握的是什么时，即完成。

2. 你需要拿回什么？ 在一次交流中，问清用户无法独自解决、需要从这个人那里获得的具体决策或事实。当你有了一份具体清单——列出用户最终必须能做或能决定的事——即完成。

3. 写问卷。 依据第 1–2 步找到的缺口起草问题，遵循下面的“文档结构”。把它写入当前目录下的 to-questionnaire-<slug>.md（slug 取自主题）并回报路径。当文件存在、且用户在第 2 步指明的每一项都有一个问题覆盖时，即完成。

文档结构

把文档定位为一份探索性问卷：用户缺上下文，收件人握有它。问题按最重要在前排序——异步意味着你可能只有一轮机会——并在问题超过寥寥几个时，用 ## 标题按主题分组。使用下面的模板来写。

<问卷标题>

目的： 这份问卷为何存在，以及依赖它的决策是什么。

发件人： <用户> — 收件人： <收件人> — 你的回答将如何被使用： <它们的去向>

背景

一段话，为不了解用户脑中所想的收件人提供方位。够回答好即可，别写成一整页。

如何作答

截止时间与大致工作量。部分回答和“我不知道”都是有用的——对任何不确定的地方做出标记，而不要跳过它。

<主题标题>

每个主题一个 ## 小节。每个小节下放其问题，最重要在前。每个问题只包含一个想法——绝不复合——正下方紧跟一个答案存根，并且只有在问题可能被误读或会招来敷衍答案时，才加一行 为什么这很重要。

### 系统在上线时预期要承受多大负载？

为什么这很重要：它决定我们现在就为突发流量做资源预留，还是先推迟。

还有别的吗？

一个收尾的兜底问题：有没有什么我们没问到、但我们应当知道的？