本地化正在成为 Agent Skill，而不是 SDK

过去本地化一个应用，意味着引入 SDK、接入 provider、手动管理键。有了 AI 编码 Agent，路径更短了：安装一个 Skill，接线的活儿交给 Agent。globalize.now 是以开放 Agent Skill 形式发布的 AI 本地化基础设施。你运行一条命令，Agent 读取其中的流程，你的代码库就具备了可翻译的结构，不必再维护新的底层代码。

什么是 Agent Skill？

Agent skill 是一个小型指令包，供编码 Agent 读取并执行。它通过开放的 skills 生态分发，用 skills CLI 安装，例如 npx skills add owner/repo。同一条命令适用于 Claude Code、Cursor、Codex、OpenCode，以及另外五十多种 Agent。

Skill 本身是一个 SKILL.md 文件加若干辅助文件，安装后会放进 Agent 默认读取的目录。CLI 会把它链接到唯一的规范副本，并在 lockfile 中记录安装信息，因此 skill 和项目的其他部分一起纳入版本管理，而不是困在某个厂商的账号里。甚至还有公开注册表，skill 和其他依赖一样，可以查找、阅读、锁定版本。

值得注意的转变在于：skill 不是 Agent 要去集成的产品，而是 Agent 吸收后用在你代码上的知识。新同事入职时这一点最明显：克隆仓库后 skill 已经在里面，他们的 Agent 会用和你一样的方式处理本地化。

为什么把 i18n 做成 skill，而不是 SDK？

因为国际化真正的难点是重构，而 skill 能教会 Agent 替你完成。SDK 默认你的代码已经为翻译做好了结构准备，可你仍然要自己找出硬编码字符串、设计键的命名方案、创建语言文件，再接入运行时库。

AI 生成的应用会让情况更糟，因为编码 Agent 优化的是“能跑的界面”，而不是翻译架构。产出通常正确、可上线，但满是 <button>Submit order</button> 这类字符串，而不是带键的调用。整个项目累积下来，本地化就成了一次重构，而不是改一下配置。

放着不管，问题只会越滚越大。同一个标签被写成三种略有出入的版本，数量显示成 1 messages，第一次加语言时才发现有些界面一半英文、一半翻译。Skill 的设计目标就是一次性揪出这些问题，免得它们变成上百个零碎的工单。

Skill 把这次重构编码成 Agent 可以执行的指令：检测框架，确认你已在用的 i18n 运行时（如 next-intl 或 i18next），提取英文字符串，生成键和语言文件。你不必引入一个新的运行时去维护版本，skill 完成配置后就退场。

Skill 和 MCP server 有什么区别？

MCP server 是 Agent 调用的服务，skill 只是项目里的文件。Model Context Protocol 适合通过运行中的 server 为 Agent 提供实时工具和数据。但 server 需要你或厂商来托管，Agent 也得依赖它随时可达。

Skill 背后没有服务。它是随仓库一起提交的文本和代码，无需网络请求就能运行，改动也像其他变更一样出现在 PR 里。对于国际化这类一次性的配置工作，文件比一个得持续运维的服务更合适：先读 skill 要做什么，运行它，再审查 diff。

Skill 还可以叠加。你可以安装多个，它们并行共存，因为每个 skill 只是指令，不是又一个需要运行、需要付费的进程。

globalize.now 如何作为 Agent skill 安装？

一条命令，剩下的交给 Agent。

npx skills add globalize-now/globalize-skills --all

--all 参数会为本机上的每个 Agent 安装所有 skill，如果你不确定自己在用哪个 Agent，这是最稳妥的默认选择。CLI 会把 globalize.now skill 放到 Agent 读取 skill 的位置，兼容你正在使用的 Agent，包括 Claude Code 和 Cursor。

接下来只需让 Agent 配置 i18n，它就会按手册执行：检测框架，确认运行时库，找出面向用户的英文字符串，生成键和语言文件。改造前后的对比，开发者一看就懂。

// before
<button>Submit order</button>

// after
<button>{t("checkout.submit_order")}</button>

这些键会写入由 skill 创建并维护的语言文件：

/locales
  en.json
  de.json
  es.json
  fr.json

英文文件由 Agent 找到的字符串填充。其他语言会在每次 push 时生成并保持最新，所以拓展一个新市场只是多一个语言文件，而不是一次冲刺。

配置完成后，翻译会在每次 Git push 时同步。无需导出，也没有待清空的队列。如果你在 vibe coding 自己的应用，到这里就全部搞定。如果你是想了解细节的开发者，同一个 skill 会干净利落地完成重构，并交给你标准的语言文件。

翻译会留在我的仓库里吗？

是的。Skill 生成的语言文件和其他源文件一样提交到你的仓库。对于避免锁定，这一点最关键。

有些方案会把翻译后的字符串放进构建步骤或托管后台，你一旦离开，翻译层也跟着一起走。而使用仓库原生的语言文件，你的 en.json、de.json 等都是项目里的普通文件。哪怕 skill 明天消失，应用依然能发布现有的每一种语言。要离开，只需不再安装这个 skill，无需迁移，因为你的东西从来没放在别处。这就是 globalize.now 定位在技术栈基础设施层的原因：生成键和语言文件，而不是把自己包在你的应用外面。

Skill 模式会让你被厂商锁定吗？

不会，而且避免锁定正是选择它的理由。Skill 从开放注册表安装，任何受支持的 Agent 都能读取，而不是封闭的插件商店。产出是你已选定的运行时库所用的标准语言文件，而不是日后还得费力拆解的私有格式。

运行之前，你可以清楚看到 skill 要做什么，因为它只是文件。如果你想看完整的操作流程，而不是论证，可以看如何本地化 AI 生成的应用这篇指南，它从头到尾介绍了同样的配置过程。