国产工业软件特惠推广月，有意者关注公众号PLM Vision发送“二维码“添加管理员！
如果说“文档语义化”解决的是 AI 能不能读文档，那么本篇要解决的，是一个更隐蔽、也更致命的问题：
AI 为什么“读了文档，还是答不对”？
答案往往不在模型，而在——术语混乱。
一、一个真实到不能再真实的问题
在 PLM场景中，你可能见过下面这些情况：
同一个对象：
零件 / 物料 / Part / Item / 组件
同一个动作：
发布 / 生效 / 冻结 / Release
同一个流程：
工程变更 / 设计变更 / ECO / ECN
而工程人员会问 AI：
“ECO 发布后，BOM 不一致一般怎么处理？”
但文档里写的是：
“ECN 生效后，物料结构需重新校验。”
人一眼就懂，AI 却可能完全匹配不到。
👉 这就是术语问题。
二、什么是“术语归一化”？
一句话定义：
把工程世界里“指向同一概念的不同说法”，统一映射到一个标准语义。
注意：它不是词典
很多人第一反应是：
“那不就是做个同义词表吗？”
但在工程场景中，术语归一化至少包含三层：
三、为什么不做术语归一化，AI 一定会失败？
3.1 向量检索不是“万能翻译”
向量模型确实能捕捉语义相似度，但在工程语境下：
ECO ≠ ECN（在很多企业里）
Release ≠ Effective
BOM 既可能是 EBOM，也可能是 MBOM
这些差异，往往是“制度定义”，不是语言相似度。
3.2 术语混乱带来的直接后果
1️⃣ 召回不全（该找的没找到）
2️⃣ 误召回（找了一堆不相关）
3️⃣ AI 回答“看似合理，实则违规”
👉 在 PLM 场景下，第三点是最危险的。
四、术语归一化在整体架构中的位置
先明确一句话：
术语归一化，介于“文档语义化”和“AI 问答”之间。
架构位置示意
它的作用不是“生成答案”，而是：
降噪
统一语义空间
提高召回稳定性
五、术语归一化应该“归一”什么？
5.1 第一类：对象类术语
👉 这类术语，直接影响检索范围。
5.2 第二类：动作 / 状态类术语
👉 这类术语，直接影响工程规则理解。
5.3 第三类：流程 / 业务类术语
👉 这类术语，决定 AI 是否“懂业务”。
六、怎么做（可落地方案）
下面是不依赖复杂 AI 训练、完全可工程化落地的做法。
6.1 构建“企业术语主表（Domain Terms）”
术语表结构建议
{
“canonical_term”: “Release”,
“aliases”: [“发布”, “生效”, “冻结”],
“domain”: “PLM”,
“object_type”: “ItemRevision”,
“notes”: “在本企业中 Release 等同于生效”
}
术语来源
PLM Help / Admin Guide
企业流程规范
现有模板、制度文档
老工程师经验（非常重要）
6.2 术语归一化的三个执行时机
① 文档入库时
文档切片后
统一替换 / 标注术语
写入向量前完成
👉 一次处理，长期受益。
② 检索 Query 时
用户问题先做术语展开
ECO → ECO + ECN + 工程变更
👉 提升召回率，但不改变底层数据。
③ 回答生成时（兜底）
AI 输出时统一用标准术语
同时标注“原始说法”
👉 适合做用户教育。
七、EasyKB 场景下的实现方式
结合上一篇的架构，这里给出一条现实可行路径。
7.1 不新增复杂系统
术语表：
YAML / JSON / 表格即可
归一化逻辑：
作为 EasyKB 的预处理插件
7.2 与权限 / 密级的关系
关键原则：
术语可以共享，内容绝不能共享。
普通库 & 高密级库：
共用术语主表
各自独立向量空间
👉 这在安全审计中是完全可接受的。
八、术语归一化之后，AI 会发生什么变化？
你会明显看到：
同样的问题，召回更稳定
回答用词更“像工程规范”
新人提问，也能命中老文档
但更重要的是：
AI 不再是“猜你懂什么”，而是“按你的工程语言工作”。
九、本篇你应该带走的 3 个关键认知
1️⃣ 术语问题不是模型问题，而是工程问题
2️⃣ 不做术语归一化，PLM 场景下 AI 一定不稳定
3️⃣ 术语归一化是“低成本、高收益”的关键一层
十、下一篇预告
《Teamcenter AI 实战指南（3）》将进入工程规则层：
结构化条件 —— 为什么 AI 不能“乱答”？
BOM 层级
生效条件
规则优先级
👉 这一步，才是真正让 AI “像资深工程师”。