企业官网建设流程全解析

经常关注老游戏汉化动态的人，看到“主线剧情已 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": f"Bearer {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", encoding="utf-8") as f: data = json.load(f) result_items = [] for i in range(0, len(data["texts"]), 10): chunk = data["texts"][i:i+10] translated = translate_block(system_prompt, glossary_text, chunk) # 这里可以继续用正则或结构化输出做文本切分 result_items.append({"id_start": chunk[0]["id"], "translated": translated}) with open("draft.json", "w", encoding="utf-8") as f: json.dump(result_items, f, ensure_ascii=False, indent=2)

输出结果会是一批带有段落感的初翻文本，但它还不是成品。更合理的做法是让模型以 JSON 数组的形式返回，每条对应一句话，这样后续精修环节会更快。实际项目中，很多汉化组会在这里加一层“翻译后的文本清洗规则”，比如把特殊符号、换行符、字号标记从中译文里剥离出来，避免污染最终字库。

5. 以 P4 线为例：初翻完成不等于可以发布

从 PQ1 的“P4 线展示”来看，所谓展示，通常是放几张实际游戏画面截图，让关注者看到字幕已经替换成了中文。这个环节其实非常考验汉化组的阶段性交付能力，因为截图一旦放出，玩家第一个关注的不是翻译质量，而是“这翻译读起来像不像人能说的话”。

如果只是让 AI 把日文逐句翻成中文，那可能得到类似这种效果：

• 原文：おう！待ってたぜ。
• 初翻：哦！等你很久了。
• 精修：来了啊，我都等半天了。

这两种译文在信息量上并没有差别，但角色感差别很大。花村阳介在原作里是个咋咋呼呼、喜欢称兄道弟的热血角色，他的台词应该充满亲近感和一点吊儿郎当的劲头，而不是一本正经地报时。这个信息，术语表给不了，上下文可能也给不全，必须靠熟悉角色的精修人员判断。

所以 P4 线展示的含义，不是“翻译已经做完”，而是“文本链路已经走通，可以用真实游戏画面对照验收”。在这个阶段，真正要做的事情是逐句走查以下三个维度：

1. 语义是否准确：有没有与剧情设定冲突的误译。
2. 角色语气是否统一：同一个人在不同章节、不同情绪下说话是否像同一个人。
3. 字幕长度是否合适：中文字符串是否超出对话弹窗或字库容量。

其中第三点经常被忽略。日语里五个假名的内容翻成中文可能变成八个汉字，而 3DS 游戏对话框天然有宽度限制。如果 AI 初翻输出的句子过长，轻则换行难看，重则导致文本显示不全。这也是为什么 AI 初翻后的流程不再是简单润色，而是一次真正面向目标平台特性的适配。

6. 运行效果与验证方法：怎么判断一次 AI 初翻能否进入精修

6.1 先看稳定性，再看准确性

一个 AI 初翻环节是否合格，首先要看它是否稳定。如果同一句原文翻两次得到两种结果，说明提示词或参数设置还有问题。实际项目里，可以抽 200 条句子做前后两次翻译，计算“自洽率”：

python compare_draft.py draft_v1.json draft_v2.json

自洽率达到 80% 以上，说明流程基本可控；低于 50% 则要优先检查上下文是否传入、温度是否设置过高、模型是否随机性太强。

6.2 对抽样文本做误译标记

更实用的验证方式是做一次小规模抽检。随机抽取 100 句初翻结果，人工标记三类错误：

• 误译：核心意思错了。
• 漏译：原文信息在译文中丢失。
• 过译：译文出现了原文没有的信息或过度美化。

统计表格可以这样设计：

从抽样比例来看，如果误译率在 3% 以内、漏译率在 3% 以内、角色语气问题在 10% 以内，这个初翻质量已经可以进入人工精修环节。如果语义错误超过 10%，不要急着精修，先改提示词和上下文策略再重新初翻一轮。

6.3 用一段新文本做盲测

最后值得做的一件事，是拿项目组之外的人来做盲测。把 AI 初翻稿和人工精修稿混在一起，让熟悉游戏但没接触过文本的人判断哪些是 AI 翻的。如果误判率超过一半，说明两者的差距比想象中小；如果一眼就能认出哪些是 AI 翻的，多半不是因为它“翻错了”，而是因为它“不像人会说的话”——说话节奏、断句习惯、语气词选择和句式完整度都有问题。

7. 常见问题与排查方法

AI 初翻在实际运行中会出现的问题比较集中，这里整理成一张排查表：

比较值得强调的一点是，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 初翻，下一步可以先做三件事：

1. 把当前游戏的文本统一导出成结构化 JSON，至少带上 id、说话人、消息正文三个字段。
2. 建立一份面向角色和术语的 Prompt 文档，包含风格基准和优先词表。
3. 先挑 200 条文本做小规模初翻测试，计算误译率和一致性，再决定是否全量推进。

AI 初翻不会终结汉化讨论，它只是把技术难度从“懂日语才能开翻”降到了“会判断翻译好坏并持续管理质量”的层面。对长期关注民间汉化的玩家来说，这意味着未来会有更多冷门老游戏能以更低成本获得中文版本；对技术兴趣者来说，这也是一块很适合研究提示词工程、文本流水线和语言质量控制的实践场地。

如果你现在还没有跑通一套自己的 AI 初翻脚本，那建议先从上面这个最小示例开始，换一份你自己的文本数据跑一遍，很快就会理解为什么“AI 初翻完”和“汉化完成”之间还隔着整整一个精修团队的距离。