翻译翻车之后，我才明白多语言文案该怎么交给AI
先说说我搞砸的那次
我给一个浏览器插件加多语言支持时，第一反应是：这不就是翻译吗，扔给AI就行。于是我把整个 zh-CN.json 文件直接粘贴进对话框，附一句“翻译成英语、日语、德语、西班牙语”，回车，收工。
结果上线第二天，用户反馈就来了：
- 德语版里，“删除”按钮的文案长得把按钮撑出了容器，界面直接错位；
- 日语版的敬语体系混乱，同一个设置页里一会儿是です体一会儿是命令形，看起来像两个人写的；
- 最尴尬的是英文版里一个占位符
{count} tabs closed被AI“贴心地”改写成了别的句式，占位符名字变了，代码里取不到值，运行时报错； - 还有一个上下文梗：插件里的“钉住”功能，AI在西班牙语里给出的词是图钉那个“钉”，完全不是浏览器语境里的“固定标签页”。
这一版我回滚了，然后老老实实复盘。发现问题不在AI能力，而在我把它当成了一个“无脑翻译机器”。以下是我踩过的三个典型坑，和后来走通的正确路径。
三个常见的失败姿势
姿势一：整包文件一次扔。 一次塞几百条键值对，AI会“疲劳”——前面翻得认真，后面开始敷衍，格式还容易散架（引号丢失、键名被顺手改掉）。你以为省了时间，其实埋了排查的雷。
姿势二：不给上下文。 界面文案不是普通文本。"Pin"、"Block"、"Session"这些词在浏览器插件语境里有特定含义。不给AI说明产品是什么、这个词出现在哪里，它只能按最通用的义项翻译，翻车是必然的。
姿势三：让AI自由发挥。 不限定长度、不限定风格、不保护占位符，AI会产出“文学性强”的译文——而UI文案要的是短、准、一致。德语和芬兰语这种长词语言尤其需要长度约束。
正确路径：结构化投喂 + 分批 + 校验
后来我重新设计了流程，核心思路是把“翻译任务”改造成“带约束的批量改写任务”：
第一步，整理术语表。 我先让AI帮我列出插件里的关键功能词（标签页、固定、分组、会话恢复等），人工确认每个词在各语言里的标准译法，做成一份术语对照表。这一步是地基——术语统一了，后面批量翻译才不会各说各话。
第二步，分批翻译。 每次只投喂20-30条文案，附上术语表、UI场景说明和硬性约束（占位符保护、长度限制、JSON格式要求）。批次小，AI的注意力和输出质量都稳定。
第三步，交叉校验。 让AI扮演“母语审校者”复查自己的输出，重点检查：占位符是否完好、按钮文案长度是否超标、敬语/语气是否一致。最后我再人工抽查关键路径（设置页、报错提示）。
第四步，用脚本兜底格式。 写了个十几行的脚本，校验每个语言文件的键集合与中文源文件完全一致、占位符变量名逐条匹配。机器查格式，AI管语义，人看重点。
我实际在用的提示词模板
你是一名资深软件本地化工程师。我正在为一个浏览器插件
（功能：标签页管理，支持标签分组、固定、会话恢复）批量生成界面文案。
请将下面的 JSON 翻译为【目标语言，如：德语】，遵守以下规则：
1. 仅翻译 value，不得改动任何 key；
2. 所有 {占位符} 必须原样保留，位置可调整以符合目标语言语序；
3. 按钮文案不超过 N 个字符，菜单项不超过 M 个字符（N/M 按界面实际宽度给出）；
4. 语气统一：使用目标语言界面文案的惯用风格
（如日语用です・ます体，德语对用户用敬称Sie）；
5. 严格遵循下方术语表，术语表中的词不得另行翻译；
6. 只输出 JSON，不要任何解释。
术语表：
- pin: 固定 (DE: Anheften)
- session: 会话 (DE: Sitzung)
- ...
待翻译文案：
{
"btn_delete": "删除",
"msg_tabs_closed": "已关闭 {count} 个标签页"
}这份模板的关键在于：约束写死、术语先行、输出纯净。目标语言一换，模板几乎不用动，我后来用同一份模板跑了八种语言。
前后对比：不只是省时间
用AI之前（我第一次的野蛮做法 + 手工修补）：六种语言的文案折腾了约三个工作日，上线后还因为格式错乱和占位符报错回滚过一次，返工又花了一天。用户看到的是“机翻感”明显的界面。
用结构化流程之后：同样的六种语言，术语表制作半天，分批翻译加校验半天，加上抽查，总共一个工作日以内。而且产出质量发生了质变——术语一致、长度可控、格式零错误（脚本校验通过率100%）。新增一个语种的边际成本从“一天起步”降到“半小时左右”。
更重要的是流程变得可复用。插件每次迭代新增文案，我只需把新条目按模板再跑一遍，术语表沉淀下来成了团队资产。这大概是我最大的收获：AI的价值不在“替你翻译一次”，而在于把本地化变成一条可重复的小流水线。
几点补充建议
- 术语表值得花时间人工确认，这是整个流程里唯一不能省的人为环节；
- 长词语言（德语、芬兰语、希腊语）务必给长度上限，否则CSS会被撑爆；
- 报错提示、确认弹窗这类高风险文案，建议母语者或至少双语同事最终过目；
- 如果文案量大、语种多，可以走API把流程脚本化，按批次调用、自动校验——成本方面以官网价格页为准，小语种单语种文案的用量通常很小。
把这套流程搭起来之后，我做新插件时已经默认“第一天就上多语言”，而不是像以前那样把本地化当成上线前才补的作业。如果你也想把这套批量翻译流程脚本化、通过API稳定调用大模型，可以在 https://api.thistoken.ai/register 注册一个账号试试，上手成本不高，适合独立开发者和小团队先把小流程跑起来。
---
不想折腾多家供应商的接入差异？在 https://api.thistoken.ai/register 注册，用一个 base_url 调用所有模型。