Grill With Docs：用统一语言让AI编程协作效率翻倍

引言：一个爆火Skill的自我革命

几个月前，一位开发者用四句话创建了一个名为「Grill Me」的LLM技能，让AI像面试官一样不断追问，直到双方对需求达成共同理解。这个技能迅速走红，每天都有人反馈说它"彻底改变了玩法"。然而，创建者本人并不满足——他发现了Grill Me的根本缺陷，并开发了一个更强大的替代方案：Grill With Docs。

这不只是一次技能迭代，更是一次AI编程协作范式的升级。它的核心思想来自一个经典的软件工程方法论——领域驱动设计（DDD），而这个方法论对AI的效果，可能比对人类更显著。

领域驱动设计（Domain-Driven Design）是Eric Evans在2003年同名著作中提出的软件设计方法论，其核心主张是：复杂软件的核心复杂性不在技术层面，而在业务领域本身。DDD提出了一系列战略和战术模式，包括限界上下文（Bounded Context）、聚合根（Aggregate Root）、值对象（Value Object）等。在传统软件开发中，DDD主要用于解决大型团队的沟通对齐问题；而在AI协作场景中，这种语言对齐的需求被进一步放大——因为LLM没有持久记忆，每次会话都需要重新建立上下文，使得"统一语言"从一种最佳实践变成了近乎刚需的基础设施。

Grill Me的局限：跨会话语言对齐的缺失

问题浮现

Grill Me的工作原理很简单：让LLM沿着设计决策的每个分支不断追问，逐一解决依赖关系。许多用户反馈说，"起初觉得这些问题把我拖慢了节奏，但用久了反而省时间——只要把上下文都收集好，就能一次性搞定一切。"

但随着深度使用，几个关键问题逐渐暴露：

• AI过度啰嗦：经常用冗长的描述来表达一个已有明确术语的概念
• 术语不统一：开发者的行话（如"standalone video"）AI并不理解，每次都要重新解释
• 共识无法沉淀：即使在某次对话中达成了很好的共用表述，这些共识不会被记录下来
• 上下文反复丢失：每次新会话都要把代码库和领域中不明显的点全部重新解释一遍

根本原因

问题的本质是：Grill Me只解决了"单次对话的需求对齐"，却没有解决"跨会话的语言对齐"。你和AI之间缺少一份持久的、共享的"语言契约"。

这一问题的技术根源在于当前LLM的工作方式：它们基于上下文窗口进行无状态推理。每次对话开始时，模型并不"记得"之前的交互内容，除非这些内容被显式地作为上下文传入。即使上下文窗口已经扩展到128K甚至更长的token，这种无状态机制仍然意味着：跨会话的知识积累必须依赖外部存储机制。没有外部文档的支撑，每一次新会话都是从零开始的认知重建过程，这不仅浪费token，更会导致理解偏差的累积。

Grill With Docs的设计思路：统一语言 + 持久化文档

领域驱动设计的启发

解决方案的灵感来自Eric Evans的领域驱动设计（DDD）中的核心概念——统一语言（Ubiquitous Language）。

统一语言的本质是：代码库、开发者、领域专家三方使用同一套语言。当领域专家说"这个应用的这一部分有问题"时，开发者能精确知道对应代码的哪个部分，因为代码本身就用了相同的术语。这个概念之所以强大，是因为它消除了"翻译层"——在传统开发中，业务人员说的话需要经过产品经理翻译成需求文档，再由开发者翻译成代码，每一层翻译都会引入信息损耗和歧义。统一语言的目标就是让所有参与者直接使用同一套词汇，从根源上消除这种损耗。

将这个概念迁移到人机协作场景：如果AI也掌握了这套统一语言，它就能用更少的token表达更精确的意思，不需要每次都重新描述上下文。

Grill With Docs的三大核心组件

新技能在Grill Me的基础上增加了三个关键层：

1. Context.md —— 共享语言文档

这是一个放在仓库中的Markdown文件，记录该上下文中所有共享术语的定义。例如：

• "Standalone Video" = lesson ID为null的视频（不与课程关联）
• "Pitch" = 视频的包装（标题、描述、呈现方式），在确定内容前先确定

对于大型monorepo，可以用context map管理多个bounded context；对于单一应用，一个context文件即可。

在DDD中，Context Map是描述多个限界上下文之间关系的工具。限界上下文定义了一个模型适用的边界——同一个词在不同上下文中可能有完全不同的含义（例如"用户"在认证上下文中指的是登录凭证的持有者，而在计费上下文中指的是付费账户的所有者）。在大型monorepo中，不同模块往往对应不同的业务领域，使用统一的全局词汇表反而会造成混乱。因此，为每个bounded context维护独立的context.md，再通过context map描述它们之间的映射关系，是更合理的组织方式。这种分层管理确保了术语在各自边界内的精确性，同时通过映射关系保持了跨边界沟通的可能性。

2. 语言对照与澄清机制

在Grilling过程中，AI会主动：

• 将新出现的用语与现有词汇表对照
• 澄清模糊措辞
• 讨论具体场景并与代码交叉引用
• 随时更新context.md

这个机制的本质是将context.md从一个静态文档变成一个"活的"知识库。每次对话都是对这个知识库的一次校验和增量更新，确保它始终反映项目的最新认知状态。

3. ADR（架构决策记录）

对于那些无法写进context.md的不明显决策，使用ADR来记录。ADR是简单的Markdown文件，专门记录那些"难以撤销"且"没有上下文会让人意外"的决策。

