最近，一位朋友跟我聊起了现在的游戏翻译工具。
只要框选屏幕上的一块区域，工具就会读取其中出现的文字，再把翻译结果显示在一个半透明窗口里。虽然会有一点延迟，但如果翻译环节使用LLM，就不只是机械替换单词，而是能结合上下文做更自然的意译。
我第一反应是：
“等等，现在已经到了不用等官方汉化或翻译补丁，也能直接玩外语游戏的阶段了吗？”
结果查着查着，话题彻底从游戏上跑掉了。
OCR负责看屏幕。
翻译模型负责理解意思。
Overlay负责把结果重新盖回原画面。
这个结构根本不只适用于游戏。
如果已经有一个能产出12种高质量语言版本的多语言文章系统，那么为什么不把这12种语言继续作为高质量核心层，再用本地翻译模型，只把热门文章薄薄地扩散到更多长尾语言？这样几乎不用增加LLM或云端API的消耗。
明明只是想聊游戏字幕。
最后却开成了全球内容分发架构会议。
1. 实时游戏翻译，其实就是四个零件
把实时翻译Overlay当魔法看，确实很酷。
拆开之后反而更有意思。
基本流程只有四步：
- 捕获游戏画面的指定区域。
- 用OCR把图像中的文字变成文本。
- 用翻译引擎、NMT或LLM转换成目标语言。
- 把翻译后的文字以半透明Overlay重新显示在游戏画面上。
公开的Windows工具已经采用了这种结构。OverlayTranslate会OCR指定画面区域，再把译文覆盖到原来的位置。SubLens会持续监视游戏画面中的特定区域，检测到新文字后自动翻译，并显示在透明Overlay中。[1][2]
以前的流程是“截图→打开翻译网站→粘贴→阅读→切回游戏”。
现在更像是“告诉翻译员该盯哪里，然后让他一直坐在游戏旁边”。
人类终于开始给没有本地化的RPG召唤常驻翻译了。
2. Google Lens很方便，但它并不等于游戏常驻翻译Overlay
Google Lens可以识别照片或摄像头画面中的对象和文字，还能选择并翻译图像中的文本。[3]
Google翻译也支持图片翻译。PC可以上传图片并翻译图片中的文字，手机则可以通过摄像头翻译。Google自己也提醒，小字、模糊文字和高度装饰化字体可能降低准确率。[4]
因此Lens很像整个系统的“眼睛”。
但朋友描述的游戏翻译工具又多走了一步。
Lens更像“请读这张图”。
游戏Overlay则是“请一直盯着这个区域，只要出现新台词就自动处理”。
差别不只在翻译质量。
持续截图、差分检测、缓存、窗口焦点判断、把文字重新画到正确位置，这些不起眼的工程细节才真正决定游戏时好不好用。
AI负责上头条。
管线工程负责让你顺利玩下去。
3. “Google翻译不是LLM吧？”到了2026年已经不能一句话说完
如果脑中想的是过去的Google翻译，那么把它和ChatGPT一类系统分开理解，大体没错。
Google翻译长期以来主要依赖专门用于翻译的神经机器翻译。
但2025年12月，Google宣布把Gemini的翻译能力带入Google Translate的文本翻译，重点提升对俚语、习语和依赖上下文表达的自然处理能力。[5]
2026年2月，Google又利用Gemini的多语言能力扩展了译法候选、语气和含义解释功能。[6]
在语音方面，Google随后公布Gemini 3.5 Live Translate，可在70多种语言中进行近实时语音到语音翻译。[7]
所以在2026年，如果简单说“Google翻译不是LLM”，已经过于粗糙。
但反过来说“每一次Google翻译请求都直接进入一个通用Gemini聊天模型”也同样武断。
Google公开的是Gemini能力已经被整合进Translate，而不是整套内部路由架构。
更准确的说法是：边界正在变模糊。
4. 免费的Google翻译界面和自动化API不是同一件事
看到这里，很容易冒出一个想法：
“那文章也全部用免费的Google翻译不就行了？”
听起来很爽。
但普通用户使用Google翻译不按字符付费，并不等于程序可以通过一个官方API无限、免费地自动翻译。
Google Cloud Translation的NMT目前给出每月前50万字符的免费额度，超过后标准价格为每100万字符20美元。[8]
假设一篇文章5,000字符。
翻译到50种语言，就是25万字符。
两篇就是50万字符。
如果一个月把10篇热门文章翻译成50种语言，总量会达到250万字符。扣掉免费部分，剩余200万字符按标准价约为40美元。
很便宜。
但不是零。
Google Cloud的Translation LLM还单独列出了输入和输出费用。[8]
所以如果“不能有持续API账单”是硬条件，最干净的设计不是无限扩大云端翻译，而是增加一条本地翻译通道。
5. 真正适合零API费用路线的，是本地翻译模型
这时，本地翻译模型就有意义了。
Google公开的MADLAD-400-3B-MT在Hugging Face上标注支持419种语言，并采用Apache 2.0许可证。[9]
如果在自己的机器上运行，就不会每翻译一次都产生API调用费用。
当然，这不代表真实成本字面上等于零。
它会占用CPU或GPU。
会耗电。
会耗时间。
但扩展逻辑发生了变化：字符越多，不再意味着必须按字符向云服务商付更多钱。
关键是不要把“支持419种语言”理解成“419种语言都达到人工翻译质量”。
低资源语言的质量可能差很多。
因此本地翻译的正确定位，不是替代高质量的12种核心语言，而是让以前因为成本问题无法测试的语言变得可实验。
6. 这时话题从游戏跳到了文章工厂——高质量12语言不要动
如果一个多语言文章系统已经使用LLM产出12种高质量语言版本，就没必要为了省钱把它们降级成廉价机器翻译。
这12种语言就是母舰。
例如核心包含日语、英语、韩语、简体中文、繁体中文、西班牙语、巴西葡萄牙语、印度尼西亚语、泰语、越南语、法语和德语。
如果这些版本已经完成上下文整理、自然意译、标题结构调整和质量检查，那么它们不仅仅是12个翻译结果。
它们是12个已经被整理过语义的中间表示。
新增语言时也不一定必须永远从日语直译。
对于某些目标语言，英语版、西班牙语版或印度尼西亚语版可能更适合作为中间源。
不过翻译链越长，误差也可能累积。
所以不能只凭“语言看起来比较近”来选父语言，而应该用小规模基准测试多个候选源，比较数字、专有名词、否定、限定词和整体含义的保留程度，再为每种目标语言固定最稳定的路线。
7. 不做“所有文章×所有语言”。热门度就是过滤器
这是整个设计最好吃的部分。
即使有5,000篇文章，也不需要把5,000篇全部翻译成100种语言。
先做热门文章就够了。
例如按最近30天PV：
- 前10名：增加50种语言
- 11到50名：增加20种语言
- 其他文章：只保留高质量12语言
也可以更简单：每天取前20篇文章，只翻译还不存在的“文章×语言”组合。
翻译一旦生成，就成为资产。
于是每天都会从热门内容开始，逐渐把世界地图涂满。
这不是“第一天就在全世界建设完整基地”。
而是“先派几乎免费的侦察兵出去，有反应的地方再派主力”。
更聪明。
也更省钱。
8. 把语言分成三层，让真实需求决定质量投资
新增语言可以分成三层。
Core：当前高质量12语言。使用LLM、本地化、严格QC，并覆盖全部文章。
Growth：已经开始产生真实访问的新增语言。默认使用本地翻译，但逐步增加文章覆盖。
Experimental：需求未知的长尾语言。只翻译热门文章，最初甚至可以限制搜索索引。
之后根据访问量、读完率、下一篇点击、复访等指标升级。
Experimental没人读，就保持原样。
波兰语开始有流量，就升到Growth。
土耳其语持续增长，而且读者行为也不错，就进入Core候选。
这样就不必在会议室里猜“下一个会火的是哪种语言”。
翻译本身直接变成市场调查。
9. 想保持免费，就先做不依赖LLM的QC
如果每个新增语言都要送进ChatGPT问一句“这个翻译对吗？”，免费翻译的意义很快就没了。
第一层QC应该尽量由代码完成。
可以自动检查的东西其实很多：
- 数字、百分比、货币、日期是否保留
- URL是否变化
- 标题数量是否异常减少
- Markdown或HTML结构是否损坏
- 标题和description是否为空
- 是否残留大量源语言
- 是否明显偏离目标语言的文字系统
- 是否疑似丢失否定表达
- 专有名词是否被异常改写
- 输出长度是否相对原文极端过短或过长
必要时，还可以使用本地模型把目标语言重新翻译回英语等中间语言，只把语义偏差特别大的内容标记出来。
这不是完美的质量评估。
但对于阻止坏翻译被批量发布非常有效。
昂贵的LLM不应该当全量流水线质检员，而应该当异常工单的复检员。
10. 比“100种语言”更重要的是，不要制造100堆垃圾
最后还有一个坑。
页面数量增加，并不意味着搜索流量会按语言数同比增长。
Google Search Central建议不同语言版本使用不同URL，并通过hreflang等方式标明对应关系；同时页面正文和导航都应该让语言清晰一致。[10]
另一方面，Google把以操纵搜索排名为主要目的、通过自动转换或翻译大量生成低价值页面的行为列为scaled content abuse的例子之一。[11]
所以Experimental页面一生成就全部放进搜索索引，没有必要。
可以先noindex。
先观察质量和需求。
只有通过质量门槛的语言再进入index。
用户必须真的能读。
不能只翻正文，界面也要对应语言。
语言URL和hreflang要正确。
语义不能坏。
原始文章本身也必须有价值。
这样，语言数量才是资产，而不是垃圾倍增器。
整件事最初只是朋友说了一句游戏翻译。
“现在可以读取屏幕上的文字，用LLM自然翻译，再通过半透明窗口覆盖回去。”
于是我们查了Google Lens，又查了Google翻译与LLM之间正在变化的边界，再查API价格，最后跑到了本地翻译模型。
最终得到的架构反而很简单：
高质量12语言保持不动。
只把热门文章通过本地翻译低成本扩展到更多语言。
真正出现需求的语言，再升级到更高质量层。
我们一开始只是想在游戏画面上叠一层翻译字幕。
最后却开始给整个文章系统一层一层叠全球语言。
技术迁移，大概就是从这种合理的跑题开始的。
参考资料（11条）
- OverlayTranslate — Windows overlay translation tool using OCR and multiple translation engines github.com
- SubLens — real-time OCR-powered game dialog translator with continuous scan and transparent overlay github.com
- Google Search Help — Google Lens can select text and translate supported text through Google Translate support.google.com
- Google Translate Help — image translation on desktop and mobile; Google notes lower accuracy for small, unclear, or stylized text support.google.com
- Google, 2025-12-12 — Bringing state-of-the-art Gemini translation capabilities to Google Translate blog.google
- Google, 2026-02-26 — AI-powered context and translation alternatives in Google Translate using Gemini capabilities blog.google
- Google, 2026-06-09 — Gemini 3.5 Live Translate, near-real-time speech-to-speech translation in more than 70 languages blog.google
- Google Cloud Translation pricing — NMT first 500,000 characters per month covered by free credit, then standard per-character pricing; Translation LLM priced separately cloud.google.com
- Google MADLAD-400-3B-MT on Hugging Face — 419 languages listed, Apache 2.0 huggingface.co
- Google Search Central — Managing multi-regional and multilingual sites; separate URLs and hreflang guidance developers.google.com
- Google Search Central — Spam policies; scaled content abuse includes low-value pages generated through automated transformations such as translating when created primarily to manipulate rankings developers.google.com
