AI Agent 国际化一个真实的 monorepo，会发生什么？

它提取了 28 个 UI 字符串候选项，跨多个文件重写了 41 条翻译条目，配置了中间件和路由，并为 5 种目标语言生成了语言文件。配置、转换和翻译端到端约 90 分钟。globalize.now 是 AI 驱动的本地化基础设施，我们在一个生产环境 monorepo 上实测了一把，看看会发生什么。没有精心准备的 demo，也没有兜底方案，只有一个真实的、有真实复杂度的代码库。

这个代码库的主人是一位本地化行业老兵，他曾在头部翻译管理平台担任架构师十余年。

这个 monorepo 里有什么？

这不是教程里的示例项目。这个 monorepo 包含一个 Next.js Web 应用、一个 Android 应用、若干 MCP 服务端，以及由第三方服务渲染的文档。这位开发者每天使用 Claude Code，全程借助 AI 工具构建，整套技术栈只用了三个月搭起来。

目标是 Next.js 前端。Android 应用、MCP 服务端、基于 Mintlify 的文档站，这些都不该被动。问题在于：AI Agent 能否在没有明确指示的情况下自己判断出来。

它做到了。Agent 扫描了整个仓库，并聚焦在 Next.js 应用上。实际使用中无需手动划定范围，不过这位开发者表示，如果能指定“只转换 /apps/web”，他会更放心。这个意见很中肯，值得加入，但它并没有妨碍这次转换。

配置过程是怎样的？

开发者选择了引导模式，以便了解整个流程。配置涉及五项决策：包管理器（NPM，尽管仓库里还留有旧的 PNPM 锁文件）、目录格式（PO/GetText，因其支持注释而被推荐）、配置模式（引导模式）、源语言（英语）以及目标语言（西班牙语、意大利语、匈牙利语、捷克语、斯洛伐克语）。

有一点值得一提：即便是深耕本地化多年的人，也会在目录格式这个问题上犹豫。他的反应很直接：他认为这个选择没重要到需要去问用户，直接自动化就好。

路由策略采用基于路径的方式。由于开发者没有额外的域名，因此没有使用基于域名的路由。应用使用 OAuth 认证，所以登录流程按设计保持英文。Agent 正确地处理了这一点。

转换步骤到底做了什么？

这才是关键。Agent 在 Next.js 应用中识别出 28 个 UI 字符串候选项，并处理了 41 条翻译条目。它重新组织了文件结构，更新了中间件，修改了组件的 import，并为全部 5 种目标语言生成了 PO 语言文件。

仅转换步骤就耗时约 30 分钟。再加上之前的配置，以及开发者事后自己完成的翻译连接，端到端接近 90 分钟。这谈不上即时完成。作为参照，只有寥寥几个页面的简单应用，整个流程可以在 15 分钟内走完；而有几十处可翻译界面的复杂应用则会更久。耗时取决于字符串数量，而不是仓库大小。

开发者看着转换步骤运行，说了这样一段话：字符串提取和代码重写才是真正的重活，也是开发者最头疼的活。在他之前任职的头部 TMS 公司，仓库里的翻译文件只是冰山一角，真正痛苦的是前期准备和国际化改造。而 AI Agent 处理的正是这一块。

这与我们从每位手动做过 i18n 的开发者那里听到的一致。没人抱怨翻译本身，大家抱怨的是：为了用 t() 包裹字符串要改 40 个文件，要生成有意义的键，要重构 import，还要配置中间件。这些正是 globalize.now 自动完成的工作。

端到端真的跑通了吗？

跑通了。现场演示结束后，开发者自己完成了剩余步骤：发布 globalize.now 的 Git 分支，将应用连接到 Web 平台，把监控指向 globalize.now 分支，并确认文件已成功上传且翻译无误。

他对捷克语翻译质量的评价是：接近完美。说这话的人，职业生涯一直在专业评估本地化产出。这不是泛泛的点赞，而是领域专家对一个不简单的语言对给出的“可用于生产环境”的确认。

