Laurel 是一个面向专业服务行业的工作智能平台。企业使用 Laurel 来自动记录工时、洞察盈利驱动因素，并证明其 AI 投资的 ROI。直到最近，这款产品还只有英文版本。如今，它已支持十多种语言——包括北欧语言、法语、荷兰语、葡萄牙语、西班牙语和韩语——同时普通话、泰语、阿拉伯语、日语和越南语也已进入规划。

Laurel 的集成过程很直接——大部分工作都在他们自己这边，主要是提取并整理现有文案，为代码库做好准备。相比之下，自建方案预计需要 4 到 6 个月的工程时间，后续还要无限期持续维护。我们发现，一旦把可能因此错失的交易算进去，“不买”的总成本大约是“购买”的 10 倍。现在，新增一种语言只需要一天——产品经理一个人就能完成。放在十八个月前，这句话听起来简直不可思议。

“我很喜欢 Lingo.dev 的合作方式：他们迅速介入，真正理解了我们的问题，并给出了对应的解决方案。我们不需要自己搭建本地化基础设施——他们把这件事处理得非常到位。企业版定价合理，而且我们和他们的工程师共用一个 Slack 频道。遇到边缘情况时，响应时间按小时计。”

—— Nick Bazley，Laurel 资深产品经理

SaaS 公司应该在什么时候投资本地化？#

Nick Bazley 是 Laurel 的资深产品经理。过去六年里，随着公司将产品推向全球市场，他一直在带领产品团队一路扩张。在这件事真正落地之前，他已经思考本地化将近一年。

“我们一直知道，迟早得做这件事，”Nick 说，“问题只在于——什么时候？每次聊到这个话题，结论都一样：这会是个 XXL 级的大项目，耗时很久，而且我们还无法完全确定最终产出的质量。”

Laurel 持续增长，客户也从中端市场扩展到全球性企业。一个清晰的模式开始出现：先在某个地区签下客户、验证价值，然后客户就会希望跨区域扩展。

随着销售团队在欧洲各地扩张、客户成功团队不断接到扩展诉求，Nick 能明显感觉到这个问题正在逼近。

“当时我们需要推进这项工作时，团队大约只有 50 人。要自己搭建本地化基础设施，代价会非常高——半个团队要被牵制好几个月，而我们还有很多真正该为客户去建设的东西。”

为什么购买本地化基础设施，而不是自己搭建？#

摆在 Laurel 面前的有两个选择：买，或者自己造。自建很可能会是一项横跨多个季度的工程，内部预估就是一个 XXL 项目——需要 4 到 6 个月的工程时间。“承担自建本地化基础设施的成本、时间和精力，并不是明智之举。以我们当时所处的增长阶段来看，对业务最合理的选择，是从市场上购买最好的解决方案，把精力集中在打造核心平台上。”

在这场讨论中，最终推动决策的关键主要落在四点上：上市速度、上线后的可扩展性、可定制性，以及质量。

“我们并不是本地化基础设施方面的专家。我们也不知道最终质量会怎样。既然已经有人围绕本地化工程建立起完整业务，我们为什么还要承担这种风险？”

如何评估本地化平台，而不是传统 TMS#

Nick 先用 Perplexity Pro 快速做了一轮搜索，梳理市场、浏览排名靠前的结果，并发现了一家传统 TMS。之后，他又通过 Google 搜索找到了几个其他选项，而 Laurel 的工程负责人也独立发现了 Lingo.dev。

于是，他对两者展开了并行评估。

“那家传统 TMS 表面上看起来确实是一家非常成熟、非常顺滑的公司，”Nick 说，“但当我们真正剥开表层，去看他们到底有什么、以及我们真正需要什么之后，为了达到我们追求的速度和质量，选择其实只有一个。”

