#/to-questionnaire

决策问卷。把用户独自答不了的决策变成问卷：一份 Markdown 文档，异步交给唯一能回答的那个人，或开会时一起填。接收者握有你缺的知识；问卷负责把它挖出来。

#概述

核心方法：拷问"发送"，而不是"主题"。只访谈用户关于发送的问题（他们总能回答）：收件人是谁、你需要带回什么。文档里的问题瞄准差距——接收者知道而用户需要的部分。

#日常使用

/to-questionnaire 我需要知道 CTO 对明年技术债预算的看法
/to-questionnaire 我想问一下设计负责人关于新品牌方向的意见

#实战

#三步

1. 谁：一次问答确定接收者的角色、专长、与用户的关系。这定下问卷的语气和要带多少上下文。完成标准：知道接收者是谁、他们知道什么用户不知道的
2. 要什么：一次问答确定用户独自解决不了、需要从这个人身上拿到的具体决策或事实。完成标准：拿到用户必须能带走做或决定什么的清单
3. 写问卷：起草瞄准步骤 1–2 差距的问题，按文档结构。写到当前目录 to-questionnaire-<slug>.md 并报告路径。完成标准：文件存在，步骤 2 的每项都有问题覆盖

#文档结构

# <问卷标题>

**Purpose:** 为什么存在、什么决策骑在它上面。
**From:** <用户>, **To:** <接收者>, **How your answers will be used:** <去哪>

## Context

一段话给没进过用户脑袋的接收者定向。够答好就行，不是一页。

## How to answer

截止日期和大致工作量。部分回答和"我不知道"都有用：拿不准就标注，别跳过。

## <主题标题>

每个主题一个 ## 小节，问题最重要者优先（异步可能只有一次机会）。
每题一个想法，绝不复合，答案 stub 直接垫在下面；只有问题可能被误读
或引来敷衍回答时才加一行 why this matters。

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

_为什么重要：决定我们是现在就为突发流量扩容还是推迟。_

>

## Anything else?

兜底：我们没问但你应该知道的？

#与其它技能的关系

• 反向：/grill-me 访谈的是用户自己；to-questionnaire 访谈的是"发送"，把问题对准差距
• 下游：问卷的答案是 /grill-with-docs 或 /to-spec 的素材
• 独立技能：阻塞你的东西不在你脑子里也不在代码库里，而在别人脑子里时用