统一语言

问题：同一概念，三种叫法

在一个订单系统里，“账户”到底指下单的客户，还是登录的用户？当产品、后端和领域专家各说各话时，代码里会留下同样的裂缝：Customer、User、Account 混用，Order 的归属方说不清，发票绑定在 Order 还是 Fulfillment 上也各执一词。这种概念漂移不会导致编译失败，但会让需求评审变慢、接口字段反复返工、测试用例覆盖不到真实边界。

技能如何工作

这个技能扮演领域建模师的角色，从对话里提炼统一语言，而不是整理一份普通词表。

核心能力包括：

• 识别 同词多义、多词同义 和 含糊术语，不只做同义词替换。
• 在多个候选词中给出有立场的规范术语，并把其他叫法列入应避免别名。
• 按子域、生命周期或角色对术语分组，而不是平铺成一张表。
• 输出关系、示例对话和被标记的歧义，让下游 domain-modeling 与 codebase-design 有共同词汇基础。

关键步骤：

1. 扫描对话，提取领域相关的名词、动词和概念；可读取 ConversationTranscript。
2. 识别问题：区分歧义、同义和过载术语，不把模糊留在注释里。
3. 提出规范术语表：每个条目说明“是什么”，不写成“能做什么”。
4. 产出工件：分组的术语表写入 UBIQUITOUS_LANGUAGE.md，同时给出 relationships、example_dialogue 和 flagged_ambiguities。
5. 内联摘要：在对话里直接展示术语裁决结果，避免团队再翻文件。

适用边界与注意点

适合在定义领域术语、建立术语表、夯实 DDD / domain model / 统一语言时使用。术语必须对领域专家有实际意义；模块名、类名只在本身承载领域含义时才收录。array、function、endpoint 这类通用编程概念默认跳过，除非在当前上下文里有领域特定含义。

不要把它当成通用文档索引：它不验证业务规则，也不代替领域事件建模。若一个词同时能指两个核心概念，技能会显式标记冲突，而不是强行合并。