一个 11 行 Skill，为什么能把方案拷问得更靠谱

短大纲

• grill-me 的核心不是“问更多问题”，而是逼方案走完整个决策树
• 它最可取的地方：单问推进、推荐答案、先查证再发问
• grill-with-docs 把追问从“聊清楚”推进到“写清楚”：术语进 CONTEXT.md，重大取舍进 ADR
• 它适合用来做方案预审、设计复盘、任务拆解和自我校准
• 它也有短板：太短，缺少退出标准、问题分类和产物模板
• 最好的用法：把它当作设计评审前的陪练，而不是替代评审

一、好方案不是写出来的，是被问出来的

很多技术方案第一次写出来时，都有一种“看上去很完整”的错觉。

标题有了，背景有了，架构图也有了，甚至连“风险与应对”都写了三条。可是真到评审会上，架构师一句“失败重试时幂等怎么保证”，测试同学一句“灰度期间新老数据怎么兼容”，运维同学一句“这个开关谁来回滚”，方案就开始像没打结的鞋带，越走越散。

这不是写方案的人不努力。很多时候是因为我们太熟悉自己的答案，反而忘了追问自己的假设。grill-me 这个 skill 的价值就在这里：它把 AI 从“帮我润色方案”的秘书角色，推到了“别让我轻易过关”的陪练角色。

源文件很短，短到可以完整贴出来：

---
name: grill-me
description: Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
---

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.

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

只有 11 行，但味道很正。它没有堆一堆大词，也没有设计复杂流程。它抓住了设计讨论里最关键的动作：沿着决策树，一次只追问一个未闭合的问题。

二、它有哪些可取之处

1. 它把 AI 变成“拷问者”，不是“捧哏”

很多人用 AI 写方案，默认姿势是：

帮我优化一下这个设计。

AI 通常会很礼貌，先夸两句“整体思路清晰”，再补几条“可考虑增加监控和回滚机制”。听起来没错，但价值有限。因为它还是在顺着你的思路往前走。

grill-me 的第一句就把姿势改了：

Interview me relentlessly about every aspect of this plan...

关键词是 relentlessly。不是“随便问问”，而是“不轻易放过”。这很像一个认真负责的技术评审人：不急着给结论，先把假设、依赖、边界、失败路径、回滚路径一层层问出来。

技术方案最怕的不是别人反对，而是没人认真反对。没人反对的方案，常常不是无懈可击，而是大家都没看懂。

2. 它要求走完整个决策树

这句也很关键：

Walk down each branch of the design tree, resolving dependencies between decisions one-by-one.

一个方案不是一堆独立选择题，而是一棵决策树。

比如你设计一个异步任务系统：

• 先决定任务状态模型，才知道失败重试怎么做
• 先决定幂等键，才知道重复提交怎么处理
• 先决定存储边界，才知道查询和清理策略怎么设计
• 先决定谁拥有任务生命周期，才知道权限和审计放在哪里

很多评审之所以聊散，是因为大家在不同树枝上跳来跳去。前一分钟讨论数据库索引，后一分钟讨论 UI 展示，再后一分钟讨论告警阈值。每个问题都重要，但依赖关系没理清，最后就像开了十个浏览器标签页，哪个都没关。

grill-me 要求“沿着树枝走”，这点很工程化。它不是要问得多，而是要问得有路径。

3. 它要求每个问题附带推荐答案

这条很容易被忽略：

For each question, provide your recommended answer.

这比单纯提问高级很多。

普通提问容易把压力扔回给用户：“你觉得怎么做？”这当然没错，但如果 AI 每次只问不建议，用户会很快疲劳。好的陪练应该像一个有经验的同事：先指出问题，再给一个默认推荐，让你有东西可以同意、反驳或修正。

例如它不应该只问：

失败重试怎么处理？

更好的问法是：

失败重试是否需要区分可重试错误和不可重试错误？我的建议是先定义错误分类：网络超时、下游限流走指数退避重试；参数错误、权限错误直接失败并记录原因。你这个场景是否有例外？

这类问题才会推动方案前进。用户不用从零开始想，而是在一个可讨论的默认答案上做判断。

4. 它一次只问一个问题

Ask the questions one at a time.

这一句看起来朴素，其实非常重要。很多 AI 评审方案喜欢一次抛出十几个问题：

