从 grill-me 到 grill-with-docs：AI 编程的下一步不是问得多，而是对齐术语
Matt Pocock 在他的新视频里做了一个非常有意思的升级——他把广受欢迎的 grill-me 技能升级成了 grill-with-docs。
乍看之下是个提示词迭代，但深入一想，背后藏着的问题非常根本：
当 AI 能帮我们写代码时，什么才是真正省不了的工作量？
当 grill-me 遇到天花板
先说清楚 grill-me 为什么好。这个技能的逻辑很简单：让 AI 继承程序员被 RUP 时代锻炼出来的反射弧——你不要直接给答案，要无情地追问我，把需求里的坑当面说出来。等大家达成一致了，再去生成代码。
这个思路绝对是对的。“一次性精准生成”本身就该是每个人和 AI 互动的基线态度，而不是先让它产出一坨，然后你再去删改。
但 Pocock 自己做大了项目后，发现一个新问题：就算逼着自己被 AI 追问，每次新会话都要重新解释一遍代码库的术语、业务概念、设计假设。他说“不直观的代码抽象”需要来回解释，AI 和程序员看似在对话，但共识只是当下那个窗口的“临时契约”，窗口一关就清零了。
这个痛点太真实了。它直接反映了一个事实：
AI 能生成代码，但它不知道你的业务语言。而如果你连团队内部都没有统一语言，那每次对话都无异于重新创业。
为什么“统一语言”才是根子问题
Pocock 引入了一个有二十年历史的概念——来自 Eric Evans 领域驱动设计的 ubiquitous language（统一语言）。
这个概念的精髓是：业务人员、开发人员和代码库，应该用同一套词汇描述同一个东西。同一个概念不能有多个名字，同一个词也不能在不同上下文里指代不同的东西。
想想看，你的代码库里有没有这种事：一个叫 courses 的表在 API 层叫 lessons，产品经理叫它们“内容单元”，而数据库字段里写的是 items。四张嘴对着同一个东西说了四个名字，AI 来了之后不疯才怪。
Pocock 的做法是：引入了 context.md，一个放在项目根目录的共享术语表，记录所有核心业务概念和关系。然后让 grill-with-docs 技能在每次会话开始时先读它，对话结束后自动更新它。
这招我拍手叫绝，原因不在文件本身，而在谁在为这个文件工作。
人类写的文档很难维护，在业务初期活跃半年，之后没人看、没人改、和代码对不上都是常态。但把 AI 放进这个循环里，它变成了愿意读文档并主动更新它的人。这个模式从“人写 AI 读”变成了“人主导、AI 执行、项目根目录做 truth”——这才是良性循环。
grill-with-docs 加了什么
三行代码值得注意：
- AI 主动读取项目 context 文件，不需要你每次把背景信息复制粘贴到新对话窗口里。
- AI 在提问阶段就会给你挑错——如果你用的词和 context.md 里的定义有冲突，它直接指出。这意味着 AI 不是被动接受术语，而是在主动维护术语的“警察”。
- 对话后自动更新 context.md 并生成 ADR（架构决策记录）——这是整套流程最值钱的部分。
ADR 专门记录那些”术语表解释不了“的决策——比如为什么选 PostgreSQL 而不是集中式设计、为什么跨服务边界切在这里、为什么某个状态机必须这么流转。这些决策是不可逆的，一旦没了上下文，三个月后回来重构的人（包括三个月后的你自己）只有猜。
他视频里的实战演示很精彩：要在视频课程平台里加一个“Pitches”（视频策划稿）的新实体。AI 读过 context 后，立刻指出了一个我之前都没意识到的问题：
“你那叫
Pitch的实体和已有的Standalone Video有什么区别？是一对一还是一对多？删除时级联吗？Pitch 没挂视频的状态怎么标？"
这几个追问直接避免了底层数据模型重复造轮子和边界情况漏处理的问题。最后 AI 把精确定义写回 context.md，整个过程的产出不只是代码，是代码+文档的同步更新。
这样做带来了什么实际收益
Pocock 自己总结了三点，我来谈我的感知：
1. 回复更简练（Concise Replies）
有了共享术语表，AI 不需要每轮对话先花 300 个 token 复述 "因为你说的这个概念在这里是 X 而不是 Y"。更少的重复铺垫，更少的上下文膨胀，也省钱。
2. 意图高度对齐
当你说“帮我加一个 Feature”，AI 知道你的 Feature 在业务语境里意味着什么，而不是按通用工程语境去猜。这是一个巨大的工程效率提升——因为 AI 生成的结果从“语法正确”升级为“语义正确”。
3. 代码更容易维护
变量名、文件名、类型名直接取自 context.md，意味着代码本身就是自描述的。未来的维护者（不管是 AI 还是人）只要读 context.md 就能进入你的业务语境。
我的点评：这不是新技巧，这是"规范驱动"的回潮
看得很清楚，grill-with-docs 的本质不是“我们搞了个更好的提示词模板”，而是把 DDD 实践中的统一语言和 ADR 流程，通过 AI agent 的方式落到了日常开发工作流里。
这跟 vibe coding 是两条路线。
Vibe coding 告诉你“不要思考直接让 AI 干就完了”。grill-with-docs 告诉你：先对齐语言，再让 AI 干活。这不仅没牺牲速度，反而在前期设计和需求澄清上反而更快——因为省下了每次重写的代价。而且最重要的是，不会在后面来大号的天价技术债。
好归好，但我有几个保留意见：
第一，context.md 谁来审？
AI 自动更新文件确实很性感，但如果一次对话里 AI 对既有概念打补丁拐进了歧义，接下来所有的对话都会被这个错误定义污染。context.md 变成另一个真理源（source of truth）时，它本身的质量就成了单点故障。建议每次 AI 更新 context.md 后，至少做一个快速人工 diff 审查。
第二，多大的项目需要上这个动作？
Pocock 自己写得很好：哪怕项目刚起步也推荐。我对这一点半信半疑。一个新项目的第二天就建 context.md 和 ADR 模板，本质上是过早设计。我的建议是：让代码先跑起来，等出现第二次“我居然忘记这个字段叫啥名字”时就说明术语混乱到了该统一语言的临界点，再建不迟。不然你为三天的 Demo 维护一份领域字典，才叫真正内耗。
第三，它能和你的 specs 体系怎么配合？
如果你已经在使用类似 OpenSpec 的结构——specs/ 目录 + changes/ 目录——那 context.md 其实可以视为你 specs/ 下的一个 domain-terms.md。家族不同但血脉相连。做规范驱动的人，天然会更喜欢 grill-with-docs 的思路。
选型建议（直接给结论）
| 场景 | 用哪个 |
|---|---|
| 有代码库、有业务概念、超过 1-2 个开发者 | grill-with-docs |
| 刚起步、还在验证业务方向、代码不到 500 行 | 先写代码，等词汇混乱了再上 |
| 通用任务、头脑风暴、非工程领域 | grill-me（不要换，它依然是最优解） |
最后说点题外话。Pocock 说有人用 grill-me 追问自己关于母亲生前的事，写出了一封动人的悼词。这个细节让我印象很深： grilling 是一种让 AI 帮人类思考的工具，不只是让她写代码。这份温度的保留，比任何技术讨论都更值得被记住。
代码会过时，但写在 context 里的业务语言会留下。先对齐语言，再让 AI 干活。
你怎么看项目里的文档维护？是写完了就落灰，还是你也在尝试让 AI 参与维护？评论区聊聊。