to-questionnaire 精读：把「答不上来的决定」做成一份发给别人的问卷

（本文读的是 mattpocock/skills 快照 5beb35b，2026-10-19。引用原文都能按文中路径回仓库核对。这是「逐个技能精读」系列的第二十六篇，聚焦 to-questionnaire 一个技能。）

它怎么工作：三个问题，产出一份 Markdown 问卷

skills/productivity/to-questionnaire/SKILL.md 的 description 就一句话：

Turn a decision you can’t fully answer into a questionnaire for someone else to fill in.

它同样是 disable-model-invocation: true（user-invoked），只有你亲手敲才会起。正文的核心是一句口号式的方法论：

Grill the send, not the subject. Interview the user only about the send, which they can always answer: who it goes to, and what they need back. The questions in the document then target the gap between what the recipient knows and what the user needs.

the send（怎么发）对应「发给谁」和「要拿回什么」；the subject（问什么）反而是不能问用户的东西——因为用户答不上来，正是这个技能存在的前提。

三步，每步各带一条完成条件：

1. 发给谁？「Ask, in one exchange, the recipient’s role, expertise, and relationship to the user.」Done when you know who the recipient is and what they know that the user doesn't. 收件人的角色、专业度与跟你的关系，决定问卷的语气，以及要自带多少上下文。
2. 要拿回什么？「Ask, in one exchange, the specific decisions or facts the user can’t resolve alone and needs from this person.」Done when you have a concrete list of what the user must walk away able to do or decide. 注意它的完成条件不是「问够了」，而是「你手里有一张清单，列出你走开之后必须能做的决定」。
3. 写问卷。 按下面的模板写成 to-questionnaire-<slug>.md，放在当前目录，并把路径报给你。Done when the file exists and every item the user named in step 2 is covered by a question. 覆盖性是硬验收：第 2 步清单上的每一项，都得在问卷里有一道题。

文档模板是这份技能的另一半。它被定义成一份发现式问卷（discovery questionnaire）——用户缺上下文，收件人握着它——因此骨架里有几条硬约束：

• 最重要的问题放最前：Order questions most-important-first, since async means you may only get one pass。异步意味着你可能只有一枪机会。
• 文档自带投递元数据：Purpose（为什么问、压在什么决定上）、From / To、How your answers will be used（答案会去哪）。一份发出去的问卷会自己说明来历。
• Context 一段：让一个没进过你脑子的人也能答得好，但不写成一篇。
• How to answer：给截止时间和大致工作量，并明说「部分回答和『我不知道』都有用」：Partial answers and "I don't know" are useful: flag anything you're unsure of rather than skipping it.
• 按主题分 ## 段，一题一念：Every question is one idea, never compound, with an answer stub directly beneath, and a one-line _why this matters_ only where the question could be misread or invite a throwaway answer. 题目下面直接留空位，只有容易读歪的才配一行「为什么问这个」。
• 结尾一个兜底：Anything else?

一次触发路径：你在推进一个只有平台 owner 能拍板的决定，卡住了。你敲 /to-questionnaire，它只问你两轮——发给谁、要拿回什么——然后落一份 to-questionnaire-*.md 在目录里、报出路径。你把它发给那个人，他异步填回来，你就拿到了原本一个人在房间里想不出来的答案。

它和「一般技能」的差别：盘问的是「怎么发」，不是「问什么」

一个「问卷生成」技能最容易掉的坑，是回头问你一堆关于主题的问题，好把题目写得更细。to-questionnaire 明确拒绝这件事：Interview the user only about the _send_, which they can always answer. 它把访谈严格限制在用户必定有答案的那半边——收件人是谁、要拿回什么——剩下那半边（题目该问什么）留给「gap」，由收件人那边补。技能因此不会把你逼进一个你本来就答不出的墙角。

第二处差别是它只产出文件，不产出答案。同样落文件，research 的文件是一份带引用、你留着自己看的断言清单；to-questionnaire 的文件是一件要寄出去的仪器——你会把它发给一个可能根本不在你的 agent 环境里的人，等他填完再收回来。

第三处差别是它把「投递」写进了文档骨架本身。多数产物不携带自己的去向；这份问卷必须写清 From / To / 用途，因为它的读者是一个外部的人。

它有意识摒弃了什么

一、摒弃了「追问用户主题」。 前提就是用户不知道；再问只会得到编造的答案。

二、摒弃了结构化提问 UI。 这一条要对着仓库里 .out-of-scope/native-question-tool.md 读。那篇决定拒绝把 grilling 接到 harness 自带的提问界面上（Claude Code 的 AskUserQuestion、宿主「question tool」），理由有两条：技能是 harness 中立文本（The skills are harness-neutral text.），而结构化选择器会「把模型推向预置答案的多选题，与 grilling 想要的『用你自己的话回答、一次推进决策树的一个分支』正好相反」。to-questionnaire 正是它选中的替代品形态：一份纯 Markdown 文件，不依赖任何 UI，收件人不在你的 harness 里也照样能填。

三、摒弃了题目数量上限，也摒弃了「用数量当闸门」。 .out-of-scope/question-limits.md 说得很直白：Grilling is intentionally open-ended. to-questionnaire 同样不设上限——它约束的不是「问几道」，而是结构与顺序：一题一念、最重要的问题排最前。数量不是杠杆，原子性和排序才是。

四、摒弃了多轮追问回收。 因为是异步，它假定只有「一轮」，所以用「最重要的问题放最前」来对冲丢信息的风险。

五、摒弃了复合问题。 never compound——一道题只装一个想法，否则收件人没法给你一个干净的答案。

六、摒弃了「每道题都写一句为什么」。 只在可能被读歪或招来敷衍的地方写；其余留白，省掉噪音。

七、摒弃了把问卷留在对话里。 它落文件、报路径，因为这东西注定要被转交。

原文证据

方法论一句话：

Grill the send, not the subject. Interview the user only about the send, which they can always answer: who it goes to, and what they need back.

第 2 步的完成条件（把「问够了」换成了「能带走什么」）：

Done when you have a concrete list of what the user must walk away able to do or decide.

异步只有一轮，以及最后一步的覆盖性验收：

Order questions most-important-first, since async means you may only get one pass

Done when the file exists and every item the user named in step 2 is covered by a question.

题目原子性与答案留空：

Every question is one idea, never compound, with an answer stub directly beneath, and a one-line why this matters only where the question could be misread or invite a throwaway answer.

可迁移结论

1. 把「我答不上来的决定」当成一类独立产物：一件要寄出去的问卷。 不是在你脑子里继续想，而是去问那个知道的人。
2. 只盘问发送者能回答的东西。 发给谁、要拿回什么——把访谈锁在用户必定有答案的那半边。
3. 让文档自带投递元数据。 Purpose / From / To / 答案去哪，写进骨架。
4. 异步一次通过，就按重要性倒着排。 最重要的问题排最前，对冲只有一枪的机会。
5. 一题一念，下面留空位。 复合问题会毁掉答案的可用性。
6. 明说「不知道也有用」。 让收件人标出不确知，而不是跳过。
7. 用纯 Markdown 文件代替任何 UI。 收件人可能不在你的 harness 里；harness 中立的文本才是能到处跑的载体。

to-questionnaire 和 grilling 是一对镜像：grilling 追着你问，用来解决你脑子里的决策树；to-questionnaire 把你答不出的那部分打包，转手去问别人。两者共享同一个关于「问题该长什么样」的判断——开放、一次一个、由人来排优先级——这也是它们一起拒绝了结构化提问 UI 的原因。