• 数据模型是什么？
• 如何保证一致性？
• 怎么做权限？
• 灰度怎么做？
• 如何监控？
• 失败怎么恢复？
• SLA 是多少？

看起来很全面，实际效果像领导在群里连发十条“你看一下”。人脑会自动进入防御模式：先挑容易的答，难的以后再说。然后“以后”一般就没有以后了。

一次一个问题，才有对话。一个问题被回答、澄清、确认，再进入下一个问题。节奏慢一点，但质量高很多。方案设计里，慢就是快。上线之后再补作业，那才是真的慢。

5. 它要求能查代码就别问人

最后一句是我最喜欢的：

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

这句话很像一个成熟工程师的基本礼貌：别把可以自己查的信息丢给别人。

如果问题是“项目里现在用 MyBatis 还是 JPA”，那应该看代码，不该问用户。如果问题是“现有权限模型怎么表达资源所有权”，也应该先查 Controller、Service、Mapper 和测试。只有查不到，或者需要业务取舍时，才问人。

这条约束把 grill-me 从“聊天机器人”往“工程助手”推了一步。它提醒 AI：提问不是偷懒，提问前要先做功课。

三、grill-with-docs：把追问接到文档和领域模型上

如果说 grill-me 是一个“设计陪练”，那 grill-with-docs 就更像一个“带着项目档案来的设计陪练”。

它保留了 grill-me 的主干：

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.

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

但它往后加了一大块 supporting-info，重点不是“多问几个问题”，而是把追问和项目里的领域语言、代码现实、文档沉淀绑在一起。

1. 它把“术语一致性”放到了第一等公民

grill-with-docs 要求 AI 在探索代码库时寻找 CONTEXT.md、CONTEXT-MAP.md 和 docs/adr/。这说明它默认一个成熟项目不只有代码，还有领域词汇和历史决策。

这点特别重要。

很多方案讨论吵半天，不是因为技术分歧，而是因为大家用同一个词讲不同的东西。一个人说 account 指公司账户，另一个人说 account 指登录账号；一个人说 cancel 指取消整单，另一个人说 cancel 指取消某个子项。会议越开越热闹，系统越改越危险。

grill-with-docs 明确要求：

When the user uses a term that conflicts with the existing language in CONTEXT.md, call it out immediately.

也就是说，只要用户的说法和既有术语冲突，AI 不能装没看见。它要当场指出来：

你的 glossary 里 cancellation 是整单取消，但你刚才说的是部分取消。到底哪个是对的？

这不是抬杠，这是救命。领域词汇一旦混乱，后面的 API、数据库字段、测试用例、监控指标都会跟着歪。

2. 它会主动“磨词”，把模糊语言变成标准语言

grill-with-docs 还有一条很实用：

When the user uses vague or overloaded terms, propose a precise canonical term.

这就是我常说的“磨词”。技术设计里，很多 bug 的种子就藏在模糊词里。

比如：

• “用户”到底是登录用户、企业成员，还是外部联系人？
• “订单”是购物车提交后的订单，还是支付成功后的履约单？
• “失败”是业务失败、系统失败，还是等待人工处理？
• “删除”是软删除、归档，还是物理删除？

这些词如果不在设计阶段磨清楚，后面就会变成代码里的 status = 3、type = 2、is_deleted = true。然后新人来了问一句“这个字段啥意思”，老员工开始望天。

grill-with-docs 的价值，是把“语言卫生”变成工作流的一部分。别小看这件事。大型系统不是被复杂算法拖垮的，很多是被混乱命名和隐含语义慢慢拖垮的。

3. 它要求用具体场景拷问领域边界

它还要求：

When domain relationships are being discussed, stress-test them with specific scenarios.

这比抽象讨论有效得多。

比如你在设计订阅系统，抽象地问“订阅和订单是什么关系”，大家可能都觉得懂。换成场景就不一样了：

• 用户买了年度订阅，中途升级套餐，原订单怎么处理？
• 企业管理员移除一个成员，成员已有的个人订阅算谁的？
• 支付成功但履约失败，订阅状态是 active 还是 pending？
• 退款后，历史发票、审计记录和权限如何处理？

场景一压上来，边界自然现形。很多“看起来没问题”的领域模型，经不起两个边缘场景。grill-with-docs 把这件事写进 skill，是很懂工程现场的。

4. 它会拿代码事实反驳你的口头理解

我最喜欢的是这一条：

When the user states how something works, check whether the code agrees.

