# General Translation Knowledge Base: 如何在 AI 翻译中保持术语一致？
URL: https://generaltranslation.com/zh/kb/ai-translation-glossary.mdx
Docs index: https://generaltranslation.com/llms.txt
Description: 维护一份统一的词汇表来收录已批准的术语（包括无需翻译的名称），在每次翻译请求中都应用它，避免变量和代码被翻译，并对结果进行审校。General Translation 通过上下文组实现这一点：上下文组中的词汇表和自定义提示词会应用于其分配到的每个项目；对于始终不翻译的值，则可使用 Var 组件。
Category: 翻译
Last updated: 2026-10-28
Authors: General Translation Team
Published: 2026-10-28

要保持术语一致，需要维护一份统一的词汇表来收录已批准的译法，在每次翻译请求中都应用它，标记出绝不能翻译的文本，并在审校时检查输出结果。术语之所以会前后不一，是因为机器翻译引擎和大语言模型会单独处理每一次请求：除非你主动提供，否则上周选定的译法不会自动沿用到本周的翻译中。

## 为什么 AI 翻译会出现术语漂移？

假设你的产品有一个名为 Vault 的功能。如果逐条字符串将其翻译成德语，它可能在定价页面上变成 *Tresor*，在应用中保留为“Vault”，在文档中又变成 *Safe*。每个译文单独看都说得通，放在一起却像是在描述三个不同的功能。术语漂移的原因主要有以下几点：

