在 AI 辅助编码中，最昂贵的失败往往不是 Bug，而是 AI 把错误的东西构建得十分完美——它完全理解错了开发者的意图。为了解决这种"错位"，开发者 Matt Pocock 推出了广受欢迎的 /grill-me 技能，通过持续深入提问来理清需求。然而，在实际使用中他发现，这套机制在处理已有代码库时存在明显局限，于是推出了升级版：Grill with Docs。
痛点：为什么仅有"深度提问"还不够？
/grill-me 的核心机制是让 AI 对开发者进行"无情"的访谈：顺着设计决策树，一次只问一个问题，理清所有依赖关系，直到双方达成共识。这虽然有效，但缺少了关键一环——对项目领域知识的持久化记录。每次开启新会话时，开发者仍需反复向 AI 解释代码库中的专有术语和业务逻辑。由于缺乏共享语言，AI 的表达有时会过于啰嗦，甚至无法主动挑战开发者的模糊用词。
解决方案：结合 DDD 与深度访谈的 Grill with Docs
Grill with Docs 是 Grill Me 的"项目感知"版本。它不仅保留了原有的深度提问机制，还引入了领域驱动设计（DDD）中的核心概念，让 AI 在编码前就能掌握项目的专有术语和非显性决策。DDD 的核心理念是：代码的结构和命名应忠实反映业务领域，而非技术实现。它强调建立一套开发者、产品、业务专家共同使用的"通用语言"，确保所有人说的"是同一个东西"。其核心运作机制包含以下三个层面：
1. 一次一问的深度访谈
技能会从设计决策树的最高杠杆未解依赖点开始，一次只问一个关键问题，并为每个问题提供推荐答案。这种做法避免了大量问题堆积带来的瘫痪感，保持了推进的节奏。如果问题能通过查阅代码库解决，AI 会自行探索而不是打扰开发者。
2. 建立通用语言与 CONTEXT.md
技能会自动读取并维护位于项目根目录的 CONTEXT.md 文件。这份文档记录了当前限界上下文内所有的通用语言（Ubiquitous Language），让代码库使用的语言、开发者的日常用语以及领域专家的术语完全统一。
在访谈过程中，AI 会对照现有术语表挑战开发者的模糊表达。例如，当开发者提出新概念（如"独立视频"或"视频包装方案"）时，AI 会通过具体业务场景进行交叉验证，并在术语达成一致后，实时将其更新到 CONTEXT.md 中。这种边问边记录的方式，让文档能够伴随决策同步进化。
3. 记录架构决策（ADR）
架构决策记录（ADR）是用简短 Markdown 文件记录重要技术决策的实践，通常包含：问题背景、最终方案、以及该选择的利弊。例如"API 用 REST 而不用 GraphQL"就是一个典型决策——写下来后，新人不用反复追问"为什么这样做"，答案就在文件里。
有些决策是"非线性的"，难以用单纯的术语表捕捉。对于这类难以回退、缺乏上下文会令人意外、且是真实权衡结果的决策，技能会将其记录为架构决策记录（ADR）保存在仓库的 docs/adr/ 目录中。如果只是可随时回退的简单决定，则不需要创建 ADR，避免了文档冗余。
实际效果：实现与 AI 的"魔法对齐"
将隐性的领域知识转化为文档后，Grill with Docs 能为开发流程带来显著收益：
- 意图对齐与沟通精简：AI 能够在开发者话没说出口前就理解上下文，实现深层的"魔法对齐"。得益于共享语言，AI 无需反复解释术语，沟通所需的 Token 大幅减少，其内部的思考过程也更贴合开发者意图。
- 代码一致性与易读性：所有的变量名、文件名都会基于 CONTEXT.md 中的术语生成，这保证了对话方式、规划文档与最终代码风格的一致性。开发者只需搜索特定术语，就能轻松在代码库中定位所有相关信息，降低了命名冲突的风险。
何时使用：Grill Me vs Grill with Docs
选择哪个技能的规则十分简单：有代码库时使用 Grill with Docs，没有代码库时使用 Grill Me。
- Grill with Docs：适用于涉及现有代码库的功能开发或重构，能够有效防止技术债累积。即使在项目初期，也强烈推荐使用它来尽早建立通用语言，这将为后续开发带来巨大收益。
- Grill Me：适用于没有代码库的一般性场景，如规划课程、思考决策，甚至有用户曾用它来辅助撰写悼词，通过深度提问挖掘出感人的故事。
通过在动手写代码前先经历这场结合了文档更新的"拷问"，开发者能以极低的前期成本，消除后期大量因理解偏差导致的返工。
