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