设备端 OCR 是如何工作的：Apple Vision 框架解析

「设备端」到底是什么意思

「设备端 OCR」这个说法在营销文案里被滥用，所以放在 Apple Vision 的语境下值得说清楚。当一个 macOS 应用让 Vision 识别图像里的文字时，整条流水线——图像预处理、检测和解码字形的卷积/Transformer 网络、用来消歧的语言模型——全都跑在你这台 Mac 物理意义上的硬件里。CPU、集成 GPU、以及在 Apple Silicon 上的神经网络引擎，三者分担计算。没有任何字节离开过这台机器。

云端 OCR 完全是另一套逻辑。Google Cloud Vision、AWS Textract、Azure Computer Vision 都需要你把图像作为 base64 块通过 HTTPS 上传。图像落到服务商的数据中心，跑过他们的模型，再把识别结果返回给你。这个往返的下限是光速 + 你的网络 + 服务商的队列。它还意味着这张图——哪怕只是短暂地——存在过别人的硬盘上，遵循着对方当下的日志、留存和模型训练策略。

设备端绕开了所有这些。没有上传步骤，应用不需要申请网络权限，也没有需要管理的 API key、需要监控的配额、按次计费的账单，更没有需要研读的隐私政策。代价是你被绑定在系统出厂的模型和你买到的芯片上。对截图 OCR 这件事来说，绝大多数 Mac 用户都觉得这笔账划算。

Apple Vision 框架的简史

Apple Vision 在 2017 年的 WWDC 随 iOS 11 和 macOS 10.13 High Sierra 一起发布。第一版只能做人脸检测、矩形检测和条形码读取——有用，但还不算 OCR。真正的文字识别要等到 2019 年 iOS 13 / macOS 10.15 Catalina，那时苹果加入了 VNRecognizeTextRequest。从这一刻起，「Vision 能读字」才不再是一句宣传语，而成了几行 Swift 就能调用的接口。

大多数人通过 Live Text（实况文本）认识到苹果设备端 OCR，那是两年后 iOS 15 和 macOS Monterey 才上线的。Live Text 不是替代品——它只是给框架套了一层 UI。底层不管你是在「信息」里长按一张照片、在 Safari 里悬停在一段文字上，还是用 Cheese! OCR 这类第三方工具，干活儿的都是同一个 VNRecognizeTextRequest。Ventura、Sonoma、Sequoia 这几代 macOS，苹果都在持续优化模型，加新语言、提升准确率。

到 2026 年，框架已经支持几十种语言，包括历史上最让 OCR 引擎头疼的中日韩三种文字。Vision 还成了照片搜索（「找出含文字的照片」）、VoiceOver 的图像描述、以及「实况查询」等功能的底层组件。

VNRecognizeTextRequest API

开发者实际调用的类是 VNRecognizeTextRequest。它接收一张输入图、一组配置项和一个 completion handler，返回一个 VNRecognizedTextObservation 数组——每一项包含若干识别候选和一个边界框。

最重要的两项配置：第一项是 recognitionLevel，有两种模式。.fast 用一个为速度优化的小模型，适合实时摄像头帧或视频滚动；.accurate 用更大的模型，是静态截图和 PDF 页面应该选的那个。包括 Cheese! OCR 在内的大多数 Mac OCR 工具默认都用 .accurate，因为用户面对的是单张静态图，多花几百毫秒人是感知不到的。

第二项是 recognitionLanguages，一个有序的 BCP-47 语言标签数组，比如 "en-US"、"zh-Hans"、"ja-JP"、"ko-KR"。顺序会作为提示喂给语言模型，帮它在相似字形里做选择——比如把拉丁字母 o、数字 0 和西里尔字母 о 区分开。一个面向通用场景的 Mac OCR 工具，默认把中英日韩四个标签全开是合理的，因为用户随手截一张知乎或者 B 站的截图，下一秒可能就在截外刊论文。

