本地化引擎是在 Lingo.dev 上构建并配置的有状态翻译 API。你不必再把字符串丢给通用 LLM，然后期待输出刚好符合预期；你构建的是一个能稳定产出理想译文的 API——无论面对哪个语言区域、哪一次请求，都能保持一致。
本地化引擎能做什么#
每个引擎都由五个可配置层组成。翻译请求到达时，引擎会自动应用全部配置——无需为每次请求单独设计提示词，也无需人工介入。
| 层级 | 控制内容 | 文档 |
|---|---|---|
| LLM 模型 | 为每个语言区域对指定处理模型，并配置按优先级排序的回退链路 | LLM 模型 → |
| 品牌语调 | 定义你的产品在每种语言中的表达方式——语气、正式程度和风格 | 品牌语调 → |
| 指令 | 面向特定语言区域的明确语言规则——可单独测试、单独调试 | 指令 → |
| 术语表 | 按语言区域提供精确术语映射，并支持语义匹配——在引擎中优先级最高 | 术语表 → |
| AI 审校器 | 每次翻译完成后，使用独立的 LLM 进行自动评估 | AI 审校器 → |
各层如何协同工作#
引擎会按既定顺序应用各层，并遵循清晰的优先级规则：
- 术语表——优先级最高。一旦命中术语表规则，就会覆盖模型判断。
- 指令——中等优先级。特定语言区域的语言规则会引导模型输出。
- 品牌语调——提供整体语境，定义该语言区域的语气、正式程度和风格。
模型配置决定由哪个 LLM 处理请求；如果主模型失败，系统会自动回退。AI 审校器会在翻译完成后异步运行——绝不会阻塞响应。
彼此互补，而非相互替代
设计术语表、指令和品牌语调时，应让它们相互配合。术语表负责精确术语，指令负责特定语言区域规则，品牌语调负责整体表达风格。如果术语表条目与某条指令冲突，以术语表为准。
通过 Async Localization API 提交的任务，还可以接入可选的 pipeline——包括 AI 源文预编辑、人工审核、AI 后编辑以及回译偏移检查。
默认配置#
创建新引擎时，系统会预先配置好默认模型——主模型和回退模型基于三年来每周开展的本地化研究精选而成，并针对常见语言和低资源语言的翻译质量一并做了优化。大多数团队都无需改动。
这些默认配置开箱即用，表现出色。你可以编辑任意模型配置、切换提供商、添加回退链路，或覆盖特定语言区域对——但这些默认值已经凝聚了我们在数百种语言对中的最佳实践。品牌语调、指令和术语表默认均为空——你可以随着对产品在各语言区域需求的理解不断加以补充。
如何使用引擎#
你可以通过所有 Lingo.dev 集成方式使用引擎：
| 集成方式 | 接入方式 |
|---|---|
| CLI | 在 i18n.json 中设置 engineId——每个 lingo.dev run 都会通过你的引擎路由 |
| API | 使用你的 API 密钥调用 localize 端点——引擎会自动应用所有层 |
| CI/CD | 使用同样的 CLI 配置——每次拉取请求中的翻译都会通过你的引擎执行 |
| MCP | AI 编码助手可以直接在对话中配置并使用引擎 |
如果省略 engineId，系统会使用你所在组织的默认引擎。
可观测性#
每一次翻译请求都会被记录：使用了哪个模型、消耗了多少 token、是否由回退模型处理，以及应用了哪些术语表条目和指令。你可以在 Reports 中监控引擎性能，在 AI Reviewers 中查看翻译质量。
在配置正式上线前，你可以先在 Playground 中测试引擎配置——将你的引擎与原始模型对比，或将两个引擎并排比较。
