经常关注老游戏汉化动态的人看到“主线剧情已 AI 初翻完”这种进度描述第一反应往往不是兴奋而是先愣一下AI 翻译真的能用来做 RPG 汉化初稿了吗它和以前那种机翻天书的印象差距为什么会这么大如果你也有同感那这篇内容可能正好适合你。这不仅仅是一条游戏汉化进度播报背后更值得拆解的是一条新的生产流程AI 初翻 术语表约束 人工精修正在变成中小型汉化项目里一种低成本、可复用的工作方式。这篇文章会从 PQ1 这个具体项目切入先说清楚“AI 初翻完”在整条汉化管线里到底完成了哪一步再讲为什么它不能直接当成品发布接着给出一套可以照搬的 AI 辅助汉化工作流和代码示例最后聊一聊这类流程最容易踩的坑以及什么样的项目适合采用它。需要先说明一点本文只讨论翻译与本地化工作的工程方法不涉及任何游戏的获取、文件破解或数据提取手段。如果你手头没有合法取得的游戏文本请先解决授权问题再往下看。1. PQ1 汉化进度里值得关注的重点不是“进度”而是“AI 初翻”“女神异闻录 PQ1”指的是 2014 年在 3DS 平台上推出的一款迷宫 RPG《女神异闻录 Q暗影迷宫》。它最大的卖点是把《女神异闻录3》和《女神异闻录4》两支团队的成员放在同一个故事里让玩家操控两种不同风格的角色在“影时间”与“暗影迷宫”中冒险。因为文本量集中在日常对话、团队互动、剧情主线和解谜提示上它天然就是一个很适合观察本地化工艺的样本。这次进度消息里真正有新意的关键词不是“主线剧情完成”而是“AI 初翻完”。放在几年前汉化组公布进度时通常只会写“文本初翻完成”或“剧情翻译进度 50%”默认这里的“翻译”是人完成的。现在多了一个“AI”前缀意味着翻译任务的下限和上限都发生了变化AI 负责以较快速度生成一块“能用但未必准确”的候选文本再由人去校对、修错、统一风格。这里需要打破一个常见误区AI 初翻并不是“让机器把日文直接变成中文然后交付”而是把一个长文本翻译任务拆成了“预翻译”和“精修”两段。预翻译解决的是“从 0 到 1”精修解决的是“从 1 到 100”。很多人在讨论 AI 汉化时会直接跳到“机翻能不能玩”的争论但如果你把视野放到汉化生产流水线上看问题其实不是能不能玩而是哪一步可以交给 AI、哪一步必须留给人。从这个角度说PQ1 这条进度的真正价值是提供了一个正在真实推进的大文本量案例AI 初翻已经完成了某条线路的主线剧情它的下一步就是进入人工质量保障环节。至于这个案例是否说明 AI 已经能独立承担 RPG 汉化答案仍然是否定的。更准确的理解是AI 把汉化项目里最消耗人力的“初翻”环节压缩了但并没有消灭最体现功力的“精修”环节。2. 核心概念AI 初翻、人工精修、翻译记忆三者在汉化中的分工2.1 为什么“初翻”和“精修”不能混为一谈在传统汉化流程里“初翻”通常由对原文有一定理解但不一定能写出好中文的人完成产出的是“草稿”“精修”由对双方语言都较熟悉的人完成产出的是“可发布文本”。初翻的价值是提供完整的语义结构和信息量精修的价值是提供可读性、一致性和角色感。AI 初翻恰好吸取了这一经验它更擅长做语义解算而不是风格创作。例如一句日语“行くぞ、相棒”AI 可以准确判断这是亲密关系下的一句行动号召但到底译成“走吧搭档”还是“上了哥们儿”它需要额外信息才能决定。这个额外信息就是角色设定、语境历史和团队此前制定的中文风格规范而这些通常保留在人工精修那一侧。2.2 翻译记忆与术语表是 AI 初翻稳定的关键很多个人尝试 AI 翻译时会把整段剧情一次性丢给大模型结果前 20 句风格统一越往后越跑偏。原因很简单模型上下文有限而 RPG 对话的句间关联又特别强。项目里稳定的做法是引入“翻译记忆”概念每次翻译时不仅传当前句还把前文的中文译文一起带入上下文形成滚动窗口。术语表同样重要。它会强制模型在指定词条上不自由发挥。比如 Persona 系列里的“ペルソナ”该用“人格面具”还是“女神异闻录”“影时间”要不要保留原名如果不在提示词里写死同一个词在 5000 句翻译里可能出现 7 种译法。真正专业的 AI 初翻流程第一步就是先做术语表再做批量翻译最后才轮到逐句校对。2.3 AI 初翻任务的输入输出到底长什么样在工程实现上AI 初翻的输入是一个结构化文本块输出是同样结构的中文文本块。它不一定直接操作游戏对话文件而是操作从工程管线里导出的中间文本。这一步很重要如果直接把字库里的文本喂给模型模型可能不知道自己翻译的是哪个人说的哪句也容易丢失转义符和格式标记。标准做法是先把源文本整理成携带 id、说话人、上下文标签的 JSON 或 TSV再按批送入翻译环节。3. PQ1 里 P4 线展示的工程意义同一项目为什么要把线路拆分这次进度展示特意选了 P4 线而不是笼统地说“整个主线完成”。从工程视角看把文本按线路拆开是有明确好处的。《女神异闻录 Q》的故事存在两条主线秩序玩家初始选择会决定以 P3 队伍还是 P4 队伍为主视角展开故事。两条线路在剧情事件、对话对象、伙伴互动上都有差异但共同文本块也很多。汉化组先走通 P4 线本质上是先跑通“主线剧情翻译 质量检查 截图验收”的最小闭环再用这条线路的术语和风格规范反哺后续流程。这种做法会直接影响汉化效率。如果两条线一起开工术语表没有沉淀角色语气没有定型后面精修时会出现大量返工。而先做一条线等于先用较低成本确定了一套“规格”后面的翻译可以围绕规格批量执行。从项目管理角度看这是典型的先做试点再铺规模的思路放到任何大型文本处理项目里都适用。4. 一套可复用的 AI 辅助汉化流水线从源文本到初翻稿现在把视角从 PQ1 的具体进度拉回工程实现。假设你手里的项目也是一款对话量很大的 RPG 游戏汉化组已经把文本导出成了一份 JSON 文件接下来要做的就是用 AI 完成初翻。以下是一个最小可跑的流程参考。4.1 环境与前置条件编程语言Python 3.9 以上。依赖openai或任何兼容 OpenAI 接口的 SDK、python-dotenv、tqdm。大模型一个支持较长上下文的语言模型接口具体型号以实际可用情况为准本文示例用 gpt-4o-mini 仅作演示。文本数据一份未经翻译的 JSON 文件结构参考如下。{ texts: [ { id: 0001, speaker: 鸣上悠, message: 行くぞ、相棒。 }, { id: 0002, speaker: 花村阳介, message: おう待ってたぜ。 } ] }4.2 构建术语表与提示词模板术语表的作用是限制模型在关键词上的发挥空间。你可以在提示词里直接用自然语言描述也可以提供一个 JSON 字典让模型严格参照。更稳妥的做法是两者结合系统提示词里写风格规范用户消息里带上术语表与待翻译文本。下面是一个用于初翻的提示词模板示例system_prompt 你是一名经验丰富的日文游戏本地化翻译擅长将日本 RPG 游戏中的日文对话翻译成简体中文。 翻译时遵循以下规则 1. 必须优先使用提供的术语表不得擅自更改官方定名。 2. 保持口语化风格贴合角色身份不要过度书面化。 3. 不输出任何解释不添加原文中没有的内容。 4. 保留原文中的语气词和情绪强度。 5. 如果遇到人名直接翻译为中文常用译名。 .strip() glossary_text 术语表 - ペルソナ - 人格面具 - 影時間 - 影时间 - シャドウ - 暗影 - 鳴上悠 - 鸣上悠 - 花村陽介 - 花村阳介 - 相棒 - 搭档 .strip()4.3 编写分段翻译与记住上文的核心脚本在真正执行翻译时推荐按“滚动窗口”分组。每次翻译一小段对话并把前一次翻译结果拼入下一次请求的上下文避免模型前文遗忘。这里给出一个直接用 requests 调用 OpenAI 兼容接口的例子方便你替换到任意模型服务import json import os import requests from dotenv import load_dotenv load_dotenv() API_URL os.getenv(LLM_API_URL, https://api.openai.com/v1/chat/completions) API_KEY os.getenv(LLM_API_KEY, ) MODEL_NAME os.getenv(LLM_MODEL, gpt-4o-mini) def chat_once(system_prompt, user_prompt): resp requests.post( API_URL, headers{Authorization: fBearer {API_KEY}, Content-Type: application/json}, json{ model: MODEL_NAME, messages: [ {role: system, content: system_prompt}, {role: user, content: user_prompt} ], temperature: 0.7 } ) resp.raise_for_status() return resp.json()[choices][0][message][content] def translate_block(system_prompt, glossary_text, messages): block_text \n.join( [f[{msg[speaker]}]\n{msg[message]} for msg in messages] ) user_prompt f{glossary_text}\n\n以下是需要翻译的对话文本请逐句翻译\n{block_text} return chat_once(system_prompt, user_prompt)这个脚本的价值不在封装 API而在于给你留出了替换模型端点的空间。实际项目里你可能还需要分片、重试、错误恢复和 token 统计但最核心的“调用模型进行批量初翻”逻辑已经完整了。4.4 批量执行与结果回写调用时把文本按对话组切片逐组送入函数并收集结果with open(source.json, r, encodingutf-8) as f: data json.load(f) result_items [] for i in range(0, len(data[texts]), 10): chunk data[texts][i:i10] translated translate_block(system_prompt, glossary_text, chunk) # 这里可以继续用正则或结构化输出做文本切分 result_items.append({id_start: chunk[0][id], translated: translated}) with open(draft.json, w, encodingutf-8) as f: json.dump(result_items, f, ensure_asciiFalse, indent2)输出结果会是一批带有段落感的初翻文本但它还不是成品。更合理的做法是让模型以 JSON 数组的形式返回每条对应一句话这样后续精修环节会更快。实际项目中很多汉化组会在这里加一层“翻译后的文本清洗规则”比如把特殊符号、换行符、字号标记从中译文里剥离出来避免污染最终字库。5. 以 P4 线为例初翻完成不等于可以发布从 PQ1 的“P4 线展示”来看所谓展示通常是放几张实际游戏画面截图让关注者看到字幕已经替换成了中文。这个环节其实非常考验汉化组的阶段性交付能力因为截图一旦放出玩家第一个关注的不是翻译质量而是“这翻译读起来像不像人能说的话”。如果只是让 AI 把日文逐句翻成中文那可能得到类似这种效果原文おう待ってたぜ。初翻哦等你很久了。精修来了啊我都等半天了。这两种译文在信息量上并没有差别但角色感差别很大。花村阳介在原作里是个咋咋呼呼、喜欢称兄道弟的热血角色他的台词应该充满亲近感和一点吊儿郎当的劲头而不是一本正经地报时。这个信息术语表给不了上下文可能也给不全必须靠熟悉角色的精修人员判断。所以 P4 线展示的含义不是“翻译已经做完”而是“文本链路已经走通可以用真实游戏画面对照验收”。在这个阶段真正要做的事情是逐句走查以下三个维度语义是否准确有没有与剧情设定冲突的误译。角色语气是否统一同一个人在不同章节、不同情绪下说话是否像同一个人。字幕长度是否合适中文字符串是否超出对话弹窗或字库容量。其中第三点经常被忽略。日语里五个假名的内容翻成中文可能变成八个汉字而 3DS 游戏对话框天然有宽度限制。如果 AI 初翻输出的句子过长轻则换行难看重则导致文本显示不全。这也是为什么 AI 初翻后的流程不再是简单润色而是一次真正面向目标平台特性的适配。6. 运行效果与验证方法怎么判断一次 AI 初翻能否进入精修6.1 先看稳定性再看准确性一个 AI 初翻环节是否合格首先要看它是否稳定。如果同一句原文翻两次得到两种结果说明提示词或参数设置还有问题。实际项目里可以抽 200 条句子做前后两次翻译计算“自洽率”python compare_draft.py draft_v1.json draft_v2.json自洽率达到 80% 以上说明流程基本可控低于 50% 则要优先检查上下文是否传入、温度是否设置过高、模型是否随机性太强。6.2 对抽样文本做误译标记更实用的验证方式是做一次小规模抽检。随机抽取 100 句初翻结果人工标记三类错误误译核心意思错了。漏译原文信息在译文中丢失。过译译文出现了原文没有的信息或过度美化。统计表格可以这样设计检查维度抽样数量发现数问题类型处理方式语义准确10072 处误译5 处漏译返工并增加术语约束角色一致10011语气跳跃或偏书面化交精修逐句调整字幕长度10013过长的句子拆行或缩写从抽样比例来看如果误译率在 3% 以内、漏译率在 3% 以内、角色语气问题在 10% 以内这个初翻质量已经可以进入人工精修环节。如果语义错误超过 10%不要急着精修先改提示词和上下文策略再重新初翻一轮。6.3 用一段新文本做盲测最后值得做的一件事是拿项目组之外的人来做盲测。把 AI 初翻稿和人工精修稿混在一起让熟悉游戏但没接触过文本的人判断哪些是 AI 翻的。如果误判率超过一半说明两者的差距比想象中小如果一眼就能认出哪些是 AI 翻的多半不是因为它“翻错了”而是因为它“不像人会说的话”——说话节奏、断句习惯、语气词选择和句式完整度都有问题。7. 常见问题与排查方法AI 初翻在实际运行中会出现的问题比较集中这里整理成一张排查表问题现象可能原因排查方式解决方案翻译结果前后称呼不一致术语表未生效模型对同一词自由发挥检查系统提示词中是否明确要求术语优先强制在输出前先复述术语表或改用后处理替换长对话后半部分跑偏上下文窗口被截断模型忘了前文检查每次请求传入的上下文长度改用滚动窗口只保留最近 6 到 8 轮对话翻译风格偏书面化角色设定信息不足在提示词中加入角色性格与说话风格描述为关键角色建立“角色 Prompt 库”译文比原文长很多模型过度解释或扩充信息统计平均句长比定位具体句式在提示词中写“禁止解释性扩写只输出对应翻译”同一段文本每次翻译都不一样temperature 过高排查参数配置将 temperature 降至 0.2 至 0.4或设置为 0 做一致性优先特殊符号和标签被误删清洗脚本和翻译脚本互相干扰对比源文本与结果文本的符号集翻译前先用掩码保护特殊符号翻译后还原比较值得强调的一点是AI 初翻最大的风险并不在“翻得对不对”而在“模型输出格式不稳定”。如果脚本没有对输出做结构化校验很可能会出现整段返回、没有换行、漏掉说话人标签等问题直接导致下游解析失败。因此在流程中必须加入格式守卫例如用正则表达式先检查返回结果是否包含预期数量的翻译段落再决定是否继续写入草稿文件。8. 最佳实践与工程建议8.1 从首个线路沉淀术语表和语气基准像 PQ1 这样两条线路共用的文本量很大的游戏最佳策略是在第一条线开工时同步完成一份可复用的术语表、角色表、语气基准表和敏感词替换表。不要等到两条线都翻完再统一术语那就等于要把一半的翻译重新返工。8.2 为角色建立独立的 Prompt 文档花村阳介、里中千枝、久慈川理世这些角色在说话方式上差异是很大的。有的喜欢用敬语有的习惯用省略语有的爱用特定口癖。建议在项目中新建一个角色目录prompts/ ├── yuu.json ├── youko.json └── chie.json每个文件里写明角色的中文译名、在游戏中的身份、与其他角色的关系、说话风格的总体描述以及 3 到 5 条示例台词和参考译法。把这个文件作为用户消息的一部分传给模型能明显提升角色语气的一致性。8.3 初翻后只做纯文本审校不直接改游戏文件很多人拿到 AI 初翻稿后会立刻想把文本替换进游戏文件去截图看效果。这个习惯不是不好而是太早了。如果术语没有统一、角色语气没有定型、字幕长度还没有适配直接替换进游戏相当于拿未验收的半成品去测流程。建议流程是先做“纯文本审校”生成一版不依赖游戏字体的中文文本稿再进入游戏内替换和截图验收。8.4 用 Git 管理文本版本汉化项目往往多人协作而 AI 初翻稿、人工精修稿、终审稿之间的差异肉眼难以追踪。强烈建议把文本数据放到 Git 仓库里每轮修改都提交一次。这样做的好处有两个一是能随时回滚到任何历史版本二是能清晰看到每一次 AI 初翻和人工编辑的差异量方便统计工作量。比如用git diff --stat draft.json refined.json就能看到人工到底改了多少行这在项目复盘时非常有用。8.5 安全与合规意识最后再强调一次AI 辅助汉化只能用在你自己合法拥有且有权处理的文本上。不要在公开渠道发布未经授权的游戏资源不要讨论绕过游戏加密或直接传播商业 ROM 的方式。技术本身是中性的但使用技术的边界必须明确。9. 总结与后续学习方向回到 PQ1 这条进度消息本身它最有价值的点并不是“主线剧情翻完了”而是它示范了一次现代汉化流程的阶段性拆分用 AI 做初翻、用术语表做约束、用线路试点做规格沉淀、用人工作最终精修。这套方法并不只适用于《女神异闻录 Q》任何文本量大的 RPG、VN 或剧情驱动游戏的本地化流程都可以参考同样的框架。如果你正准备在自己参与的项目里引入 AI 初翻下一步可以先做三件事把当前游戏的文本统一导出成结构化 JSON至少带上 id、说话人、消息正文三个字段。建立一份面向角色和术语的 Prompt 文档包含风格基准和优先词表。先挑 200 条文本做小规模初翻测试计算误译率和一致性再决定是否全量推进。AI 初翻不会终结汉化讨论它只是把技术难度从“懂日语才能开翻”降到了“会判断翻译好坏并持续管理质量”的层面。对长期关注民间汉化的玩家来说这意味着未来会有更多冷门老游戏能以更低成本获得中文版本对技术兴趣者来说这也是一块很适合研究提示词工程、文本流水线和语言质量控制的实践场地。如果你现在还没有跑通一套自己的 AI 初翻脚本那建议先从上面这个最小示例开始换一份你自己的文本数据跑一遍很快就会理解为什么“AI 初翻完”和“汉化完成”之间还隔着整整一个精修团队的距离。