OCR 引擎和 AI 翻译模型有什么区别？屏幕翻译的两步分工
用屏幕翻译时你可能遇到过这种困惑：译文看着不对劲，但说不上问题出在哪——是工具没认对屏幕上的字，还是翻译本身翻岔了？这两种故障的解法完全不同，而把「读字」和「翻译」拆成两步看，问题立刻清晰。
屏幕翻译是两步，不是一步
很多人以为屏幕翻译是一个黑盒：丢进去一个画面，吐出来一段译文。实际工作流程分两步，各由不同的部件负责。
以 VoriTrans 为例，整个链条是这样的：
- OCR 引擎负责「读」：把屏幕上选区里的图像文字转成可编辑的文本，输出的是原文，比如日文对白「宿は右です」。这一步只认字，不理解意思。
- 翻译模型负责「译」：拿到 OCR 输出的文本，翻译成你选的目标语言，输出的是译文。这一步只管语言，看不见画面。
两步是流水线关系：翻译模型的输入，就是 OCR 的输出。这意味着一个关键结论——OCR 认错了字，翻译模型再强也翻不对。垃圾进、垃圾出，上游出错会一路传导到译文。
第一步：OCR 为什么在屏幕场景特别难
OCR（光学字符识别）本身不是新技术，扫描件识别已经很成熟。但屏幕场景比扫描件刁钻得多，难点都出在「画面」上。
扫描件是干净的平面：白纸黑字、方向固定、字号统一。屏幕画面则完全不同——文字可能压在渐变背景上，可能被半透明对话框盖着，可能是手写体或带描边的艺术字，甚至和画面元素交叠。竖排日文还要额外处理阅读顺序：OCR 得知道先读右列还是左列，读反了句子就乱了。
所以工具会给你调整空间。VoriTrans 的偏好设置里提供多个 OCR 引擎可切换，不同引擎对艺术字、低分辨率画面的适应能力不同；框选时缩小选区、只框文字所在区域，也能减少画面干扰。识别效果不理想时，先怀疑画面条件，再怀疑引擎，这个顺序能少走弯路。
第二步：翻译模型决定译文的上限
OCR 输出的原文文本交给翻译模型，译文质量从这一步开始分层。
翻译模型分两类。本地模型跑在你自己的电脑上，响应快、不依赖网络传输，短句对白处理得干净利落，代价是语境理解有限——游戏里的双关、梗、称谓，本地的处理通常保守。云端模型（Qwen、DeepSeek、GLM 这类大模型）参数量更大，长句、语境、语气明显更好，代价是按用量消耗积分。
值得强调的是：翻译模型无法弥补 OCR 的错误。如果识别文本本身缺字错字，云端大模型拿到的就是残缺输入，译文照样跑偏。所以「换更强的模型」和「修识别」是两件事，别指望用前者解决后者的问题。
拆成两步看，排查和优化都不迷路
理解分工的实际价值在用的时候：出问题能定位环节，优化能对症下药。
VoriTrans 的界面就是按这个分工设计的——「识别原文」和「翻译结果」是两个并列面板，识别这一步的中间产物直接可见。排查口诀很简单：
- 原文面板就错了：问题在 OCR。缩小选区、换个 OCR 引擎、调画面稳定等待，或者在术语词库里给易错的专有名词加一条 OCR 纠错（原词→替换词），下一次翻译自动生效。
- 原文对了、译文不对：问题在翻译模型。短文本换本地和云端各翻一遍对比；固定译名（人名、地名、技能名）不一致，用术语词库的翻译译法锁死。
一个小例子：角色名「ユキ」某几次被识别成「ユヌ」，译文跟着乱。在术语词库把「ユキ」设为 OCR 纠错词条后，识别环节先把字修正，翻译环节再统一翻成 Yuki——两个环节各修各的，互不干扰。这种精准度，正是两步架构给的。
一条边界：分工管的是屏幕上的字
两步流水线的适用范围是屏幕上显示的文字。角色没有字幕的语音、通话连麦、纯音频内容，OCR 无字可读，翻译模型自然无从接手——这不是模型强弱的问题，是输入端就没有可识别的对象。
理解了这一点，工具的能力边界就清楚了：只要文字出现在画面里——游戏对白、漫画气泡、视频硬字幕、软件界面——两步流水线就能接手；文字只存在于声音里，就需要另外的方案。VoriTrans 支持的目标语言有 105 种，两步中的第二步按你选的语言输出，识别端则对原文语言自动检测。
常见问题
OCR 和翻译模型，哪个出错的概率更大？
分场景。画面干净、字号清晰时，OCR 出错少；艺术字、低分辨率、文字压背景的场景，识别是重灾区。排查时先看识别原文面板：原文对，才轮到评估翻译模型。
换更强的翻译模型能补救识别错误吗？
不能。翻译模型的输入是 OCR 的输出，识别环节丢了字、错了字，上游错误会原样传下去。正确顺序是先修识别（选区、引擎、OCR 纠错），再考虑升级翻译模型。
术语词库作用在哪一步？
两步都能用。设为「OCR 纠错」时，它修正识别环节的易错字；设为「翻译译法」时，它约束翻译环节的译名统一。同一条词条只能选一种用途，按你要解决的问题选。
下次译文不对劲，先别急着怪翻译——打开识别原文面板看一眼，两秒钟分清是哪一步的问题。把分工弄明白，屏幕翻译的排查和优化都不再靠猜。