还有一个 usesLanguageCorrection，用来开启识别后的语言模型纠错。打开后，「teh」会被纠成「the」，识别结果会被词频统计平滑过。关掉则按像素逐字返回，对代码、车牌、产品 SKU 这类内容更合适。

一段最小可用的 Swift 示例

下面这段是用 Apple Vision 在 CGImage 上跑 OCR、并把识别结果打印出来的最小 Swift 代码。Cheese! OCR 内部用的就是这条调用路径，把错误处理和 UI 部分剥掉了。

import Vision

func recognizeText(in cgImage: CGImage) {
    let request = VNRecognizeTextRequest { request, error in
        guard let observations = request.results as? [VNRecognizedTextObservation] else {
            return
        }
        let lines = observations.compactMap { $0.topCandidates(1).first?.string }
        print(lines.joined(separator: "\n"))
    }

    request.recognitionLevel = .accurate
    request.recognitionLanguages = ["en-US", "zh-Hans", "ja-JP", "ko-KR"]
    request.usesLanguageCorrection = true

    let handler = VNImageRequestHandler(cgImage: cgImage, options: [:])
    try? handler.perform([request])
}

有几点值得说一下。Completion handler 跑在后台队列上，所以做 UI 的应用要先切回主线程再去更新剪贴板或弹通知。topCandidates(1) 只取最高置信度的那个，要是想把多个备选给用户看，可以传更大的数。这里 VNImageRequestHandler 接的是 CGImage，但它也接 CVPixelBuffer、CIImage 或者文件 URL——从视频帧或 PDF 页喂数据时很有用。

普通场景的 API 表面就这么大。不用装 SDK、不用打包模型文件、没有授权流程、没有用量看板。系统提供模型，芯片负责跑，应用只是调一个函数。

为什么神经网络引擎在 Apple Silicon 上很重要

神经网络引擎（Neural Engine）是每颗 Apple Silicon 芯片里那个专用的机器学习加速器。M1 起步就是 16 核，M2、M3 沿用，M4 在吞吐和共享内存带宽上又做了架构升级。在 Apple Silicon Mac 上，Vision 的文字识别模型默认会被编译到神经网络引擎上跑，神经网络引擎搞不定的部分由 GPU 兜底。

带来两个实在的影响。一是 OCR 真的快——快到你按下快捷键截一小块屏幕，几乎是「瞬时」反馈。二是 OCR 很省电。神经网络引擎单次推理的能耗远低于 CPU 或 GPU，意味着连续 OCR 几百张截图，MacBook 的电量也不会被显著拖垮。同一块硬件还在加速 Siri、照片搜索、语音备忘录的转写、Apple Intelligence 的功能——Vision 只是众多用户之一。

Intel Mac 上框架照常工作，回落到 CPU 和 GPU 的路径，会稍慢一些，但对一张普通截图大小的图像，人感知不出多大差别。Vision 在设计上就是要让整个 Mac 产品线都能用，而不是只服务最新的硬件。

隐私：本地化为什么真的重要

设备端 OCR 最常被一笔带过的部分恰恰是隐私。技术层面这件事很简单：用 Apple Vision 识别一张截图时，那张截图的字节从来没离开过你这台 Mac。Apple 看不到。你的网络看不到。哪怕调用 Vision 的是某个第三方应用——它本身也看不到。

最后一点之所以重要，是因为「设备端 OCR」这个词有时候会被滥用。一个应用完全可以在用 Apple Vision 的同时，把识别结果、遥测数据甚至原始截图回传服务器去「训练」。验证它是否真的本地化的方法，是看它在 App Store 沙盒里的网络权限。通过 Mac App Store 分发的应用必须声明所有用到的网络能力；一个完全没有网络权限的应用，从内核层面就被禁止发起任何 HTTP 请求——一次都不行。

