Lingo.dev 的 MCP 服务器让 AI 编码助手可以直接访问你的本地化引擎配置。本指南将带你从零开始完成本地化引擎设置——从安装到完整配置，涵盖按 locale 定制的品牌语调、术语表规则、语言指令和模型路由。
你将配置哪些内容#
| 层级 | 作用 | 示例 |
|---|---|---|
| 品牌语调 | 按 locale 设定语气和正式程度 | 面向德国开发者使用更随意的“du”，面向日语使用礼貌正式语气 |
| 术语表 | 自定义翻译 + 不可翻译项 | “Deploy” 在德语中译为 “Bereitstellen”，而 “OAuth” 在所有语言中都保持不变 |
| 指令 | 特定 locale 的语言规则 | 法语标点前使用不换行空格，日语使用全角字符 |
| 模型路由 | 按 locale 选择模型，并设置回退 | 欧洲语种组合使用 Claude Sonnet，日语回退到 GPT-4o |
最终你会得到一个有状态的翻译 API。你可以通过 localization API 在代码中调用它，通过 CLI 在命令行中调用它，或者通过 CI/CD 在每个拉取请求中自动运行。每一次请求都会自动应用所有层级。
问题是什么#
每个本地化引擎都需要按 locale 配置品牌语调、术语表规则、语言指令和模型路由。通过控制台手动配置这些内容既耗时又重复——尤其是第一次做时，你还得边学边弄，理解每一层的作用，以及它们之间如何相互配合。
Lingo.dev MCP 服务器可以让 AI 编码助手在一次对话中完成初始配置。你只需要把产品内容交给它，它就会创建引擎、编写品牌语调配置、识别术语表所需术语、添加特定 locale 的指令，并配置模型路由——一轮完成。你再在这个基础上审核并继续微调即可。
第 1 步：安装 MCP#
在 Lingo.dev 控制台的 API Keys 页面生成一个 API 密钥，然后把 MCP 服务器添加到你的编码代理配置中。
将其添加到你的 .claude/settings.json 或项目级别的 .mcp.json 中：
{
"lingo": {
"type": "http",
"url": "https://mcp.lingo.dev/account",
"headers": {
"x-api-key": "your_api_key"
}
}
}组织作用域
API 密钥决定了 MCP 服务器管理的是哪个组织。所有操作都会自动在该组织下执行——你的助手无需手动指定组织 ID。
重启你的代理后，让它列出当前已有的本地化引擎，以验证连接是否成功。如果 MCP 已启用，它会返回结果（新组织则可能返回空列表）。
第 2 步：配置引擎#
复制下面的提示词并粘贴到你的 AI 编码助手中。将末尾的 URL 替换为你的产品官网、文档或 README——代理需要有代表性的内容，才能推断你的语调、术语和目标受众。
Create a localization engine called 'My Product' for localizing into
German, French, Japanese, and Spanish. Study the content at the URL
below to understand our tone, terminology, and audience. Then configure
everything in one pass: brand voices for each locale (and English),
glossary entries for terms that need consistent translations or should
stay untranslated, and locale-specific linguistic instructions.
https://docs.yourproduct.com别忘了替换 URL
这个提示词最后有一个占位 URL。请将它替换为能真实体现产品表达风格的内容链接——比如文档、README、引导流程或营销网站。否则，代理生成的配置会比较通用。
代理会读取你的内容，创建引擎，并一次性完成所有层级的配置。接下来的步骤，就是审核并微调它生成的内容。
第 3 步：微调品牌语调#
检查代理为每个 locale 创建的 品牌语调。品牌语调定义了你的产品在某种语言中“怎么说话”——包括语气、正式程度和风格。代理会从你的内容中推断这些，但其中的文化细微差别仍然值得你亲自确认。
重点检查：
| Locale | 常见调整项 |
|---|---|
| 德语 | 使用“du”（非正式）还是 “Sie”（正式）——取决于你的受众 |
| 法语 | 使用“tu”（非正式）还是 “vous”（正式）——取决于面向消费者还是企业客户 |
| 日语 | 礼貌等级——对大多数产品来说，礼貌正式体（です/ます）是更稳妥的选择 |
| 英语 | 源语言的品牌语调往往会缺失——建议补上，以保持整体一致 |
一个配置得当的德语品牌语调通常会像这样：
Use informal "du" address. Keep a direct, technical tone.
Prefer short sentences. Use active voice. When a German equivalent
exists for a technical term, use it (e.g., "Bereitstellung" for
deployment), but keep widely-adopted English terms as-is
(e.g., API, CLI, Token).如果语体不对，直接告诉你的助手：
The German brand voice is too informal for our enterprise docs.
Switch it to formal "Sie" register.第 4 步：微调术语表#
检查代理创建的 术语表 条目。术语表让引擎能够精确控制特定术语——要么强制采用指定译法，要么完全不翻译。代理会从你的内容中识别术语，但它可能会漏掉产品特有术语，或者选错译法。
初次配置后，一个典型的术语表大致如下：
| 源文本 | 目标文本 | 源 locale | 目标 locale | 类型 |
|---|---|---|---|---|
| Deploy | Bereitstellen | en | de | 自定义翻译 |
| workspace | espace de travail | en | fr | 自定义翻译 |
| Lingo.dev | Lingo.dev | * | * | 不可翻译 |
| OAuth | OAuth | * | * | 不可翻译 |
需要检查：
- 遗漏术语——代理没有接触到的产品功能名称或内部术语
- 错误译法——代理可能会选用与你现有用法不一致的同义表达
- 遗漏的不可翻译项——应该保持原样的品牌名、协议名或缩写
术语表条目是按语义相似度匹配的——为 “Deploy” 建的条目，也会匹配 “Deploying”、“deployment” 和 “deploy your application”，无需分别单独建条。对于适用于所有 locale 的术语，可以使用 * 通配符。
Add a glossary entry: 'checkout' should stay as 'Checkout' in
German - it's our product feature name, not the shopping action.第 5 步：微调指令#
检查代理创建的 指令。指令是面向特定 locale 的、清晰且可测试的规则。和设定整体语气的品牌语调不同，指令编码的是通用模型常常忽略的规则——比如标点、缩写、字符宽度和数字格式。
初次配置后，一组典型的指令大致如下：
| Locale | 名称 | 规则 |
|---|---|---|
| fr | 法语标点空格 | 在 :、;、! 和 ? 前始终使用不换行空格 |
| de | 德语地址缩写 | 将 “Straße” 缩写为 “Str.”，将 “Nummer” 缩写为 “Nr.” |
| ja | 日语字符宽度 | 使用全角括号（）而不是半角 () |
每条指令只解决一个问题，因此可以单独测试——如果德语缩写规则出了问题，只需要更新这一条指令，不用动其他内容。
需要检查：
- 遗漏规则——目标 locale 中的数字格式、日期格式和货币习惯
- 源语言——英语中的牛津逗号、标题大小写或数字格式等指令经常会缺失
In French, there should always be a non-breaking space before
colons and semicolons. Add that as an instruction for fr.第 6 步：配置模型路由（可选）#
新引擎会预先配置好默认模型，针对常见语言和低资源语言的翻译质量做了优化。大多数团队都不需要调整。
如果你有特定需求——例如某个模型在你的领域表现更好、预算有限，或有合规要求——也可以覆盖默认设置：
Set Claude Sonnet as the primary model for European language pairs,
with GPT-4o as fallback for Japanese.每个模型配置都支持按优先级排序的回退方案。如果主模型失败（如服务中断、触发速率限制或被弃用），引擎会自动尝试下一个模型。
