统一术语，避免同义词混用

以下示例与示意结果由本站编写，用于说明方法，不是模型实测结果。

使用场景

计费设计文档交替使用 customer、user 和 account，读者不知道一句“删除 account”会影响谁。教学领域定义：Customer 拥有计费关系，User 是登录身份，一个 Customer 可以关联多个 User；Account 暂未定义。你要保留区别，而不是靠近义词让文字显得丰富。

具体做法

先从维护的领域材料提取概念及其职责，建立短词表，说明哪些词不是同义词。检查规格、示例和输出中的出现位置；含糊的 account 先指出可能指 Customer 或 User，必要时请用户决定。确认后统一对应位置，不把真正不同的概念一律替换成同一个词。

反例

改写上述计费文档，为了可读性把 Customer、User、Account 交替使用。把“删除 account”直接解释为删除登录用户。

改进写法

使用上述教学词表：Customer=计费关系主体，User=登录身份，Customer 可关联多个 User；Account 不作为两者同义词。检查文档与示例，统一同一概念的名称。遇到“删除 account”，列明含义未定并询问它指 Customer、User 还是另一概念；确认前不改成用户删除流程。输出词表、已统一位置与未决用词。

为什么这样改

近义词替换在领域模型里可能改变对象、关系和后果。共享词表让歧义显露，确认后再统一，比把含糊句子润色得更流畅更能保留业务含义。

如何验证

示意结果保留 Customer 与 User 的一对多关系，并把“删除 account”列为待确认。检查每个词能对应定义、同一概念没有随意换名、未知词没有被自动赋予删除含义。

若新材料正式定义 Account 为另一实体，应扩充词表并核对关系，而不是因先前未定义就永久禁用。

适用边界

词表可以演进，应记录版本与决定；它不替代领域确认。source 中的“禁止同义词”服务于特定词汇约定，不代表普通文章都不能使用自然同义表达。本篇计费关系是教学模型。