04 / ESSAY · METHODOLOGY INTO PRACTICE
从语言经验到工作台：
AI 翻译验收方法论的产品化
让经验成为检查点，让判断留下证据，让修复回到下一次工作中。
01 / THE STARTING POINT
缘起：翻译完成之后，工作还没有结束
作为英语语言专家，我的工作涉及翻译、验收与 LQA。面对 AI 翻译，我关心的不只是初稿生成得多快，更是这份译文能否以可控的成本进入游戏、完成验收。
我的方法来自行业文章、标准资料、工具使用，以及实际项目中的观察与复盘。阅读帮助我整理问题，工具实践让我看见流程的限制，自己的判断则把这些线索连接成可执行的工作方法。
这套方法会随着新文本、新场景和反馈继续生长。每次整理都围绕同一个问题：哪些检查可以稳定交给程序，哪些需要模型理解，哪些应交回人工确认。YEAT 的设计也由此逐步连接翻译、验收与语言资产积累。
02 / THE FRAMEWORK
先分清职责，再讨论自动化
AI 负责判断，规则负责确定，
人机分工原则
数据负责积累，人负责例外。
让质量检查前移
术语、标签、角色语气等问题应尽量在翻译阶段暴露。把翻译问题默认留给 LQA，会把一次局部修正变成跨环节返工。质量前置的目标，是减少问题进入下游的机会。
计算整个语言版本的成本
只看模型调用费或初稿速度，会漏掉人工复核、问题定位与重导复验的消耗。应核算交付一个语言版本的总成本，并同时观察效率与质量。
让不确定性有自己的位置
资料不足既不算通过，也不应直接判错。“待确认”是一种正常状态；每次判错需要规范依据，每次修复都应回流为术语、风格指南、规则或回归案例。
03 / THE METHOD ATLAS
一套持续生长的方法框架
从上下文供给到游戏内验证，每个主题都对应语言工作中的一组判断。这里按问题组织方法，随着新资料、工具实践与项目反馈持续补充。点击卡片可查看各主题的检查思路。
总原则
分清人、模型与规则的职责，让判断可追溯。
译前与上下文
先整理文本与语境，再让模型开始翻译。
术语与语言资产
把干净、明确的语言资产送进工作流。
角色声音与风格
把角色的声音和关系沉淀成长期资产。
翻译阶段
按文本类型分流，保留语义与句式约束。
译后 QA 引擎
确定性硬检先行，把人工精力留给难题。
验收体系
用检查点和证据组织验收，而非凭流畅感打分。
LQA 与游戏内验证
让候选问题成为可定位、可修改、可复测的记录。
风险与文化审核
结合词、场景与市场判断风险，保留适用条件。
工程与资产管理
把一次性处理沉淀为可审查、可复用的流程。
度量指标
效率和质量一起衡量，关注问题关闭的总成本。
典型误区
用反例提醒工作台：流畅、命中与高召回都不等于正确。
总原则
确定性问题交给规则，需要语境理解的交给 AI，高风险或信息不足的交给人。质量前置、总成本与经验回流，共同构成工具设计的底层约束。
信息不足明确标记“待确认”；没有规范依据的改写属于偏好。
返回导览译前与上下文
维护带独立 Key 的文本总表，补充界面位置、说话人、文本类型与场景说明。成段提供对话，按需召回会改变译法的信息；原文质检与占位符保护应发生在翻译之前。
上下文供给要具体；开发阶段用完整句子模板减少字符串拼接。
返回导览术语与语言资产
人用表保留冲突与完整上下文，AI 工具表是经过清洗审核的发布产物。概念、别名、适用场景与确定度应显式记录，避免把一句“视语境而定”留给模型猜。
已确认的术语是硬规则；低频专名也应进入发现与判断流程。
返回导览角色声音与风格
声音档案记录人称、敬语、口癖、句尾和句长偏好；呼称矩阵管理角色之间的称呼。按角色批量比较声音漂移，并把 UI 语态与剧情表达的规则分开。
单句都正确，也可能无法形成稳定的角色声音。
返回导览翻译阶段
专名、对白、UI 与叙事需要不同检查重点。数字、条件、否定与效果必须逐项对齐；共享句式与记忆库历史表达都需要核对。多模型分歧提供待决策信号，不能直接当作错误。
审校与质检分离，并明确暂停点、停止条件和局部退回路径。
返回导览译后 QA 引擎
占位符、标签、数字、空译与异常字符适合程序检查。术语 QA 同时关注既有规则是否执行，以及新词是否出现译法分歧；每次修复都应复检，并留下可回归的案例。
明确错误、风险项与信息不足分开处理，减少无处理价值的误报。
返回导览验收体系
先区分信息忠实型与体验等效型文本，再逐项检查内容锚点、术语规则、上下文和角色冲突。问题要关联原文检查点、译文位置及理由，资料不足时保留待确认。
评分必须有证据与统一分母；合理改写不应被当作错误。
返回导览LQA 与游戏内验证
截图、运行时字符串、术语库、控件状态与 Loc Key 共同组成证据链。先确认场景可测，再归并候选问题、补齐证据并人工确认；修复后沿原界面、语种和状态定向复测。
爆框、字体、字幕同步与图文匹配仍需游戏内验证。
返回导览风险与文化审核
还原谁在说、对谁说、前后发生了什么，再检查指向、程度和立场有无变化。区分译文问题、原文问题与当地联想问题，审核记录需包含市场、用途、版本和依据。
词表没有命中，不能证明没有风险。
返回导览工程与资产管理
提示词、QA 规则与解析脚本需要版本管理；敏感信息不入库。确定性步骤写成脚本，判断任务保留正反案例；区分重复句、重复词组、相似句式与长片段。
基准语种变更要联动转译语种；每次修改应能审查和回溯。
返回导览度量指标
项目层看交付周期、首轮通过率与成本；审校层看耗时、严重错误与返工；LQA 层看人工确认率、定位时间与复测通过率。单看工具运行次数或报告条数，无法证明收益。
用同口径数据区分能力、估算与实测结果。
返回导览典型误区
不把质量压力留到 LQA，不把偏好当错误，不靠单一提示词处理所有文本，也不在缺少上下文时强求唯一答案。重复原文未必同译，跨作品的一致性更不能只看单句。
评估整套流程的成本，并让修复回流语言资产。
返回导览04 / RULES INTO FEATURES
三个例子：规则怎样成为产品设计
映射不是把清单逐项搬成开关，而是明确输入、判断方式、输出证据和人工接手的位置。下面区分规则依据、界面设计与仍需校准的能力。
例 01
把确定性要求交给硬检模块
占位符 {0} 可以随目标语言调整位置，但不能丢失、增加或改变字符。数字 10000、10,000 与 １００００ 则需要先理解其表示规则，再做归一化比对。NBSP、零宽字符与首尾空格也应成为显式检查项。
- 识别检查对象占位符、标签、数字、空译与异常字符。
- 程序执行比对保留字符与位置证据，区分格式差异和内容缺失。
- 输出判定与证据明确错误、风险项、信息不足分开呈现。
这样的模块先回答“哪里不一致”。是否可以修复，还要看规则是否明确、语种与场景信息是否充分。歧义不能靠静默替换消失，信息不足应进入待确认。
例 02
先设计证据报告，再考虑评分
信息忠实型文本检查数字、对象、条件、范围与结果；体验等效型文本检查情绪、人物与体验。混合型文本拆开检查，而不是用同一种“读起来顺不顺”的尺度覆盖所有内容。
原文哪个检查点受影响？
验收证据的三个问题
译文哪部分造成？
为何不是合理改写？
报告因此需要保留检查点、原文与译文片段、理由及处理状态。资料不足时标为待确认；无法说清依据的意见，不应变成扣分依据。
评分框架：方法论参考
八类错误为功能、准确性、形态、句法、术语、语域声音、一致性、文化。严重度权重为 Critical 5、Major 3、Minor 1；这套项目参考口径要求任一 Critical 必改。
得分 = 100 −（总扣分 ÷ 目标语词数 × 100）
项目参考通过线为 ≥95 分，并要求观察错误分布。这个分值不是首轮通过率。它需要项目标准与样本校准，未作为当前 YEAT 的自动放行门槛，也不表示作品已取得该分数。
例 03
让术语库承担输入质量管理
术语资产采用双轨管理的思路：人用表保留冲突、废弃、待定状态与完整上下文；AI 工具表是经过“导出 → 映射 → 清洗 → 审核”的发布产物。它们服务于不同使用对象，不能直接混为一张未经整理的表。
把常见入库问题转成审核清单
- 注音括号混入词条
- 用裸“/”占位
- 一个单元格放两个词头
- 同一术语出现冲突译法
- 把风格规则伪装成词条
- 废弃或待定词条混入发布表
- 语种码不统一
这些规则为入库审核提供依据。产品化时仍需判断字段与语境，不能把合法的括号、斜杠或多义词一律判成错误。
变体归一进一步连接术语与验收：聚合同一源词条的译法，先排除大小写、冠词、复数等假分歧，再对真实分歧进行判断，确认后回写资产。别名、概念与确定度字段则帮助保留“为何这样译”的依据。
双轨发布、严格入库审核与自动批量回写属于术语系统的后续设计方向；此处展示规则到功能的映射，不把它们列作当前已完成能力。
05 / THE NEXT ITERATIONS
按依赖关系推进，而不是一次堆满功能
后续建设按依赖关系分为三个优先级。先让判断依据清楚可查，再完善资产与上下文，最后连接复检和度量；实际采用要结合输入数据、项目标准与验证条件。
- P0
验收引擎核心
检查点、确定性硬检、证据链与待确认队列先形成清晰报告；评分设计保留项目校准要求。
- P1
术语系统与上下文
推进入库审核、别名与确定度、变体聚合，并补齐字符串元数据、角色声音档案与呼称矩阵。
- P2
流程资产与度量
复用翻译过程信息，连接局部修复、复检和回归案例；用返工、耗时、严重问题与首轮通过率衡量效果。
要判断效率是否提高，需要同口径的基线、复核记录和返工成本。度量不仅关注完成速度，也要关注严重问题是否减少，以及人工精力是否用在更需要判断的地方。
06 / KEEP THE LEARNING
把经验留在工具里
工作台承载的不只是翻译入口。它还应记住约定，把风险送到合适的人面前，并让一次修复成为下一次检查的依据。确定性的步骤逐渐固化，无法确定的部分保持可见，人工判断才能花在真正需要它的地方。
下一轮迭代需要回答的，是这套流程能提前发现并消除多少问题，以及它是否减少了从发现到关闭的总成本。这些答案应来自真实项目记录，而不是工具运行了多少次。
07 / REFERENCES
参考与延伸阅读
行业阅读
- 公众号「游戏AI本地化翻译」
- 公众号「游戏葡萄」
- 任玩堂（GameRes 游资网转载） · 中文版≠本地化，游戏汉化有多难你知道么？
- Keywords Studios · Balancing Speed & Accuracy in AI Translation
- Keywords Studios · Operationalizing AI in Game Localization
- Keywords Studios · How to Choose the Right Chinese Locale Setup for Your Game, Audience, and Release Path
标准、文章与工具文档
- W3C · Text size in translation
- W3C · Structural markup and right-to-left text in HTML
- Unicode · Unicode Bidirectional Algorithm (UAX #9)
- Unicode · Unicode Normalization Forms (UAX #15)
- Unicode CLDR · Plural Rules
- Microsoft · Localization Style Guides
- MQM Council · Multidimensional Quality Metrics
- OmegaT · Documentation