Scribe 让邮箱签名变得简单且可量化：企业可以在全公司范围内统一部署风格一致、符合品牌规范的签名，无需为每位员工单独设置，还能把签名变成可衡量的营收渠道。这家公司成立五年，已经验证了强劲的产品市场契合度。在一次彻底的产品重构中，Scribe 将整个产品和文档一次性上线为 16 种语言。接入耗时不到一天；此后，两位创始人亲自完成本地化工作，无需招聘专人，也无需外包给代理机构。他们通过 Lingo.dev 的 MCP server 与 Claude 反复迭代，完成了整套引擎配置——术语表、品牌语调、各 locale 指令，以及对每条翻译进行 AI 质量评分。

"Lingo.dev 给了我们一套可通过 API、MCP 和 CLI 驱动的本地化引擎，直接运行在我们自己的技术栈里。对工程优先的团队来说，根本不用多想。"

Clément Champau，Scribe CEO 兼联合创始人

为什么五年后才开始做本地化#

AI 让本地化对一个两人团队也变得切实可行，而时间点又刚好碰上一次完整的产品重构——全新的 UI、全新的 UX，也正是顺势宣布支持 16 种语言的最佳时机。经过五年发展，Scribe 已经拥有强劲的产品市场契合度和稳定的 UI，因此不必担心界面频繁变动导致反复重译。

市场也在朝同一个方向推动。部分企业买家仍处在数字化阶段，而不是直接采用 AI；在不少市场里，如果产品不讲本地语言，销售流程里就会多出明显阻力。Scribe 先从最接近收入的市场入手：法语，包括法语非洲地区；西班牙语，以拉美优先；以及英语。这三种语言基本覆盖了大部分西方世界和拉丁美洲。之后，他们又扩展到 GDP 最高的市场——瑞士、挪威、瑞典。正如 Clément 所说："欧洲最高 GDP，世界最高 GDP。"

为什么“工程优先”平台成了决定性因素#

Clément 是通过 Y Combinator 名录发现 Lingo.dev 的；他一直会关注新的 YC 工具，并倾向于尽早采用。真正让他拍板的，是这个平台在技术栈中的位置。Lingo.dev 是一个本地化工程平台：一套可配置的本地化引擎——术语表、品牌语调、各 locale 指令，以及独立为输出打分的 AI 质量评分——由 API、MCP server 和 CLI 驱动。它运行在开发流程的最前层，就像团队运行其他基础设施一样。

"我们想要的是位于开发流程最前层的东西。你需要 API，你需要 MCP——一旦有了这些，我们就能很轻松地把这种乐高积木接进自己的智能体工作流。"

Scribe 的联合创始人兼 CTO Gil 看完 API 文档后，判断这套东西足够扎实，并在不到一天内完成了全部接入。

"我把它发给了 Gil。他看了 API 文档，说这东西靠谱，不到一天就把所有东西都接好了。"

CEO 如何通过 MCP 配置整套引擎#

在一天内完成接入后，尽管 Clément 并不是开发者，他还是通过 Lingo.dev 的 MCP server 亲手配置了整套引擎——品牌语调、术语表，以及各 locale 指令。最终配置规模相当可观：16 套品牌语调、133 条指令、644 个术语表词条。

这个迭代闭环非常具体。他先跑一种语言，打开应用查看效果，截屏，再通过 MCP 发回去：这里把 CTA 弄坏了，那里把 UI 弄坏了。然后 Claude 就会调整三大杠杆——术语表、指令、品牌语调——直到输出稳定为止。之后，他再跑完整翻译，继续推进其余语言。

"我会先跑一种语言，看看应用，截屏，再通过 MCP 发回去——这里把 CTA 弄坏了，这里把 UI 弄坏了——然后 Claude 会不断调整术语表、指令和品牌语调，直到结果正确。"

这个智能体还会在同一工作流里主动出手。在为重构后的首页做 SEO 优化时，Claude 发现 Google 把本地化页面当成英文页面的 fallback，而不是独立的 locale 目标页面。由于它能通过 MCP 访问这套引擎，它直接重新运行了 Lingo.dev sync 来修正这个问题。

