name: ddd-glossary-gen description: “从当前对话中提取和规范领域术语，生成DDD风格统一语言术语表，识别歧义并给出规范用语建议，保存为UBIQUITOUS_LANGUAGE.md文件。当用户需要定义领域术语、构建术语表、统一词汇规范、创建统一语言，或在讨论中提及“领域模型”、“DDD”或“统一语言”等关键词时触发。”
统一语言术语表
从当前对话中提取并规范化领域术语，形成一致的术语表，保存为本地文件。
流程
- 扫描对话内容，识别与领域相关的名词、动词和概念
- 发现问题：
- 同一个词被用于不同概念（歧义）
- 不同的词指代同一个概念（同义词冗余）
- 含义模糊或过度泛化的术语
- 提出规范术语表，给出明确的术语选择建议
- 写入工作目录下的
UBIQUITOUS_LANGUAGE.md，格式如下 - 在对话中输出摘要
输出格式
生成一个 UBIQUITOUS_LANGUAGE.md 文件，结构如下：
# 统一语言
## 订单生命周期
| 术语 | 定义 | 应避免的别名 |
| ---- | ---- | ------------ |
| **订单** | 客户购买一件或多件商品的请求 | 购买、交易 |
| **发票** | 在交付后发送给客户的付款请求 | 账单、付款请求 |
## 人员
| 术语 | 定义 | 应避免的别名 |
| ---- | ---- | ------------ |
| **客户** | 下订单的个人或组织 | 客户、买家、账户 |
| **用户** | 系统中的身份认证标识 | 登录、账户 |
## 关系
- **发票** 属于恰好一个 **客户**
- **订单** 产生一个或多个 **发票**
## 示例对话
> **开发者：** "当 **客户** 下了 **订单**，我们是否立即生成 **发票**？"
> **领域专家：** "不——只有当 **履约** 确认后才会生成 **发票**。如果物品分开 **发货**，一个 **订单** 可以产生多个 **发票**。"
> **开发者：** "所以如果 **发货** 在发货前取消，那么就没有对应的 **发票**？"
> **领域专家：** "没错。**发票** 的生命周期是跟 **履约** 绑定的，而不是跟 **订单**。"
## 已标记的歧义
- "账户" 被同时用来指代 **客户** 和 **用户** —— 这是不同的概念：**客户** 下订单，而 **用户** 是身份认证标识，可能代表也可能不代表 **客户**。
规则
- 要有主见。 当同一概念存在多个词汇时，选定一个最佳术语，其余列为"应避免的别名"。
- 明确标记冲突。 如果某个术语在对话中被模糊使用，在"已标记的歧义"部分指出，并给出明确建议。
- 只收录领域专家关心的术语。 跳过模块名或类名，除非它们在领域语言中有实际意义。
- 定义要精炼。 最多一句话。定义它是什么，而不是它做什么。
- 展示关系。 使用加粗的术语名称，在明显的地方标注基数关系。
- 只收录领域术语。 跳过通用编程概念（数组、函数、接口等），除非它们在领域中有特殊含义。
- 将术语分组到多个表格中，当自然的类别出现时（例如按子域、生命周期或角色分组）。每个分组有自己的标题和表格。如果所有术语属于同一个内聚的领域，用一个表格就够了——不要强行分组。
- 编写示例对话。 一段简短的对话（3-5 轮交流），由开发者和领域专家进行，展示这些术语如何在自然交流中配合使用。对话应澄清相关概念之间的边界，并展示术语的精确用法。
<example>
示例对话
开发者： “怎么在不用 Docker 的情况下测试 同步服务？”
领域专家： “用 文件系统层 替代 Docker 层。它实现了同样的 沙箱服务 接口，只是用本地目录作为 沙箱。”
开发者： “那 同步入站 还是会创建 包 然后解包吗？”
领域专家： “没错。同步服务 不知道它在跟哪个层通信。它调用
exec和copyIn——文件系统层 只是把这些当作本地 shell 命令来执行。”
</example>
重新运行
在同一对话中再次调用时：
- 读取已有的
UBIQUITOUS_LANGUAGE.md - 将后续讨论中出现的新术语纳入
- 如果理解发生变化，更新定义
- 重新标记新发现的歧义
- 重写示例对话，融入新术语