把 helloGPT 的术语库按“领域—粒度—语言—用途”四层架构来设计：先划分行业与通用词库，按词性和短语/句子粒度做子集，为每条术语添加标签、优先级、同义词与禁用项，配合版本控制、审校流程和导入导出接口，最终通过统计反馈不断迭代，保证一致性、可追溯并便于自动化调用。
先说结论，为什么要分类术语库
想象你在整理一间书房：把小说、工具书、参考文献分别放在不同书架上，比全部堆成一摞要好得多。术语库分类也是这个道理。它让翻译引擎知道在什么场景下优先使用哪个词、什么时候该用行业术语、什么时候用更口语化的表达，从而提高准确性和一致性。
分类的目标与原则
目标（你要实现什么）
- 提高翻译一致性：同一概念在相同场景下保持相同翻译。
- 提升可用性：快速检索并在机器翻译或检索时优先命中。
- 支持可审计与版本回滚：谁改了哪条术语、何时生效。
- 便于自动化：API 调用、批量导入/导出、与模型联动。
设计原则（怎么去做）
- 场景优先：按使用场景分层（行业/通用/品牌/项目）。
- 最小重复：相同术语放在最合适的层级，避免多重冲突。
- 可追溯性：每条记录要有来源、作者、版本和审核历史。
- 可扩展性：支持新行业、新语言快速加入而不破坏原结构。
- 实用性：不仅存词，还要存用法示例、上下文和禁用替代。
四层分类模型：从宏到微
把术语库想成四个逐层细化的抽屉：行业层、项目/品牌层、通用语义层、条目粒度层。每层有不同的优先级规则。
1. 行业（Domain）层
按行业划分：金融、医疗、法律、电子商务、游戏等。行业层包含行业专有词与常见术语。优先级高于通用层。
2. 项目/品牌（Project/Brand）层
针对某个客户或产品的专有名词、品牌表述、UI 标签、法规合规语句。用于覆盖行业或通用条目以满足个性化需求。
3. 通用语义（General）层
适用于多数场景的通用术语，如“提交”、“下载”等。作为默认后备库。
4. 条目粒度（Granularity）层
同一术语可以以“词—短语—句子”不同粒度存在。短语或句子级条目常用于固定表述、警告语或合同条款。
为每条术语设置的标准字段（元数据）
好的术语库不是只有“源词—目标词”。需要一套结构化字段，方便检索、优先级判断与审核。
| 字段名 | 说明 |
| id | 唯一标识符（UUID） |
| source_text | 源语言文本 |
| target_text | 目标语言文本（可多条） |
| domain | 所属行业（金融/医疗/电商） |
| project | 项目/品牌名称 |
| part_of_speech | 词性（名词/动词/短语/句子） |
| priority | 优先级（高/中/低） |
| tags | 自定义标签（简称、地区变体、术语族） |
| examples | 上下文示例（原文与译文） |
| forbidden | 禁用项或替代建议 |
| synonyms | 同义或近义表达 |
| language_pair | 语言对（如 zh-en） |
| status | 草稿/已审/废弃 |
| author | 录入者 |
| reviewer | 审核者 |
| version | 版本号与变更日志 |
| created_at / updated_at | 时间戳 |
具体设置步骤（一步步操作）
第一步：收集与去重
- 来源包括现有翻译记忆库（TM）、机器翻译输出错例、用户反馈、行业术语表、产品文档。
- 用简单的正则和分词做规范化（大小写、标点、全角半角、空格）后去重。
- 对高频短语做聚类，识别核心术语。
第二步：初步分层
- 把术语先放到“通用/行业/品牌”三个桶里。优先把明显行业词放行业桶。
- 如果一个词既是行业词又出现在品牌列表，标注“冲突”以便人工决策。
第三步：标注元数据与示例
为每条术语补全上表字段，尤其是示例句子。示例句能显著提升模型在上下文判断时的命中率。
第四步：设定优先级规则
- 规则示例：Project > Domain > General。同一冲突以优先级高者生效。
- 粒度规则：精确短语或句子优先于单词匹配。
第五步：审核与版本控制
- 每次修改应有提交说明与审核者签名。
- 用语义版本号（例如 v2026.05.01）记录发布时间，支持回滚。
第六步：导出/同步与接入
- 提供 CSV/TSV/JSON/ROSETTA 等格式导出，便于与翻译管理系统（TMS）对接。
- 提供 REST API，支持按 domain/project/language_pair 查询或批量替换。
实战样例：电商与医疗两个场景对比
电商（高频、短语为主）
- 常见术语：SKU、快递派送时效、退换货政策。
- 粒度优先：短语条目（“七天无理由退货”）优先于单词翻译。
- 示例：source_text=”七天无理由退货” target_text=”7-day no-questions-asked return”
医疗（专业、谨慎为主）
- 常见术语：检查名、医学缩写、药品成分。
- 需要：出处（指南/文献）、专业审核者签名与证据链。
- 示例：source_text=”冠状动脉粥样硬化性心脏病” target_text=”coronary atherosclerotic heart disease”（附出处：中华医学会指南）
冲突与优先级策略（常见问题）
术语冲突不可避免，关键是预先定义清晰的优先级策略并把冲突记录下来供人工决策。
- 规则化优先级：Project（品牌）> Domain（行业）> General（通用）。
- 粒度覆盖：Longest match wins（最长匹配优先）。短语/句子优于单词。
- 地区变体：对不同地区用不同语言代码（zh-CN, zh-TW, en-GB）并设置地区优先级。
工具与技术实现建议
存储与检索
- 关系型数据库（Postgres/MySQL）适合结构化元数据与事务管理。
- 全文检索引擎（Elasticsearch）适合模糊匹配与快速检索。
- 必要时用图数据库（Neo4j）维护术语之间的关系（同义、包含、替代）。
接口与自动化
- 提供 RESTful API：按 language_pair、domain、project、tags 查询，支持模糊和精确两种模式。
- 支持 Webhook：当术语更新时通知下游系统进行热加载。
- CI/CD 流程：术语变更通过审核后自动部署到线上服务。
质量控制与度量
- 关键指标：命中率（术语匹配占比）、人工纠错率、回退次数、平均修正时间。
- 抽样审核：定期抽取翻译结果对照术语库执行人工校验。
- 用户反馈：在产品中内嵌“建议替换”按钮，把建议回流到术语库。
治理与权限管理
术语库既要开放协作也要防止随意篡改。权限体系建议按角色细分：
- 管理员（Admin）：能增删项目、设置策略、回滚版本。
- 术语编辑（Editor）：能新增/修改条目，需提交审核。
- 审核者（Reviewer）：负责最终确认并发布。
- 只读用户（Viewer）：查询与导出权限。
实用小技巧（避免踩坑）
- 不要把口语与书面混在同一条目里：如“加油”在不同语境下翻译差异大，分别建条目并加标签。
- 别过度细分：条目数过多会拖慢检索速度，把低频或可由规则处理的项移到规则层。
- 示例优先：示例句比抽象定义更能减少歧义，尤其是多义词。
- 自动化测试：在模型更新或术语变更后跑回归测试，避免意外回退。
示例条目（演示格式）
下面给出一个简化的 JSON 风格条目示例（仅为说明字段，不是真正的 JSON 数据输出环境），帮助你把思路具体化：
| 字段 | 示例值 |
| id | term-000123 |
| source_text | 发货 |
| target_text | ship / dispatch |
| domain | 电商 |
| project | FastShop |
| part_of_speech | 动词/短语 |
| priority | 高（Project） |
| tags | 物流, UI |
| examples | 原文：“预计2日内发货” -> “Estimated to ship within 2 days” |
| forbidden | 不建议翻译为“deliver”用于出货动作 |
| status | 已审 |
如何把术语库和模型协同工作
术语库本身是知识层面，模型是执行层面。把术语库当作模型的“偏好词典”或“规则引擎”：
- 在推理阶段优先替换：先做术语匹配替换，再输入模型以减少误译。
- 或在后处理阶段替换：让模型翻译全句，再用术语库做一致性替换（注意上下文匹配）。
- 混合策略：对高优先级条目做前置替换，对低优先级做后置校正。
长期维护与社区驱动
术语库不是一次性产品。把维护当成习惯，建立反馈闭环：
- 定期回顾高纠错率条目并修订示例或优先级。
- 鼓励翻译团队、客服与市场提供用例，把真实用户语言纳入库内。
- 保留废弃历史，便于稽查与追责。
常见误区
- 误区一：把所有用法都硬编码成术语。实际应保留模型的创造性，仅对关键术语施加强约束。
- 误区二：把条目只写成单一翻译，缺少上下文示例会导致多义词错误。
- 误区三：缺乏版本控制，导致历史翻译不可回溯。
最后一点建议（实践中的小贴士）
一开始用简单的三层模型（项目/行业/通用）起步，把精力放在高频与高风险的术语；随着使用积累再引入细颗粒度、自动化检查与更复杂的优先级规则。慢慢来，比一次性把系统弄得面面俱到要有效得多。然后，你会发现术语库变成了一种习惯——团队里每次讨论翻译时，先去查一查术语库，好像顺手翻开那本老书，一切就更有底。