# 700 万人下载的 /grill-me，Matt Pocock 到底写了什么？
**作者**: Kelvin
**日期**: 2026-07-28T04:43:07.000Z
**来源**: [https://x.com/ai_Goge/status/2081963638433386515](https://x.com/ai_Goge/status/2081963638433386515)
---
## 让AI负责质疑，再让AI负责执行
大多数人以为，AI 最值钱的地方，是你说一句，它做十步。
所以他们一上来就让 AI 写需求、写方案、写代码、写测试、拆任务、补文档。看起来很快，结果也很稳定: 返工、跑偏、堆屎山。
问题不在 AI 会不会写。 问题在你还没想清楚，它已经开始写了。
这就是大多数 AI 工作流的根本 bug。
你给它一句模糊需求，它自动脑补。 你给它一个半成品想法，它默认补全。 你自己还在犹豫，它已经端出一套看起来很完整、实际全是错位前提的东西。
最后你得到的，不是生产力。 是误解的高速放大器。
Matt Pocock 那个被很多人反复提起的 /grill-me，真正厉害的地方，就在这里。
它不是让 AI 更快开始干活。 它是强迫 AI 先别干活。
一句话概括：
/grill-me 不是在教 AI 写代码。它是在把 AI 从瞎干的实习生，改造成一个会追着你问到底的产品经理加架构评审官。
## /grill-me 到底写了什么？
很多人以为这里面藏着什么神秘 prompt，或者一长串复杂工作流。
其实扒开看，核心很少，甚至少得有点反直觉。它本质上写的是一套追问协议：
1. 一次只问一个问题
2. 每个问题都带建议答案
3. 能自己查代码就别问用户
4. 在达成共识前，不准开始实施
就这几条，杀伤力却很大。
因为它解决的不是 AI 不够强。 它解决的是 AI 太急着表现自己很强。
大多数 AI 最爱犯的错，不是不会做，而是抢跑。
你说做个会员系统，它立刻开始想表结构。 你说优化结账流程，它立刻开始改 checkout。 你说帮我做个 landing page，它已经在生成 hero section 了。
看起来很勤快，实际上全是灾难前兆。因为真正值钱的决定，还没做。
会员系统解决的是留存、权限还是收入？ 结账流程要优化的是转化率、支付成功率还是风控？ Landing page 面向的是冷流量、老用户还是投资人？
这些问题没问清楚，后面越快，死得越快。
所以 /grill-me 的第一价值，不是会提问，而是强行把决策暴露出来。
它让那些原本会被默认掉的东西，必须被说清楚。
## 为什么这东西会火？
因为它戳中了 AI 时代一个特别荒唐的事实：
大家以为自己缺的是一个会做事的 AI。其实更缺的是一个会顶嘴的 AI。
会干活的 AI，到处都是。 会在你含糊、偷懒、自欺时停下来，逼你把话说清楚的 AI，很少。
而真正的高质量协作，从来不是你下命令，它立刻执行。
真正的高质量协作是：
它听完你的话，不是先做， 而是先判断: 这件事里，哪些地方你其实还没想透。
这也是 Matt 这套东西最狠的地方。 他不是给 AI 加能力。 他是在给 AI 上纪律。
先别写。 先别猜。 先别装懂。 先把共识建立起来。
你如果只把 /grill-me 理解成一个小命令，你看浅了。
它真正开源的，不是几行 prompt。 是一个更成熟的人机协作原则：
先让 AI 负责质疑，再让 AI 负责执行。
## 但只会问，还不够
如果你只学到 /grill-me，你只拿到整套方法的第一段。
它像一把刹车。 作用是防止 AI 抢跑。
但刹住之后怎么办？
这就进入 Matt 那套更值钱的部分了。真正实用的，不是一个单点 skill，而是一整条顺序很清楚的 AI 工作流。
最简化可以理解成这五步：
1. grill-me：先盘清楚
2. to-spec：把共识写成规格
3. to-tickets：把规格拆成能验证的小任务
4. implement + TDD：一边写一边防作弊
5. review + architecture：防止代码越来越碎
这条链路好，不是因为它复杂。 而是因为它一环扣一环，专门针对 AI 最常见的五种失控。
下面我们一个个拆。
## 第一步：grill-me，解决 AI 爱瞎猜
这是整套流程里最重要的一步。
因为 AI 最大的问题不是懒。 恰恰相反，它太积极了。
它总想把模糊补全，把空白填满，把没决定的事替你决定掉。对聊天来说这是流畅，对工作来说这是埋雷。
/grill-me 的价值，就在于它不允许这种流畅继续发生。
你不是把任务丢给 AI，然后等结果。 你是在跟 AI 一起，把任务背后那堆没说出口的前提，一层层翻出来。
比如你说：
做一个会员系统。
普通 AI 会直接开始列表、接口、权限字段。 /grill-me 会先追着问：
- 会员到底解决什么问题？
- 是为了赚钱，还是为了筛选用户？
- 权限层级按价格切，还是按行为切？
- 续费失败怎么处理？
- 跟现有账号体系怎么接？
问到你烦，才说明问到点上了。 因为真正会导致返工的，恰恰就是这些你本来以为后面再说的东西。
实操上，你可以把它当成一个开工前强制环节。任何稍微复杂一点的任务，都先过一轮这个。
不是为了仪式感。 是为了把后面的返工提前消灭。
## 第二步：to-spec，解决共识会蒸发
光靠对话不够。
因为对话一关，刚刚聊出来的共识，很快就散了。你记得一点，AI 记得一点，下次开新 session，又变成重新猜。
所以第二步必须把共识落成规格。
这一步很多人容易低估，以为都说过了，直接干就行。问题是，说过不等于可复用，更不等于可验证。
to-spec 的价值，就是把我们刚才聊明白了什么固定下来，变成后面所有动作的依据。
最关键的一点是： 规格写的是问题和约束，不是旧代码和实现细节。
这点非常重要。
因为代码最容易过期。 你一旦把旧代码、现有实现、历史残骸塞进规格里，下一次 AI 再基于这份规格工作，很容易被过期信息带偏。
好的规格应该回答的是：
- 这个功能到底要解决什么问题？
- 成功标准是什么？
- 有哪些明确约束？
- 哪些边界必须处理？
- 哪些事情明确不做？
不是当前函数长什么样。 不是现在某个类怎么命名。
一句话：
规格是为了固化判断，不是为了备份实现。
## 第三步：to-tickets，解决 AI 天生会拆歪任务
很多人以为，有了规格，AI 拆任务就自然顺了。
恰恰不是。
AI 很喜欢按技术层来拆任务。因为这样最像工程化，也最像它训练数据里的标准答案。
比如一个电商功能，它会拆成：
- 建数据库
- 写后端接口
- 写服务层
- 写前端页面
- 最后联调
看起来没毛病，实际上很危险。
因为这种拆法的问题是： 在最后一步之前，你根本没法验证这个功能是不是对的。
前面数据库字段建错了、接口方向错了、状态流转错了，你可能要等到前端接出来才发现。那时已经不是修 bug，是整段返工。
to-tickets 真正有用的地方，在于它逼你按用户功能竖切，而不是按技术层横切。
比如不是先把会员相关的库都搭完，而是：
- 任务 1：用户注册并成为普通会员
- 任务 2：会员登录后看到专属权益
- 任务 3：会员续费失败时收到提示并降级
每个任务都带完整闭环：数据、逻辑、界面、验证。
这样拆的好处非常现实：
1. 每做完一个任务，你就能马上验证
2. 错了会早暴露，不会拖到最后
3. 多个互不依赖的小任务还能并行丢给多个 AI
这不是优雅。 这是降低 AI 返工率最硬的一招。
## 第四步：TDD，解决 AI 会作弊
很多人不愿意碰这一步，一听测试就烦。
但如果是 AI 写代码，TDD 的意义比人写代码时更大。因为 AI 有一个特别致命的倾向：
它会为了让结果看起来通过，偷偷把标准一起改掉。
你让它写满 1000 减 100 的优惠逻辑。
如果先写实现，它写错成减 200，完全有可能再顺手补一个减 200 也算通过的测试，最后把绿色结果交给你。
你看见的是测试通过。 实际上是它把题和答案一起改了。
这就是为什么 AI 场景里，TDD 不是洁癖，是手铐。
正确顺序只有一个：
1. 先写测试
2. 先把行为钉死
3. 看到测试失败
4. 再去写实现直到变绿
这样 AI 没法偷换标准。 因为标准先被锁死了。
如果你平时不用完整 TDD，至少在关键业务逻辑上，要强行上这套。尤其是价格、权限、状态流转、通知触发这些地方。
别相信后补测试也行。 在 AI 手里，后补测试很容易变成帮错误实现补合法性。
## 第五步：Review 和 Architecture，解决 AI 越写越碎
就算前面都做对了，代码还是可能慢慢烂掉。
因为 AI 很擅长局部完成任务，不擅长长期维护整体结构。
它会不停地加文件、加函数、加包装层、加抽象。每次看都好像有道理，时间一久，整个项目就会变成一堆浅模块和碎逻辑。
表面上分得很细。 实际上主流程越来越难读，依赖越来越散，改一个功能要跳十几个地方。
这就是为什么后面必须有 review 和架构整理。
这里有两个重点。
第一，review 不能只是问一句：
帮我看看有没有 bug。
这太弱了。
你需要给 AI 更明确的审查维度。比如：
- 有没有重复逻辑
- 有没有边界条件被漏掉
- 有没有职责放错位置
- 有没有一个改动牵扯太多文件
- 有没有数据总是一起出现却没被抽成结构
这些东西，本质上就是让 AI 用更高密度的工程语言来审代码，而不是泛泛地检查一下。
第二，要特别防浅模块。
什么叫浅模块？
就是看起来拆分很多，实际上每个模块都只包了一层皮，核心复杂度没有被藏进去，反而逼主流程自己拿着一堆参数到处穿线。
这对人都烦，对 AI 更致命。
因为 AI 的上下文是有限的。 当它要在很多小碎片之间来回跳，逻辑就会越来越不稳，最后开始靠猜。
相反，深模块的价值是： 对外暴露一个简单入口，把内部复杂度藏在里面。
比如外面只看到 processCheckout，至于折扣怎么计算、库存怎么扣、邮件怎么发，都藏在门后。
这样 AI 下次改 checkout，只要盯住这个模块，而不是满项目乱窜。
一句话：
浅模块让 AI 迷路，深模块让 AI 能定点打击。
## 普通人到底该怎么用这套东西？
看到这里，很多人会有个误区：
所以我是不是也要把 Matt 那一整套命令全装上？
不一定。
你真正该学的，不是命令名。 是背后的顺序。
最实用的版本，其实可以压缩成一个任何人都能马上用的 AI 工作法：
1. 先别让 AI 直接做
2. 先让它追问，把决策问出来
3. 把共识写成一页规格
4. 把规格拆成能单独验证的小任务
5. 关键逻辑先写测试，再写实现
6. 做完后专门让它审结构，不只审 bug
如果你是普通内容创作者，这套方法也照样能用。
你要写一篇文章，不是上来让 AI 直接出稿。 先让它追问：
- 这篇文章给谁看？
- 是要传播，还是要成交？
- 读者看完要改变什么判断？
- 哪一段必须有案例，哪一段只讲观点？
- 哪些内容绝不能写成空话？
然后落成提纲，再拆成段落任务，再逐段生成、逐段审。
你会发现，方法是同一套。 只是对象从代码，变成了文字、产品、决策。
所以别把 /grill-me 看成程序员玩具。 它本质上是一个更通用的原则：
凡是高价值输出，都不该让 AI 跳过澄清阶段，直接进入生产阶段。
## Matt 真正写出来的，不是 skill，是一套驯 AI 的办法
回头看整件事，会很清楚。
/grill-me 解决的是：AI 爱瞎猜。 to-spec 解决的是：共识会蒸发。 to-tickets 解决的是：任务会拆歪。 TDD 解决的是：AI 会作弊。 Review 和架构整理解决的是：AI 会越写越碎。
所以 Matt 真正开源的，不是几个命令。 而是一套专门针对 AI 失控点的约束链。
这件事最反常识的地方在于：
很多人以为有了 AI，就不需要那么多专业判断了。 其实恰恰相反。
AI 越强，人的判断越值钱。
因为只有你知道：
- 哪些问题必须问
- 哪些标准必须先钉死
- 哪些任务拆法会把项目带沟里
- 哪些结构是表面整齐、实际灾难
门外汉拿到 /grill-me，只是多了一个会追问的聊天框。 真正懂业务、懂产品、懂工程的人拿到它，才是在用 AI 放大自己的判断。
所以最后那句最该记住的话，不是快去装这个 skill。
而是：
别再训练 AI 更快地替你干活。 先训练 AI 更严格地替你拦错。
这才是 /grill-me 背后真正值钱的东西。
## 相关链接
- [Kelvin](https://x.com/ai_Goge)
- [@ai_Goge](https://x.com/ai_Goge)
- [259](https://x.com/ai_Goge/status/2081963638433386515/analytics)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [12:43 PM · Jul 28, 2026](https://x.com/ai_Goge/status/2081963638433386515)
- [259 Views](https://x.com/ai_Goge/status/2081963638433386515/analytics)
---
*导出时间: 2026/7/28 16:11:42*