用 Claude API 做翻译本身并不复杂，真正麻烦的地方在于：一旦文档变长、文件变多，或者进入技术文档、产品本地化这类场景，术语就很容易“跑偏”。很多团队遇到的并不是译文读不通，而是同一个功能名在不同页面被翻成了几种说法，API 名称被误译，缩写第一次出现和后面出现的写法对不上，甚至术语表里明明已经规定了标准译法，模型还是换成了看似自然的同义表达。

所以，专业翻译提示词的重点不应该只是“请翻译得自然”。更准确地说，目标应该是：让 Claude 按照你的术语表稳定翻译，并且在翻译完成后还能检查、定位问题、必要时返修。

这篇文章主要面向开发者、译者、技术文档团队和本地化负责人，介绍一套比较容易复用的 Claude API 术语一致性翻译方法。内容会从术语表设计讲起，然后聊到 System Prompt、XML User Prompt、API 参数、Python 调用示例，以及翻译后的质检流程。

为什么 Claude 翻译专业文本时会出现术语不一致？

大模型在翻译专业文本时出现术语不一致，其实很常见，原因也不止一个。

首先，模型本身就倾向于根据上下文做自然改写。比如“提示词”有时可能被翻成 prompt，有时又变成 prompt word；“上下文窗口”有时是 context window，换个段落可能又成了 contextual window。普通读者也许不会太在意这种差别，但放到技术文档、产品界面或帮助中心里，这就是典型的术语漂移。

另外，长文档分段翻译时，上下文很容易断开。第一章里“控制台”被翻成 console，到了第三章可能就变成 dashboard；某个缩写第一次出现时写了全称，后面的批次却忘了这个规则。尤其是批量翻译时，如果每一批输入的约束不一致，结果也很难保持统一。

还有一个常见问题是，术语表只是被放进了提示词里，但没有被明确声明为“必须遵守的规则”。这种情况下，模型可能会把它当成参考材料，而不是硬性约束。它会觉得自己可以根据语气、上下文或流畅度稍微改一改。

再就是品牌名、API 名称、类名、函数名、命令行参数、占位符这类内容，本来很多时候不应该被翻译。但如果提示词里没有专门说明，普通翻译任务很容易把它们也一起处理掉，结果反而出错。

因此，Claude API 翻译提示词的核心并不是简单写一句“请保持术语一致”。更可靠的做法，是把术语表、翻译任务、不可翻译内容、输出格式和质检流程都结构化地交代清楚。

术语一致性翻译的基本原则：术语表不是参考资料，而是硬约束

做术语一致性翻译时，有几个原则很值得先定下来。

第一，术语表要有清楚的边界。不要把术语表、源文和说明混在一起，否则模型很容易分不清哪些是规则，哪些是待翻译内容。比较稳妥的做法是用 XML 标签或 JSON 字段把它们分开。

第二，要明确要求使用 target_term。也就是说，只要源文中出现了 source_term，就必须使用术语表里对应的 target_term，不能临场发挥。

第三，要禁止同义替换。模型有时会为了让句子更顺，自动换成看起来差不多的词。对普通翻译来说这可能没问题，但对术语一致性翻译来说，这恰恰是需要避免的。

另外，还要区分强制翻译、禁止翻译和条件翻译。有些术语必须翻译成指定译法，有些品牌名、API 名、代码标识符应该保留原文，还有一些词则需要根据领域选择不同译法。

当然，没列进术语表的词，不必全部写死。术语表应该管理关键术语，而不是控制每一个普通词。否则译文会变得僵硬，读起来不像正常语言。

最后，翻译后一定要做质检。不能完全指望模型“自觉遵守”。比较专业的流程里，至少应该包括二次检查、禁用译法扫描，以及必要时的自动返修。

推荐的术语表格式：从 Markdown 到 JSON

如果术语数量很少，用 Markdown 表格就足够直观，也方便人工维护：

