to-questionnaire

1. Bilingual SKILL.md

左右滑动可直接切换英文版与中文版；两种语言按段落自动对齐。英文中的蓝色虚线词语可点击查看解释。共标记 15 处。

Entry SHA-256: b5eb929842ee0e93d867c5e906d183d350f2f2d149eaeaa86967d94d8eda1d3b

2. Why This Skill Is Clever

一句话核心机制

只向用户追问他们一定知道的“发送接口”——接收者是谁、需要收回什么——再把两者之间的知识缺口编译成一份可独立填写、按决策价值排序的 Markdown 问卷。

触发与调用边界

直接来源： frontmatter 的 disable-model-invocation: true 把 to-questionnaire 设为用户显式调用的工具。正文把适用场景限定为：用户无法独自回答，但某一个接收者掌握缺失知识；产物是交给这个人异步填写或在会议中共同填写的问卷。

支持背景： agents/openai.yaml 的 allow_implicit_invocation: false 再次确认禁止模型自行触发。配套 docs 将入口写成 /to-questionnaire，并明确它不是多接收者路由、分支问卷或自动发送工具。这些信息帮助解释调用边界，不属于本页展示的原始 SKILL.md。

信息架构与执行顺序

1. 先确认唯一接收者的角色、专业能力和与用户的关系，用它校准语气与背景信息量。
2. 再确认用户必须从此人处获得的具体事实或决策，建立完整性清单。
3. 用前两步计算“接收者所知”与“用户所需”之间的 gap，而不是继续审问用户不掌握的主题。
4. 把 gap 转成一题一意的问题，按 most-important-first 排序；问题较多时再按主题分组。
5. 为接收者补齐 Purpose、From/To、Context、How to answer、截止时间与投入预期。
6. 给每题直接放置回答占位符，仅在可能误解或敷衍时解释 why this matters。
7. 以 Anything else? 兜底，并把文件写成当前目录中的 to-questionnaire-<slug>.md。
8. 用明确停止条件验收：文件存在，而且用户在第二步列出的每一项都能追踪到一个问题。

最巧妙的设计点

1. 用“可回答性”重新划定访谈边界

“Grill the send, not the subject.”

直接来源： 用户之所以需要外部接收者，正是因为他们不知道主题答案。skill 不让 agent 在错误的人身上继续消耗访谈轮次，而只询问用户一定能回答的发送对象与预期结果。

解释： 这是一个信息所有权路由器。它先判断知识在哪个人脑中，再决定向谁提什么问题；因此避免把“用户不知道”误诊为“还没追问够”。

2. 把模糊求助编译成可验收的 gap

“target the gap between what the recipient knows and what the user needs”

直接来源： 问题不以主题百科为中心，而以接收者能力与用户决策需求的差集为中心。第二步的 concrete list 同时成为输出覆盖率清单。

解释： 需求收集和验收共用同一份事实集合，减少“问卷写得很专业，但没有回答真正阻塞项”的失败。

3. 每个访谈阶段都有局部完成定义

“Done when you know who the recipient is”

“Done when you have a concrete list”

“Done when the file exists”

直接来源： 三步都以可观察结果结束，而不是依赖 agent 主观判断“聊得差不多”。前两步还被约束为 in one exchange，抑制无限澄清。

解释： 这些 stopping conditions 把生成式对话变成有限状态机：识别接收者 → 固化回收目标 → 写文件并做覆盖检查。

4. 用异步最坏情况决定排序，而不是追求文档叙事感

“since async means you may only get one pass”

直接来源： 问题必须 most-important-first。即使接收者中途停止填写，最有决策价值的答案仍最可能先被收回。

解释： 这是面向部分失败的内容排序，相当于让文档具备 graceful degradation。主题分组只是辅助导航，不能取代全局重要性。

5. 同时降低回答成本与错误自信

“Partial answers and \"I don't know\" are useful”

直接来源： 文档要求写明 deadline 与 rough effort，并明确允许部分回答和“不知道”；不确定内容应被标记，而不是跳过。

