为什么本地化正在前移到开发循环中？

本地化之所以前移，是因为旧流水线的核心假设已经失效：它假定代码变化足够缓慢，可以在下次发布之前，导出一份稳定的字符串目录，到别处翻译，再把结果导入回来。AI 编码 Agent 打破了这个假设。globalize.now 是为这一新位置打造的 AI 驱动本地化基础设施：本地化在开发循环中运行，并以 PR 的形式交付。本文要讲的是，真正改变的是位置，而不是翻译质量。

本地化前移是什么意思？

这意味着本地化工作的单位不再是字符串目录，而是提交。在旧模式中，本地化在代码完成之后才开始；在前置模式中，它在代码所在之处、代码变更的那一刻发生，产出的也是代码：一个可以 diff、审查和合并的本地化 PR。

两种流水线对比如下。

Traditional:   build → internationalize → export → translate → review → import → ship

Upstream:      code → push → localized PR → merge → ship

第一种流水线有七个阶段，要两次离开仓库；第二种只有五个阶段，且全部在仓库内完成。本文要讲的，正是这种结构上的差异，而不是某个单独的功能。

传统的本地化流水线是怎么运作的？

它是一个往返流程，其中每个箭头都是一次排队。先构建功能；再做国际化，把字符串提取为键——前提是你的团队或 AI Agent 一开始就写出了结构化的代码；然后把目录导出到翻译平台；由译员或机器翻译处理；有人审校；最后导入结果，解决目录在外期间积累的冲突，再发布。

每一次交接，都是因为工作发生在不同的地方，由不同的人负责，节奏也各不相同。在发布按季度进行、字符串成批变更的年代，这是合理的设计。这条流水线有个隐藏的依赖：稳定性——目录必须保持不变足够久，才能完成这一来一回。

它不再保持不变了。根据 DORA 2025 年 AI 辅助软件开发现状报告，90% 的软件从业者在工作中使用 AI 工具；DX 2025 年第四季度的影响研究则测得，在其追踪的公司中，位于中位数的那家，已合并代码里有 22% 由 AI 编写。过去每周才变一次的代码，现在午饭到站会之间就变了。

在开发循环内，本地化是什么样子？

就像推送时自动运行的其他检查一样。你只需转换一次代码库：提取字符串、生成键、创建语言文件、接入运行时。此后，同步在每次推送时运行。当某次提交引入新字符串，翻译会以 PR 的形式回到你的分支，位于你的仓库中，结构与应用的其余部分保持一致。

这并非理论上的吞吐量。在 2026 年 8 月对一个演示仓库的实测中，一次推送的提交在 49 秒内就返回了一个本地化 PR，覆盖德语、法语和西班牙语共 30 个翻译单元。从提交到可审查的 PR 不到一分钟，直到审查之前全程无人介入。拿它和任何带有“导出”二字的流水线比比看。

需要说明的是，一次性转换并不是瞬间完成的。在真实应用上大约需要 30 分钟，因为它在重构代码：提取字符串、生成键、接入运行时。这是入口，此后每次推送所运行的循环才是产品本身。

这个循环最重要的特性不是速度，而是没有任何东西离开过仓库。不存在一份躺在外部平台、慢慢与 main 分叉的目录。我们此前发布的 monorepo 实测展示了一次性转换在大规模代码库上的表现；而让转换结果长期保持有效的，正是这个循环。合并，或者关闭——和处理其他所有改动用的是同样两个动词。如果你已经这样工作，开发者文档中有配置说明。

为什么 AI 编码 Agent 会倒逼这种转变？

因为它们转移了瓶颈。过去本地化的限制在于翻译产能：供应商或引擎处理一份结构良好的目录有多快。Agent 的生成速度远远超出了这一限制，并在它的上游制造了新的限制。如今稀缺的是生成之后的架构治理：在 Agent 每天往代码库里添加 UI 的同时，保持键一致、语言文件完整、结构不被破坏。

让 Agent 写一个结账页，它会交出一个能用的结账页，字符串则硬编码在 JSX 里。我们在 AI 代码打破了本地化中剖析过这一现象：一个被分析的 React 项目有 312 个文件、1,284 条 UI 字符串，却没有任何 i18n 结构。传统流水线想要导出的那份目录，在这个代码库里根本不存在。而且代码库明天又会变样，因为 Agent 还在不停地交付。

下游流水线面对这种现实，永远慢半拍。它导出的内容，到导入时已经过期。要跟上生成代码的节奏，本地化唯一可行的位置就是生成代码的那个循环内部，无论代码来自 Cursor、Claude Code 还是 Lovable，都是如此。

这不就是 AI 翻译吗？

不是，市场上的讨论恰恰在这里跑偏了。Lokalise 自称 AI 本地化平台；Phrase 推出了面向大规模机器翻译的 Language AI。两者的能力都是真实的，但它们都只是让旧流水线中的一个箭头变快：翻译这一步。目录依然要导出，依然存放在外部平台，依然要经过导入才能回到代码库。

在七个阶段的往返流程里把一个箭头变快，属于优化；而消除往返流程，是另一种产品。这才是层级上的真正区别：围绕译员工作流构建的平台位于管理层，而 globalize.now 位于它之下的基础设施层，直接在仓库里根据代码本身生成键和语言文件。“AI 驱动”可以形容两者，却区分不了两者。区分它们的是位置。

哪些工作仍然属于下游？

高风险文案仍需人工判断。法律文本、受监管的表述、你格外看重的市场里的品牌调性，都值得由专业译员翻译并经过审校，有这类需求的团队也会继续使用围绕译员工作流构建的工具。前置本地化并不妨碍这一点：本地化 PR 本身就是可审查的界面，合并之前，人可以按任何标准把关。

终结的是这样一个时代：每个团队只为发布第二种语言，就必须采用译员工作流平台。独立开发者做出的 AI 产品，手里没有需要管理的译员，只有提交。工具应该在这里与他们相遇。

循环才是产品

如果你的代码通过 PR 交付，翻译也应该如此。globalize.now 一次性转换代码库，之后在每次推送时保持本地化：PR 提交，PR 合并，上线。