“我很欣赏 Lingo.dev 的一点是，他们一上来就真正理解了我们的问题、我们想实现什么，并拿出了相应的解决方案。企业版定价合理，而对速度和质量的承诺，是驱动我们决策的关键。最打动我的是这种可达性。我们和真正构建这个平台的工程师共用一个 Slack 频道。遇到边缘情况时，周转时间按小时算。几乎让人觉得他们就是我们团队的一部分。”

AI 本地化在法律和会计术语上到底有多准确？#

Laurel 的用户是法律和会计专业人士。如果德语界面把 “billing rate” 或 “matter” 这样的词用错了，不只是观感不好，更会削弱用户对整个产品的信任。法律和会计术语必须足够精准。

Nick 用真实客户测试了质量。第一轮先交给北欧客户和一位法国客户。北欧团队没有任何反馈。那位法语母语客户只指出了两处不准确：团队立即把它们加入术语表。此后，在荷兰语、葡萄牙语、西班牙语等语言中都没有再出现问题。

我们在六个月内，与母语客户一起对 12 种语言的质量进行了测试。最终只报告了两处术语问题，而且都在当天通过补充术语表解决。结果证明，配置了术语表的本地化引擎，在法律术语的一致性上，比从零开始自建翻译逻辑更强——因为这个引擎能够同时在所有语言对之间统一执行术语，这一点是人工流程无法保证的。

“我们已经有一段时间不需要再回到术语表里做任何调整了。”Nick 说。

给 SaaS 产品新增一种语言，到底要多久？#

过去，当客户成功经理反馈某位客户需要葡萄牙语界面时，这个请求通常会先进入路线图、再排优先级、等待进入某个冲刺，然后一等就是几周。

现在，Nick 会创建一张工单，引用此前新增语言的工单作为模板，把任务交给 AI Tooling，然后等待。接着，这套工具会把新语言加入配置、更新语言切换器，并发起一个 PR。工程师审核 PR 并发布后，Lingo.dev 就会以自动驾驶模式持续处理本地化。

“一天是指端到端——从撰写工单到 PR 完成。但这不意味着我一整天都在做这件事。大部分时间里，我其实在处理别的工作。”

借助 AI 编码工具和 Lingo.dev 的本地化基础设施，Nick 无需占用工程带宽就能新增一种语言。

“有了 Lingo.dev，现在公司里的任何人都可以新增语言，并调优我们的本地化引擎。这真的非常了不起。”

本地化速度会如何影响企业交易推进速度？#

这个商业案例的重点并不只是节省工程时间——虽然它确实做到了。更重要的是，确保我们能够快速响应不断变化的扩张机会。

“对于企业客户来说，扩张机会可能会很快出现，”Nick 说，“我们的客户可能会先在某个新办公室取得一些进展，如果我们能迅速把产品提供成他们的语言版本，他们就会希望在那里进一步扩展。为了持续增长，我们必须能够毫无障碍地以这样的速度做出反应。”

Laurel 最初先上线了五种北欧语言和法语，以支持其首次欧洲扩张。此后，销售和客户成功团队又推动了葡萄牙语、西班牙语、荷兰语等需求——而现在，随着我们向全球各地办公室扩展，他们还在讨论更多语言。

我们统计过：在集成后的六个月里，Laurel 因客户扩张需求新增了七种语言。每一种都不到一天就能完成。如果采用“自己搭建”的模式，这七种语言大约会消耗 28 个工程冲刺——而这些产能后来被用于核心产品功能。

本地化基础设施，应该自建还是购买？#

当被问到，他会如何建议一家类似公司的产品副总裁——企业级 B2B、专业用户、正在全球扩张、工程团队还有大量真实产品工作要做——Nick 毫不犹豫。

“我百分之百会选择供应商。”

如果他们选择自己搭，最容易低估的是什么？“复杂性和质量。你根本不知道最终质量会是什么样。为什么要承担这种风险？”

如果他们选择供应商，最容易做错的又是什么？就是对自身问题理解得不够清楚，结果选错了供应商。“真正理解你要解决的问题，并为这个具体问题选择合适的供应商——这一点至关重要。”

