打开 Matt Pocock 的 grill-me，它的正文只有一句：
Run a
/grillingsession.
真正承载规则的 grilling 也不过十几行。^1^
短不是它最值得讨论的地方。真正有意思的是：它没有教 Agent 新知识，却明显改变了 Agent 的工作方式。
grill-me 不负责补能力，而是负责纠正 Agent 的默认行为。它把当前目标从「尽快做出东西」临时切换成「先把隐藏假设摊开」。
这篇文章不只介绍怎么用 /grill-me。更重要的是，我们可以从它反推出一种写 Skill 的方法：
默认行为 → 可观察失败 → 最小反向约束 → 必要确认条件 → 前后验证
一、同一个需求，差别不在方案，而在假设
来看一个示意场景：
给 App 做离线优先：数据存本地，恢复联网后自动同步。
如果直接让 Agent 开工，它很容易迅速给出技术选型、数据结构和同步流程。计划看起来很完整，但至少有几个问题还没有答案：
- 两台设备离线修改同一条记录，谁覆盖谁？
- 删除操作如何传播，是否需要 tombstone？
- 本地数据量有没有上限？
- 同步失败是自动重试，还是交给用户处理？
这些问题不会因为计划写得完整就自动消失。更麻烦的是，Agent 可能已经替你选了常见默认值，却没有明确标出「这是我的假设」。grill-me 所针对的典型问题正是 Agent 带着错误假设直接开工，等用户看到结果后再返工。^2^
切到 /grill-me 后，交流方式会变成另一种节奏。
注意：以下非实际运行记录，而是依据
grilling规则整理的示意：
| 轮次 | Agent 的问题 | 暴露出的未决事项 |
|---|---|---|
| 1 | 冲突策略怎么定？我建议暂以服务端版本为准，你是否接受？ | 冲突策略尚未决定 |
| 2 | 两台设备离线修改同一条记录时，是否允许用户手动合并？ | 多端冲突没考虑 |
| 3 | 本地数据是否设容量上限？我建议先限定最近 90 天 | 数据边界没定义 |
关键并不是 Agent 多问了三个问题，而是原本会被默默补齐的假设，被改成了必须显式确认的决策。
grill-me 也不是让 Agent 只提问题、不提供判断。它要求每个问题附上推荐答案，降低用户决策成本；但推荐不等于授权。在双方确认达成 shared understanding 之前，它不能开始实施。
二、它纠正了 Agent 的哪些默认行为
1. 行动偏置：先做点什么，看起来才像在工作
Agent 产品通常强调自主推进。这个方向对「重命名一个函数」「补一个明确的测试」很有效，但面对架构设计、排障和需求不完整的任务，行动本身可能制造更多返工。
Anthropic 的 Claude Code 仓库中，有公开 issue 披露 Auto Mode 提示曾包含类似措辞：
Prefer action over planning.
#优先行动，而非规划。
Make reasonable assumptions over asking questions.
#合理假设，而非提问。
这些 issue 不是正式产品规范，但它们呈现了一种工程张力：为了减少中断、提高自主性，Agent 会被推向「合理假设并继续」。在明确任务里这是效率，在模糊任务里就可能变成带病开工。^3^
grill-me 用一条执行前 checkpoint（执行前确认点）反向约束它：
Do not enact the plan until I confirm we have reached a shared understanding.
#在我确认双方已达成共同理解之前，不得实施计划。
当前目标不再是尽快产出，而是先取得开工许可。
2. 顺从偏置：沿着用户的前提继续说
Anthropic 对多种 RLHF 模型的研究发现，当回答符合用户观点时，更容易获得人类和偏好模型的青睐；优化偏好有时会让模型牺牲真实性，表现出 sycophancy（迎合或谄媚）倾向。^4^
它在编码场景里不一定表现为明显的「你说得都对」，更常见的是：用户抛出一个模糊方案，Agent 沿着这个框架迅速补全，很少停下来挑战前提。计划越流畅，双方越容易产生一种虚假共识------看起来聊清楚了，其实关键决策从未发生。
所以 grill-me 不要求 Agent「友好地确认一下」，而是要求：
Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.
#就计划的每个方面持续追问，直到双方达成共同理解。沿设计树的每个分支推进，逐项解决决策之间的依赖；每个问题都附上你的推荐答案。
推荐答案负责推进，持续追问负责破坏虚假共识。
3. 隐性填坑：规格缺口被写成默认答案
当需求没有说明冲突策略、失败恢复或数据边界时，Agent 仍然可以生成一份完整计划。这里暂且叫「隐性填坑」：缺失的信息没有保持为空，而是被某个看似合理的默认值填上。
这不是 Anthropic 发布的正式失败模式分类，而是一种实用的观察框架。它的危险不在于默认值一定错，而在于读者很难从流畅文本里区分：哪些是已确认需求，哪些只是模型推断。
grill-me 的处理方式很朴素：
Ask the questions one at a time, waiting for feedback on each question before continuing. Asking multiple questions at once is bewildering.
#一次只问一个问题，等待用户对每个问题的反馈后再继续。一次抛出多个问题会让人不知所措。
它没有让模型变得更聪明，只是禁止多个未决事项在一份漂亮计划里被同时掩盖。
4. 事实与决策混淆：该查的不查，该问的不问
Agent 还容易混淆两类工作：
- 代码库里已经存在的事实，例如当前认证方式、数据库字段和模块边界；
- 必须由人拍板的决策，例如是否接受数据覆盖、兼容成本和业务风险。
如果不区分，Agent 可能把能读代码查到的问题反问用户，又在真正需要授权时自行选择方案。
grill-me 对此给出了一条非常清楚的分工：
If a fact can be found by exploring the codebase, look it up rather than asking me. The decisions, though, are mine --- put each one to me and wait for my answer.
#能从代码库找到的事实，自己去查，不要问我。决策属于用户------逐项交给我确认，并等待我的回答。
把四点放在一起，就能看出它为什么用十几行也能生效：
| Agent 的默认问题 | grill-me 的反向约束 |
|---|---|
| 倾向行动而非澄清 | 执行前 checkpoint：确认理解一致前不得实施 |
| 倾向顺着用户前提推进 | 持续追问并遍历决策分支 |
| 用默认值补齐规格缺口 | 一次只处理一个决策 |
| 混淆事实与决策 | 事实查代码，决策归人 |
它改的是工作目标与交互纪律，不是扩充知识库。模型本来就有追问、推荐方案和读取代码的能力，Skill 只需要阻断错误路径。因此，短并不神奇；每句话都对应一个可观察的默认问题，才是它有效的原因。
三、从 grill-me 反推：如何写行为纠偏型 Skill
多数人写 Skill 时，第一反应是列流程：第一步做什么、第二步做什么，再补一串「必须」「禁止」。grill-me 提醒我们，起点应该更靠前：
没有 Skill 时，Agent 会稳定地怎么做错？
Anthropic 的 Skill 编写建议也强调，先用代表性任务测试没有 Skill 的 Agent，记录具体失败或缺失的上下文，再逐步构建 Skill，而不是提前猜出所有规则。^5^
可以把方法压缩成四步。
1. 把不满意改写成可观察失败
「Agent 思考不够深入」无法测试。而真正具备落地价值的是可观察、可复现的失败行为，如：
- 未确认冲突策略便开始编码；
- 一次抛出五个问题，用户只回答其中两个；
- 询问代码中可以直接查到的事实；
- 未经用户同意选择不可逆方案。
只有问题可观察，约束才有明确靶点。
2. 一条约束只纠正一个问题
不要写「请全面、严谨、深入地理解需求」。可以直接写：
| 可观察失败 | 最小约束 |
|---|---|
| 过早开工 | 用户确认前不得实施 |
| 多个问题一起抛出 | 每次只问一个问题并等待回答 |
| 擅自补齐关键决策 | 每个决策分支都交给用户确认 |
| 把事实反问用户 | 能从代码库验证的事实自行查找 |
具体约束比态度要求更容易执行，也更容易验证。
3. 区分建议与确认条件
不是所有规则都要写成禁止项。
「每题给出推荐答案」是建议，Agent 可以根据场景调整表达；「确认前不得实施」是确认条件 ，其中最关键的一类是执行前 checkpoint------在双方对齐之前，阻止计划进入执行。
这里需要划清一个边界：写在 SKILL.md 里的确认条件仍然是模型要遵守的指令，并不是权限系统级的强制锁。涉及部署、删除数据、付款等高风险操作时，还应使用工具权限、审批流程或 Hook 做确定性拦截，不能只靠一句「不得执行」。
确认条件过多也会让 Agent 寸步难行。只有会造成明显返工、风险或不可逆结果的节点，才值得设置；真正不可逆的操作，则交给模型之外的机制兜底。
4. 用同一任务做 Before / After
同一个输入分别在没有 Skill 和启用 Skill 时运行。不要只看文字是否更专业，而要检查：
- 未决假设是否减少；
- 用户返工纠正的次数是否下降；
- Agent 是否真的停在执行前 checkpoint 前；
- 事实查询与用户决策是否被正确分开。
如果这些行为没有变化，继续往 SKILL.md 里加说明未必有用。更可能的情况是：根因找错了，或者约束无法被观察和验收。
📌 判断一个 Skill 是否有价值，不看它有多厚，而看它能否把一种稳定的默认错误，变成可验证的正确行为。
四、什么时候该用，什么时候别开
grill-me 不是每个任务都要走的仪式。意图越模糊、决策分支越多、做错后的返工成本越高，它越有价值。
| 场景 | 建议 |
|---|---|
| 复杂改动、多分支决策、意图模糊 | /grill-me |
| 还要沉淀领域词汇、CONTEXT.md 或 ADR | grill-with-docs |
| 需要完整设计文档到实施计划的链路 | superpowers/brainstorming |
| 已经讨论清楚，只差整理成规格 | /to-spec |
| 改一行配置、目标和约束都很明确 | 不必开启 |
作者推荐通过 skills CLI 安装整套 Skills：^6^
bash
npx skills@latest add mattpocock/skills回到开头，grill-me 的价值不只是让 Agent 多问几个问题。它展示了一类不同的 Skill：不负责告诉 Agent 更多，而是阻止它在错误时机做出看似合理的事。
以后再写 Skill，可以先别急着罗列流程。先裸跑一次 Agent，找到它稳定出现的默认错误，再写最小约束、必要确认条件，并用同一个任务验证前后差异。
这比继续往 SKILL.md 里堆「必须认真思考」，更接近一个可复用、可验证的工程方法。
Footnotes
-
Firecrawl, Best Claude Code Skills to Try in 2026，社区实践文章（
community，本文仅作弱引用）。 ↩ -
Anthropic Claude Code GitHub Issues #51429、#57836，官方仓库中的用户报告与机制讨论（
github，非正式产品规范）。 ↩ -
Anthropic, Towards Understanding Sycophancy in Language Models，官方研究文章（
official-blog）。 ↩ -
Anthropic, Agent Skills Authoring Best Practices，官方文档（
official-doc）。 ↩ -
Matt Pocock, Skills For Real Engineers，GitHub README 一手材料（
github）。 ↩