grill-me

1. Bilingual SKILL.md

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

Entry SHA-256: 6189dfceb7304a6e5558f75d87e68fa3bc7fcf7ba120e44f21f8a61fe01eba54

Path: skills/productivity/grilling/SKILL.md · View implementation source

Implementation SHA-256: fa5c1e5ee76b1c8f1ae56101f52c9e239de75d5c578adc61227b92d10b7e52ef

2. Why This Skill Is Clever

一句话核心机制

这个学习单元分成两层：grill-me 是只允许用户主动开启的超薄入口；grilling 是真实执行机制，它把模糊想法建模为一棵动态设计树，每轮只询问当前前置条件已经满足的“前沿”问题，直到没有隐含假设。

1. 为什么这里确实是“纯套壳”，而不只是普通调用

grill-me 的 body 只有一句：

Run a /grilling session.

它没有自己的提问步骤、格式、停止条件、事实查找规则或产出定义。全部核心行为都由唯一的 grilling 承担。因此它符合三个纯套壳条件：

1. 自身没有流程；
2. 只全量委托一个 skill；
3. 被委托者负责全部核心行为。

这与“一个完整的 implement skill 在最后调用 code-review”不同。后者有自己的主体流程，code-review 只是局部能力，不能把两份原文合并成一个学习单元。

2. 入口层的巧妙之处：高干扰能力必须 opt-in

grill-me 写了：

disable-model-invocation: true

这意味着高强度追问不能由模型擅自发起，而要由用户显式选择。这个边界非常合理：grilling 的目标就是“不留情面地追问”，如果自动触发，正常对话会突然变成几十个问题，用户体验极差。

作者没有削弱能力，而是限制了谁有权启动能力。这是 skill 设计中很值得迁移的一条原则：高成本、高干扰、强控制型流程，最好采用显式 opt-in 入口。

3. 真实机制不是“多问问题”，而是维护依赖图

grilling 最重要的一句不是 Interview the user relentlessly，而是：

Map this as a design tree

普通访谈常先写一张固定问题清单，然后从上到下提问。这里却把每个问题视为决策节点，并显式表达依赖关系：某些问题只有在上游答案确定后才有意义。

所以用户的每次回答不仅“填入答案”，还会：

• 新增后续分支；
• 删除已经不可能的分支；
• 改变问题优先级；
• 解锁原本不能合理询问的问题。

这就是原文所说的：

Each round the user answers reshapes the tree

它把访谈从静态 questionnaire 升级成了动态规划过程。

4. frontier 是整份 skill 最精巧的抽象

原文把前沿定义为：

every decision whose prerequisites are already settled

也就是：当前所有前置条件已经满足、现在可以不靠猜测直接询问的节点集合。

这个抽象同时解决了两类失败：

失败 A：过早提问

如果问题 B 的答案依赖问题 A，就不能在同一轮让用户同时回答 A 和 B。否则用户只能猜测 A 的答案，再基于猜测回答 B。

原文明确规定：

belongs to a later round, not this one

失败 B：一次只问一个导致低效

只问单个问题虽然安全，却会造成无谓的来回。frontier 允许把彼此独立、前置条件均已满足的问题整批提出。

因此它不是“批量提问”或“逐个提问”二选一，而是：按依赖关系做最大安全并行化。

5. 每道问题都附推荐答案，避免把思考成本甩给用户

格式要求是：

❓ **Q1** - **<question title>**: <question body>

➡️ <your recommended answer>

agent 不只是主持人，还必须表明判断。推荐答案有三个作用：

1. 给用户一个可反驳的具体起点；
2. 暴露 agent 当前的理解和偏见；
3. 避免用开放问题把全部分析工作推回用户。

用户仍拥有最终决策权，但 agent 必须先完成自己的思考。这比不断问“你想怎么做？”更有价值。

6. “事实归 agent，决策归用户”划分了责任边界

真实 skill 中最值得迁移的规则是：

Finding facts is your job, never the user's.

以及：

The decisions are the user's

它把两类不确定性拆开：

• 可查询的不确定性：代码现状、文件内容、API 能力、运行结果——agent 用工具查。
• 价值判断的不确定性：接受什么取舍、哪个目标优先、什么体验更重要——用户决定。

许多 agent 访谈失败，是因为它们让用户回答本可自行查证的事实；另一些则擅自替用户作价值决策。这两句话把边界切得很干净。

7. 子 agent 调研不会阻塞整轮

当某个问题依赖尚在查询的事实时，原文没有要求整个访谈暂停，而是说：

only the questions downstream of it wait

只有依赖调研结果的分支等待，前沿中的其他独立问题继续推进。这相当于在决策图上进行异步调度：局部阻塞，而不是全局阻塞。

8. 完成条件可验证，而不是“感觉问得差不多”

结束条件是：

when the frontier is empty

也就是说，所有可达分支均已处理，没有节点仍在等待确认。它还增加了一道用户确认闸门：

Do not act on it until the user confirms

这防止 agent 在最后一个问题刚答完时立即开始实现，却没有让用户确认整体理解是否正确。

9. 为什么要拆成 grill-me 与 grilling

拆层带来三种价值：

• 权限边界： grill-me 规定只能由用户主动启动。
• 机制复用： grilling 可被 grill-with-docs、wayfinder 等其他完整流程调用。
• 单一真理来源： 设计树、frontier、事实/决策边界只维护一份。

但不能把“调用另一个 skill”一概视为套壳。只有入口不拥有任何主体流程、全部行为由一个实现 skill 承担时，这种拆层才成立。否则展开每个依赖会让报告无限递归，也会混淆当前 skill 自己的设计责任。

防失败机制与 trade-off

防失败机制

• 禁止模型隐式触发，防止无意进入高压访谈。
• 按前沿分轮，防止用户回答依赖尚未确定的问题。
• agent 自己查询事实，防止把可检索工作甩给用户。
• 只阻塞下游分支，防止一次调研拖停整个会话。
• 前沿为空且用户确认后才执行，防止隐含假设直接进入实现。

代价

• 设计树过大时，问题数量可能膨胀，需要先缩小主题范围。
• 有些问题无法靠语言决定，例如 UI 手感；此时应先做 prototype，而不是继续追问。
• grill-me 单独看几乎没有教学内容，必须识别其纯套壳性质并同时阅读 grilling，才能理解完整行为。

可迁移到自己 Skill 写作中的原则

1. 不要把固定问题清单当作需求澄清；用依赖图决定下一轮能问什么。
2. 最大化安全并行：问整个 frontier，而不是盲目批量或机械逐题。
3. 事实由 agent 查，价值取舍由用户定。
4. 每个问题给推荐答案，让用户反驳具体判断。
5. 定义可验证的完成条件，并在行动前设置用户确认闸门。
6. 只对真正的纯套壳展开实现 skill；普通组合调用保持边界。

今日实践题

选一个你正在考虑的真实决策，画出 5–8 个决策节点。然后标出：

• 哪些节点现在已经满足前置条件，属于当前 frontier？
• 哪些问题必须等上游答案后才能询问？
• 哪些是 agent 应该自己查的事实，哪些必须由你作价值判断？

如果所有问题仍能平铺在同一张清单里，说明你还没有真正建出设计树。