架构决策记录（Architecture Decision Records）是Michael Nygard在2011年提出的轻量级文档实践。每条ADR通常包含五个部分：标题、状态（提议/接受/废弃）、上下文（做出决策时的背景和约束）、决策内容、以及预期后果。ADR的核心价值在于记录"为什么"而非"是什么"——代码能告诉你系统当前的状态，但无法告诉你为什么选择了这种方案而非另一种。在AI协作中，ADR的价值被进一步放大：当AI需要修改或扩展现有代码时，如果不了解历史决策的背景和约束条件，很容易做出与原始设计意图相悖的修改，导致架构腐化。

关键判断标准：如果只是"用这个库还是那个库"这种可互换的选择，不需要写ADR；但如果决策会在后续产生连锁影响，就必须记录。

实战演示：共享语言如何提升AI推理质量

一次典型的Grill With Docs会话

以"给应用添加Pitch实体"为例，AI的表现明显不同：

第一步：读取context.md

AI首先识别出"standalone video已被定义为lesson ID为null的视频"，无需重新解释。

第二步：关注语言而非实现

AI主动提出术语问题："pitch和standalone video之间是什么基数关系？一个pitch包含多个视频，还是一对一？"这比直接跳进代码层面要高效得多。

这种"先对齐语言，再讨论实现"的顺序至关重要。在传统开发中，过早进入实现细节是需求偏差的主要来源之一。当AI先确认术语的精确含义和实体间的关系时，后续的代码生成自然会更贴合业务意图。

第三步：发现语义冲突

AI敏锐地注意到：如果standalone video现在可以关联pitch，那"standalone"这个词的定义是否需要更新？这个看似细枝末节的问题，实际上会影响UI设计、数据模型和用户认知。

这正是统一语言的威力所在——当术语定义足够精确时，任何新增功能与现有定义的冲突都会被自动暴露。如果没有context.md中的明确定义，AI可能会直接忽略这个语义矛盾，生成在逻辑上自相矛盾的代码。

第四步：更新共享文档

会话结束时，AI主动将新达成的共识写入context.md，包括pitch实体的定义、pitch status的状态机、以及与standalone video的关系。

用户反馈验证

一位早期测试者的体验很有代表性："一开始它让我定义很多术语，有些很难达成一致。但过了四五次会话后，AI在grilling中抓住了上下文，奇妙地和我脑子里还没说出口的想法对上了。"

这种"越用越懂你"的体验，本质上是context.md作为外部记忆的累积效应。随着文档中的术语定义越来越丰富和精确，AI需要推测的空间越来越小，其输出自然越来越贴合开发者的意图。

核心收益：统一语言对AI协作的三重提升

1. 回复更简洁

有了共同语言，AI不再需要冗长重复地描述所有内容。它可以直接说"standalone video的定义要变了，我们需要调整pitches的展示方式"——一句话传达了之前需要一大段解释的信息。

从token经济学的角度看，这意味着在相同的上下文窗口限制内，可以传递更多有效信息。当AI不需要花费大量token来描述基础概念时，它就有更多的"认知带宽"用于深度推理和创造性思考。

2. 推理更精准

由于LLM用语言与自己"思考"（chain of thought），统一语言意味着AI的推理链路也更贴合你的意图，用更少的token实现更准确的推理。

这一点有深层的技术原因：Chain of Thought（思维链）是LLM进行复杂推理时的核心机制。研究表明，当模型需要用模糊或冗长的表述来描述一个概念时，它的推理链路中每一步都会引入额外的歧义和噪声，这些噪声会在多步推理中累积放大。反之，当有精确的术语可用时，模型能在更少的token内完成更准确的推理，每一步的确定性更高，最终结论的可靠性也随之提升。这解释了为什么统一语言不仅是沟通效率问题，更是AI推理质量的根本性问题。

3. 代码更易读

当规划文档、对话方式、代码命名三者使用同一套语言时，代码自然变得更容易阅读和检索。想找所有关于pitch的信息？直接搜索即可。

这种一致性还带来了一个隐性收益：代码审查和知识传递的成本大幅降低。新加入项目的开发者（或新的AI会话）只需阅读context.md就能快速理解项目的核心概念和术语体系，而不需要通过阅读大量代码来反向推断业务含义。

适用场景选择指南

场景	推荐方案	原因
有代码库的项目	Grill With Docs	能从共享语言中持续获益
无代码库/通用场景	Grill Me	适合写作、策划等一次性任务
项目早期阶段	Grill With Docs	早期正是建立共享语言的最佳时机
多人协作项目	Grill With Docs	统一语言同时服务于团队成员和AI

总结：DDD思想在AI时代的新价值

这个案例最有趣的发现是：那些对人有效的软件工程实践，对AI同样适用，甚至效果更显著。领域驱动设计强调的统一语言、限界上下文、决策记录，在AI协作场景中获得了全新的应用价值。

这种现象并非偶然。DDD的核心假设是"软件的复杂性源于沟通的复杂性"，而AI协作本质上就是一种高频、高密度的沟通活动。人类团队可以通过日常交流、代码审查、白板讨论等方式逐渐建立隐性共识；但AI没有这些渠道，它唯一的信息来源就是显式传入的文本。这意味着，所有在人类团队中可以"意会"的知识，在AI协作中都必须被"言传"——而DDD恰好提供了一套将隐性知识显式化的成熟框架。

当我们不再把AI当作一个需要反复教育的工具，而是当作一个可以共建语言体系的协作者时，人机协作的效率就会产生质的飞跃。语言对齐不是锦上添花，而是高效AI编程的基础设施。

核心要点