在独立走完流程后，他指出了 Web 应用中的两个问题。第一，重新扫描仓库时显示“未检测到 i18n 文件”，而翻译任务其实正在后台运行。这是误导性的界面状态，并非真正的故障。第二，翻译任务在没有明确同意的情况下就启动了。任何消耗额度的操作都应该先经过确认。这两个都是合理的 UX 问题，正在处理。

哪里出了问题？

确实出了问题。这是一次真实的测试，所以我们如实交代。

安装命令（npx skills add globalize-now/globalize-skills）在 Windows PowerShell 上失败了。这是该工具第一次在 Windows 上测试。由于 Google 拦截了邮件附件，Skill 只能打成 zip 包，通过 Swiss Transfer 发送。在正式流程开始前，配置环节总共折腾了约 15 分钟。

转换途中出现了 ES modules 与 CommonJS 的冲突。项目使用 CommonJS，而 Agent 的输出在某处假定了 ES modules。这不致命，但应该在配置阶段就检测出来并主动处理。

会话结束时，在 globalize.now Web 应用中连接 GitHub 仓库返回了空白页。开发者当时用的是 Opera。没有登录界面，没有报错，也没有任何内容。会话结束时问题还没解决。

三个 bug，都是真实存在的，目前均已修复或正在修复。

为什么说字符串提取才是真正的瓶颈？

大多数 i18n 内容聚焦在翻译质量、框架配置或 TMS 功能对比上，却忽略了开发者真正耗时的地方。

给现有代码库加上国际化，意味着要扫描每个组件里的硬编码字符串，判断哪些字符串需要翻译，生成有意义的翻译键，用相应的 t() 或 <Trans> 调用包裹每个字符串，更新整个文件树里的 import，创建初始语言文件，并配置路由中间件。对于 monorepo，还要先搞清楚代码库的哪些部分需要 i18n。

这件事繁琐、易错，恰恰是 AI Agent 擅长的活。亲眼看完全程的开发者说得很明白：从开发者的角度看，这就是重活。这让人大大松了一口气。用 AI 工具构建应用的 vibe coder，现在可以彻底跳过出海过程中最糟心的那一步。

我们对 monorepo 范围划定有什么发现？

Agent 隐式地完成了 monorepo 的范围划定。它聚焦在 Next.js Web 应用上，没有人告诉它，就自动忽略了 Android 代码、MCP 服务端和 Mintlify 文档。多数情况下，这是正确的行为。

但隐式划定不等于显式划定。开发者希望能在配置步骤里指定“只转换我的 Next.js 应用”。在包含多个 Web 前端的 monorepo 里，比如一个面向客户的应用加一个管理后台，你会希望精确控制先国际化哪个前端。

这是我们正在补上的产品缺口。目前 Agent 在实践中判断得没错，但显式划定范围应该是一个配置步骤，尤其是当转换会改动几十个文件时。

与手动配置 i18n 相比如何？

在这种复杂度的代码库上手动配置 i18n 需要好几天。并不是某一步有多难，而是步骤多达几十个，每一步都得留神。漏掉一个字符串，就会上线一个只翻译了一半的页面；键名取错，就会产生重复条目，困扰你好几个月；忘了更新中间件，语言路由就会悄无声息地失效。

AI Agent 端到端约 90 分钟就完成了同等工作量。这位开发者职业生涯中见过成千上万个 i18n 实现，他称之为“优雅”。

对用 AI 工具构建应用的开发者来说，这改变了何时添加语言的决策。如果 i18n 配置要一周，你会拖到验证了产品与市场匹配之后再做；如果只要 90 分钟，你完全可以从第一天起就支持多语言。

globalize.now 搞定这一切。连接仓库，转换在应用中一次性跑完；之后的工作由编辑器里的 npx skills add globalize-now/globalize-skills Skill 接手。了解运作方式，请访问 globalize.now。