这句话很扎心。因为很多老项目里，“大家以为系统是这样工作的”和“代码实际是这样工作的”，中间可能隔着三任同事、两次重构和一次线上事故。

grill-with-docs 要求 AI 发现矛盾就直接指出：

你刚说支持 partial cancellation，但代码里 cancelOrder() 会取消整个 Order。哪个才是当前事实？

这类问题听起来不太客气，但很有价值。方案设计不能只基于人的记忆。人的记忆会美化系统，代码不会。代码最多写得难看，但它诚实。

5. 它把对话结果沉淀到 CONTEXT.md 和 ADR

grill-me 最大的短板之一，是对话结束后产物不明确。grill-with-docs 在这方面补得很漂亮：

• 术语解决后，立即更新 CONTEXT.md
• CONTEXT.md 只做 glossary，不写实现细节
• 只有在“难逆转、没上下文会奇怪、确实有取舍”三条都满足时，才建议写 ADR

这三条 ADR 条件非常克制，我很喜欢：

1. Hard to reverse：以后改起来成本高
2. Surprising without context：未来读者会问“为什么这么干”
3. The result of a real trade-off：确实比较过替代方案

这避免了另一个常见毛病：什么都写 ADR。ADR 不是项目日记，也不是会议纪要。只有那些“未来的人如果不知道原因就会踩坑”的决定，才值得写进去。

6. 它适合什么场景

grill-with-docs 比 grill-me 更重一点，所以不要什么场景都上它。

我建议在这些情况下用：

• 项目已经有 CONTEXT.md、CONTEXT-MAP.md 或 ADR 体系
• 方案涉及领域模型变化，比如订单、账户、权限、计费、履约
• 团队里同一个词已经出现多种解释
• 代码事实和口头理解可能不一致
• 你希望评审过程顺手沉淀文档，而不是会后再补

如果只是个人想法、早期草稿、一次性小任务，用 grill-me 就够了。等方案进入项目语境、会影响术语和长期决策，再切到 grill-with-docs。

一句话：grill-me 负责把你问清楚，grill-with-docs 负责把项目也问清楚。

四、它有什么用

我认为这类 grilling skill 最适合放在四个场景里。早期用 grill-me，够轻；一旦问题进入项目语境，涉及既有术语、代码事实和长期决策，就换成 grill-with-docs。

1. 方案评审前的自检

在正式拉人评审前，先让 AI 拷问一轮。目标不是让 AI 批准你的方案，而是提前暴露那些会在会上被问爆的问题。

尤其适合这些方案：

• 涉及数据迁移、灰度、回滚
• 涉及权限、租户隔离、审计
• 涉及异步任务、消息队列、重试、幂等
• 涉及旧系统改造，隐性约定很多
• 涉及跨团队依赖，责任边界容易模糊

一句话：凡是“失败路径比成功路径更重要”的方案，都值得 grill 一下。

如果这类方案还涉及老系统的领域词汇，比如“订单”“账户”“租户”“成员”“订阅”这些容易一词多义的概念，就别只停留在聊天里。用 grill-with-docs 对照 CONTEXT.md 和 ADR，把词义和决策一起落下来。

2. 开发前的任务拆解

很多任务不是难在写代码，而是难在没拆清楚。

比如“支持批量导入用户”听起来是一个功能，其实里面有文件上传、格式校验、预览、异步执行、进度查询、错误报告、权限、审计、限流、重试。你不拆，它就会在开发中途自己裂开。

用 grill-me 可以让 AI 顺着设计树追问：

• 导入是同步还是异步？
• 文件最大多大？
• 错误是整批失败还是部分成功？
• 重复用户怎么处理？
• 谁能下载错误报告？
• 任务记录保留多久？

问完一轮，任务边界自然就清楚了。写代码前多问 30 分钟，常常能少修 3 天 bug。老程序员都懂，所谓经验，很多时候就是知道哪几个坑不能省。

3. 事故复盘后的改进设计

事故复盘最怕两种东西：一是“加强监控”，二是“提高意识”。这两句话不是没用，而是太容易变成墙上的标语。

如果你要把复盘结论落成改进方案，可以让 grill-me 追问：

• 这次事故的触发条件是什么？
• 哪个信号本来应该提前暴露？
• 如果同样问题再发生，系统如何自动降级？
• 哪个环节需要人介入，哪个环节应该自动化？
• 改进完成后，怎么证明风险真的下降了？

