说真的，@mattpocockuk 的 grill-me，应该是我使用频率最高，同时也觉得最有用的 Skill 之一。我在做产品和技术设计时，经常用它来检查，还有哪些地方没有真正想清楚。
从模糊的不满开始
很多时候，大的交互框架、产品流程和技术方向已经比较明确了。往下落到细节，却会发现还有不少模糊的地方。
有些是自己遗漏的，有些之前压根没想到。还有一种情况更常见：AI 已经给出了方案，甚至做出了 Mock UI，我看完却总觉得不太对。麻烦就在这里，我知道自己不满意，却很难立刻说清楚到底哪里有问题，以及我真正想要的是什么。
这时候我通常会先把目前的想法、目标和已有方案告诉 Agent，然后直接来一句：“grill me”。接下来，Agent 就会开始不断盘问我。
它会沿着设计中的一个个分支继续往下问，把那些原本模糊的地方一点点挖出来：这个功能到底解决什么问题？这个状态应该怎么处理？用户为什么要在这里做这个动作？两种方案之间，你真正看重的是什么？
很多问题，我其实从来没有认真想过。但在一轮轮回答这些问题的过程中，脑子里原本只是一个模糊的感觉，会慢慢变成具体的产品决策。有时候，缺的不是 AI 再给你一个方案，而是有人不断追问，帮你把自己真正想要的东西想明白。
我通常不会一上来就 grill
我更愿意把 grill-me 当成一次 Review，而不是让 AI 从零开始替我设计。
做产品设计时，我一般会先把需求、目标和自己已经想好的交互逻辑描述给 Agent，让它先做一版 Mock UI。我比较常用 Claude，这方面的效果相对好一些。
拿到原型之后，我还会继续聊几轮，先处理那些一眼就能看出有问题、自己也很清楚应该怎么改的地方。等整个方案基本成形之后，我才会开始 grill-me。
原因很简单：自己设计交互时，最容易想到的往往是那条“正常路径”。用户按照我们的预期理解产品，按照预期顺序操作，设备正常，网络正常，也没有做什么意料之外的事情。但真实用户显然不会永远这样使用。
不同的人有不同的理解方式、操作习惯和注意力，设备、网络、权限、数据状态也可能完全不同。很多边界情况，在最开始设计的时候，很难一次性考虑完整。所以，我会先把方案做成一个相对完整的版本，再让另一个视角来 Review。
把 grill-me 当成一次评审会
你可以把它想象成一次产品评审会：你拿出了一个相对完整的方案，团队里的其他人开始不断提问：
- 这里如果用户这样操作怎么办？
- 这个状态有没有考虑？
- 为什么一定要这样设计？
- 如果前一步没有完成呢？
- 如果网络中断呢？
- 两个状态同时出现怎么办？
这些问题未必都会改变你的方案，但它们会迫使你重新检查那些默认成立、却从来没有认真验证过的假设。这也是我觉得 grill-me 最有价值的地方：它不急着替你做决定，而是把你没有检查过的地方暴露出来。
产品之外，技术设计也一样
技术设计和程序设计也是一样。一个程序员能想到多少异常路径、边界条件和潜在风险，很大程度上和经验有关。很多技术方案在主流程上没有问题，真正容易出问题的地方，往往藏在失败路径、状态切换、并发、重试、兼容性和各种极端情况下。
在技术场景里，grill-me 很像一次技术方案评审。让“另一个团队成员”站在不同角度不断提出问题，再根据这些问题去完善设计。
它可以追问：
- 请求失败之后，状态会停在哪里？
- 重试是否会造成重复写入？
- 两个操作同时发生时，谁拥有最终状态？
- 旧版本数据进入新逻辑后，会不会走到没有处理的分支？
- 权限、网络或依赖服务变化时，系统还能不能给用户一个清楚的结果？
这些问题不一定都要解决。有些场景发生概率极低，有些即使发生了影响也很小，还有些只是过度设计，直接跳过或者忽略就可以。重点是把那些自己原本没有意识到，同时又确实重要的问题找出来。
不需要把它当成固定流程
grill-me 并不需要局限在某一种固定流程里。你可以 grill with doc，也可以直接 grill based on context。只要你觉得现在需要另一个视角来帮自己 Review、完善设计，或者一起把一个模糊的问题梳理清楚，都可以用这种方式。
甚至不一定需要安装这个 Skill。完全可以把这种思路直接写进 CLAUDE.md 或 AGENTS.md：当方案已经形成时，从另一个视角主动提出问题，检查遗漏的边界情况、隐含假设和潜在风险，并重点关注你真正关心的维度。
当然，AI 提出来的问题不需要全部照单全收。Review 的价值不在于问题越多越好，而在于能不能让你发现真正值得处理的遗漏。我觉得 grill-me 给我最大的启发就是：AI 不只可以帮我们生成方案，也可以成为那个专门负责挑问题、做 Review 的人。
相关分享：