source_term	target_term	forbidden_terms	note
术语一致性翻译	terminology-consistent translation	term consistent translation	固定译法
提示词	prompt	cue word, prompt word	AI 场景使用 prompt
Claude API	Claude API	Claude interface	产品/API 名称保留

但如果你要通过 Claude API 做批量调用，JSON 会更合适。它更方便程序筛选术语、拼接 prompt，也方便后面做自动质检。

[
  {
    "source_term": "上下文窗口",
    "target_term": "context window",
    "domain": "AI / LLM",
    "definition": "模型一次请求中可处理的上下文长度",
    "forbidden_terms": ["contextual window", "context frame"],
    "case_sensitive": false,
    "do_not_translate": false,
    "example": "Claude has a large context window.",
    "note": "不要翻译为上下文框架"
  },
  {
    "source_term": "API Key",
    "target_term": "API Key",
    "domain": "developer documentation",
    "definition": "用于调用 API 的访问凭证",
    "forbidden_terms": ["API 密钥"],
    "case_sensitive": true,
    "do_not_translate": true,
    "example": "Set your API Key as an environment variable."
  }
]

常用字段可以这样设计：

字段	作用
source_term	源语言术语
target_term	指定译法
domain	适用领域
definition	帮助模型消歧
forbidden_terms	禁用译法
case_sensitive	是否大小写敏感
do_not_translate	是否保留原文
example	示例句
note	特殊说明

简单来说，格式可以按使用场景来选：

• 术语不多、主要靠人工维护，用 Markdown 就够；
• 需要程序化调用、批量翻译，JSON 更方便；
• 组织 Claude 提示词时，建议用 XML 标签分隔任务、术语表、源文和输出格式；
• 如果术语表很长，不要一股脑全塞进 prompt，最好先匹配源文，只传当前批次相关的术语。

Claude API 翻译提示词模板：System Prompt 怎么写

System Prompt 更适合放长期稳定的规则，比如角色定位、翻译原则、术语优先级和输出限制。下面这个英文模板可以直接作为基础版本使用：

You are a professional translation engine specialized in terminology-consistent translation.

Your task is to translate the source text according to the terminology glossary provided by the user.

Rules:
1. Use the target_term in the glossary exactly as provided.
2. Do not replace glossary terms with synonyms.
3. If a source_term appears multiple times, translate it consistently every time.
4. If a glossary entry is marked as do_not_translate, keep it unchanged.
5. If a forbidden term appears in your draft, revise it before final output.
6. Preserve numbers, units, code identifiers, API names, URLs, Markdown structure, code blocks, file paths, and placeholders.
7. If a source term is not included in the glossary, translate it naturally according to context.
8. Do not explain your translation unless explicitly asked.
9. Output only the translated text.

如果团队更习惯中文，也可以这样写：

你是一名专业翻译引擎，擅长执行术语一致性翻译。

你的任务是根据用户提供的术语表翻译源文。

规则：
1. 凡是源文出现术语表中的 source_term，必须使用对应的 target_term。
2. 不得使用同义词替换术语表中的指定译法。
3. 同一 source_term 多次出现时，必须保持译法一致。
4. 如果术语标记为 do_not_translate，必须保留原文。
5. 如果草稿中出现 forbidden_terms，最终输出前必须修正。
6. 保留数字、单位、代码标识符、API 名称、URL、Markdown 结构、代码块、文件路径和占位符。
7. 未列入术语表的内容，按上下文自然翻译。
8. 除非用户要求，不要解释翻译过程。
9. 只输出译文。

需要注意的是，System Prompt 不适合塞入所有源文和完整术语表。它更像是长期规则区。每次请求里具体要翻译什么、这批文本相关的术语有哪些，应该放在 user message 里。

User Prompt 模板：用 XML 分隔任务、术语表、源文和输出格式

Claude 通常更容易处理结构清楚的提示词。因此，建议用 XML 标签把不同内容分开：