这类追问能把“反思”变成“机制”。技术组织真正的进步，不是复盘会开得感人，而是下一次同类事故更难发生。

4. 学习一个新方案或新代码库

grill-me 不只适合拷问自己的方案，也适合反过来训练自己理解别人的方案。

你可以把一份设计文档、一段核心代码、一个模块 README 丢给 AI，然后说：

用 grill-me 的方式问我，直到确认我真的理解这个模块。

这时 AI 会像面试官一样追问你：入口在哪里、核心状态是什么、失败路径是什么、哪些地方不能乱改。答不上来的地方，就是你还没真正理解的地方。

学习不是把文档看完，而是能经得起追问。这个标准虽然朴素，但很管用。

五、怎么用：一个实用流程

如果只是输入“grill me”，当然也能用。但想用得更好，我建议按下面这个流程来。

第一步：先给上下文，不要只给结论

不要只说：

Grill me on this design.

最好补上：

• 目标：这个方案要解决什么问题
• 边界：哪些事情不在本次范围
• 约束：时间、人力、兼容性、合规、安全要求
• 当前设计：核心流程、关键数据结构、依赖系统
• 你最担心的点：性能、可靠性、权限、迁移、回滚等

可以直接套这个模板：

请用 grill-me 的方式拷问这个方案。

目标：
我想解决的问题是 ...

当前设计：
1. ...
2. ...
3. ...

约束：
- 时间：
- 兼容性：
- 安全/隐私：
- 运维：

不在范围：
- ...

我最担心：
- ...

请一次只问一个问题。
每个问题请给出你的推荐答案。
如果能通过代码或文档查到答案，请先查证再问我。

第二步：把每个回答都变成决策记录

grill-me 的输出最好不要停留在聊天里。每回答完一个关键问题，就把它沉淀成三行：

Decision:
我们选择 ...

Reason:
原因是 ...

Consequence:
代价和后续影响是 ...

这其实就是轻量版 ADR。不是每个项目都需要一堆正式文档，但关键选择一定要留痕。否则两周后你自己都会忘：“当初为啥不支持部分成功来着？”

第三步：让它按风险优先级追问

默认逐层追问是好的，但在时间有限时，应该先问高风险问题。

可以追加一句：

请先从最可能导致线上事故、数据错误、安全问题或返工的问题开始问。

这样它会优先盯住失败路径、数据一致性、权限、回滚、监控，而不是一上来纠结命名和格式。命名当然重要，但数据删错了，变量名再优雅也没用。

第四步：最后要求输出“未闭合问题清单”

一轮追问结束后，不要让对话自然散掉。请它总结：

请输出：
1. 已确认的关键决策
2. 仍未闭合的问题
3. 需要查代码或查文档的问题
4. 正式评审前必须补齐的材料

这个清单才是 grill-me 的最终产物。否则你只是经历了一场“很有启发的对话”，但明天还是不知道该改哪一页文档。

第五步：如果涉及领域词汇，切到 grill-with-docs

当讨论开始碰到“这个词到底是什么意思”“现在代码是不是这么干的”“这个决定以后怎么解释”时，就该考虑换成 grill-with-docs。

可以这样提示：

请用 grill-with-docs 的方式继续。

要求：
1. 先查项目中是否有 CONTEXT.md、CONTEXT-MAP.md 和 docs/adr/
2. 如果我的术语和现有 glossary 冲突，请立即指出
3. 如果我说的行为和代码不一致，请引用代码证据
4. 术语一旦确认，建议更新 CONTEXT.md
5. 只有在决定难以逆转、没有上下文会显得奇怪、并且确实存在取舍时，才建议写 ADR

这一步的意义，是把“问清楚”推进到“写清楚”。团队协作里，没写下来的共识很容易蒸发。尤其是过了两个 sprint，再加一个假期，大家的记忆会自动进行垃圾回收。

六、它的短板：好用，但还可以更硬一点

grill-me 的优点是短，短到没有废话。缺点也是短，短到有些关键机制还没写出来。

我会补四类约束。

1. 缺少退出标准

“until reaching shared understanding” 是个好目标，但怎么判断已经达成？目前没有定义。

可以补一个结束条件：

• 所有高风险分支都有明确决策
• 所有假设都有证据或责任人
• 所有未决问题都有 owner 和截止时间
• AI 能用自己的话复述方案，并得到用户确认