解释： 这把“完成率”从每题必填改成不确定性也可被结构化回收。缺失值被显式标注，优于让接收者用猜测填满表格。

6. 通过一题一意和选择性解释提升答案可用性

“Every question is one idea, never compound”

直接来源： 每题只有一个意思并紧邻回答占位符；只有容易误解或引出 throwaway answer 时才加入 why this matters。

解释： 原子问题让缺答、歧义和后续追踪都能定位到单一变量；选择性解释则避免问卷被冗长理由淹没。

防失败机制与明确不变量

• 接收者必须是一个具体的人；角色、专业能力和关系决定整份问卷的语气与背景量。
• 用户必须给出需要收回的具体事实或决策，而不是笼统说“多了解一下”。
• 访谈只围绕 send，不得把用户重新当作主题专家审问。
• 每个回收目标都必须由至少一个问题覆盖，形成可追踪的覆盖不变量。
• 问题按重要性从高到低排列，每题只表达一个意思，不得使用 compound question。
• Context 只写一个足以回答的段落，不能膨胀成一页。
• deadline、rough effort、允许部分回答和“不知道”都必须进入答题说明。
• 文件名和落点固定为当前目录的 to-questionnaire-<slug>.md，生成后必须报告路径。
• Anything else? 是补漏，不是用宽泛问题替代具体问题的捷径。

Trade-offs、可移植风险与 harness 假设

直接来源： skill 假设 harness 能理解 disable-model-invocation，能在当前目录写 Markdown 文件，并能向用户报告实际路径。<questionnaire-template> 和 <question-example> 是供 agent 解析的结构标记，不是通用 Markdown 标准。

支持背景： docs 明确静态问卷不做分支逻辑、不拆分多个接收者、也不自动发送；它还依赖同一会话上下文承接先前 grilling 的背景。agents/openai.yaml 中的调用策略是特定 harness 元数据。

解释：

• 两轮访谈让流程短，但复杂组织中的权限、敏感性、术语偏好和回复渠道可能还需要额外确认。
• 静态问题能被异步传递，却无法根据前一个回答实时重算下一题；依赖关系强时，应改用同步访谈或多轮跟进。
• “一个人”保持语气一致，但知识分散在多人手中时必须分开运行，否则责任和答案来源会混淆。
• Markdown 便于版本控制与复制，但非技术接收者可能更适合表单或文档平台；移植时应保留信息架构，而不是拘泥于文件格式。
• 覆盖检查保证每个需求都有问题，不保证问题本身无诱导性、无偏见或能得到真实答案；高风险场景仍需要人工审阅。

可迁移原则

1. 先定位信息所有者，再设计问题。 不要向没有答案的人持续增加追问强度。
2. 把“我需要知道什么”同时用作生成输入和验收清单。
3. 为每个阶段写可观察的完成条件，让对话型流程也能有限停止。
4. 按部分失败设计内容顺序。 最重要信息先出现，保证只完成一部分时仍有价值。
5. 一题只采集一个变量，并把回答空间放在问题旁边。
6. 把不确定性当作有效数据。 允许“不知道”，并要求标记信心边界。
7. 模板应服务于陌生接收者。 产物必须脱离原会话仍能说明目的、背景、截止时间和使用方式。

今日实践题

假设你的上线计划被“客户真实峰值流量”阻塞，而客户技术负责人掌握答案：你会如何分别写出 Who is it going to? 与 What do you need back? 的完成条件，并把最关键的问题放在问卷第一位？

Evidence note

• 直接来源： 本报告展示的完整 skills/productivity/to-questionnaire/SKILL.md，以及其中的步骤、模板、不变量和短引文。
• 支持背景： agents/openai.yaml、docs/productivity/to-questionnaire.md、productivity 索引和 ask-matt 路由仅用于解释显式调用、单接收者、静态问卷与流程位置；它们没有被冒充为所选原文。
• 解释： 关于信息所有权路由、有限状态机、graceful degradation 和原子变量采集的论述是工程判断。