一句话定义：翻译术语表（Glossary）是一份"源词 → 指定译文"的对照清单，翻译时强制模型照表执行；术语库（Termbase）是它在翻译工具里的工程化版本，除译文外还带词性、定义、禁用译法和适用范围等字段。
为什么需要它：模型没有跨段落的稳定记忆。翻译长文常常要分段、分批送进去，每一次生成都是独立采样——前一段把 rendering pipeline 译成"渲染管线"，后一段可能就变成"渲染流水线"；同一个角色名，第三章叫"艾拉"，第五章变成"爱拉"。人翻长稿也会漂移，但人至少记得自己前面写过什么，模型不一定。
打个比方：这就像给新入职的译者发一本《公司内部叫法手册》——不是教他怎么翻译，而是告诉他"这几个词我们已经定死了，别自由发挥"。手册越薄越好用，通常只收三类词：产品名与品牌名、行业内有多个通行译法的术语、以及客户明确指定过的说法。
和相邻概念的区别：
| 概念 | 管到哪一层 | 典型作用 |
|---|---|---|
| 术语表 Glossary / Termbase | 词级 | 这个词必须这么译，全程强制 |
| 翻译记忆库（Translation Memory） | 句级 | 这句以前这么译过，直接复用 |
| 风格指南（Style Guide） | 语级 | 语气、人称、数字与标点格式 |
| 提示词里临时写一句 | 一次性 | 短文本够用，长文撑不住 |
术语表是"硬约束"，风格指南是"软引导"，两者常一起用，但不能互相替代。
对从业者的实际意义：
1. 一定要写"禁用译法"。只写"用 A"，模型仍可能冒出 B；写上"不要用 B"，命中率明显更高。
2. 按段落检索，而不是整表塞进去。术语表几百条时，全量塞进上下文既浪费又稀释注意力，通常做法是根据当前段落召回相关条目再注入。
3. 译完做一致性检查。用脚本或模型自查一遍"表内词是否都按指定译法出现"，比事后人工通读便宜得多。
4. 表要能改。术语争议应当在表里解决一次，而不是在每个项目里重复吵。
对普通职场人来说，这条概念最实用的地方是：下次让模型翻一份长文档，先在开头贴一张十来行的对照表（人名、产品名、关键术语），前后不一致的情况会少掉一大半。具体工具怎么建库、支持哪些字段，以各家官方页面为准。