Github 106k Star 的 Skill！作者 mattpocock 亲授你用不好 grill-me 的 9 个原因

提到 mattpocock 这个名字，你可能会觉得有些陌生。

但要是说起他的 grill-me skill，相信大部分开发者都非常熟悉。

这位大佬的 skills 仓库开源不过两个月，GitHub 上的 Star 数已经突破了 106k+。

mattpocock 写的 skills 非常简洁，完全围绕 issue 设计，省去了复杂流程，反而更加适合模型能力发挥。

如今，这个仓库也是我开发过程中使用频率最高的技能库，没有之一。

最近，mattpocock 本人发布视频，亲自介绍了使用 /grill-me and /grill-with-docs 时最容易踩坑的几大误区。这波必须狠狠学习。

---

开始

/grill-with-docs 技能已逐渐成为了 plan 模式的热门替代方案。

不过，很多人并没有真正用好它。

这个技能的工作原理是不断地向你提问，直到与你达到共识，但这也要求你自身具备良好的规划能力。

本文的目标，是希望帮你理解使用技能时最常见的九大误区，从而让你真正掌握它们。

理解问题：低保真 vs 高保真

当你进入 grill 对话时，你会回答很多关于你要做的事情的问题。

问题的“低保真“和“高保真“听起来可能有点抽象，下面是具体说明：

问题类型	定义	示例	适合 grill 吗？
低保真	不需要详细原型或图片就能回答的问题	“这个路由应该使用哪个 URL？”	✓ 是
高保真	需要放大细节、借助图片或原型才能回答的问题	“这个 UI 实际用起来应该是什么感觉？”	✗ 否

比如，表单字段的布局就是一个典型的高保真问题。

“你应该把表单字段拆到多个页面，还是放在一个巨大的表单里？“ 这种问题需要先看原型，或者把整个东西做出来才有办法判断。

处理无法 grill 的问题

第一个误区，就是试图在 grill 对话里回答高保真问题。

当你遇到无法轻易回答的问题时，可以使用 handoff：

1. 在第一个对话（蓝色）里继续 grill 低保真问题
2. 遇到高保真问题时，/prototype 交接给另一个对话（黄色）
3. 在这个独立对话里构建或制作原型，把问题理解清楚
4. 再交接回原来的对话，继续处理适合 grill 的问题

这个模式可以概括为：grill → prototype → 再次 grill，它能让你在不中断 grill 节奏的情况下，回答高保真问题。

确定合适的任务范围

任务范围，也就是你要 grill 的东西有多大，非常关键。

任务范围太大，会出现两个问题：

问题 1：隐藏高保真问题

比起无休止地规划未来，在已经确认可行的基础上继续构建会更容易一些。

很多人都试图一次性为 AI 安排数天的工作任务，结果往往会因为没有建立在自己了解的坚实基础上，而导致效果不佳。

问题 2：窗口上下文限制

一开始你的上下文窗口可能几乎是空的，但你不停地问，很快就会到达窗口上下文的阈值（对大多数最先进的模型来说，大约在12 万个 token 左右）。一旦你超过了这个阈值，模型的注意力就会开始丧失，决策质量开始下降。

拆分任务

不要围绕一个巨大的任务范围直接 grill。更好的做法，是先让 agent 把它拆开来：

1. 先给出一个大的范围
2. 让 agent 把它拆成更小、更适合 grill 的模块
3. 分别围绕每个小模块进行 grill
4. 在这些独立对话中回答所有问题

主动参与而不是被动回答

很多很长的 grill 对话会失败，是因为人在面对 agent 时太过于被动了。

你要记住：这是对话，不是面试。

agent 会不断提问，但你需要：

• 判断行动路径
• 了解范围
• 避免行动偏离轨道
• 主动引导对话

如果你太被动，agent 可能会用几百个问题轰炸你，不断发散任务范围，问一堆根本不该深入讨论的问题。

但这里也需要平衡。

过于主动，意味着你可能在应该编写代码的时候，没完没了地抠那些低质量的细节。

如果你只是一味地计划和规划，而不进行真正构建，那就是过度追求完美。

所以，找到中间点：积极参与并引导对话，同时了解什么时候该停止规划、开始实现。

保存你的设计方案

这是一个十分关键但经常被忽视的问题。

在 grill 的过程中，你会创造出一个非常有价值的产物：一个装满设计决策的上下文窗口。

等你完成 grill 时，你已经围绕系统如何工作做出了大量选择，这些都非常有价值。

你可以选择：

• 如果上下文还够：直接在同一个对话里实现，不要 handoff
• 如果上下文不够了：使用 /2PRD skill 创建 PRD（产品需求文档），把它作为 handoff 的基础

永远不要为了写 PRD 而清空上下文并重新开始，这样做会毁掉你所有的设计工作。

在这次讨论中做出的每一个决定都是有价值的，都应该成为代码或记录在文件中。

使用更聪明模型执行 grill

使用低级模型来完成 grill，属于常见误区。原因如下：

grill 时，你会依赖两类知识：

知识类型	来源	可靠性	什么时候重要
上下文知识	你传入的文件、prompts、工具结果	非常可靠	实现阶段
参数知识	模型训练数据和参数里的知识	没那么可靠，但更有创造性	问答阶段

在问答阶段，你依赖的是模型的参数知识，也就是它对系统和应用天生的内在理解，来提出你可能没有考虑到的问题。

如果你本来就想得到某些问题，你肯定会把它们作为上下文传进去。

笨模型不会给你太多好想法。 你需要参数量足够大的模型，通常是那些大模型厂商最前沿模型，才能得到有创造性的建议和能激发思考的问题。

到了实现阶段，你范围可以使用更低级的模型，因为那时大部分信息都来自上下文（比如详细计划、代码库等等）。

并行执行多个 grill 对话

最后，一个简单但强大的使用技巧：并行执行多个 grill 对话。

具体的工作方式是：

1. 你正在对话 A 里 grill
2. agent 向你提了一个问题
3. you 回答它
4. agent 思考时，切到对话 B
5. 继续回答这里的问题
6. 对话 A 准备就绪，再切回去
7. 重复这个过程

这并不会造成很重的上下文切换，只是在管理不同的对话。

优点：

• 产出效率翻倍
• 用更少时间完成更多规划
• 同时推进多个设计方案

大多数人最多能比较舒服地同时处理两个对话。如果其中一个对话正在做研究这类的长时间任务，你也许可以同时处理三个。

随着你越来越熟悉 grill 流程，可以逐步提高并行数量。

总结：关键要点

• grill 的核心是问题： 低保真问题适合 /grill；高保真问题更需要 /prototype。
• 确定任务范围很重要： 选择更小的任务范围，避免快速耗尽窗口上下文。
• 保持主动： 引导对话，同时知道何时停止规划，开始写代码。
• 保存决策： 你在 grill 中做出的每个决策，都应该记录在某个地方。
• 使用聪明模型： 你需要参数知识来获得有创造性的建议。
• 并行运行： 一旦理解每个对话在做什么，就可以高效地在它们之间切换。

你越理解这些误区，就越能有效地使用 grill 在编码之前完成系统设计。

参考链接

https://www.aihero.dev/things-people-get-wrong-with-grill-me-and-grill-with-docs

https://x.com/mattpocockuk/status/2058900756640453072