Agent Skills 工程化实践 08：谁来回答问题，决定你该用哪种采访工具

先判断答案在哪里

这组 Skills 表面上都在“问问题”，实际分工由答案所在的位置决定：

• 答案在你脑中，但还没被展开：grill-me；
• 已经在 repo 中工作，需要把术语和决定留下来：grill-with-docs；
• 需要复用采访机制：grilling；
• 正在改变项目里的概念、关系或 ADR：domain-modeling；
• 答案在客户、业务专家或另一个同事脑中：to-questionnaire。

把这条边界搞错，Agent 就会问你本可以自己查到的事实，或者更糟——替真正的 decision owner 做决定。

grilling：所有采访的 primitive

触发方式：Model-invoked，也可以显式要求。 它把主题画成 design tree，把当前所有前置条件已满足的 decisions 称为 frontier，并按 round 提问。

一个合格 round 里的问题彼此不依赖；每题都有编号、标题和 Agent 的推荐答案。你回答后，frontier 才向下一层移动。事实由 Agent 查，决定由人回答；frontier 清空后仍要由人确认双方已经形成 shared understanding。

请使用 grilling 压测“是否把审批流改成可配置状态机”，先查代码事实，再按 frontier 分轮提问，不要开始实现。

成功信号： 后一轮出现了前一轮不可能提前问出的分支；Agent 没有替你回答产品取舍；最后停在确认门，而不是直接生成代码。

上游 Skill：grilling

grill-me：无状态地挖出你自己的决定

触发方式：User-invoked。 它是一行很薄的 wrapper：

/grill-me 我想做一个面向企业客户的 AI 交付产品

适合没有 working directory 的产品构想、职业选择、内容方案和业务设计。它不会写 CONTEXT.md 或 ADR；输出是 conversation 中的 shared understanding。

什么时候不要用： 已经在 codebase 中工作时，优先 /grill-with-docs；问题需要看到真实 UI 或跑通 state machine 时，先承认“谈话无法回答”，转入 prototype；答案属于另一个人时，转入 /to-questionnaire。

上游 Skill：grill-me

grill-with-docs：采访与项目记忆同时发生

触发方式：User-invoked。 在 repo 中运行：

/grill-with-docs 我们要重新定义“订单完成”，并调整退款流程

它组合 grilling 与 domain-modeling。采访不是结束后才整理纪要，而是在术语和 hard-to-reverse decisions 成形时，实时维护 CONTEXT.md 与 ADR。这样后续 spec、tickets、tests 与代码命名都共享同一套 language。

关键边界： CONTEXT.md 记录项目词汇和难以凭代码快速恢复的关系，不是需求文档仓库；ADR 只记录 hard to reverse、surprising 或有真实 trade-off 的选择。可轻易撤销的偏好不值得制造永久文档。

上游 Skill：grill-with-docs

domain-modeling：改变语言时才触发

触发方式：Model-invoked。 它不是“每次读 CONTEXT.md 都要启动”的仪式；只有在讨论 codebase terminology、编辑 CONTEXT.md、记录或修改 ADR 时，才进入 active discipline。

使用方式可以很直接：

请用 domain-modeling 检查这里的 request、submission、review 是否混用了概念，并用边界场景验证新的 glossary。

它会挑战 overloaded terms，用 concrete scenarios 检查两个概念是否真的不同，并把每个 glossary entry 写成“一两句话说明它是什么”，同时列出不再使用的近义词。好的 domain model 会让代码与对话都变短；坏的 glossary 只是把普通名词换成团队黑话。

2026-08-14 的 upstream main 还更新了它的 trigger：讨论 terminology，或显式写 CONTEXT.md / ADR 时都应触发。这是 v1.2.3 之后 main 上的变化，因此报告当前状态时要区分 release 与 main。

上游 Skill：domain-modeling

to-questionnaire：把问题交给真正知道答案的人

触发方式：User-invoked。 运行：

/to-questionnaire 我需要向财务负责人确认计费、退款和对账规则

它只采访你两件事：发送给谁，以及你必须拿回哪些事实或决定。然后生成当前目录下的 to-questionnaire-<slug>.md。它不会继续追问 subject，因为你不知道 subject 的答案正是调用它的原因。

文档应最重要问题优先、一个问题只问一件事、允许回答“不知道”，并给不在场的 recipient 足够 context。它只面向一个 recipient；知识分散在三个人手里，就运行三次，而不是制造一份没人完整负责的问卷。

回答回来后，把它作为下一轮 grilling、grill-with-docs 或 to-spec 的输入。问卷不是 decision，它只是把缺失的一手知识带回 decision flow。

上游 Skill：to-questionnaire

一条不会把责任问错人的判断式

我自己知道，只是没想清楚          → /grill-me
repo 里有事实，而且要留下项目语言   → /grill-with-docs
正在改变 glossary 或 ADR           → domain-modeling
答案在另一个人的专业知识里          → /to-questionnaire
说话也无法判断，必须看到运行结果     → prototype

这组 Skills 真正有价值的地方，是把“提问”从聊天技巧变成 ownership 设计。问题交给错误的人，答案再完整也不可靠；先确认 knowledge owner，才有资格谈自动化。

来源与版本

• 上游参考：README Reference
• 参考分支：main · 核验 commit：8b78b53 · 核验日期：2026-08-14