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