转为问卷
它的作用¶
to-questionnaire 将一个你无法独自决定的决策转化为问卷:一份 Markdown 文档,交给那个掌握你所缺失信息的人,让他们异步填写,或你们二人在会议中一起完成。
它会追问发送对象,而从不追问主题。围绕主题进行访谈没有意义,因为不了解主题正是你向别人求助的原因。因此,它会询问你总能回答的两件事(这份文档发给谁,以及你需要对方返回什么),并将文档中的每个问题都指向这两者之间的缺口。
何时使用¶
你通过输入 /to-questionnaire 来调用它;代理 不会自行使用它。
当某个决策被只存在于另一个人头脑中的知识卡住时,就使用它:客户、领域专家、掌握业务规则的高管,或一个你不同组的同事。你需要哪个技能取决于答案在哪里:
| 答案在…… | 使用 |
|---|---|
| 你自己的头脑中,但尚未理清 | grill-me |
| 代码库 | grill-with-docs |
| 别人的头脑中 | to-questionnaire |
| 答案尚不在任何人头脑中,问题需要某个具体对象来回应 | prototype |
常见情况是一次 追问 会话因它提出的一些问题并非你能回答而停滞。在同一对话中运行 /to-questionnaire,将这些问题离线处理,然后把答案带回来继续。
发送对象,而非主题¶
访谈包含两轮交流,然后停止。
- 它发给谁? 对方的角色、专长、与你的关系。这决定了语气以及文档需要承载多少上下文。外部客户需要背景介绍;队友则不需要。
- 你需要对方返回什么? 你无法独自解决的具体决策或事实。这会成为完成文档的清单。你列出的每一项都会得到一个指向它的问题。
之后的一切都是起草。该技能会将文件写入当前目录的 to-questionnaire-<slug>.md。没有设置,没有工作区,也没有任何需要配置的内容。
文档¶
文档是一份发现问卷,因为你缺少上下文,而收件人拥有它。这决定了它的结构:
- 一行目的说明,指出依赖它的决策,以及一个简短的上下文部分,供不了解你背景的收件人阅读。
- 问题按最重要优先排序,并按主题分组,因为异步意味着你可能只有一次机会。
- 每个问题只表达一个想法,绝不复合,下方有回答占位符,并且仅在问题可能被误解时添加为什么这很重要一行。
- 明确允许回答“我不知道”,因为标记出的不确定性是有用的,而一个读起来像事实的自信猜测则不是。
- 结尾兜底:我们没问但应该知道的事情?
文档刻意不是两样东西。它不是分支式的。问题是一个扁平的分组列表,不是一棵如果你回答了 A 就跳过 D 节的树。它也不是多收件人的。一次运行只为一个人生成一份文档。
常见问题¶
它会读取我的追问会话并从中提取问题吗? 不是作为它自身的一个步骤。该技能没有导入阶段。它会询问发送对象,然后起草。让它在追问会话之后有效的是,你在同一对话中运行它,因此会话已经在上下文中,起草可以从中取材。如果你在一个新会话中启动它,它不了解任何追问内容,当回答“你需要对方返回什么?”时,你需要自己再次提供主题。
缺失的答案并不都在同一个人那里。它能按收件人拆分吗? 不能。第一步询问的是那个收件人,单数,并且该技能会将整份文档的语气和上下文都针对这个人。如果三个人分别掌握答案的三个部分,就运行三次,每人一次。有人要求过一份按专业或角色路由问题的文档,但那未发布。
问题之间是否依赖:它会基于前面的答案跳过某些部分吗? 不会。依赖式问题设计曾被探索,但未发布。输出是一份静态文档:主题分组、最重要优先、每个问题都保留。对它的反对意见是合理的。一个在真实答案之前提前规划两三个以上问题的模型会规划得很差,而分支式文档必须在每个答案之前规划所有问题。
如果收件人也不知道怎么办? 文档会告诉他们如实说明。它明确要求回答“我不知道”和部分答案。标记出的不确定性比猜测更有价值,因为模糊的答案和自信的错误答案一旦回到你的上下文中,看起来一模一样。
它会把它发送到任何地方吗(Slack、问题跟踪器、电子邮件)? 不会。它在当前目录写入一个 Markdown 文件,并告诉你路径。交付由你负责:把它粘贴到工单中,放到 Slack 线程里,作为电子邮件附件,或在共享屏幕上打开并实时一起处理。人们已经手动完成过这四种方式。
这不就是 /grill-me 的批量模式吗?
不是。grill-me 已经按轮次提问。它会一次性提出所有未决问题的整个前沿,然后根据答案重新计算,因此它已经满足“一次性给我所有问题”的需求。to-questionnaire 在另一个维度上不同。它关乎答案在谁的头脑中,而不是问题如何交付。想更快地自己回答它们,使用 grill-me。想从别人那里得到它们,使用这个。
我不使用技能,直接让代理做这个不行吗?
可以,而且在它出现之前,很多人已经这么做了:OPEN_QUESTIONS.md 文件、发给客户的电子表格、每个未回答问题一张“需要更多信息”的工单。这个技能为你带来两样东西:访谈不会偏移到主题,并且文档会以非技术收件人能够填写的形式输出。如果你已经有一个可用的内部格式,就不需要它。
正常工作条件¶
- 它会询问接收者是谁、你需要对方返回什么,然后就停止提问。如果它询问的是主题本身,那说明这个技能出错了。
- 你列出的每一项“需要对方返回的内容”都能追溯回文件中的某个问题。
- 这些问题读起来应针对接收者所知道的信息,而不是你自己悬而未决的问题被逐字照搬下来。
- 你可以把这份文件交给一位没有参与对话的人,对方也能明白自己为什么收到它,以及最晚何时回复。
- 返回的答案应能作为新一轮盘问的有效输入,而不是又冒出一组新问题。
适用场景¶
to-questionnaire 是一个随时可以拿来用的独立技能。当你的知识储备用尽、下一步是去问另一个人,而不是运行另一个技能时,就用它。这种情况最常发生在流程中途:规划在某件不由你决定的事情上卡住了。
它的邻近技能是 grill-me,两者的区别在于答案的源头。盘问从你这里获得答案;问卷则从另一个人那里获得答案。把得到的回答投入新一轮盘问,或者如果工作即将进入构建环节,就交给 grill-with-docs 或 to-spec。当你拿不准当下该用哪个技能时,ask-matt 会为你分流指路。
本页原文 Markdown:在 AtomGit 查看·内容源自开源项目 skills13/skills