Lingo.dev 是由 AI 驱动的本地化工程平台，帮助产品团队将 LLM 转化为有状态的翻译 API，为应用、文档和内容稳定产出适用于生产环境的一致性翻译，覆盖所有语言。
上下文与本地化工程#
用 LLM 做翻译并不稀奇。任何团队都可以把一段字符串发给模型，再拿回一版译文。真正决定翻译是否足够出色的，只有两点：上下文和本地化工程。
上下文，是指模型在字符串本身之外所掌握的信息——产品是什么、受众是谁、品牌如何表达，以及不同语言区域各自遵循的表达习惯。没有这些，模型只能靠猜；有了这些，模型才能真正完成本地化。
本地化工程，就是把这些上下文沉淀为可复用、可复现的工程基础设施——包括术语表规则、语气正式度偏好、文化适配方式——从而确保每一条翻译在每个语言区域都能被一致执行。
少了这两者，你得到的只是翻译；有了这两者，你得到的才是本地化。
问题所在#
在 LLM 出现之前，团队只有两种选择——而且都不理想。
机器翻译速度很快，却在能力结构上无法理解产品上下文。团队明知 MT 输出会一点点消耗各个市场用户的信任，却仍不得不将其上线。
人工翻译足够准确，但扩展方式是线性的。每新增一个语言区域，都需要培训语言学家熟悉产品术语、品牌语调和领域概念。我们处理过超过 1 亿词、覆盖 42 种语言后发现：89% 的本地化延迟并非发生在翻译本身，而是出现在团队之间的交接环节。
这两种方式都把本地化当作项目管理流程。Lingo.dev 则把它视为工程问题。
你将构建什么#
在 Lingo.dev 上，团队会构建属于自己的本地化引擎。每个引擎都由以下要素组成：
按语言区域配置的 LLM 模型——为每个语言对选择合适的模型，并设置按优先级排序的回退方案。
品牌语调——定义你的产品在每种语言里该如何开口。比如德语使用正式的 "Sie"，意大利语使用非正式的 "tu"，法语使用礼貌的 "vous"。
术语表——将源语言术语映射为各语言区域中的准确译法。比如面向欧洲市场时，"911" 会变成 "112"；产品名称则保持不译。
指令——编码那些通用模型容易忽略的语言规则。比如西班牙语中的形容词位置、百分号前是否留空格，以及不同市场对代词正式度的要求。
质量评分——GEMBA 评分、BERTScore、术语表合规性、语言区域专属校验器。持续运行，全自动完成。
最终，团队可以将自身独有的洞察与偏好，与 Lingo.dev 自 2023 年以来持续推进的语言工程研究结合起来，从第一天起就以可预测的方式走向全球，在自己并不熟悉的语言中同样稳定扩展。
开源开发者工具#
Lingo.dev 的开源社区（GitHub 5,100+ stars）正在打造一系列开发者工具，将代码库连接到本地化引擎：
- CLI——直接在命令行完成翻译。从安装到产出首个翻译版本，只需 4 分钟。
- CI/CD——GitHub Actions、GitLab CI、Bitbucket Pipelines。让翻译随代码一同交付。
- Compiler——构建时 i18n。无运行时开销，也不会引发布局偏移。
- I18n MCP——为 AI 编码助手带来本地化感知能力：Claude Code、Cursor、GitHub Copilot。