* **每次请求都从零开始。** DeepL 的 API 参考指出，请求中的每个字符串都是[独立翻译的](https://developers.deepl.com/api-reference/translate/request-translation)。LLM 每次调用都会重新选择措辞，而换了新的模型版本，选择也可能不同。
* **短字符串携带的上下文很少。** 标为“Vault”或“Spaces”的选项卡看起来就是普通名词，引擎自然也就按普通名词来翻译。
* **不同用户交互界面使用不同工具。** 应用字符串用一个工具，文档用另一个，营销页面又交给供应商，结果就是要维护三份词汇表，或者干脆一份都没有。
* **语法会改变词形。** 德语和波兰语的名词要加格词尾，因此经过审定的译文只是一个基本形式，需要在句中进行屈折变化，而不是能直接粘贴的字符串。

需要制定规则的术语通常包括：品牌和产品名称、功能名称、文档中引用的 UI 标签 (“点击**保存**”必须与各语言中的按钮文字保持一致) 、领域术语，以及所有必须原样保留的内容：代码、变量、URL 和用户数据。

## 这些方案有何区别？

| 方案                                        | 如何保持术语一致                                                                               | 不足之处                                    |
| ----------------------------------------- | -------------------------------------------------------------------------------------- | --------------------------------------- |
| 机器翻译词汇表 (DeepL、Google Cloud Translation)  | 按语言对配置术语对，每次请求时通过 ID 应用                                                                | 每次调用都要传入 ID，并逐一维护各个语言对；短字符串仍然缺少上下文      |
| 在 LLM 提示词中列出术语 (OpenAI API、Claude API)    | 在每条提示词中列出术语和规则                                                                         | 需要自行判断每个字符串用到哪些术语；除非自己实现检查，否则输出不会经过任何校验 |
| 翻译管理系统 (TMS) 中的术语库                        | 译者和 AI 可以看到已批准的术语；质量保证检查会标记遗漏                                                          | 术语库存放在 TMS 中，与代码相互分离，且每个项目都需要单独连接       |
| 禁止翻译标记 (`translate="no"`)                 | 翻译引擎会跳过被标记的元素                                                                          | 仅适用于 HTML 输入；只能保持文本不变，无法选择译法            |
| General Translation 上下文组                  | 词汇表和自定义提示词会应用于每个已分配项目中的所有翻译；[`<Var>`](/docs/react/reference/components/var) 可将值排除在翻译之外 | 现有译文只有在应用词汇表或重新翻译后才会更新                  |

### 机器翻译词汇表

DeepL 的[多语言词汇表](https://developers.deepl.com/docs/customize/managing-glossaries)为每个语言对保存一个术语对字典，支持以 TSV 或 CSV 格式上传，单个请求最多可通过 `glossary_ids` 应用五个词汇表。Google Cloud Translation 的[词汇表](https://docs.cloud.google.com/translate/docs/advanced/glossary)既支持单个语言对的术语对，也支持跨多种语言的等效术语集，可从 TSV、CSV 或 TMX 文件导入。Google 默认区分大小写匹配术语，除非设置了 `ignoreCase`；它会同时返回使用和未使用词汇表的译文，便于对比；此外，其上下文词汇表模式仅适用于 Translation LLM。

### LLM 提示词中的术语

使用 OpenAI API 或 Claude API 时，词汇表就是提示词里的一段文本。只发送该字符串中实际出现的术语，要求模型按 JSON schema 输出，并在事后检查每个已批准的术语是否都已体现在译文中。模型能很好地遵循指令；但术语筛选、结果检查，以及在各个脚本之间保持列表同步更新，都得由你自己负责。

### TMS 中的术语库

[翻译管理系统](/kb/what-is-a-translation-management-system)会将术语库与字符串放在一起管理。译者在编辑器中能看到匹配的术语，AI 翻译也能利用这些术语 (Crowdin 的 [AI 提示词](https://support.crowdin.com/crowdin-ai/)可以包含词汇表术语) ，质量保证检查则负责发现遗漏：如果某条译文中的源词没有采用词汇表规定的术语，Crowdin 的[术语一致性](https://support.crowdin.com/project-settings/qa-checks/)检查就会将其标记出来。

### 禁止翻译标记

将 HTML 的 [`translate` 属性](https://html.spec.whatwg.org/multipage/dom.html#the-translate-attribute)设为 `no`，即可告知翻译工具保留该元素的文本不做改动。当 `tag_handling` 为 `html` 时，DeepL 会跳过标记了 `translate="no"` 或 `class="notranslate"` 的元素 ([Translating HTML](https://developers.deepl.com/docs/translate/translating-html)) ；Google Cloud Translation 处理 `text/html` 输入时同样如此 ([故障排除](https://docs.cloud.google.com/translate/troubleshooting)) 。纯文本请求则会忽略该属性。

如果你在自己的流水线中直接调用 DeepL 或 Google，请使用机器翻译词汇表。如果翻译本就是产品现有模型调用的一部分，请使用提示词指令。如果译者和供应商都在某个 TMS 中工作，请使用该 TMS 的术语库。如果要将 HTML 发送给翻译引擎，请使用 `translate="no"`。如果希望每次发布时，同一批术语在应用、文档及其他内容中始终保持一致，又不想在每个脚本中逐一传递词汇表，请使用 General Translation。

## General Translation 如何保持术语一致

General Translation 通过[上下文组](/docs/platform/dashboard/guides/defining-context-for-translations)来统一术语：上下文组是一组可复用的指令，在组织级别进行管理，并作用于你为其分配的每个项目。每个上下文组都包含一个用于管理术语的词汇表，以及用于控制语气和风格的自定义提示词。

### 设置上下文分组

1. 在仪表板中，打开组织侧边栏中的 **Context**，点击加号，然后选择 **Create new group**。如果改从项目的 **Context** 页面创建，还可以选择 **Autogenerate context**，根据该项目的文件自动生成词汇表术语和自定义提示词的草稿。
2. 在 **词汇表** 标签页中逐一添加术语，并为每个术语编写定义，说明其含义及处理方式。
3. 填写每个目标区域设置的译文：可以手动输入，可以导入 CSV、TSV 或 JSON 文件，也可以在项目的 **Context** 页面点击 **Translate**，让 AI 为尚无译文的术语补全翻译。之后可按需修改任意单元格。
4. 在 **自定义提示词** 标签页中添加语气和风格规则，例如仅适用于德语的“Use the formal Sie”。每条提示词既可应用于所有区域设置，也可仅应用于某一个区域设置。
5. 在每个项目的 **Context** 标签页中，将该组分配给项目。多个组重叠时，以列表中排在最上方的组为准。

以 Vault 为例，其词汇表可能如下所示：

| 术语        | 定义               | `de`           | `ja`    |
| --------- | ---------------- | -------------- | ------- |
| Vault     | 加密文件夹的产品名称。保留英文。 | Vault          | Vault   |
| Workspace | 应用中团队的共享区域。      | Arbeitsbereich | ワークスペース |

默认的 **管理员** 和 **编辑者** 角色均可编辑上下文分组。

### 词汇表如何作用于每条译文

General Translation 在翻译每个字符串时，会找出其中出现的词汇表术语，并将这些术语的定义及其在目标区域设置中的译文随字符串一并发送。模型会以批准的译文为基本形式，根据句子进行相应的词形变化；如果某个词的用法与其定义不符，则按常规方式翻译。同一套上下文组适用于 [`<T>`](/docs/react/reference/components/t) 内容、使用 [`npx gt translate`](/docs/cli/reference/commands/translate) 翻译的文件、使用 [`tx`](/docs/node/reference/functions/tx) 进行的运行时翻译，以及由 [Locadex](/docs/platform/locadex/quickstart) 生成的译文，因此应用、文档和营销网站都会统一使用“Vault”。

### 使用 `<Var>` 让值不参与翻译

有些文本必须原样保留，例如名称、ID、代码以及其他运行时值。General Translation 的 [`<Var>`](/docs/react/reference/components/var) 会按原样渲染其中的内容，这些内容也永远不会发送到 General Translation API：

```tsx title="InviteBanner.tsx"
import { T, Var, Plural, Num } from 'gt-react';

export function InviteBanner({
  inviterName,
  vaultCount,
}: {
  inviterName: string;
  vaultCount: number;
}) {
  return (
    <T context="Team settings banner. Vault is our product name for an encrypted folder.">
      <p>
        <Var>{inviterName}</Var> invited you to their workspace.{' '}
        <Plural
          n={vaultCount}
          one={<>You can open one Vault.</>}
          other={<>You can open <Num>{vaultCount}</Num> Vaults.</>}
        />
      </p>
    </T>
  );
}
```

邀请人的名字放在 [`<Var>`](/docs/react/reference/components/var) 中。&quot;Vault&quot; 则留在句子里，由词汇表确保它保持英文，模型再围绕它组织语法；[`<Plural>`](/docs/react/reference/components/plural) 则涵盖目标语言所需的全部复数形式。产品名称应放入词汇表，而不是 [`<Var>`](/docs/react/reference/components/var)：这样模型能看到该名称，并据此调整句子。

### 更新已有译文

编辑上下文分组只会影响新生成的译文，不会改变已有译文。如需让已有内容与之保持一致，请在项目的 **Context** 页面点击 **Apply**，然后选择要更新的词汇表术语和区域设置；也可以通过 CLI 或一次 Locadex 运行重新翻译文件。 (参见[应用术语表翻译](/docs/platform/dashboard/guides/defining-context-for-translations#apply-glossary)。) 之后，请懂该语言的人员在仪表板中检查结果。 (参见[如何审校和编辑译文？](/kb/review-translations))

## 常见问题

### 词汇表能保证每次都使用批准的术语吗？

词汇表会将批准的术语设为默认译法，但最终仍要靠审校把关。语法可能要求使用不同的词形，而用作其他含义的词也不应套用词汇表中的译法。请对每种语言中访问量最高的界面进行审校，具体做法参见[AI 翻译的准确度足以用于生产环境应用吗？](/kb/is-ai-translation-accurate)

### 如何让品牌名称不被翻译？

在词汇表中将其添加为术语，定义可写为“产品名称。保留英文。”，并在每个区域设置中直接使用该名称作为译文。如果要将 HTML 发送给 DeepL 或 Google Cloud Translation，请将品牌名称包裹在带有 `translate="no"` 标记的元素中。

### 词汇表和翻译记忆有什么区别？

词汇表用于统一单个术语的译法。翻译记忆则保存以往的完整译文，当相同或相似的句子再次出现时直接复用。 (参见[什么是翻译记忆？有了 AI 还需要它吗？](/kb/what-is-translation-memory))

### 一个词汇表能否同时覆盖我的应用、文档和网站？

可以。在 General Translation 中，为所有项目分配同一个上下文分组，仅当某个用户交互界面需要使用不同的术语或语气时，再为相应项目添加专属的组。 (这种方式与在每次请求中传递词汇表 ID 的做法有何不同，请参阅 [General Translation vs. DeepL](/kb/general-translation-vs-deepl)。)

## 要点总结

* 术语之所以会出现不一致，是因为每次翻译请求都彼此独立，而短字符串本身携带的上下文又很少；为每个请求都应用词汇表，就能统一默认译法。
* DeepL 和 Google Cloud Translation 按语言对、通过 ID 应用词汇表；使用 LLM 提示词时，需要你自行筛选术语并进行检查；TMS 术语库则额外提供质量保证检查，例如 Crowdin 的 术语一致性。
* `translate="no"` 能让 HTML 文本在 DeepL 和 Google Cloud Translation 中保持原样，但它并不能指定译法。
* General Translation 的上下文组可让所有已分配的项目共享同一套词汇表和自定义提示词；**Translate** 会为指定区域设置补全缺失的术语译文，**Apply** 会更新现有译文，而 [`<Var>`](/docs/react/reference/components/var) 则能让运行时值完全不参与翻译。

## Related questions

- [AI 翻译的准确度足以用于生产环境应用吗？](https://generaltranslation.com/zh/kb/is-ai-translation-accurate.mdx): 对于使用广泛的语言，通常可以，但前提是它要先通过针对你自己的语言、UI 字符串和高风险内容的评估。在 WMT25 中，Gemini 2.5 Pro 在 16 个语言对中有 10 个达到或超过了人工参考译文的水平，但文档级基准测试无法说明简短的界面字符串是否已经可以上线。
- [DeepL 替代方案：General Translation 与 DeepL 对比](https://generaltranslation.com/zh/kb/general-translation-vs-deepl.mdx): DeepL 是一款机器翻译 API，你发送的每段文本或每份文档，它都会返回对应的译文。General Translation 则是一个本地化平台，它补足了 API 留给你自行处理的部分：来自代码和团队的上下文、在所有用户交互界面中保持一致的术语、在仪表板中进行审校，以及随每次发布持续翻译。
- [面向开发者的最佳 AI 翻译工具：翻译 API 与本地化平台对比](https://generaltranslation.com/zh/kb/best-ai-translation-tools.mdx): 如果你已经有自己的本地化流水线，可以直接使用翻译 API；如果你希望统一管理上下文、一致性检查、审校和持续交付，请选择 General Translation。DeepL、Google Cloud Translation、OpenAI 和 Claude 可以作为生产环境流水线的翻译引擎；而 General Translation 则直接为你的应用、文档和网站提供一整套流水线。
- [如何审阅和编辑译文？](https://generaltranslation.com/zh/kb/review-translations.mdx): 将每条译文与其源内容及其他区域设置的版本进行对比，修正读着别扭的地方。借助 General Translation，你可以在仪表板的翻译页面中编辑译文，并通过标签和评论跟踪审阅进度；其 AI 智能体 Locadex 下一次运行翻译时，会将这些修改纳入拉取请求。
- [什么是翻译记忆库？有了 AI 还需要它吗？](https://generaltranslation.com/zh/kb/what-is-translation-memory.mdx): 翻译记忆库（TM）是一个存储既往源文与译文片段对的数据库，翻译工具会在其中查找完全匹配、上下文匹配和模糊匹配。即便使用 AI，你仍然需要复用已批准的措辞，并将过往译文作为上下文。General Translation 会复用早期文件版本中匹配的译文并保留团队所做的修改，无需另外维护一套 TM。

## Previous and next questions

- Previous question: [如何在 .NET 应用中翻译 .resx 文件？](https://generaltranslation.com/zh/kb/translate-resx-files.mdx)
- Next question: [如何在 Payload CMS 中翻译内容？](https://generaltranslation.com/zh/kb/translate-payload-content.mdx)

## Sitemap

See the [Knowledge Base sitemap](https://generaltranslation.com/zh/kb/sitemap.md) for every article.