需要向掌握信息的人收集决策所需答案时…

当用户无法独自回答某个决策或事实需求，而某位收件人掌握所需知识时，生成一份 Markdown 问卷，让对方异步填写或在会议中共同填写。

适用场景

解决思路

1. 把用户无法独自回答的问题转化为 Markdown 问卷；该问卷可交给一位收件人异步填写，也可在会议中共同填写。
2. 明确收件人掌握用户缺少的知识；问卷的作用是把这些知识从收件人那里提取出来。
3. 只围绕“发送”采访用户，不围绕主题本身盘问：用户总能回答这份问卷要发给谁、需要拿回什么；问卷中的问题则瞄准收件人已知与用户所需之间的差距。
4. 通过一次交流问清收件人是谁：其角色、专业领域、与用户的关系；据此确定问卷语气和需要携带多少背景。完成标准：知道收件人是谁，以及他掌握哪些用户不知道的信息。
5. 通过一次交流问清用户需要拿回什么：用户无法独自解决、必须从对方获得的具体决策或事实。完成标准：得到一份具体清单，明确用户看完后必须能做什么或决定什么。
6. 起草问卷：围绕第1-2步识别出的差距写问题，遵循文档结构。
7. 将问卷写入当前目录下的 `to-questionnaire-<slug>.md`（slug 来自主题），并报告该路径。完成标准：文件已存在，且第2步中用户列出的每一项都由至少一个问题覆盖。
8. 将文档定位为 discovery questionnaire：用户缺少上下文，收件人掌握上下文。
9. 问题按最重要优先排序，因为异步填写可能只有一轮机会。
10. 当问题不止少数几个时，用 `##` 标题按主题分组。
11. 使用给定模板，标题为 `# <Questionnaire title>`。
12. 写 `**Purpose:**`：说明问卷为何存在，以及依赖它做出的决策是什么。
13. 写 `**From:** <the user>, **To:** <the recipient>, **How your answers will be used:** <where they go>`。
14. 写 `## Context`：用一段话让不在用户脑子里的收件人建立方向；足够回答好，不要写成一页。
15. 写 `## How to answer`：说明截止时间和大致投入；告知部分回答和“我不知道”也有用，不确定的内容要标记出来而不是跳过。
16. 每个主题一个 `## <Theme heading>` 章节；每个主题下放它的问题，按最重要优先。
17. 每个问题只包含一个想法，绝不复合问题；问题下方直接放回答占位符 `>`。
18. 仅当问题可能被误解或会招来敷衍回答时，加一行 `_Why this matters:_` 说明为何重要。
19. 在结尾写 `## Anything else?` 兜底：有没有我们没问到但应该知道的事？
20. 可参考示例格式：`### What load is the system expected to handle at launch?`，下方写 `_Why this matters: ..._`，再写回答占位符 `>`。

适用边界 · 注意事项

• 用户自己已能回答该决策，或所需信息不掌握在某个可询问对象手中时。
• 无法确定合适收件人、对方没有你缺少的知识，或问题必须依赖连续多轮互动、敏感协商而不适合一次性问卷时。
• 只需要快速同步确认、不值得生成文档和走问卷流程时。