<task>
Translate the source text from Chinese to English.
Follow the glossary strictly.
</task>

<glossary>
[
  {
    "source_term": "术语一致性翻译",
    "target_term": "terminology-consistent translation",
    "forbidden_terms": ["term consistent translation", "consistent terminology translation"]
  },
  {
    "source_term": "提示词",
    "target_term": "prompt",
    "forbidden_terms": ["cue word", "prompt word"]
  },
  {
    "source_term": "Claude API",
    "target_term": "Claude API",
    "do_not_translate": true
  }
]
</glossary>

<source_text>
用 Claude API 做专业术语一致性翻译时，提示词需要明确区分术语表、翻译任务和输出格式。
</source_text>

<output_format>
Return plain text only.
</output_format>

这样写的好处很明显：模型能更清楚地判断哪些是任务说明，哪些是术语表，哪些是待翻译文本，哪些是输出要求。尤其是长文本翻译时，不建议把源文直接接在说明后面，因为边界一旦混乱，就更容易出现误翻、漏翻或格式错乱。

完整示例：把中文技术文档翻译成术语一致的英文

源文：

在调用 Claude API 时，应将 API Key 放在环境变量中。对于长文档翻译，建议按章节切分，并为每个批次传入相关术语表。这样可以降低提示词膨胀，同时提高术语一致性翻译的稳定性。

术语表：

[
  {
    "source_term": "Claude API",
    "target_term": "Claude API",
    "do_not_translate": true
  },
  {
    "source_term": "API Key",
    "target_term": "API Key",
    "do_not_translate": true
  },
  {
    "source_term": "术语表",
    "target_term": "glossary",
    "forbidden_terms": ["term table", "terminology list"]
  },
  {
    "source_term": "术语一致性翻译",
    "target_term": "terminology-consistent translation",
    "forbidden_terms": ["consistent terminology translation"]
  },
  {
    "source_term": "提示词膨胀",
    "target_term": "prompt bloat",
    "forbidden_terms": ["prompt expansion"]
  }
]

预期译文：

When calling the Claude API, you should store the API Key in an environment variable. For long-document translation, it is recommended to split the content by chapter and pass the relevant glossary for each batch. This can reduce prompt bloat while improving the stability of terminology-consistent translation.

这里有几个地方值得看一下：

• Claude API、API Key 都保留了原文；
• “术语表”统一翻成 glossary；
• “术语一致性翻译”固定为 terminology-consistent translation；
• “提示词膨胀”固定为 prompt bloat；
• forbidden_terms 里的禁用译法没有出现在译文中。

Claude API 参数建议：temperature、max_tokens、system、messages 如何设置

做专业翻译时，参数设置应该优先考虑“稳定”和“可控”。

• temperature：建议设低一些，比如 0 到 0.2。较低的 temperature 通常能减少随机改写，也能降低术语漂移的概率。具体值可以根据文本类型做几轮测试，不必追求一个绝对固定的数字。
• max_tokens：要给译文留出足够的输出空间，避免长段落被截断。中译英并不一定会变短，技术文档还可能因为表达更完整而变长。
• system：放长期规则，比如术语硬约束、格式保留、禁止解释等。
• messages.user：放本次任务、相关术语表、源文和输出格式。
• 分段策略：长文不要盲目整篇提交。通常按章节、标题或自然段切分会更稳。
• 上下文策略：不要指望模型“记住上一批”。每次请求都要带上本批相关术语，以及全局不可翻译词。
• retry 策略：如果发现术语违规，不建议只是简单重试。更好的方式是先用质检 prompt 找出问题，再要求模型按违规项返修。

如果你使用的是第三方 Claude API 兼容接入服务，比如中文市场里常见的 ClaudeAPI 类平台，还要注意它们并不是 Anthropic 官方。这类平台通常会提供兼容接入、多线路选择、中文支持、企业充值、开票或基础技术协助等服务，但具体模型、价格、额度和服务规则，还是要以官网最新说明为准，不能默认等同于官方政策。

