给 Claude Code 配工具，它却未必使用

给 Claude Code 接上 10 个专门补翻译的工具，它就会主动使用吗？作者测了最初 9 次运行，其中 6 次能访问工具，却有 2 次完全绕开工具，直接改 JSON。反过来，作者原以为容易出错的直接编辑，全部保住了占位符、标签和复数结构。

这组实验更有意思的结论是：工具能缩短执行时间、守住修改边界，但工具是否被调用、传给模型的上下文是否足够，是另外两件事。对正在给 AI 编程助手接 MCP 的团队，这比再接几个工具更值得琢磨。

补齐翻译没出错，为什么仍然有风险

测试项目是一个使用 i18next 的小型 React 应用：5 个命名空间，英文基准共 54 个 key。任务是补齐法语、 西班牙语和意大利语里的 92 个缺失值，同时保留已有的 70 个值。待翻译内容包括 {{name}} 占位符、_one / _other 复数对、<b> 标签和换行。

每次都使用相同提示，只要求根据英文补齐 public/locales，没有提工具。作者用全新项目副本启动独立的无界面会话，版本是 Claude Code 2.1.319，模型是 Sonnet 5.5。

下面的命令用于固定运行条件，尽量排除个人配置和历史会话的影响：

claude -p "$PROMPT" \
  --model sonnet \
  --setting-sources project \
  --strict-mcp-config \
  --permission-mode acceptEdits \
  --settings '{"sandbox":{"enabled":true,"autoAllowBashIfSandboxed":true}}' \
  --allowedTools Read Edit Write Glob Grep \
  --no-session-persistence \
  --output-format stream-json --verbose

要留意 --setting-sources project：它让个人设置不进入会话。工具组另外增加 --mcp-config 和 10 个工具名的调用许可。

没有工具的 3 次运行都保住了占位符、标签和复数对。模型通常读取文件，再完整重写需要修改的 11 个文件，其中一次改用 Python 脚本生成。作者最初担心的结构损坏没有出现。

但第一次运行修改了已有的 fr/auth.json：把 login.title 从「Login」换成「Se connecter」。翻译可能更自然，却超出了「只补缺失项」的任务范围。产品团队也许就是决定保留「Login」，而这一次修改藏在新增 205 行的 diff 里，很容易漏看。

文件格式正确，不等于修改范围正确。

作者每轮都用脚本比较新增值、已有值变化，以及占位符和标签；耗时、费用和轮次来自会话报告。这能检查结构和越界修改，但不能证明翻译质量，作者也明确没有给译文打分。

工具为什么更快，却有三分之一没被调用

最初 6 次接入 MCP 的运行里，4 次真正使用了工具。它们平均耗时 27 秒，对照直接编辑的 66 秒；平均费用是 $0.14，对照 $0.22。

原因并不神秘。模型不打开 JSON，而是按目标语言获取缺失项，再按语言提交译文，由插件写入。原文展示的法语返回有 total:10，包含 key、英文原文和 pluralFromOther 等字段。输出量因此从约 10,000 tokens 降到约 4,000。

写入工具还把约束变成了程序规则：已有且未标记为 stale 的值会被拒绝覆盖；缺少 {{name}} 的译文也会被拒绝。作者手动调用验证了这两种情况。模型直接编辑时可以越界，走工具时则写不进去。

问题在入口。第 3、4 次运行虽然连接了服务器，也能看到工具列表，却没有搜索工具，直接改了文件，而且再次把「Login」改成「Se connecter」或「Connexion」。

作者观察到，成功使用工具的会话都会先搜索并取得工具定义，据此推测按需加载影响了工具发现。IDE 的 MCP Server 暴露了 119 个工具，定义约 236,000 字符，其中这 10 个翻译工具占 9,146 字符；实际首轮上下文只从 20,556 tokens 增至 22,879，增加 2,323。

省上下文和工具被忽略，可能来自同一个机制：定义没有提前全部加载。

作者随后在 CLAUDE.md 加入明确路由：

For translation files (public/locales), use the i18n_* MCP tools instead of editing the JSON files.

关键是同时指定目录 public/locales 和工具模式 i18n_*，让任务能对应到工具。随后 3 次运行全部使用工具，耗时 26 至 30 秒，每次 $0.13，没有触碰已有值。不过，3 次成功只能说明这条指令在本次测试中有效。

只返回缺失项，也会丢掉翻译依据

直接读文件还有优势：模型能看到项目已经采用的术语。

已有法语保留英文「trustee」，已有西班牙语把 Dashboard 写成「Panel」。不接工具的 3 次运行都沿用了这两种表达。工具只提供缺失项的英文，模型看不到这些约定；累计 7 次实际使用工具的会话里，6 次自行翻译了「trustee」，3 次用了「Panel de control」。

占位符都正确，所以工具不会拒绝。但产品里的用词不统一了。

排序也类似。工具向空文件写入时按字母排序，把 errors 放在 login 前；直接编辑的模型则沿用英文文件里 login 在前的顺序。

这提醒工具作者：压缩上下文不能只看 token。缺失项之外，已有术语、同命名空间的相关文案、参考文件顺序，都可能影响结果。补充这些信息是合理的改进方向，但作者尚未提供改进后的测试。

我的判断

我认同把「只补缺失值」「占位符必须匹配」交给程序执行。相比完全依赖提示词，这类检查能直接拒绝错误写入；不过，直接编辑配合校验脚本、CI 和 diff 审查，也是可选方案，原文没有比较它们的整体成本。

这份结果需要保留实验边界：总共 12 次会话、一个模型、一个 54-key 项目，是一下午的测量。5 次直接编辑中，4 次遭遇沙箱拒绝两三条 shell 命令，增加了轮次；没有被拒绝的那次是 57 秒、$0.20，差距仍在，但不能完全排除环境影响。

大项目里工具优势会扩大，是作者根据全文件读写成本作出的推测，尚未实测。工具能否提升译文质量，也没有答案。

这里验证的是特定任务下的效率和写入约束，还不是普遍的翻译能力提升。

能拿来做什么

• 给 AI 接入 MCP 后，用同一任务重复运行，记录是否搜索和调用工具，并检查最终 diff。服务器连接成功只能证明工具可用。
• 在前端多语言项目里，把适用目录和工具选择写进 CLAUDE.md，同时保留对已有值、占位符、标签和复数对的程序校验。
• 设计补翻译工具时，在缺失项之外提供已有术语和相关文案，避免节省了 token，却丢掉统一措辞的依据。
• 使用 JetBrains 的团队可以试验 I18n Support Plus。原文说明它采用 MIT 协议，工具要求版本 2025.2.6 或更高，并需保持项目在 IDE 中打开。在 Settings › Tools › MCP Server 启用服务后，用 claude mcp add --transport http jetbrains http://127.0.0.1:64342/stream 连接，再加入上述项目指令。