grill-me 可以理解成一个 “拷问式需求澄清 / 方案审查 skill”

它不是让 AI 直接写代码,而是让 AI 像一个很挑剔的技术负责人一样,不断追问你:

  • 这个需求到底要解决什么问题?

  • 哪些情况不做?

  • 边界条件是什么?

  • 有没有更简单的方案?

  • 现有代码里有没有类似实现?

  • 这个设计会不会引入复杂度?

  • 如果失败,怎么回滚?

  • 你是不是漏了权限、异常、并发、幂等、兼容性?

简单说:

grill-me = 在开工前拷问你的想法,防止 AI 带着模糊需求乱写代码。

它常见于 Claude Code skill 生态。比如 ClaudSkills 对它的描述是:在 PR 前做 adversarial review,让 Claude 提硬问题,直到方案经得起审查。Grill Me
Matt Pocock 版本的说明也强调,它会系统性追问你的设计、想法和边界,适合架构决策、产品规划、实现方案审查。Grill Me Skill

一、先理解 grill-me 适合干什么

它最适合三类场景:

场景

用法

需求还模糊

让它追问你,把需求问清楚

方案不确定

让它挑战你的设计,看看有没有漏洞

准备让 AI 开写代码前

让它先审查需求和方案,避免后面返工

比如 Java Web 里这些任务就很适合:

任务

grill-me 会追问什么

做登录功能

token 怎么过期?是否支持刷新?失败次数限制?

做支付回调

如何保证幂等?重复通知怎么办?签名失败怎么办?

做订单状态流转

状态机规则是什么?非法状态怎么处理?并发修改怎么办?

做权限系统

RBAC 还是 ABAC?接口级权限还是数据级权限?

做缓存

缓存 key 怎么设计?失效策略是什么?脏数据怎么办?

二、grill-me 和 brainstorming 的区别

它和头脑风暴有点像,但味道不一样。

对比

brainstorming

grill-me

目的

帮你发散和成型想法

挑刺、拷问、找漏洞

语气

合作式讨论

审查式追问

重点

“我们可以怎么做?”

“这个方案哪里会坏?”

适合阶段

需求刚开始

准备定方案前

产物

初步设计

经得起质疑的决策记录

所以它们可以这样配合:

brainstorming:先把想法展开
grill-me:再把方案拷打一遍
plan:最后写实现计划

三、推荐学习路线

你可以按 4 步学。

第一步:先拿小需求练

不要一上来拿大系统练,先用一个小功能。

比如:

Use grill-me to challenge this idea:

我要在 Java Web 项目里新增一个用户注册接口。
要求支持手机号、验证码和密码。
请你先不要写代码,只追问我需求和边界。
一次只问一个问题。

你会发现它会追问很多你原来没想清楚的东西,比如:

问题方向

示例

账号规则

手机号是否唯一?是否允许注销后重新注册?

验证码

验证码有效期多久?错误次数限制?

密码

密码强度要求?是否加密存储?

返回格式

注册成功返回什么?是否自动登录?

异常

手机号重复、验证码错误、验证码过期分别返回什么?

安全

是否需要限流?是否需要防刷?

第二步:要求它输出决策记录

问完之后,不要直接让它写代码,而是让它总结:

请把刚才确认过的内容整理成决策记录,分成:
1. 已确认需求
2. 不做的范围
3. 风险点
4. 待确认问题
5. 推荐实现方案

这样 grill-me 的价值才会沉淀下来。

第三步:把结果转成 PRD 或 Trellis Task

如果你用 Trellis,可以让它进一步变成任务文档:

把上面的 grill-me 结果整理成 Trellis task 的 prd.md。
要求包含 Goal、Requirements、Acceptance Criteria、Out of Scope、Technical Notes。

这样就很顺:

flowchart TD A[初始想法] --> B[grill-me 追问边界] B --> C[形成决策记录] C --> D[生成 PRD / Trellis Task] D --> E[写实现计划] E --> F[AI 开始编码]

第四步:开工前再 grill 一次方案

当 AI 写完实现计划后,再让 grill-me 审一遍:

Use grill-me to review this implementation plan.
Focus on missing edge cases, wrong assumptions, over-engineering, transaction boundaries, idempotency, and test gaps.
Do not implement anything.

Java Web 里尤其要让它检查这些:

检查点

说明

事务边界

@Transactional 是否应该在 Service 层

幂等性

支付、订单、消息消费是否可重复执行

并发问题

库存扣减、状态流转是否有并发风险

异常处理

是否走统一异常处理

返回结构

是否符合 ApiResponse<T>

数据对象

是否混用了 Entity、DTO、VO

测试缺口

是否覆盖成功、失败、边界、重复请求

四、日常使用模板

以后你可以直接这样用:

Use grill-me.

我要做:xxx

项目背景:这是一个 Java Web 项目,使用 Spring Boot + MyBatis。
请你先不要写代码。
先审查这个需求是否清楚。
一次只问一个问题。
每个问题都给出你的推荐答案。
最后整理成需求决策记录。

如果是审查方案:

Use grill-me to challenge this plan.

计划如下:
xxx

请重点检查:
1. 是否遗漏边界条件
2. 是否违反分层设计
3. 是否有事务、并发、幂等问题
4. 是否有测试缺口
5. 是否有更简单的实现方式

不要写代码,只做审查。

五、什么时候不要用 grill-me

不是所有任务都要用。

不适合

原因

改错别字

太重

改一个样式

太重

修一个明确的小 bug

可以直接 systematic debugging

已经有非常明确的 PRD

可以直接 plan 或 implement

临时脚本

没必要拷问太久

适合用在:

适合

原因

新功能设计

容易漏边界

架构调整

决策影响大

支付、订单、权限

风险高

重构前

需要明确不破坏什么

写 Trellis Spec 前

可以帮你抽出项目规则

总结

学习 grill-me 不要把它当成“写代码工具”,而要把它当成:

需求评审 + 方案审查 + 边界条件挖掘工具。

最推荐的使用方式是:

想法 → grill-me 拷问 → 决策记录 → PRD / Task → 实现计划 → 编码

如果你结合 Trellis,它的位置大概是:

grill-me 负责把想法问清楚
Trellis 负责把结果沉淀成 task/spec/workspace
Codex/Claude 负责根据 task/spec 去实现

一句话:grill-me 不是让 AI 更快开工,而是让 AI 不要在错误方向上开工。