夜雨聆风
Matt Pocock 几个月前写了四句话，打包成了一个叫 /grill-me 的 Claude Code 技能。
这个技能做的事情很简单：让 AI 在写代码之前不断追问你，沿着设计树一层层往下走，逐个解决决策之间的依赖，直到双方达成足够一致的理解。
这个技能火了。Matt 说他每天都能收到大约五条消息，开发者们告诉他用了之后很喜欢。
有人说「grill-me 简直是 game changer」。有人说「一开始觉得问题太多拖慢了节奏，但用了一段时间发现它其实省时间——收集完上下文之后基本能一次性搞定」。
但在收到这么多好评之后，Matt 自己却不再用它了。
他做了一个更好的。
/grill-me 哪里不够用
Matt 在视频里用了一个真实例子来说明。
他的应用目前处理的实体有 Course（课程）、Lesson（课时）、Video（视频）、Section（章节）等。他想加一个新概念：Pitch。
Pitch 来自 MrBeast 的一个理念：在制作视频之前，先想好怎么包装它。标题、描述、呈现角度——这些就是 Pitch。先批量写一堆 Pitch，挑出最好的，再把它们变成视频。
在跟 AI 解释 Pitch 的过程中，他又用到了另一个词：standalone video。在他的项目里，这个词指的是不挂在任何课程或课时下面的视频。他自己很清楚这个约定，但 AI 不知道。
于是每次聊到这里，AI 要么追问「standalone video 是什么意思」，要么自己从代码里猜。
Matt 越用越觉得不对劲。AI 经常过于冗长，他得反复提醒「这个概念已经有专门的术语了」。更麻烦的是，有时候他自己的表达也很啰嗦，AI 并不会挑战他。偶尔双方确实聊出了很好的共识语言，但这些共识没有被记录在任何地方。
问题的核心是：他们能有效地讨论代码，但每次开始新任务，他都要把代码库里那些不显而易见的东西重新解释一遍。
▲ 视频 0:56 处，Matt 开始演示 /grill-me 在真实任务中遇到的瓶颈。
他先做了一个「通用语言」技能
Matt 开始想：最薄的一层文档是什么，能让 AI 多一点先验知识？
他从领域驱动设计（DDD）里借了一个概念：Ubiquitous Language，通用语言。出自 Eric Evans 的那本经典蓝皮书。
通用语言的意思是：代码库用的词、开发者说的词、业务专家理解的词，应该是同一套。业务专家说「应用的某个部分有问题」，开发者马上知道他在说哪块代码；开发者说「standalone video」，业务专家也知道它不是课程里的课时，而是另一种内容形态。
于是 Matt 做了一个 /ubiquitous-language 技能。在 grilling session 进行到一半、发现需要明确某些术语时，他会调用这个技能，生成一个 ubiquitous-language.mmd 文件。
用了一段时间之后，他发现自己总是同时用 /grill-me 和 /ubiquitous-language 两个技能。
那为什么不把它们合成一个？
/grill-with-docs 怎么工作
新技能叫 /grill-with-docs。顶部保留了 /grill-me 的全部文本，但多了几个关键能力。
第一，它会自动查找context.md。
这个文件记录当前代码库里的共享语言。在 DDD 里，bounded context 是指应用中使用同一套语言的一个部分。如果你有一个大型 monorepo，可以按上下文拆成多个 context.md；如果只是一个中等规模的项目，根目录放一个就够了。
Matt 在视频里展示了自己仓库的 context.md：开头是对项目的简要描述，然后逐个列出 Course、Course Version、Standalone Video 等实体的定义。每个词都有精确的规格说明。
他还在本地的 CLAUDE.md 里加了一个指针，告诉 AI 去哪里找这份领域文档。
▲ 视频 6:39 处，Matt 展示自己仓库里的context.md，里面列出了所有核心实体的定义。
第二，它会在对话中持续打磨语言。
具体来说，/grill-with-docs 会拿你说的话跟现有术语表做比对，挑战模糊的表达，讨论具体场景，跟代码交叉引用，并且随时把新的共识更新回文档。
Matt 收到的用户反馈也印证了这一点。有人说「用了一整天，刚开始它让我定义了很多术语，有些词很难达成一致，而且是那种自己肯定会忘的词。但四五轮 session 之后，Claude 开始自动拾取上下文，说出来的话跟我脑子里想的完全对齐了」。
第三，它会维护架构决策记录（ADR）。
有些东西光靠统一术语解决不了。比如一些非显而易见的技术决策，context.md 装不下。Matt 引入了 ADR——就是放在仓库里的简单 markdown 文件，专门记录那些重要的、非显而易见的决定。
什么时候该写 ADR？Matt 给了三个判断条件：
这个决策难以逆转——不是随手能换的库选择。
这个决策脱离上下文会让人意外——很多仓库里的决定，没有背景就是让人困惑的。
这个决策是真正权衡的结果——会对后续产生连锁影响。
他在仓库里还放了一个 ADR 格式模板，AI 在创建新的 ADR 时会自动使用。
Demo：从术语冲突到领域建模
视频 8:25 之后进入实战演示。Matt 把 /grill-me 替换成 /grill-with-docs，然后开始一轮新的 grilling session。
AI 做的第一件事：读取 context.md，发现内容很丰富，standalone video 已经被定义为 lesson_id 为 null 的视频。然后它说：在继续之前，我想先指出术语表里的一个问题。
这就是 /grill-with-docs 的典型行为：先聚焦语言，再谈实现。
它问的第一个问题是关于基数（cardinality）：一个 Pitch 对应多个 standalone video，还是一对一？Matt 跟着它的建议，选了一对多。
接着它指出了一个术语冲突：standalone video 现在既可以有 Pitch，也可以没有 Pitch。那「standalone」到底是指不属于课程，还是指没有任何包装提案？
这个问题的答案会影响整个 UI 设计。因为这里定义的语言，也是用户在页面上看到的语言。如果把有 Pitch 的视频和没有 Pitch 的视频分成两个概念，页面上就会出现两个入口。Matt 原本以为会给 pitched video 单独做一个区域，但想了想之后同意了 AI 的建议：把 Pitch 当作 standalone video 的一层元数据，模型更简单。
然后是状态语义。AI 提议 Pitch 可以有 idle、scheduled、shipped 三种状态。Matt 选择了自由切换，不做自动化流转——以后接入 YouTube 发布流程时再加也来得及。
AI 又问：一个 Pitch 能不能没有视频？Matt 说当然可以。因为 Pitch 本质上就是 MrBeast 式的创意包装，先把包装想好，再决定做不做。存在一批还没被制作的提案是正常的。
这个结论直接影响了删除策略。Matt 选了 onDelete restrict，因为他更习惯归档而不是直接删除。
最后 Matt 让 AI 把讨论结果保存到 context.md. AI 更新了几个新条目：Pitch 实体定义、Pitch Status 状态枚举、Pitched Standalone Video、Unattached Standalone Video.
Matt 看了之后觉得有些命名还不够好，比如「Pitched Standalone Video」有点别扭，「Unattached Standalone Video」基本等于说了两遍 standalone。但他也说：不能无限纠结下去，先 ship，以后随时可以重构语言。
▲ 视频 8:25 处的 Demo。AI 没有急着写代码，而是先识别术语冲突、关系基数、状态语义和删除策略。
Matt 在这里特别强调了一句：你可能觉得这是在 bike-shedding（纠结无关紧要的细节），但请记住，所有变量名、所有文件名都会基于context.md里的这些词。把语言搞对，对于跟 AI 保持一致至关重要。
三个实际收益
Matt 在视频后半段总结了好处。
回复变短了。 AI 能用更少的 token 跟你交流，因为有了共享语言，它不需要每次都冗长地复述背景。它可以直接说「standalone video 的显示方式需要改一下」，而不是先花一段话解释什么是 standalone video。
AI 的思考也变高效了。 AI 用语言进行内部推理。共享语言让它的 thinking trace 更对齐你的意图，实际消耗的 token 也更少。Matt 说他观察到了这一点，感觉相当不错。
代码更容易导航。 因为你跟 AI 的对话方式、规划文档的组织方式、代码的结构方式三者一致，想找所有跟 Pitch 有关的逻辑，直接搜索就行。
Matt 说，这些好处其实就是领域驱动设计本身描述的那些。对人类有效的协作技术，对 AI 同样有效。
/grill-me 没有死
Matt 特别澄清了这一点：他没有杀死 /grill-me。
他把 /grill-me 移到了技能列表的「生产力」分类下，用于没有代码库的通用场景。他讲了一个故事：有人在为母亲写悼词时，用 /grill-me 让 AI 不断追问关于母亲的回忆，挖掘出了很多具体的故事。
规则很简单：
有代码库，用 /grill-with-docs。
没有代码库，用 /grill-me。
项目很早期？Matt 仍然推荐 /grill-with-docs，因为项目初期正是建立共享语言的最佳时机。
写在最后
现在很多关于 AI 编程的讨论集中在模型能力和提示词技巧上。这些当然重要，但它们解决的是「AI 能不能写」的问题。
真实项目里更难的，是「AI 写出来的东西是不是属于这个系统」。
context.md 和 ADR 看起来朴素，却正好补上了这一层。它们让 AI 在写代码之前，先理解项目里的语言、关系和取舍。
AI 辅助开发不是把工程纪律扔掉，而是让工程纪律变得更重要。以前这些纪律服务人类协作，现在它们还要服务人机协作。
这不是魔法，这是工程。
——
本文基于 Matt Pocock 的视频 I stopped using /grill-me for coding. Here's what I use instead 整理，适合正在把 AI 深度引入开发流程的团队参考。
