用 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_termtarget_termforbidden_termsnote术语一致性翻译terminology-consistent translationterm consistent translation固定译法提示词promptcue word, prompt wordAI 场景使用 promptClaude APIClaude APIClaude 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 标签把不同内容分开taskTranslate the source text from Chinese to English. Follow the glossary strictly./taskglossary[ { 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 } ]/glossarysource_text用 Claude API 做专业术语一致性翻译时提示词需要明确区分术语表、翻译任务和输出格式。/source_textoutput_formatReturn 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 bloatforbidden_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 放到环境变量中不要直接写死在代码里。importosfromanthropicimportAnthropic clientAnthropic(api_keyos.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_promptf 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 messageclient.messages.create(modelclaude-3-5-sonnet-latest,max_tokens1000,temperature0.1,systemsystem_prompt,messages[{role:user,content:user_prompt}])print(message.content[0].text)模型名称、可用版本和 SDK 用法都可能随着时间变化。生产环境里最好参考当前接口文档同时做好异常处理、超时控制和日志记录这些细节会直接影响批量任务的稳定性。翻译后质检如何检查 Claude 是否真的遵守术语表专业流程不能停在“生成译文”这一步。比较稳妥的做法是至少做两层检查一层是 AI 质检另一层是非 AI 的规则检查。AI 质检 prompt 可以这样写taskCheck whether the translation follows the glossary. Do not rewrite the translation unless violations are found./taskglossary.../glossarysource_text.../source_texttranslation.../translationoutput_formatReturn 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 和翻译记忆。说到底重点并不是堆砌越来越复杂的提示词而是把“术语一致性”从一句模糊要求变成一套可执行、可检查、可返修的翻译工作流。