DeepL术语表功能如何设置并使用？
DeepL 术语表设置与使用全解：从网页版与 API 的创建路径、CSV 批量导入，到命中规则、审计留痕与不适用边界，帮你在合规前提下锁定译法一致性。
DeepL 术语表是什么：把译法从“个人习惯”变成“配置项”
DeepL 术语表（Glossary）可以理解为账户内的一层翻译约束配置：你为某个语言对登记一组“源词—目标词”的对应关系，翻译时命中这些词，就按登记的写法输出。它并不提升模型的语义理解能力，作用点只在词汇层——把“每次交付前都要人工把产品名再校一遍”的重复劳动，前移到一次可留存、可复用的声明上。
从工程视角看，术语表解决的是“表述漂移”。同一份中文材料交给三位译者，可能产出三种译法；交给同一位译者隔三个月再翻，也可能又变一种。术语表把这种漂移收敛成一个可导出、可比对、可交接的文件，使一致性从“人的自觉”转为“流程的默认值”。
本文按“功能拆解—场景映射—操作路径—审计与边界”的顺序展开。前两部分回答它是什么、适合放在哪里；中间给出网页版、桌面端、移动端与 API 的最短可达路径和回退方案；最后落到可审计性设计与不适用清单，帮助你在使用之前就判断什么时候不该用它。
功能拆解：术语表实际由四层能力构成
如果把术语表只当成“一个词表”，很容易低估它的实际构成。它至少包含四层能力，任何一层没有对齐，最终效果都会打折扣。
- 条目层：源术语与目标术语的一一对应，是约束的最小单位，也最直接。
- 语言对层：术语表绑定在具体的源语言与目标语言组合上，不同语言对之间彼此独立、互不通用。
- 作用域层：术语表可以设为默认自动应用，也可以在单次翻译、单份文档翻译、单次 API 调用时显式指定。
- 权限层：账户内的术语表由谁创建、谁能编辑、谁只能选用，决定了它能否成为团队资产而非个人草稿。
这四层里，最容易被忽略的是语言对层。有人建了一张中英术语表，转头去翻中日文档，发现毫无作用，于是判断“功能坏了”；实际原因是作用域没有覆盖到那个语言组合。排查时不妨先看语言对，再看条目，最后才怀疑功能本身。
与相邻概念的边界：术语表不做什么
术语表常被和翻译记忆库（Translation Memory，即复用历史译文的句库）混为一谈，但两者作用机制完全不同：术语表只约束词汇，逐条命中、逐条替换，不检索历史；翻译记忆库按句子相似度召回既有译文，管的是句式与段落。术语表条目写得再多，也不会让模型因此学会你的行文风格。
它也和“在提示里叮嘱一句”不同：临时说明是一次性的，随会话结束而消失；术语表是持久配置，可跨会话、跨设备、跨协作者生效。反过来说，术语表不适合承载临时约定——这类内容应写进任务说明，而不是污染长期配置。
第三组容易混淆的是“后编辑”。后编辑是译后修正，术语表是译前约束；判断标准很简单：如果某类错误每次都要人工改一遍，且形态高度固定为“某个词被译成了别的说法”，它就适合进术语表；如果错误形态是语序、语气、断句，术语表帮不上忙。下面的对照表把两者的差异压缩成几个关键维度。
| 对比项 | 术语表 | 翻译记忆库 |
|---|---|---|
| 作用单位 | 词或短语 | 句子或句段 |
| 触发方式 | 精确命中后强制替换 | 相似度召回后建议替换 |
| 主要收益 | 专名与合规用语一致 | 减少重复句的返工 |
| 典型失效 | 词形变化、跨行断词 | 新句式无历史可召回 |
合规视角：术语表里该放什么、不该放什么
讨论合规时，主线应放在数据留存上。先要认清一件事：术语表不是“阅后即焚”的临时输入，而是账户内的持久配置。写进条目的内容会随账户保存，直到被主动删除或账户终止。这意味着它的合规属性更接近“配置文件”，而不是“临时粘贴的文本”。
由此可以推出一条清晰的准入规则：进入术语表的，应当是“即使被长期保存也不会造成风险”的内容——产品名、商标、法规条文的固定译法、行业标准术语。反过来，客户真实姓名、身份证件号、未脱敏的合同条款、内部代号，都不应出现在条目里。这些内容一旦进了术语表，就等于在配置层留下了一份副本，而且往往被人遗忘。
关于 DeepL 对订阅方案的数据处理说明，官方有公开表述，且会随条款更新而变化，本文不做复述。可操作的做法是：在把术语表投入生产前，回到官方隐私政策与订阅协议，核对当前版本对“配置数据”与“翻译文本”的区分。这一步不能省略，也不能靠第三方转述替代。
提示：验证术语表是否真的生效，可以用一条可控的复现步骤。新建术语表，登记“示例词→SampleTerm”，然后翻译一句包含“示例词”的短句。若输出中稳定出现 SampleTerm，说明约束已生效；随后删除该条目再翻同一句，若输出回退为常规译法，说明约束确实来自术语表而非巧合。
网页版最短路径：创建、编辑与选用
截至当前的最新版本，术语表的完整管理能力集中在网页版。最短可达路径是：登录 DeepL 账户后，在左侧导航中找到“术语表”（Glossary），进入列表页，点击“创建术语表”，依次填写名称、选择源语言与目标语言，然后逐条添加或整批上传。保存后，该术语表即出现在可选列表中。
选用路径有两条：一是在术语表列表里把某一张设为默认，之后在翻译器中自动生效；二是在翻译器界面的术语表选择器中临时切换。前者适合“一个语言对长期只用一套词表”的稳定场景，后者适合“同一语言对下按客户切换词表”的并行场景。
失败分支需要提前知道。若左侧导航里根本看不到“术语表”，先确认当前订阅方案是否包含该功能——免费方案通常不提供术语表管理，权益以账户订阅页显示为准。若入口存在但目标语言在下拉中不可选，说明该语言组合不在术语表支持范围内；这不是配置错误，而是功能边界。
桌面端：以“选用”为主，维护建议回网页
Windows 与 macOS 桌面应用提供术语表相关入口，具体位置会随版本调整，建议在设置区域或翻译界面的语言选项附近查找，以实际界面为准。经验性观察是：桌面端更适合日常翻译时切换已建好的术语表；复杂的批量导入、条目清理与语言对调整，回到网页版完成更稳妥。原因在于桌面端与网页版的更新节奏并不同步，管理类功能的完备度通常也会滞后一些。
移动端：受益方而非管理方
iOS 与 Android 应用的术语表管理能力有限。实践中，移动端主要是“受益端”——只要账户级已配置默认术语表，移动端翻译也会应用约束；但新建、批量编辑、导入导出这些操作，建议放在桌面浏览器完成。若你在手机上找不到术语表入口，不要据此判断账户没有该功能，先回到网页版确认。
API 路径：把约束写进请求
程序化调用时，术语表是一种显式参数：创建术语表走术语表资源接口，翻译请求里带上对应的标识即可。端点区分免费与付费环境，字段名与配额请以官方 API 文档为准；下面仅是结构示意：
POST https://api.deepl.com/v2/glossaries auth_key=...&name=legal_zh_en &source_lang=ZH&target_lang=EN &entries_format=csv &entries=数据留存,data retention POST https://api.deepl.com/v2/translate text=...&target_lang=EN &glossary_id=<上一步返回的标识>
需要留意的是回退路径。如果术语表标识失效（例如已被删除），翻译请求可能直接报错，而不是静默降级。生产环境应当把“术语表不可用”作为一个显式分支来处理：记录日志、回退到无术语表翻译并触发告警，而不是让整批任务失败。
条目配置：单条添加与 CSV 批量导入
单条添加适合补漏：在术语表详情页新增一行，填好源术语与目标术语，保存即可。批量导入适合初始化：网页版提供文件上传入口，通常支持逗号分隔的两列文本以及术语交换格式（TBX）。建议先在页面上下载官方模板，按模板结构填写，再用同一份文件导入，这样能规避大部分编码与分隔符问题。
CSV 的结构是两列：第一列源语言术语，第二列目标语言术语，一行一条。下面仅示意结构，实际以官方模板为准：
数据留存,data retention 术语表,glossary 后编辑,post-editing 神经网络,neural network
有三个细节经常导致导入后“看起来成功、实际不生效”。其一是编码：含非 ASCII 字符的文件应以 UTF-8 保存，否则会出现乱码条目。其二是分隔符：术语本身含逗号时，需要用引号包裹整段，否则会被切成三列。其三是行尾空白：肉眼不可见的空格会让“精确匹配”失效。
创建术语表时，通常还会有一个是否区分大小写的开关（界面文案随语言版本可能不同）。对品牌名这类大小写固定的对象，开启更安全；对普通技术词，关闭可以减少漏匹配。这个开关没有普适最优值，取决于词表里有多少“仅靠大小写区分含义”的条目。
警告：不要把整句塞进术语表。条目越长，命中条件越苛刻，稍有人称、时态或标点差异就会失配；同时长条目会掩盖模型本该处理的语义判断。术语表的最优条目长度是“词或固定短语”，超过一个短句就该考虑改用其他手段。
场景映射：三类最值得投入的词表
第一类是品牌与产品命名。假设某团队要把一份中文产品手册译成英文，手册里反复出现产品名与三个功能模块名。如果没有约束，模型可能把同一个模块名译出两三种写法，读者会误以为是不同功能。把这四五个名称写进术语表，一次配置，整本手册的称呼就统一了。
第二类是法规与合同用语。这类文本的译法往往不是“哪种更好”，而是“哪种已经被认可”。固定译法一旦确定，就不应随段落语境变化。术语表在这里的价值不是提升质量，而是消除随机性——让同一份材料在多次修订、多人协作中保持术语层面零漂移。
第三类是多市场物料的横向一致。同一条产品文案要出多个语言版本时，源语言侧的术语表可以保证中文表述本身先统一，再分别翻译。这一步常被跳过，结果是各语言版本各自漂移，最后很难追溯是哪一环引入的差异。
三类场景的共同点是：术语数量有限、复用频率高、错误代价明确。反过来，一次性的、术语密度极低的短文本，投入术语表维护的成本很可能高于收益。
应用链路：文本、文档与第三方协同
在翻译器里翻短文本时，术语表按当前选中的那一张生效。这里最实用的习惯是：开工前先看一眼选择器指向哪张表，收工后不要随手改动默认设置，避免下一个人接手时继承了错误的约束。
翻译整份文档时，上传文件后通常可以在翻译选项中指定术语表。这一步值得单独确认，因为文档翻译的产出往往是直接交付物，一旦术语没约束住，返工成本远高于段落翻译。建议先用一小段包含全部关键术语的样张试译，确认命中情况，再提交完整文件。
与第三方计算机辅助翻译工具协同时，通常通过 API 接入。原则是权限最小化：给集成方单独创建术语表或单独授权，不要让它持有账户主密钥；读取与写入分开授权；在集成方侧记录每次调用的术语表标识，便于事后追溯是哪一版词表影响了哪批译文。
可审计性设计：让词表经得起回看
术语表最大的隐性成本不是创建，而是半年后没人说得清“这条为什么这么写”。经验性观察是：界面侧通常呈现词表的当前状态，未必提供逐条变更历史。因此审计能力需要你在外部补齐，而不是指望产品内置。
第一步是命名规范。建议采用“语言对_用途_版本标识”的结构，例如 zh-en_legal 这类可读名称，避免“新建术语表 1”这种默认名。名称本身要能回答三个问题：给谁用、管什么、是不是最新。
第二步是导出留档。每次修改后导出一次，放进版本管理工具，让差异可对比、可回滚。这一步的关键不在于工具多先进，而在于把“导出”固化成流程动作，而不是想起来才做。
第三步是变更说明。条目增删改时同步记录一句原因，例如“依据某版术语规范调整”。这句话在半年后价值极高——它能区分“有意为之”与“手误”，而这恰恰是审计最需要的信息。
第四步是权限收敛。把“能编辑”与“能使用”分开：多数协作者只需要选用，不需要改动。编辑权限集中在少数人手里，词表才不会被一次次善意修改稀释成四不像。
故障排查：按现象定位，而不是靠猜
排查的顺序建议固定为：先确认术语表是否被选中，再确认语言对是否匹配，然后确认条目写法，最后才怀疑功能异常。这个顺序能覆盖绝大多数“没生效”的报障。
| 现象 | 可能原因 | 验证方法 | 处置 |
|---|---|---|---|
| 完全没替换 | 术语表未被选中，或语言对不符 | 查看选择器当前指向；核对源语言与目标语言 | 切换术语表或重建匹配语言对 |
| 部分句子替换、部分不替换 | 词形变化、大小写或断词差异 | 用含原形的短句单独试译对照 | 补充词形条目，或调整大小写开关 |
| 导入后条目数为零 | 编码或分隔符问题 | 用纯 ASCII 小样本重试导入 | 转存 UTF-8，含逗号术语加引号 |
| 接口调用报错 | 标识失效或参数缺失 | 单独查询该术语表是否存在 | 重建术语表并更新配置 |
还有一类现象值得单独说明：文档翻译时术语已生效，但导出后发现个别位置仍是旧译法。这通常不是术语表失效，而是该位置在原文中被断行或带了格式标记，导致匹配窗口被切断。把原文中该词前后的换行去掉再试一次，即可判断。
不适用清单：这些场景不要指望术语表
第一类是不支持的语言组合。术语表并非对所有语言对开放，创建时下拉列表已经做过过滤。若你的目标语言不在其中，与其反复尝试，不如改用译后统一替换的流程。
第二类是语法层面的要求。术语表管词，不管语序、不管敬语层级、不管标点习惯。想让译文统一使用某种句式，术语表无能为力。
第三类是需要上下文消歧的词。同一个词在不同段落有不同含义时，把它写进术语表反而会造成误伤——所有出现位置都会被强制替换成同一译法。这类内容应该留给译者判断。
第四类是高频变形的语言。在形态变化丰富的语言里，一个词可能有多种屈折形式，逐条穷举会让词表迅速膨胀到难以维护。此时更现实的做法是只约束不变形的专名，其余交给后编辑。
第五类是临时性约定。项目期间临时统一、项目结束就作废的写法，不该进长期词表。判断标准是：这条约定半年后还成立吗？如果答案是否定的，写进任务说明即可。
最佳实践清单：按决策规则落地
把上面的内容压缩成可直接执行的判断规则，会更容易在团队内推行。下面这份清单按“建—用—审—退”四步组织，每一步都给出触发条件。
- 建之前先问复用率：某个术语在该语言对下预计出现十次以上，才值得进表；只出现一两次的，直接人工修改更快。
- 一个用途一张表：法务、市场、产品分别建表，不要混装。混装之后，切换时容易误伤，也无法按用途授权。
- 先小样后全量：新表投入生产前，用一段包含全部关键术语的样张试译，确认命中情况后再批量使用。
- 默认表要克制：把默认术语表限制在“全账户通用”的那一张，其余靠显式选择，避免误用。
- 每次改完就导出：把导出动作绑定在修改流程里，而不是绑定在某个人的记忆里。
- 权限分读写：编辑权限收敛到少数人，使用权限放开，减少善意修改带来的漂移。
- 定期清理失效条目：产品改名、法规更新后，旧条目应及时下线，否则会持续误伤。
- 接口侧做降级：术语表不可用时回退到无约束翻译并告警，不让整批任务因一个标识失效而中断。
这份清单的核心逻辑是“用成本换确定性”。术语表把不确定性从译后前移到配置期，代价是配置期需要有人负责。如果你的流程里没有人对这个配置负责，那么术语表大概率会在三个月内退化成一份没人敢动的历史文件。
验证与观测：怎么确认它真的在起作用
定性判断很容易自欺——译文看起来“好像对了”，未必是术语表的功劳。建议用可复现的对照法：准备一句包含 3 个已登记术语的短句，分别在“术语表开启”和“术语表关闭”两种状态下翻译，比较输出差异。差异应当集中在登记的这三个词上，其余部分基本不变；若差异扩散到整句结构，说明条目可能写得太长。
批量场景可以做一个抽样观测：从待译材料中抽取包含关键术语的若干段落，记录术语在译文中的写法分布。如果同一术语出现两种以上写法，说明词表存在漏洞——可能是词形未覆盖，也可能是条目本身有拼写差异。这个观测不需要精确统计，只需定性判断“是否存在不一致”。
接口侧可以观测得更直接：在请求日志中记录每次调用携带的术语表标识与返回状态，定期统计“因术语表导致的失败”占比。这个比例应当维持在极低水平；一旦上升，通常意味着词表被删除或标识未同步更新。
常见问题（FAQ）
免费账户可以使用 DeepL 术语表吗？
术语表通常属于付费方案的功能范畴，免费方案一般不提供管理入口。判断方法很直接：登录后在左侧导航查看是否存在“术语表”入口；若没有，再核对账户订阅页显示的功能权益。权益内容会随方案调整，请以账户页面的实时显示为准，不要以第三方转述为依据。
修改术语表后，之前翻译好的文档会自动更新吗？
不会。术语表是在翻译发生时施加约束，已完成并导出的译文是静态结果，不会回溯重算。因此调整词表之后，受影响的既有文档需要重新翻译或人工替换。这也是为什么建议在批量交付前先做小样验证——改词表的成本，远高于改一次译文。
术语表条目数量有上限吗？
不同订阅方案的限制不同，具体数值请以官方文档和账户页面显示为准，本文不给出未经核实的数字。从实践角度看，真正的约束往往不是接口上限，而是维护成本：条目越多，含歧义、含变形、相互冲突的概率越高，词表也就越难保持可信。控制规模本身就是一种质量手段。
为什么同一个术语有的地方被替换、有的地方没有？
最常见的原因是词形变化与匹配边界。术语表按登记写法做匹配，源文中出现复数、变格、断行或标点紧贴时，可能落不进匹配窗口。其次是大小写开关设置与条目写法不一致。验证方法是把该词单独抽成一句试译：如果能稳定命中，说明问题出在原句的上下文而非词表本身。
删除术语表会影响账户里的其他配置吗？
删除操作针对的是该术语表本身，不会波及其他术语表或账户设置。但有两处连带影响需要提前处理：一是若它被设为默认，删除后翻译将回到无约束状态；二是若有 API 集成在引用该标识，请求可能报错而非静默降级。建议先解除默认与集成引用，再执行删除。
收尾：把术语表当成一份需要维护的资产
回到最初的问题：DeepL 术语表怎么设置、怎么用。设置的动作其实很短——在网页版建表、选语言对、填条目或导入 CSV、保存并选用；真正的难点不在点击路径，而在决定“放什么进去、由谁负责、怎么留痕”。把这三件事想清楚，术语表才会成为资产；想不清楚，它很快会变成一份没人敢动的历史遗留配置。
如果只记一条结论，建议是：术语表负责确定性，不负责质量上限。它能让专名和合规用语在多次翻译中保持同一写法，但无法让译文更通顺、更贴合语境。判断某个词该不该进表，看的是“它是否必须每次都一样”，而不是“它是否重要”。
下一步可以从最小闭环开始：挑一个正在进行的项目，找出其中出现频率最高、最不该被译错的三到五个词，建一张只包含这几条的术语表，用一段样张验证命中效果，导出留档，再投入完整文档。跑通这一轮之后，再考虑扩充条目、拆分用途、接入接口——顺序反过来，通常会在维护成本面前停下。