Cheese! OCR 就属于后者。它没有网络权限、没有遥测 SDK、没有数据分析服务、也没有把崩溃日志送出机器的服务。Vision 调用送给系统、识别结果送给系统剪贴板，整个数据流就到此为止。如果你是在公司内部 Slack 频道、机密合同或私人聊天截图上做 OCR，这件事的分量就完全不一样了。

Apple Vision 与云端 OCR 对比表

把权衡集中放在一处，下面是 Apple Vision 与三大云端 OCR API 的对照。云端价格用区间表示，因为这些厂商的计费档位经常重排，实际单价取决于用量、地区和功能开关；当作大致量级看就好，具体以官方定价页为准。

对一款面向终端用户的 Mac 应用来说，结论很清楚：成本、延迟、隐私三项 Apple Vision 占优；当你需要服务端批处理、结构化表单解析、或者苹果不支持的语种时，云端 API 更合适。

Apple Vision 仍然搞不定的场景

装作 Apple Vision 完美无缺并不诚实，知道它的边界对挑选 OCR 方案很重要。

连笔手写。整齐的印刷体手写 Vision 还能勉强读出来，但连笔英文、手写汉字或自由记笔记基本就是看运气。要是你的工作流核心是扫手写笔记，光靠 Apple Vision 不够——多模态大模型或专门的手写识别引擎效果会更好。

中文竖排。古籍、传统竖排报纸、繁体古文献往往是上至下、右至左排版。Vision 的文字检测器深度偏向横向左到右的行布局，经常会把竖排切碎或者读乱顺序。它没有公开的「竖排模式」开关。

严重倾斜或扭曲的文字。对着书脊弯折的纸页拍照、斜角度拍的招牌、做了透视变形的截图都可能让检测器懵。Vision 自带一定校正能力，但没有某些云端服务那么激进。

装饰性字体。游戏 UI 的特殊字、书法、复古招牌、字间距夸张的 logo 字，识别准确率会下降。模型主要训练在常见字体上，长尾的装饰字体是已知短板。

数学和化学符号。方程、积分号、化学结构式以及任何不是按阅读顺序排布的二维版式，都会被压平成一行字符串。要 LaTeX 或 MathML 输出，得用专门的模型——Mathpix 之所以存在就是这个原因。

这些短板并不意味着设备端 OCR 不适合常见场景。它只是说明它不是万能溶剂。

这一切对 Cheese! OCR 这类工具意味着什么

这些底层细节对一款 Mac OCR 工具的意义在于：选哪套框架，决定了这个应用能承诺什么、不能承诺什么。一个走云端的 OCR 应用宣传「极速识字」，本质上有一个网络延迟的硬下限和一个永远去不掉的隐私脚注。一个完全本地、基于 Apple Vision 的 OCR 应用，则会同时继承框架的下限（非常快）和它的天花板（苹果支持的语种和准确度）。

Cheese! OCR 直接构建在 Apple Vision 之上。按下快捷键、拖选屏幕区域，得到的 CGImage 被交给 VNRecognizeTextRequest，默认开启中英日韩四种语言。识别结果稍后落入剪贴板，并被写入本地的 SQLite 历史库。没有服务器。没有网络权限。没有遥测。这个应用跑的是和 Live Text 一样的模型，只是上面套了一个不一样、坦白说更顺手的 UI。

这个选择是用户能感觉到的。它在飞机上能用。它在某些封锁了大半个互联网的公司 VPN 里能用。它在 Google 服务无法访问的地区能用。家里 Wi-Fi 抽风时它不会卡。当你截一张机密合同、内部聊天或私人短信的截图来 OCR，你不需要再多想一个「现在哪家第三方看到了这张图」的问题。

给自己挑 OCR 方案时，「框架」这件事应该是最先讨论的话题。云端和本地各有合理用途。日常在自己的 Mac 上做截图 OCR，本地的 Apple Vision 很难被超越——下面的常见问题列出了大家最常问的那几条。