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 糾錯」時，它修正識別環節的易錯字；設為「翻譯譯法」時，它約束翻譯環節的譯名統一。同一條詞條只能選一種用途，按你要解決的問題選。
下次譯文不對勁，先別急着怪翻譯——打開識別原文面板看一眼，兩秒鐘分清是哪一步的問題。把分工弄明白，熒幕翻譯的排查和優化都不再靠猜。