没有退出标准的追问，容易从严谨变成磨人。好评审不是把人问到怀疑人生，而是让方案变得可执行。

2. 缺少问题分类

它说要追问 every aspect，但没有告诉 AI 哪些 aspect 最重要。

我会建议至少分成这些类：

• 目标与非目标
• 用户与调用方
• 数据模型与状态机
• API 与兼容性
• 权限与审计
• 失败、重试、幂等
• 灰度、回滚、迁移
• 监控、告警、SLO
• 测试与验收

有了问题分类，追问会更稳定，不容易漏掉常见高风险区域。

3. 缺少证据标准

“能查代码就查代码”很好，但还可以更进一步：查到之后要引用证据。

比如：

如果通过代码库回答问题，请给出文件路径、关键函数或配置名，并说明该证据如何影响当前决策。

这样可以避免 AI 查了一圈，最后仍然只给一个模糊判断。工程讨论里，证据比语气重要。哪怕语气再自信，也抵不过一个真实的调用链。

4. 缺少产物模板

追问之后应该产出什么？目前没有规定。

我建议至少输出四样：

• 决策记录
• 风险清单
• 待验证问题
• 评审前补齐项

这能把对话变成工作成果。AI 最大的问题不是不会聊，而是聊完之后容易没有落地物。对工程团队来说，没有落地物的聪明对话，价值会打折。

七、我会怎么改这个 Skill

如果保持它的短小风格，我会这样增强：

Interview the user relentlessly about every aspect of this plan until we reach shared understanding.

Walk down the design tree one branch at a time. Resolve dependencies between decisions before moving to dependent questions.

Ask one question at a time. For each question:
1. explain why the question matters,
2. provide your recommended answer,
3. ask the user to confirm, correct, or reject it.

If a question can be answered by exploring the codebase or provided documents, do that first. Cite the evidence with file paths or document sections when available.

Prioritize high-risk areas first: data correctness, security/privacy, authorization, compatibility, failure handling, rollback, observability, and testability.

At the end, summarize:
- confirmed decisions,
- unresolved questions,
- risks and mitigations,
- evidence still needed before implementation or review.

这版不复杂，但更像一个可复用的工程评审流程。它仍然保留原来最好的部分：追问、单问、推荐答案、先查证。

如果把 grill-with-docs 的思路也合进来，我会再补三句：

When domain terms are used, compare them against CONTEXT.md and ask for clarification when they conflict or remain overloaded.

When a domain term is resolved, suggest updating CONTEXT.md as a glossary entry, without implementation details.

Only suggest an ADR when the decision is hard to reverse, surprising without context, and based on a real trade-off.

这三句能让它从“方案问诊”进化成“方案问诊 + 知识沉淀”。前者帮你过今天的评审，后者帮未来的同事少踩一次坑。

总结

grill-me 的可取之处，不在于它写得多完整，而在于它抓住了 AI 协作里一个很容易被忽略的角色：AI 不只可以帮你生成答案，也可以帮你暴露问题。

grill-with-docs 则往前多走了一步：它不只暴露问题，还要求把术语、代码事实和关键决策沉淀下来。一个负责“问”，一个负责“问完以后别忘”。

它们有什么用？一句话：在方案进入开发、评审或上线前，先让 AI 替你把隐含假设、依赖关系、领域词汇和失败路径问出来。

它们怎么用？也很简单：早期草稿用 grill-me，进入项目语境后用 grill-with-docs；给足上下文，让它一次只问一个问题；每个问题必须带推荐答案；能查代码就先查代码；最后沉淀成决策、风险、术语和未闭合问题清单。

行动清单

1. 下次写设计方案前，先用 grill-me 跑一轮自检。
2. 把每个关键回答沉淀成 Decision / Reason / Consequence 三行记录。
3. 要求 AI 优先追问高风险点：数据、安全、权限、幂等、回滚、监控。
4. 如果方案涉及领域词汇或历史决策，切到 grill-with-docs，检查 CONTEXT.md 和 ADR。
5. 结束时必须输出未闭合问题清单，不要让对话只停留在“很有启发”。
6. 如果要团队复用，给 grill-me 增加问题分类、证据标准和产物模板。

最后说句实在话：一个方案能经得起 grill-me，不代表它一定完美；但经不起追问的方案，多半还没准备好面对生产环境。生产环境可不会像 AI 一样说话客气，它通常直接给你一个红色告警。

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。