提取“通用语言”：如何让 AI 从你的聊天记录里自动长出业务术语表？

在领域驱动设计（DDD）的实践中，最让架构师崩溃的不是写代码，而是沟通成本。同一个“用户”概念，在产品经理口中是“流量”，在前端眼里是“Account”，而在后端库表里又变成了“Member”。这种语义不一致是导致大型项目腐化的万恶之源。

我最近在深度研究 Matt Pocock 的 ubiquitous-language 技能时，发现他提供了一个极其硬核的解决方案：让 AI 实时监听你的技术讨论，并自动萃取出一套 Ubiquitous Language（通用语言） 术语表。

💡 报错现象总结：团队在多人协作开发复杂业务逻辑时，常因术语不统一导致代码命名混乱。在使用 AI 辅助开发时，若缺乏统一的领域模型约束，AI 生成的代码往往会引入非预期的业务术语，造成严重的语义偏移和维护成本。

语义冲突的代价：为什么代码会变成“方言”？

如果你不显式地定义术语表，AI 会根据它的概率预测给你的变量起名。在一个电商项目中，如果没有 ubiquitous-language 技能的约束，你可能会看到这样的惨状：

// 典型的语义混乱代码：同一个业务实体有三个名字
interface OrderProcess {
  buyer: User;      // 术语 A
  customer: Member; // 术语 B
  client: Account;  // 术语 C
}

Matt Pocock 的 skills 项目通过 ubiquitous-language 技能，强制 AI 从对话中提取出被各方认可的“官方称呼”。它的核心逻辑是：代码中的每一个变量名，都必须在术语表中有据可查。

深度剖析：ubiquitous-language 如何从聊天中萃取资产？

这个技能的底层架构并不是简单的文本提取，它实际上执行了一次语义聚类。

当你在对话中提到“那个负责处理支付退回的逻辑”时，AI 会识别到这是一个核心领域行为。它会询问或建议将其命名为 RefundProcessor，并记录其定义。

评估维度	传统文档记录 (手动)	ubiquitous-language (自动)
实时性	极低，文档往往在项目结束后才补	极高，随着技术讨论同步生成
一致性	依赖人工核对，容易漏更	强一致，AI 会在后续对话中强制应用该术语
可追溯性	难以找到术语确定的背景	能直接追溯到当初讨论该概念的原始上下文

在 skills 源码中，这个技能会输出一个 Markdown 格式的术语表，它可以被直接集成到项目的 docs/ 目录下，作为整个团队的“真理来源”。

手动维护“业务词典”的各种坑

在没有这个工具前，架构师为了维持语义统一，通常要经历这些痛苦：

1. 无休止的命名会议：为了一个变量名是叫 Price 还是 Amount 争论半小时。
2. 过时的 Wiki 页面：好不容易写好的术语表，在项目代码迭代两周后就彻底过时了。
3. 代码审查（PR Review）中的体力活：你不得不一遍又一遍地在 PR 里留言：“这个概念我们统一叫 X，请修改变量名”。

这种手工劳动不仅低效，而且容易挫伤开发者的积极性。

让你的团队拥有“同一种语言”

架构师最高的境界不是写最复杂的算法，而是建立最清晰的秩序。利用 Agent Skills 的自动化提取能力，你可以让业务逻辑在代码中实现“自解释”。

为了帮你快速建立团队的语义秩序，我已经在 GitCode 分享了一套 《DDD 领域驱动设计：Ubiquitous Language 术语表实战模板》。你可以配合 ubiquitous-language 技能生成的导出结果，直接填充到这份模板中。访问 GitCode，让你的术语表从聊天记录里“长”出来，彻底告别团队沟通中的语义黑洞。

[在 GitCode 分享你的术语表，获取领域建模专家点评，并下载实战模板。]