Python 示例：调用 Claude API 完成术语一致性翻译

下面这个例子展示的是基本思路。实际项目里，请把 API Key 放到环境变量中，不要直接写死在代码里。

import os
from anthropic import Anthropic

client = Anthropic(api_key=os.environ.get("ANTHROPIC_API_KEY"))

system_prompt = """
You are a professional translation engine specialized in terminology-consistent translation.

Rules:
1. Use the target_term in the glossary exactly as provided.
2. Do not replace glossary terms with synonyms.
3. If a glossary entry is marked as do_not_translate, keep it unchanged.
4. Preserve numbers, units, code identifiers, API names, URLs, Markdown, code blocks, file paths, and placeholders.
5. Output only the translated text.
"""

glossary = [
    {
        "source_term": "术语一致性翻译",
        "target_term": "terminology-consistent translation",
        "forbidden_terms": ["consistent terminology translation"]
    },
    {
        "source_term": "提示词",
        "target_term": "prompt",
        "forbidden_terms": ["prompt word"]
    },
    {
        "source_term": "Claude API",
        "target_term": "Claude API",
        "do_not_translate": True
    }
]

source_text = "用 Claude API 做术语一致性翻译时，提示词需要明确区分术语表和源文。"

user_prompt = f"""
<task>
Translate the source text from Chinese to English.
Follow the glossary strictly.
</task>

<glossary>
{glossary}
</glossary>

<source_text>
{source_text}
</source_text>

<output_format>
Return plain text only.
</output_format>
"""

message = client.messages.create(
    model="claude-3-5-sonnet-latest",
    max_tokens=1000,
    temperature=0.1,
    system=system_prompt,
    messages=[
        {"role": "user", "content": user_prompt}
    ]
)

print(message.content[0].text)

模型名称、可用版本和 SDK 用法都可能随着时间变化。生产环境里最好参考当前接口文档，同时做好异常处理、超时控制和日志记录，这些细节会直接影响批量任务的稳定性。

翻译后质检：如何检查 Claude 是否真的遵守术语表

专业流程不能停在“生成译文”这一步。比较稳妥的做法，是至少做两层检查：一层是 AI 质检，另一层是非 AI 的规则检查。

AI 质检 prompt 可以这样写：

<task>
Check whether the translation follows the glossary.
Do not rewrite the translation unless violations are found.
</task>

<glossary>
...
</glossary>

<source_text>
...
</source_text>

<translation>
...
</translation>

<output_format>
Return JSON:
{
  "passed": true,
  "violations": [
    {
      "source_term": "",
      "expected_translation": "",
      "actual_translation": "",
      "problem": "",
      "suggested_fix": ""
    }
  ],
  "revised_translation": ""
}
</output_format>

如果返回 passed: false，可以把 violations 和原译文再次提交给 Claude，让它只修正违规术语，不要重写整篇。这样返修范围更可控，也不容易引入新的问题。

同时，也不要完全依赖模型自查。很多规则检查用脚本就能完成，而且成本很低：

• 对强制术语做字符串匹配；
• 对大小写敏感术语做精确匹配；
• 扫描 forbidden_terms 是否出现在译文中；
• 检查 {user_id}、{{name}} 这类占位符有没有保留；
• 检查 URL、文件路径、命令行参数是否被改写；
• 检查数字、单位、Markdown 链接和代码块有没有被破坏。

这些检查非常适合接入 CI、批量翻译流水线或本地化平台。效果不一定花哨，但很实用。

长文档和批量翻译中的术语一致性策略

在真实项目里，术语一致性问题最容易出现在长文档和多文件翻译中。可以从下面几个方面入手。

首先，建立项目级 glossary。产品名、功能名、核心技术术语、禁用译法、不可翻译词，最好都统一维护。这样后续不管是谁翻译、用哪个批次翻译，都有同一套依据。