不会这些语言，怎么验证翻译质量？#

这套引擎会自己衡量输出质量。在 Scribe 的多次运行中，AI 质量评分平均约为 87/100，约 96% 的已评分翻译达到 70 分及以上——这为两位并不亲自阅读这 16 种语言的创始人提供了清晰的质量信号。

Scribe 目前大约在 95% 的完成度就会发布，并把人工后编辑视为未来随着规模扩大、补上最后差距的路径。逻辑很简单：如果产品真正解决了用户的问题，用户不会因为翻译还没打磨到绝对完美，就放弃使用它。

"即便只有 95%，也已经足够好了。如果你解决的是一个真实问题，而用户也确实需要这个解决方案，那么翻译不够完美，并不会阻止他们使用产品。"

本地化该自建，还是采购？#

Clément 曾把 Lingo.dev 推荐给自己的一位投资人；这位投资人同时也是 CTO，而且此前已经在内部自建过本地化系统。他的反应，基本给“自建还是采购”这个问题下了结论。

"我向我们的一位投资人推荐了 Lingo.dev，他同时也是 CTO。他之前自己在内部做过本地化系统，而他的反应是：这正是我们当初应该用的东西。如果我早知道，我就会投资他们。"

真正让 Scribe 意外的成本，并不是最初搭建出来的那一下，而是后续维护——那些永远层出不穷的边缘情况，以及围绕如何持续改进系统而不断发生的决策成本。

"没有什么是容易的。一旦你开始处理所有这些边缘情况——而且它们永远不会停止出现——维护就会真正吞掉你的时间。更好的做法，是接入一个工程优先的方案，并且知道背后有一个团队在全天候打磨它。"

当 AI 负责执行具体工作，价值就转移到了系统设计者手里。本地化引擎——术语表、品牌语调、指令和 AI 质量评分——本质上是一套架构；而一个赶着 deadline 的内部团队，往往很难把它设计得同样出色。

计费上的摩擦，以及后来的修复#

早期，成本可见性还比较薄弱。Clément 必须先发起一次运行，再不断刷新界面，确认 credits 不会在中途耗尽；一旦耗尽，运行就会停止，他只能重新开始。他提出这个问题后，修复在同一周就上线了：运行前成本预估，以及自动充值使用指示器。

"现在我可以在开始之前就看到一次运行要多久、要花多少钱。以前我必须先启动运行，再不停刷新，确认 credits 不会用完，因为一旦用完，一切都会停下来，我们就得重来。"

这一改动让他可以提前预测结果——在运行开始前就知道耗时和成本。他特别强调的对比是：一边是提了需求后漫长等待，另一边则是看到请求的改动在一周内上线。正如他说的："祝贺你们拥有这么快的迭代闭环。"

现在进展如何#

Scribe 现在通过同一套本地化引擎，管理四个应用——Web 应用、桌面应用以及其他应用——外加文档，全部以英语为源语言。Autosync 目前仍然关闭；Gil 会在重大更新后手动触发运行，这个习惯最早源于一次 credits 问题，后来也因为大版本发布之后改动不多而延续了下来。等一切完全稳定后，他们计划开启 Autosync，让一次 push 就能部署到所有应用和文档。

MCP server 是进入这个平台的三种方式之一，另外两种是 API 和 CLI。大多数 MCP 要么只读，要么受上下文限制；而 Lingo.dev 的 MCP 让非开发者也能配置整套本地化引擎，因此 Gil 在完成一天的设置后，就能腾出手去做别的事。

"其实我几乎没怎么花时间在界面里，但它做得很好。"

引擎负责翻译；Clément 负责配置。

这对做软件本地化的小团队意味着什么#

Scribe 的上线方式揭示出一种不止适用于邮箱签名领域的模式。对于工程优先的团队来说，本地化已经从一个人力问题，转变成一个系统设计问题。翻译交给模型；剩下的工作，是配置那套负责管理模型的引擎——术语表、品牌语调、各 locale 指令，以及为输出打分的 AI 质量评分。

