游戏文本中译外语的 AI 翻译系统，如何判断是否能满足质量要求？

结论：先用真实且分层的游戏文本做盲评，再决定 AI 翻译系统是否达标。不能只看一句译得顺不顺，也不能套“多少比例可直接用”；应分别测量严重错译、术语一致性、角色语气、上下文、变量与标签完整性、界面长度，以及目标语母语审校的修改时间。任何影响玩法、付费或合规的严重错误都应单独设红线。

游戏本地化比普通段落翻译更难，因为源文本常被拆成缺少上下文的字符串。同一句“Ready”可能是角色状态、按钮命令或战斗播报；代词、敬语、性别、阵营和前后剧情也可能存在于另一张表。模型流畅并不代表忠实，自动指标高也不代表玩家能理解任务条件。因此，评测数据必须保留场景、说话人、前后句、字符限制、占位符和截图等上下文。

文本类型	主要质量风险	评测重点	处理建议
UI、按钮与系统提示	字符溢出、动作含义错误	长度、术语、可操作性、变量完整	规则校验后在真机或截图中复核
技能、数值与付费文案	条件、数值、否定词错译	准确性与严重错误	必须人工复核，不因平均分高而放行
剧情和角色对白	人设漂移、语气与指代不一致	风格、连贯、文化适配	带角色卡和上下文，由母语审校评分
道具、地图与世界观	专名和阵营关系不一致	术语覆盖与跨版本一致性	术语库设负责人并保留变更历史
双关、诗歌和敏感内容	直译失效或文化风险	创译质量、地区适宜性	由资深本地化人员重写和批准

在继续拆分功能、数据与验收场景时，还可以对照 我担心 App 做出来太难用，你们有做培训吗？还是有其他方式吗？ 和 如何判断项目适合定制开发还是购买 SaaS？；这些内容补充了需要放在同一项决策中考虑的上下文。

样本应代表风险，而不是只代表数量

从待上线版本按文本类型、角色、章节、长度和风险分层抽样，并故意纳入占位符、富文本标签、多义词、敏感文化、缺失上下文和历史版本。500 句或 1000 句都不是通用门槛：内容少但风险高的付费游戏可能需要全量检查，文本量极大的持续运营游戏则要分层抽样并对高风险类别全检。样本选择方法、随机种子或筛选规则应保存，防止只挑模型擅长的句子。

准备一份经目标语母语专家确认的术语、角色设定和风格指南，但不要把唯一参考译文当作唯一正确答案。同一源句可能有多种合格译法，更适合用 MQM 一类错误分类记录准确性、术语、语言规范、风格和地区惯例，并给“导致玩家误操作”“改变付费含义”等严重错误更高权重。W3C 的 MQM 社区组也将其定位为适用于人工、机器和生成式 AI 翻译的分析型质量框架。

盲评要回答“省了多少可靠人工”，而非“模型得几分”

同一批样本至少比较人工基线、通用模型、术语与上下文增强方案；隐藏方案来源并随机排序，避免审校者先入为主。两名审校者先独立标注一部分样本，再校准错误定义；分歧过大说明标准不清，不能直接平均。记录每千字或每百条的审校时间、改动字符、严重错误和退回重译量，才能判断系统是否真正降低成本。

自动校验适合发现不可丢失的内容：变量、HTML 或富文本标签、数字、货币、换行、禁用词、前后空格和字符上限。它不能代替语言判断。术语命中率也要区分“该用而没用”和“机械套用导致语法错误”。上线前在实际界面检查截断、字体、方向、语音与字幕同步，并对更新版本做回归，防止翻译记忆库中的旧译污染新剧情。

系统验收条件应由业务风险决定，例如高风险文本严重错译为零、占位符完整率达到约定值、术语错误不超过阈值、母语审校时间相对人工基线下降且玩家测试没有阻断问题。所有数字都需写明样本、语言对、模型版本、提示词、温度和审校口径；模型升级后重新抽测，不能把一次结果永久外推。

滚水科技会先做小规模评测工具，而不是先建完整翻译平台：导入文本和上下文，固定多种候选方案，支持盲评、错误标签和修订时间记录。只有评测证明收益后，才增加术语库、翻译记忆、批量任务、权限、版本差异和发布回写。客户或合作本地化团队负责目标语最终批准；滚水科技负责系统、数据追踪和评测可复现性，不把模型输出包装成无需审校的成品。

参考资料：

• W3C Multidimensional Quality Metrics 社区组：用于参考翻译错误类型与质量评估框架的发展方向。
• W3C Internationalization Tag Set 2.0：用于理解术语、翻译说明和本地化元数据在内容交换中的作用。
• 滚水科技 AI 中文学习案例：用于了解滚水科技公开展示的语言类 AI 项目经验；不能替代本项目的目标语评测。