最先该测试什么？“速度和上市时间。完成初始设置之后，接下来要看的就是速度和可扩展性。”

等待的真实成本#

初始设置大部分由 Laurel 自己完成，主要是让技术栈准备就绪。之后呢？每增加一种语言只要一天，不需要工程冲刺，也不用再为路线图优先级来回拉扯。

另一种选择则是花三到四个月工程时间去自建，之后还要无限期持续维护，而且对于团队里没人会说的语言，他们也无法保证质量。

Nick 的总结很直接：“本地化基础设施不是那种做完就能翻篇的项目。它是持续性的——每次扩张、每次进入新市场、每次新增功能，都会涉及它。它必须足够简单。我不想一再回头去找工程团队，再要一个冲刺来交付我们需要的一切。”

这对拓展新市场的产品团队意味着什么#

Laurel 的经历揭示了一个在面向国际企业客户的 B2B SaaS 公司中反复出现的规律：本地化会从“一个功能需求”，演变成“限制增长的瓶颈”。团队不再纠结“我们要不要做本地化？”，而是开始思考“我们能多快进入下一个市场？”

Laurel 的选择由三个因素决定：团队无法把宝贵的工程资源投入到并非核心产品的基础设施上；法律和会计术语的质量必须可验证，而不能凭感觉判断。

本地化工程的思路，是把语言支持当作一层配置能力，而不是一个工程项目。产品经理无需排 sprint、无需占用工程带宽，也无需协调翻译供应商，就能新增一种语言。对于那些市场扩张速度直接决定营收增长的团队来说，这样的运营转变，往往就是抓住机会与错失机会的分水岭。

Laurel 为法律和会计专业人士打造 AI 产品。他们的产品已覆盖十多种语言，而且新增一种语言只需一天。他们的本地化基础设施由 Lingo.dev 提供支持。

常见问题#

为 SaaS 产品新增一种语言需要多久？

Laurel 端到端新增一种语言大约只需一天。产品经理会创建一张工单，参考此前新增语言的案例，交给 AI 编码代理执行，再由工程师审核 PR。无需专门排一个 sprint，也无需协调供应商。相比之下，之前的备选方案——内部自建本地化基础设施——预估需要四到六个月，而且在此之前无法上线任何新语言。

初创公司应该自建还是采购本地化基础设施？

Laurel 的 Staff PM Nick Bazley 评估过自建与采购两种方案。他的结论是：“我们不是本地化基础设施方面的专家。我们也无法判断最终质量会怎么样。既然已经有人围绕本地化工程建立了完整的业务，我们为什么还要承担这个风险？” 按估算，自建会是一个 XXL 级项目，数月内就要占用半个工程团队。

AI 本地化在专业术语上的准确度如何？

Laurel 在六个月内联合法律和会计领域的母语客户，对 12 种语言进行了测试。术语问题总共只有两个，而且都通过补充术语表在当天解决。本地化引擎可以同时在所有语言对之间强制执行术语表一致性——这一点是人工自建方案在规模化时无法保证的。

本地化速度会如何影响企业销售周期？

Laurel 的经验是：当企业客户提出新增语言支持的需求时，他们期待的是几天内得到答复，而不是几个月。Nick Bazley 这样描述这种现实：“机会窗口不会一直敞开。如果我们没法在一周内完成响应，机会可能就没了。” 切换到本地化基础设施之后，Laurel 在六个月内新增了七种语言——每一种都不到一天。

本地化的自建与采购，成本差距有多大？

Laurel 的对比很直接：一边是较短的集成周期和持续的按使用量计费成本，另一边是四到六个月的工程投入来自建，再加上无限期的维护成本，以及他们无法保证的质量。按自建模式计算，六个月内新增这七种语言大约会消耗 28 个工程 sprint——而这些资源后来都投入到了核心产品功能上。