我一直在好几个真实项目里用 Claude Code、Cursor 这类 AI 编码代理。过去三个月,模型确实在不断变强,但对我帮助最大的反而是 /grill-me 这个 skill。它会在你动手之前,不断拷问你,帮你省掉很多写一版、再改一版的循环。

为什么需要「被拷问」?

平时的用法是我们把需求丢给 AI:描述功能、举例子、列边界情况。AI 点头答应,写起来才发现它根本没理解——漏了业务约束、跟现有架构对不上,或者把复杂度想简单了。然后就开始来回改,token 和时间都烧掉了。

/grill-me 把方向反过来了:AI 来提问,沿着决策树一个分支一个分支往下走,直到双方对计划有共识。核心指令就这几行:

---
name: grilling
description: Interview the user relentlessly about a plan or design. Use when the user wants to stress-test a plan before building, or uses any 'grill' trigger phrases.
---

Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.

Ask the questions one at a time, waiting for feedback on each question before continuing. Asking multiple questions at once is bewildering.

If a question can be answered by exploring the codebase, explore the codebase instead.

它逼你把那些没说出口的假设摊开,风险也会提前冒出来。

快速上手

在项目目录运行:

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

然后在 coding agent 里输入 /grill-me 加上你的初步计划。

真实项目里怎么用

用法很简单:/grill-me 加上你的需求描述。注意,代理不会对着空白文档连环发问——它会先读代码库,边探索边提问。我喜欢配合 Cursor 的 Plan Mode 使用,先通过 /grill-me 构建一个计划然后再实现计划。

下面两个例子来自同一个多租户中后台项目,一个做新功能,一个改老逻辑。

新功能:批量导入

最初想法:加个批量导入,支持 Excel 和 API。
直接扔给 AI,第一版就翻车——审计日志没考虑、事务一致性没想清楚、配额和大文件处理也漏了。

换成 /grill-me 后,代理先翻了现有导入模块和权限模型,然后才开口:

「批量导入是谁触发的?手动上传、定时任务,还是第三方 webhook?」答完接着问:「成功和失败怎么通知?要不要异步?失败重试几次?」每答一个,它会给推荐方案,并确认依赖,比如「这会动到现有权限模型吗?」

几轮下来,功能边界清楚了,跟领域模型的冲突也提前暴露(比如 materialization cascade)。最终实现基本一次过。

已有功能迭代:订单支持部分取消

这次是改一条老链路:已发货订单原先只能整单取消,产品要求支持部分取消。

代理没有先写方案。它顺着 OrderService 的状态机往下追,发现取消会触发退款、库存回滚和仓库 webhook;又追到 PromoEngine,看到满减是按整单算的。然后才开始问:

  • 部分取消后,满减要不要重算?代码里三种算法,注释只写了『按运营规则』——你定哪一种?
  • 混合支付(余额 + 微信)时,退款按什么比例拆?现有 RefundService 只处理整单,没有部分退的路径。
  • 仓库 webhook 是 fire-and-forget,没有幂等键。部分取消如果重试,会不会重复通知?

这些问题里,有些能从代码推断出推荐答案;有些连开发都说不准!历史上运营改过口径,文档没更新。这种场景只能拉业务确认,有时候你自己做不了决定,AI 更替你做不了决定,这种情况下的决定往往是错的。grill-me 的价值恰恰是把它们提前拎出来,而不是写完了才发现。

如果直接改,我大概率只会动 OrderService 的状态判断,漏掉 bundle 重算、混合支付拆账和 webhook 幂等。上线后就是「取消成功但退款不对」或者「仓库收到两次取消通知」这类 bug。grill-me 逼我把这些分支走一遍,该写 ADR 的写 ADR,该找运营确认的当场记下来。改完跑回归,没有冒出新的边角问题。

修遗留 bug

我仍然这么用!先 grill-me + plan mode 代理先复现代码路径,再问你影响范围和回归点,少踩修好一个冒出三个的坑。

流程长什么样

flowchart TD A["Idea / 初步计划"] --> B["grill-me + 需求描述"] B --> C{"已有代码库?"} C -->|是| D["先读代码库,可选 grill-with-docs"] C -->|否| E["从领域约束出发"] D --> F["沿决策树逐分支探索"] E --> F F --> G["一次只问一个问题"] G --> H{"问题可由 codebase 回答?"} H -->|是| I["AI 探索代码上下文并给出推荐"] H -->|否| J{"开发或 AI 能拍板?"} J -->|是| K["用户回答 + AI 推荐方案"] J -->|否| L["记录待确认项,拉业务确认"] I --> M["确认该分支决策"] K --> M L --> M M --> N{"决策树还有未收敛分支?"} N -->|是| F N -->|否| O["达成共享理解"] O --> P["更新 CONTEXT.md 或 ADR"] P --> Q["Plan Mode 制定实现计划"] Q --> R["tdd 或 implement 等后续 skill"] R --> S["回归验证"] S --> T["持续优化或新 idea"] T --> A

对齐放在实现前面,形成一个闭环。如果项目已经有代码库,可以用 grill-with-docs,边问边把 ubiquitous language 和 ADR 建起来。

为什么这三个月它一直在用

最大的感受是少返工。很多误解在写代码之前就暴露了,不用等到实现阶段才发现。对话本身也能沉淀成文档,后面查起来方便。而且这个 skill 不绑特定模型,换代理、团队共享都省事。它逼我自己想清楚,而不是把坑留给 AI 去填。用久了,这点比省下来的 token 更值。

Matt Pocock 的 skills 仓库整体偏向真实工程,不是 vibe coding。grill-me 核心就几行,但能跟别的 skill 组合着用,这点我挺喜欢。

grill-me 和 superpowers 那些工具有什么不同

我试过不少 AI 增强工具,包括各种 superpowers 插件——预设模板多、自动化流程全、领域知识也齐。grill-me 不一样,它不替你定方案,而是把你的意图和约束挖出来。复杂、定制化的项目里,这点特别管用。

superpowers 适合快速套模式,比如某个框架的最佳实践。grill-me 更像元技能:先想清楚问题,再决定用什么模式。我自己加上 frontend-design 或 review 这几个 skill 就够用了,不用堆一堆配置。

跟仅仅使用 Plan Mode 比,grill-me 更主动。它不会一次吐一篇长计划,而是一个问题一个问题地问,确认完再往下走。

有什么不好?

我发现有些模型追问过细,这也并没有什么不好。

总结

如果你也被 AI 编码里的反复迭代搞烦了,可以试试,它会让你想得更清楚。这三个月它帮我绕了不少弯路,包括迭代核心业务代码也让我更有信心。

试试吧,有奇效!

相关链接


原文地址: http://www.cveoy.top/t/topic/qGWV 著作权归作者所有。请勿转载和采集!

免费AI点我,无需注册和登录