这种变化也改写了“自建还是采购”的算式。内部本地化最昂贵的部分，从来都不是第一版，而是维护：边缘情况、模型变化，以及随着时间不断累积的各 locale 规则。本地化工程平台能够吸收这些复杂性，这也是为什么一个两人团队能在没有专职本地化人员的情况下，跑起 16 种语言。

要把这种模式推广到其他团队，有三个前提。源内容要放在版本控制里。引擎由 API、CLI 和 MCP server 驱动，因此可以无缝接入团队现有的工作流。再加上 AI 质量评分，即使团队里没人会说这些语言，也能衡量输出质量——这正是“相信翻译”和“验证翻译”之间的区别。

他们这样说#

"当 AI 已经把执行做得这么好，价值现在就在架构这一侧——最好的系统设计者会胜出。如果是我自己来做，我不会设计出这么好的系统。"

"我向我们的一位投资人推荐了 Lingo.dev，他同时也是 CTO。他之前自己在内部做过本地化系统，而他的反应是：这正是我们当初应该用的东西。如果我早知道，我就会投资他们。"

"先为你想打开的市场跑一种语言。接进去，测试 MCP——它会自己把事情做好。真正让人豁然开朗的，其实就是 MCP。"

Clément Champau，Scribe CEO 兼联合创始人

Scribe 是一个电子邮件签名平台，数千家公司借助它在全公司范围内统一上线风格一致、符合品牌规范的签名，无需逐个员工配置，还能把签名变成可衡量的营收渠道。两位创始人用 16 种语言运营产品与文档，并将其配置成一套统一的本地化引擎，像管理其他基础设施一样来运行维护。他们的本地化体系基于 Lingo.dev。

常见问题#

集成本地化引擎需要多久？

不到一天。Scribe 的 CTO 看完 API 文档后，确认方案扎实可靠，不到一天就把 Lingo.dev API 接入了现有的 agent 工作流。之后，引擎配置——术语表、品牌语气，以及各语言区域的说明——则由 CEO 通过 MCP 服务器单独完成。

非开发者也能配置本地化引擎吗？

可以。完成一天的集成后，Scribe 的 CEO——有技术背景，但不是开发者——通过 Lingo.dev 的 MCP 服务器亲自完成了整套引擎配置：先跑通一种语言、检查应用效果，再让 Claude 反复调整术语表、说明和品牌语气，直到输出稳定达标。最终，这套配置覆盖了 16 套品牌语气、133 条说明和 644 个术语表条目。

不会目标语言，怎么验证翻译质量？

Scribe 依靠 AI 质量评分：每条翻译都会交由一个独立于生成模型的模型打分。在 Scribe 的多次运行中，平均分约为 87 分（满分 100 分），约 96% 的翻译得分在 70 分及以上。这让一个只有两个人的团队，即使并不亲自阅读这 16 种语言，也能获得可量化的质量信号；人工后期编辑则只在最后一步用来补齐剩余差距。

本地化应该自建还是购买？

Scribe 的两位创始人都有技术背景，原本完全可以在内部自建本地化能力。但权衡之后，他们选择了平台，因为他们考量的不是初始开发，而是后续维护。一位曾在公司内部自建过这套能力的投资人兼 CTO 说得很直接：这正是我们当初应该用的。真正会持续累积成本的，不是第一个版本，而是随着时间不断出现的边界情况和各语言区域规则。

本地化工程师实际是做什么的？

少做翻译，多做配置。在 Scribe，这项工作的重点是搭好引擎——术语表、品牌语气、各语言区域说明——并根据 AI 质量评分持续调优，而不是管理译者或文件。这个角色更接近平台工程，而不是供应商协调：你要设计并运营产出翻译的系统，而不是管理产出翻译的人。

如果要给正在评估它的同行一句建议，你会说什么？

“先针对你想开拓的市场跑通一种语言。把它接起来，测试一下 MCP——它自己就能把事情做好。真正让人眼前一亮的，其实就是 MCP。”