然后，每批只传相关术语。不要把几千条术语全部塞进 prompt。更合理的做法是先用 source_term 对源文做匹配，只把当前段落或章节会用到的术语传进去。

另外，全局不可翻译词要长期保留。品牌名、API 名、SDK 名、类名、命令、路径、占位符等内容，通常可以作为全局规则固定下来。

切分文本时，也要注意粒度。句子切得太碎，上下文会不够；整本手册一次提交，成本、延迟和截断风险又会升高。一般来说，按章节、标题或语义块切分会更自然。

对特别重要的内容，可以让模型为每批输出术语使用报告。不过正式译文和报告最好分开输出，避免污染最终交付格式。

批量翻译完成后，还应该做一次全局检查。比如扫描所有译文，看看同一个 source_term 是否出现了多个 target_term，禁用译法有没有混进去，关键术语有没有漏译。

这里还要区分翻译记忆和术语表。术语表控制的是“词怎么翻”，翻译记忆控制的是“相似句怎么复用”。两者结合起来，才更适合产品文档、帮助中心和软件本地化这类长期项目。

常见错误与修正方法

Claude 没按术语表翻译

这通常是因为提示词只说了“参考术语表”，却没有明确说“必须使用 target_term”。修正时，可以在 System Prompt 里直接声明术语表是硬约束，并加入 forbidden_terms。

Claude 改写了品牌名或 API 名称

把这些内容加入 do_not_translate，同时说明要保留大小写、空格、连字符和版本号。品牌和接口名称这类内容，最好不要让模型自行判断。

Claude 把代码也翻译了

在规则中明确要求保留代码块、函数名、变量名、命令行参数、文件路径和占位符。遇到复杂文档时，也可以在翻译前先用占位符保护代码块，翻译后再还原。

同一个术语出现多个译法

先检查分批翻译时是否传入了同一套相关术语表。长文档翻译不要依赖上一轮对话记忆，每次请求都应该带上当前批次需要的术语。

术语表太长导致成本高

可以先做术语匹配，只传源文中实际出现的术语。同时维护一份全局不可翻译词列表，避免每次都传完整大表。

译文被截断

提高 max_tokens，缩短单批源文，或者按章节拆分。不要在同一次请求里同时要求翻译、解释、报告和改写，否则输出空间很容易不够。

输出了多余解释

在 System Prompt 和 output_format 里都写清楚“只输出译文”。如果确实需要质检报告，建议单独调用一次，不要和正式译文混在一起。

Markdown 格式被破坏

提示词里要明确要求保留 Markdown 标题、列表、链接、代码块和表格结构。对复杂表格，最好逐块翻译，并在后面做格式校验。

JSON 输出不合法

如果要求 Claude 输出 JSON，字段尽量简单，不要让模型在 JSON 外再补充解释。生产环境里仍然要做 JSON parse 异常处理，不能默认每次输出都完全合法。

结论：一套可复用的术语一致性翻译工作流

用 Claude API 做专业术语一致性翻译，关键不是让模型“更聪明”，而是把任务边界说清楚，把术语规则变强，再配上一套能检查、能返修的流程。

实际落地时，可以按这个顺序来做：

• 准备项目级术语表；
• 标注 target_term、forbidden_terms、do_not_translate 和 condition；
• 翻译前筛选当前批次相关术语；
• 用 System Prompt 固定术语硬约束；
• 用 XML User Prompt 分隔任务、术语表、源文和输出格式；
• 调用 Claude API，并使用较低的 temperature 和足够的 max_tokens；
• 翻译后执行 AI 质检和字符串/正则检查；
• 发现违规后，根据质检结果返修；
• 把新增术语写回 glossary 和翻译记忆。

说到底，重点并不是堆砌越来越复杂的提示词，而是把“术语一致性”从一句模糊要求，变成一套可执行、可检查、可返修的翻译工作流。