我用 grill-me 整整一个月了。现在，我几乎在开始每一个任务之前，都会用grill-me给我把关，通过这个skill，让大模型了解我这个任务中，我没有说说清楚的细节。
但真正让我震惊的不是它能做什么，而是它本身------只有5 句话。一个几乎改变了我跟 AI 协作方式的 skill，短到几乎可以写在一张便签纸上。
这让我意识到一件事：一个 AI Skill 的效力，不取决于它写了多少字，而取决于它在哪些维度做了约束。
一张照片，11 个决策
说说我最近的一次使用体验：在一个微信小程序项目里，我想在牌位编辑页加一张照片。
听起来很简单对吧？客户端选图，上传，展示。三个步骤，直觉上只会需要修改app端和api端的代码即可。
我启动了 grill-me SKILL。它居然前后一共问我了 11 个问题：
- 布局方式：作为 field_layout 条目，和 display_name/birth_death 同级，还是写死位置？
- 照片样式：直角还是圆角？有边框吗？
- 无照片时显示什么：空白？占位符？隐藏？
- 填充方式：contain 还是 cover？
- 上传接口：新建一个，还是复用管理端已有的 admin/upload？
- 选图方式：wx.chooseMedia，参数怎么设？
- 编辑交互：点击照片弹出什么？
- 创建和编辑是否都支持？
- Platform 端模板配置要不要支持 photo 类型？
- 对其他场景的影响：先管还是先不管？
- 权限：App 端用户能否上传，还是仅限管理员？
其中至少 5 个问题，在我启动 grill-me 之前根本没想过。比如"复用 admin/upload"------看起来省事，实际等于把管理员接口暴露给普通用户；还比如使用"contain vs cover"这样的设计细节，不得不让我佩服。
这就是 AI 通过 grill-me 这个SKILL 做的事情：把"加一张照片"这种看起来一个简单（线性）的需求，拆成一棵决策树。你不需要在写作时就想好所有分支，但你必须在编码前走过所有分支。 真正实现了，我们只需要提供"点子和想法"，让AI 来帮我实现的最后一块拼图，即将"点子和想法"转化成更加精确的描述，然后将其喂给AI。
协议 vs 剧本
到目前为止，我也写了不少 prompt、skill 指令，长篇大论，恨不得把每一步该说什么话都写进去。但越写到后面，越觉得这是在限制AI的能力。今天我算是看明白了，我之前写的是"剧本"，而grill-me中的内容是协议。
Grill-me 只有 5 条：
- "Interview me relentlessly..." --- 定调：追问模式
- "Walk down each branch of the design tree" --- 定方法：深度优先展开
- "Provide your recommended answer" --- 定立场：AI 要有自己的判断
- "Ask one at a time" --- 定节奏：一次一个问题
- "Explore the codebase instead" --- 定边界：先看代码再问
没有一条在教 AI "应该问什么"。它们全在约束 交互方式。这就是协议和剧本的区别。剧本告诉你每一句台词，协议告诉你游戏规则。
协议的代价
但我要说 grill-me 不完美的地方。
协议式交互有它的成本。还是上面提到的那个照片的任务，grill-me 启动时先探索了代码库------一口气烧了 56,524 个 token。原因是它说"为了避免提出已经实现的功能的问题"。
而且 11 个问题回答完，我已经精疲力竭，但这也算是代价吧，但我觉得这个代价是值得的。
需求的问题没有想清楚，后面积累的各种"债务"指不定会在什么时候爆发。
当然，并不是说让grill-me过了一遍需求后，生成的代码就会100%没问题-- 这是不可能的。即使经过了 grill-me 的 11 个问题洗礼，我在后续实现中依然踩了坑：数据库返回的 field_layouts 缺少 photo 字段导致页面显示不全。grill-me 能帮你扫清上游的设计盲区，但下游的执行细节还得自己盯，不过这些问题只能称之为bug，不是架构上和设计上的问题。
如果你还没用过 grill-me，去试试。不是为了用这个 skill，而是为了感受一下"协议式设计"和"剧本式设计"的差距有多大。