name: to-questionnaire description: "把你无法独自回答的决策问题转成供别人填写的问卷。" disable-model-invocation: true
第 25 课 / to-questionnaire
把你无法回答的问题交给真正知道的人
先了解问卷发给谁、需要拿回什么，再为那个知识缺口写问题。
还不清楚 Skill、Agent、安装和调用？先读 从零开始的6节入门课。
在关系图中查看 to-questionnaire 与其他技能的关联 →
一 / 读这一课之前
先把必要的概念讲清楚
有些问题你并不知道答案，但另一位同事或专家知道。这项技能把这种知识缺口转成一份对方可以异步填写的问卷，而不是持续追问你不掌握的事实。
下面是老师补充的入门说明；原作者的要求保留在中英对照正文中。所有例子均为帮助理解而构造的教学情境。
spec / specification｜规格说明
把要解决的问题、预期行为、约束和验收依据写明确的文档。它比“做个好用的学习网站”具体：例如登录用户能收藏课程，刷新后仍保留，重复收藏不会多出记录。它不必规定每个内部函数怎么写，但应让实现者和验收者对同一结果达成一致。
acceptance criteria｜验收条件
明确规定结果满足什么才算完成，应尽量可观察、可检验。例如“收藏后刷新页面仍可见，重复点击只保留一条”。“体验很好”“代码完善”没有明确边界，难以判断。验收条件关注结果，不是把实现步骤换个标题列出来。
二 / 中英全文对照与精讲
读原文，理解每一步为什么这样做
左右内容按小节对应；窄屏先中文、后英文。两种语言均完整展示，对应讲解紧接在小节之后。译文传达原文要求；老师讲解补充概念、原因、例子与适用边界。
中文译文English · 英文原文
name: to-questionnaire description: Turn a decision you can't fully answer into a questionnaire for someone else to fill in. disable-model-invocation: true
把用户无法独自回答的问题，整理成一份问卷：用 Markdown 文档交给一位收件人，可以由对方稍后填写，也可以开会时一起完成。对方掌握用户缺少的知识，问卷用来把这些信息获取出来。
先问清发送安排，不要让用户代答问卷主题。 只向用户询问他能回答的两件事：发给谁、需要拿回什么。然后针对收件人所知与用户所需之间的缺口设计问题。
- 发给谁？ 一次交流中了解对方的角色、专业经验以及与用户的关系。这决定语气和需要提供多少背景。知道对方是谁，以及他掌握哪些用户缺少的知识后，此步完成。
- 希望得到什么？ 一次交流中确认用户无法独自确定的具体事实或决定。形成明确清单：获得回答后，用户应能够做什么或决定什么。
- 编写问卷。 根据前两步的信息缺口，采用下方结构。在当前目录保存为
to-questionnaire-<slug>.md，其中 slug 根据主题命名，并报告路径。文件存在，且第 2 步每项需要都有对应问题时，才算完成。
Turn something the user can't answer alone into a questionnaire: a Markdown document they hand to one person to fill in async, or fill out together over a meeting. The recipient holds knowledge the user lacks; the questionnaire pulls it out of them.
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.
-
Who is it going to? Ask, in one exchange, the recipient's role, expertise, and relationship to the user. This fixes the questionnaire's tone and how much context it must carry. Done when you know who the recipient is and what they know that the user doesn't.
-
What do you need back? 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.
-
Write the questionnaire. Draft questions aimed at the gap from steps 1–2, following the Document structure below. Write it to
to-questionnaire-<slug>.mdin the current directory (slug from the topic) and report the path. Done when the file exists and every item the user named in step 2 is covered by a question.
老师讲解 · 对应上方原文 · 含教学举例
先问清向谁询问、希望获得什么
用户通常知道收件人的角色与自己想做的决定，即使不知道技术答案。例如你不知道服务器容量需求，却知道问的是负责实际使用的同事，想确定同时在线人数与峰值时段。
AI 应把访谈集中在发送安排，而不是要求你先回答“系统到底要承受多少负载”。问卷随后针对对方知道、你又需要的内容设计问题。
对方专业程度决定背景多少和措辞。向业务负责人问“每天多少人同时学习”可能比先问 QPS 更有效，除非该指标正是对方熟悉的信息。
不知道答案的人，不应被要求替真正知情的人回答
假设你想确定 AI 学习网站要接入哪些课程资料，但具体资源由合作老师掌握。AI 若追问你“老师有多少文档、授权范围是什么”，你也许无法回答，这正是需要问卷的原因。
它应先问你：收件人是课程作者还是运营人员？你拿到回答后要决定资料接入范围，还是上线时间？然后给对方写具体问题，例如“哪些资料允许在网站向学习者展示”。
一题只问一件事，是为了容易作答和检查遗漏。把“资料格式、数量、授权、更新时间”塞成一个问题，对方可能只答前两项。分开后，哪些仍未知一目了然。
问卷产物是文档，并不表示已经发送给别人。发送、收件人确认和收到回答，是之后的实际动作，不能因文件生成就声称外部沟通已完成。
文档结构
把它写成探索信息的问卷：用户缺少背景，对方掌握背景。问题按重要程度排序，因为异步填写可能只得到一次回应。问题较多时，按主题使用 ## 标题分组。采用下面模板：
<questionnaire-template>
Document structure
Frame the document as a discovery questionnaire: the user lacks context, the recipient holds it. Order questions most-important-first, since async means you may only get one pass, and group them under ## headings by theme once there are more than a handful. Write it using the template below.
<questionnaire-template>
老师讲解 · 对应上方原文 · 含教学举例
一问一事，让回答真正支持决定
问题从重要到次要排列，因为异步问卷可能只有一次机会。每个问题只处理一个意思，下面留回答位置；必要时说明为什么重要，帮助对方给出具体而非敷衍的答案。
不佳例子：“用户有多少、怎么使用、未来会不会增长、预算多少？”对方可能只答其中一项。**改进：**分别问上线时同时使用人数、最常见操作、预计增长、可接受预算，并说明用途。
允许部分回答和“不知道”，能保留不确定性。最后的兜底问题让对方提出你没想到的重要背景。问卷已写好只是获取知识的起点，回收答案后仍需综合。
<问卷标题>
目的： 为什么需要这份问卷，哪些决定依赖回答。
发件人： <用户>；收件人： <对方>；回答的用途： <将用于哪里>。
<Questionnaire title>
Purpose: why this questionnaire exists and the decision riding on it.
From: <the user>, To: <the recipient>, How your answers will be used: <where they go>
必要背景
用一段话帮助未参加前面讨论的收件人理解情境。提供足够作答的信息，不需要写成整页背景。
Context
One paragraph orienting a recipient who wasn't in the user's head. Enough to answer well, not a page.
怎样回答
说明截止时间和预计投入。部分回答和“不知道”也有用；不确定的内容请标明，不要直接跳过。
How to answer
Deadline and rough effort. Partial answers and "I don't know" are useful: flag anything you're unsure of rather than skipping it.
<主题标题>
每个主题一节，内部按重要程度排列问题。一题只问一件事，不把多个问题捆在一起；每题后直接留出回答位置。只有容易被误解或随便敷衍的问题，才加一句“为什么重要”。
<question-example>
<Theme heading>
One ## section per theme. Under each, its questions, most-important-first. 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.
<question-example>
系统刚上线时预计需要承受多大负载？
为什么重要：这决定现在是否需要为突发流量配置资源，还是可以以后再做。
</question-example>
What load is the system expected to handle at launch?
Why this matters: it decides whether we provision for burst traffic now or defer it.
</question-example>
还有需要补充的吗？
最后开放询问：有没有我们没问到、但应该知道的事情？
</questionnaire-template>
Anything else?
A closing catch-all: anything we didn't ask that we should know?
</questionnaire-template>
三 / 你问我答
先作答，再看参考思路
Q1 · 理解
用自己的话说明：它解决什么问题，完成后会留下什么？
请各用一句话回答。若它只做规划或解释，不要把“已开发”“已部署”写成产物。
Q2 · 判断
为什么先问“发给谁”会影响问卷内容？
我已思考，查看参考思路
收件人的知识范围决定术语、背景量和可回答的问题。给供应商和给家庭成员的问卷不能只替换名字。
Q3 · 追问
原文中哪条要求在你的环境下可能不成立？
说出具体一句及其前提，例如工具不可用、资料缺失、已有项目约定冲突，或它只是作者偏好。把你的答案带回课堂，我们据此继续讨论。
课堂回传格式：第 25 课 / 我的理解 / Q2 回答 / 仍不理解的原句。这里是阅读教材；实时问答在我们的对话中进行。
四 / 应用场景讨论
把方法放进一个具体情境
教学案例：你不清楚服务器有哪些权限，问卷可以给服务维护者，询问当前访问方式、已运行服务和限制；不应要求你猜服务商内部配置。
边界与容易误读的地方
不要写成复合长问题，也不要把保存文件说成已经联系对方。真实发送需要明确授权和准确收件人。
讨论后再实践：先判断上述情境是否适用，再选择真实任务。现在无需安装、运行命令或修改现有项目。