Batch Grill Me：把 13 轮拷问压成 3 轮

核心结论

Batch Grill Me 是 Grill Me 的提问节奏升级：它不再一次只问一题，而是按 design tree 的 frontier 分轮批量提问——前置条件已经定了的问题，同一轮一起问完。

它解决的不是「问题问得不够狠」，而是另一个更具体的失败模式：一次一问把人问废了。中等功能 20 到 50 题，回着回着你只会反复说 I agree。

Matt 给过一组很干净的数字：

同样 13 个问题，以前 13 轮，现在 3 轮。

如果你已经读过 Grill Me，这篇可以当成它的续篇：铁律还在，摩擦少了。

失败模式：一次一问会把人问废

/grill-me 确实管用。你说想加个评论功能，它不会立刻开写，而是先问：要不要登录？能不能匿名？删父评论时子评论怎么办？审核谁来做？这些问题一问出来，你就知道自己刚才那句需求有多糊。

但烦也是真的烦。

每题单独弹出来时，你的注意力被切得很碎。前 5 题还行，到第 15 题，你开始只想结束。推荐答案一出来，手指比脑子快，直接同意。表面上完成了 30 个决策，其实后半程很多是疲劳签字。

Matt 自己把这个失败模式说得很准：到后面你只会反复回一句 I agree。

他改的不是“少问”，是“怎么问”

很多人一听 batch，第一反应是：一次甩一堆问题，那不就乱了吗？

不是。

原来的 grill-me 有一条铁律：一次只问一题。原因也很合理，问题之间有依赖。你还没决定“要不要登录”，它就不该接着问“登录失败几次锁账号”。

batch-grill-me 没有把这条铁律扔掉。它只是换了节奏。

它还是先把方案看成一棵树。树根是上游决策，树枝是下游决策。每一轮，它只问当前已经能问的那一层，也就是 Matt 说的 frontier：前置条件已经定了、现在问还不需要猜你还没说的答案。

一轮里可能同时出现 5 到 8 个问题。你一口气答完。它根据你的回答重算树，再推下一层。依赖还没解开的问题，不会混进这一轮。

所以问题数量没有变少。变少的是来回次数。

Matt 后来还说，/grill-me 和 /grill-with-docs 也准备这么改，不再死守 one question at a time，而是按 rounds 问。更快，更省 token，但依赖关系还在。

源文件在这里：

frontier 到底是什么

以前我觉得 one-at-a-time 更认真。

现在回头看，它认真归认真，也有自己的坑。

Matt 改本地版本的时候，最先喜欢上的不是“更快”，而是另一种状态：

你可以一口气把答案说完。

这很像你真的在拍板，而不是在应付一场漫长口试。一轮里同时看到 6 个上游问题，反而更容易发现冲突。比如你一边说“游客也能评论”，一边又说“必须登录才能嵌套回复”，这两题放在一起时，矛盾会直接撞上；拆开一题一题问，反而容易漏。

还有一件小事，也比看起来重要：每题都要给推荐答案。

原版就有这句。batch 之后，它更值钱了。一轮问 8 题，如果每题都甩给你一个空白选择题，人会炸。有推荐答案，你才是在审核，不是从零发明。

拿“博客评论”走一遍

假设你要对 AI 说：给博客加评论。

原版常见路径是：

1. 谁能评论？
2. 要不要登录？
3. 要不要嵌套？
4. 要不要审核？
5. 要不要通知？

一题一回，稳，但慢。

按 batch 的逻辑，第一轮更像这样：

1. 评论到底服务什么？
   推荐：优先深度讨论，不追求热闹。
2. 谁可以发？
   推荐：登录用户可发，游客只读。
3. 扁平还是嵌套？
   推荐：先做一层回复，不做无限楼中楼。
4. 要不要审核？
   推荐：先发后审，敏感词拦一下，人工能删。
5. 多语言文章怎么处理评论？
   推荐：评论跟着文章语言走，不要中英串到同一条线程。
6. 第三方还是自建？
   推荐：先第三方，真有需求再自建。

这 6 题能放同一轮，因为它们大多是上游选择，彼此还没形成硬依赖。

下面这些问题就不该出现在第一轮：

• parent_id 能不能为空
  你都还没决定要不要嵌套。
• 审核队列的 webhook 怎么接
  你都还没决定审不审、谁来审。
• SSO 失败重试几次
  你都还没决定要不要登录。

第二轮才会轮到它们。

这就是 batch 和“一次甩 20 个大杂烩”的差别。后者是堆问题，前者是按依赖分层推进。

和原来比，到底差在哪

如果非要压成一句：

严格还在，摩擦少了。

什么时候用，什么时候别用

我现在会这么分。

你已经知道自己大概要做什么，只是细节很多，而且其中一部分问题彼此独立，用 batch。它适合那种“我不是完全没想法，我只是不想一题一回磨半小时”的状态。

你连树根都不确定，就别急着 batch。比如你还说不清这个功能到底解决谁的问题，或者你现在只想先抓住一个最大分歧，那一次一问，甚至先做 blind spot pass，可能更合适。我之前写 别急着让 AI 写代码，先让它帮你找盲点 时讲过：有些时候你缺的不是更快的提问，而是先承认自己不知道什么。

还有一种情况也不适合硬上 batch：决策高度耦合，几乎每题都挂在上一题上。这时强行并成一轮，看起来快，实际上你还是得回头改前面的答案。

怎么开始

现在这个 skill 还在 Matt 仓库的 in-progress 里。装法很直接：

npx skills add https://github.com/mattpocock/skills --skill batch-grill-me

然后：

/batch-grill-me

比较顺的用法是：

1. 先用一句话说清楚你要做什么。
   比如：“我想给博客加评论，还没定登录、审核和是否自建。”
2. 开 batch。
3. 第一轮认真看完再答，别整轮“都同意”。
4. 让它根据回答推下一轮。
5. 问完了，先确认共识，再去写 PRD 或动手。

两件小事值得记：

不要中途清 context。后面如果要压成 PRD，这些对话本身就是材料。

“你定”可以用，但只用在真不重要的题上。身份、数据边界、兼容策略，这些别随手甩给模型。

我现在怎么看这件事

以前我们总觉得，需求对齐的核心是“问得够不够狠”。

Grill Me 证明了：够狠很重要。AI 越能干，越不能让它替你猜产品决策。

batch 补上的是另一半：

够狠之后，过程别把自己耗死。

13 个问题还是 13 个问题。
只是不用再为了认真，硬生生走完 13 轮。

如果你已经会用 grill-me，最近最值得试的，未必是换一个更新的模型，而是换一种提问节奏。

上一篇：Grill Me：让 AI 在你写代码前拷问你 50 个问题

下一篇：Grill With Docs：维护项目语言和 ADR——grill-me 的进阶版，给有领域复杂度的项目用。