macOS原生OCR：用Swift Vision实现命令行文字识别工具

如果你在 macOS 上遇到过“图片里有文字，但不能复制”的尴尬，一定会对今天的主题感兴趣。我见过不少人为了从截图、扫描件、网页图片里提取文字，专门去装一个 OCR 软件，或者把图片传到在线识别网站。问题是，这些方案要么涉及隐私风险，要么受网络限制，要么需要付费，用起来总是不够顺手。

实际上，macOS 系统里早就内置了 OCR 能力，只是它藏得比较深，普通用户很难直接调用。这篇文章要讲的正是如何把这套系统级能力挖掘出来，用 Swift 和 Vision 框架做一个“猴子看见什么，就能复现什么文字”的小工具。这种原生方案最大的价值在于：不需要联网、不需要上传图片、不需要额外付费，识别结果完全留在本地。

读完这篇文章，你可以做到三件事：第一，理解 macOS 原生 OCR 的技术原理和适用范围；第二，动手写一个完整的命令行 OCR 工具，输入一张图片就能输出识别文本；第三，知道如何把它接入自己的自动化工作流，比如快速提取截图文字、批量处理扫描文档。整个过程不需要复杂的图形界面开发，一份 Swift 脚本就能跑通。

1. 这篇文章真正要解决的问题

先聊一个真实场景。假设你正在做一个知识管理项目，需要从几十张截图里提取文字，建一个检索库。最容易想到的方案是什么？可能你会打开一个在线 OCR 网站，一张一张上传，再把识别结果复制回来。这个过程不仅慢，而且每一张图片都经过第三方服务器，敏感信息的安全完全没法保证。如果你是开发人员，或许会想到用 Python 的 pytesseract，但 tesseract 在中文识别上的准确率并不理想，尤其遇到截图里带水印、字体太小或者背景花哨的图片时，结果往往惨不忍睹。

在这个背景下，macOS 的原生 OCR 方案就很有吸引力。从 macOS 10.15 开始，Apple 在 Vision 框架里提供了VNRecognizeTextRequest这个 API，它直接调用系统级文本识别引擎。这套引擎经过 Apple 多年优化，对系统截图、文档扫描、网页图片的识别效果都相当稳定。更关键的是，它是原生能力，识别过程完全在本地完成，不需要把图片发到任何服务器。

但这里有一个现实问题：普通用户不知道怎么调用它。VNRecognizeTextRequest是给开发者用的 API，没有现成的图形界面，也没有命令行工具。你不可能在“终端”里敲一个命令就让 macOS 帮你识别图片文字。于是，很多人明明手里有最好的工具，却只能绕远路用第三方服务。

这篇文章要解决的就是这个“能力存在但不可用”的断层。我会拆解如何用 Swift 写一个命令行工具，把 Vision 框架的原生 OCR 能力封装成一个可复用的程序。做完之后，你只需要在终端里执行一句命令，传入图片路径，就能在终端里看到识别结果。

这件事对三类人最有价值：第一，经常处理截图的效率工具爱好者，希望能把图片转文字的速度提高几个量级；第二，正在做文档处理、知识库、自动化脚本的开发者，需要一个纯本地的 OCR 引擎；第三，关注隐私的普通用户，不想把个人图片上传到任何在线服务。

2. 基础概念与核心原理

要理解 macOS 原生 OCR，先要弄清楚几个关键概念。这个概念链条从最上层的应用场景，一直延伸到系统底层的神经网络模型，但对开发者来说，核心只需要抓住Vision 框架和VNRecognizeTextRequest。

Vision是 Apple 提供的计算机视觉框架，它不是只能做 OCR，还能做人脸检测、物体分类、二维码扫描等任务。理解这一点很重要：Vision 是一个框架集合，OCR 只是它的能力之一。在 Vision 内部，文本识别请求通过VNRecognizeTextRequest这个类来构建。你把一张图片交给它，它返回一个数组，每个元素包含识别到的文本、置信度，以及文本在图片上的位置信息。

VNRecognizeTextRequest最核心的配置有两个：

• recognitionLevel：识别精度模式，分为.fast和.accurate两档。.fast速度更快，适合实时场景；.accurate精度更高，适合静态图片和处理复杂内容。
• recognitionLanguages：识别语言列表，需要指定["zh-Hans", "en-US"]这类值，让引擎知道该用哪些语言模型。

从 macOS 11（Big Sur）开始，Vision 的 OCR 对中文简体、繁体、英文、法文、意大利文、德文、葡萄牙文等多种语言都有了不错的支持。在 macOS 10.15 Catalina 时代，识别语言相对有限，能识别中文是后续版本的重要更新。

这里要澄清一个常见误区：很多人以为 Vision 框架的 OCR 只是把图片“看”一遍，然后输出文字，实际上它的返回值远比这丰富。除了文本内容，它还提供了boundingBox——也就是每个识别区域在图片中的坐标位置。这意味着你不仅能提取文字，还能知道文字出现在图片的哪个位置，这为后续的排版重建、区域截图标注提供了可能。

另外一个容易混淆的概念是VNImageRequestHandler。它是所有 Vision 请求的入口，负责把图片数据解析成可供模型分析的格式，然后执行请求，返回结果。每次 OCR 处理的基本流程是：创建识别请求 → 创建图片处理器 → 把请求交给处理器执行 → 从结果中解析文本。

用一个类比来帮助你理解：VNImageRequestHandler相当于一个工厂的接收台，它接收原材料（图片），然后分派给生产线（识别请求），最后把成品（识别结果）送到你手上。你只需要关心怎么描述需求（配置请求），以及怎么处理成品（解析结果），中间的生产细节由系统完成。

还有一个值得了解的概念是“原生”这个词意味着什么。macOS 原生 OCR 和网上常见的 OCR 服务最大的区别在于计算发生的位置。原生方案在你的 Mac 上完成所有计算，不依赖网络。而在线方案需要把图片上传到服务商的服务器。两者的隐私边界完全不同，这也是原生方案如今备受关注的原因。

3. 环境准备与前置条件

在开始写代码之前，需要先确认几件事。这个项目虽然名为“macOS 原生 OCR”，但并不是所有 Mac 都能立刻运行，也不是随便一个 macOS 版本就能支持所有语言。

3.1 操作系统要求

Vision 框架的VNRecognizeTextRequest最早出现在 macOS 10.15 Catalia 中。但如果需要良好的中文识别支持，更稳妥的起点是 macOS 11 Big Sur 或更高版本。从实测角度看，macOS 12 Monterey、macOS 13 Ventura 以及之后的 Sequoia 版本中，Vision 的中文识别能力已经有明显优化，可以放心使用。

你可以在终端执行以下命令查看当前系统版本：

sw_vers

输出会包含类似这样的信息：

ProductName: macOS ProductVersion: 14.5 BuildVersion: 23F79

如果显示的系统版本低于 10.15，建议先升级系统，否则接下来的代码无法编译运行。

3.2 开发工具要求

这个项目需要使用 Swift 编译器。最方便的方式是安装 Command Line Tools for Xcode，它包含swiftc、swift等命令行工具，不需要安装完整的 Xcode 应用。

安装命令：

xcode-select --install

执行后系统会弹出安装窗口，按照提示完成即可。安装完成后，验证 Swift 版本：

swift --version

正常输出类似：

swift-driver version: 1.90.11.1 Apple Swift version 5.10 Target: arm64-apple-macosx14.0

如果你的 Mac 是 Apple Silicon（M1/M2/M3/M4），这里显示的 Target 会是arm64，如果是 Intel 芯片则是x86_64，这都不影响项目运行。

3.3 权限准备

macOS 对访问系统资源有严格限制。这里有一个容易被忽略的地方：Vision 框架识别图片时，如果图片位于“下载”“桌面”“文稿”等受保护目录，在使用某些 API 时可能会触发权限限制。更稳妥的做法是，在测试阶段把图片放到/tmp目录，或者放到一个你有完整读写权限的自定义目录，比如~/Projects/ocr-test。

此外，如果你在“系统设置 → 隐私与安全性”里启用了增强隐私保护，终端应用（Terminal 或 iTerm2）可能需要额外的“文件与文件夹”访问权限。遇到权限问题不要慌张，先检查系统设置里的隐私项。

3.4 验证系统 OCR 能力

一个有趣的方法是先不用代码，直接验证系统 OCR 是否可用。在 macOS 较新版本中，你可以打开“预览”应用，打开一张包含文字的图片，然后用“预览”的“文本选择”功能（如果系统支持）拖动选择文字。如果能用鼠标选中图片里的文字，说明系统 OCR 引擎正在工作，代码调用不会存在底层问题。

另外一个更快的测试方式是用 Spotlight 搜索。在某些系统版本中，Spotlight 可以对图片内容进行 OCR 索引。如果你搜索一个只有图片里才有的关键词，Spotlight 能找到这张图片，那说明系统 OCR 能力完全正常。

4. 核心流程拆解

整个原生 OCR 工具的实现流程并不复杂，但每一步都有值得注意的细节。下面把流程拆成五个阶段，从创建项目到最终验证。

4.1 创建 Swift 命令行项目

最简单的做法是创建一个独立目录，在里面放一个 Swift 源文件。这里不需要使用 Xcode 工程，直接使用 Swift Package Manager 或单文件编译都可以。为了保持演示的简洁性，下面采用单文件方式。

mkdir OcrTool cd OcrTool touch main.swift

这样做的好处是整个项目只有一个文件，后续编译命令非常直接。缺点是如果项目变得庞大，单文件的维护性会下降。对于本文场景，单文件已经足够。

4.2 读取图片数据

OCR 的第一步是把图片加载到内存。macOS 下加载图片有几种方式，最常用的是NSImage。但需要注意一点：NSImage是一个高层抽象，它内部可能包含多分辨率表示，直接交给 Vision 不一定能得到最好结果。更可靠的方式是使用CGImageSource直接读取底层图像数据，或者用NSImage获取cgImage属性。

在命令行工具中，我们需要从命令行参数拿到图片路径，然后判断文件是否存在，再加载为CGImage。这一步的错误处理一定要做好，路径不存在时程序应该给出明确提示，而不是直接崩溃。

4.3 创建识别请求

创建VNRecognizeTextRequest时，需要设置识别精度和语言列表。这里有一个关键的“坑”：语言列表排序会影响识别效果。优先将你最常用的语言放在前面。比如处理中文截图，可以设置["zh-Hans", "en-US"]，而处理英文文档，可以设置为["en-US"]。

精度设置也要根据使用场景选择。命令行工具通常处理静态图片，推荐使用.accurate；如果你后续要做实时取词，为了流畅性可以考虑.fast。

4.4 处理图片并执行识别

用VNImageRequestHandler加载图片，然后调用perform方法执行请求。这是整个流程里最消耗资源的环节。对于普通截图，几百毫秒内可以完成；对于高分辨率图片，可能需要一两秒。如果图片过大，建议先做缩放预处理，把最长边限制在 2000 像素以内，这样既保证识别质量，又显著提升速度。

4.5 解析结果并输出

执行完成后，从请求的results属性中取出VNRecognizedTextObservation数组。每个 observation 代表图片中一个文本区域，通过topCandidates(1)方法可以拿到最可能的识别结果。按顺序取出每个文本的字符串，然后在终端输出。

这里有一个值得注意的细节：Vision 返回的结果顺序并不保证和人类阅读顺序完全一致。实际开发中，可能需要根据boundingBox的坐标进行排序，才能得到更自然的阅读顺序。

5. 完整示例与代码实现

现在进入本文最核心的部分：完整代码实现。我们将会开发一个名为MacaqueOCR的命令行工具，这个名字来源于“Monkey see, monkey do”的双关——它看见什么图片，就能“复现”出什么文字。

5.1 项目文件结构

OcrTool/ ├── main.swift └── 测试图片/ └── screenshot.png

如果你有 Xcode，也可以直接创建一个 Swift Package：

mkdir OcrTool cd OcrTool swift package init --type executable

这样会生成标准的包结构，main.swift位于Sources/OcrTool/main.swift。使用 SPM 的好处是后续扩展依赖更加方便。

5.2 完整 Swift 代码

下面是一个完整的命令行实现。代码文件路径为main.swift。

import Foundation import Vision import AppKit // 从命令行参数获取图片路径 guard CommandLine.arguments.count > 1 else { print("用法: swift main.swift <图片路径> [--fast]") print("示例: swift main.swift /path/to/image.png") exit(1) } let imagePath = CommandLine.arguments[1] let useFastMode = CommandLine.arguments.contains("--fast") // 检查文件是否存在 guard FileManager.default.fileExists(atPath: imagePath) else { print("错误: 图片文件不存在: \(imagePath)") exit(1) } // 加载图片 guard let image = NSImage(contentsOfFile: imagePath), let cgImage = image.cgImage(forProposedRect: nil, context: nil, hints: nil) else { print("错误: 无法加载图片文件: \(imagePath)") exit(1) } // 创建 OCR 请求 let request = VNRecognizeTextRequest() request.recognitionLevel = useFastMode ? .fast : .accurate request.recognitionLanguages = ["zh-Hans", "en-US"] request.usesLanguageCorrection = true // 执行识别 let handler = VNImageRequestHandler(cgImage: cgImage, options: [:]) do { try handler.perform([request]) } catch { print("错误: OCR 识别失败: \(error.localizedDescription)") exit(1) } // 解析结果 guard let observations = request.results as? [VNRecognizedTextObservation] else { print("错误: 未获取到识别结果") exit(1) } // 输出结果 print("识别完成，共找到 \(observations.count) 个文本区域：") print("----------------------------------------") for observation in observations { if let candidate = observation.topCandidates(1).first { let text = candidate.string let confidence = candidate.confidence print("\(text) [置信度: \(String(format: "%.2f", confidence))]") } }

5.3 代码关键逻辑说明

这段代码虽然不长，但每部分都有对应的问题考虑。

CommandLine.arguments用来读取用户传入的图片路径。Swift 命令行工具的参数规则是：arguments[0]是程序自身路径，arguments[1]才是第一个用户参数。这也是为什么判断count > 1。

NSImage加载图片后，通过cgImage(forProposedRect:context:hints:)获取底层的CGImage。这一步非常关键。如果不做转换直接使用NSImage，Vision 可能在处理多分辨率表示时出现异常。

VNRecognizeTextRequest创建后，设置recognitionLevel。这里提供了--fast参数开关，让用户能根据需求选择精度模式。recognitionLanguages设置了两门语言，这意味着引擎会在中英文混合场景下工作。usesLanguageCorrection启用了语言修正，这个功能会自动纠正一些明显的拼写错误和语法问题，对中文英文混合的截图效果不错。

VNImageRequestHandler用cgImage初始化，然后调用perform方法。如果图片格式不合法，这一步会抛出异常，所以必须用try包裹。

结果处理时，先把results转为[VNRecognizedTextObservation]数组，然后遍历每个 observation，用topCandidates(1)取置信度最高的候选文本。输出时附带置信度，方便你判断哪些结果可能不够准确。

5.4 SPM 配置

如果你的项目采用 Swift Package Manager 组织，需要在Package.swift中添加以下配置：

// swift-tools-version:5.9 import PackageDescription let package = Package( name: "OcrTool", platforms: [ .macOS(.v11) ], targets: [ .executableTarget( name: "OcrTool", path: "Sources/OcrTool" ) ] )

5.5 Shell 封装脚本

每次执行swift run或swiftc编译比较麻烦。可以创建一个 Shell 脚本ocr.sh来封装调用：

#!/bin/bash # 文件路径：OcrTool/ocr.sh cd "$(dirname "$0")" swift run OcrTool "$@"

执行以下命令赋予脚本执行权限：

chmod +x ocr.sh

之后使用方式就变成了：

./ocr.sh /path/to/image.png ./ocr.sh /path/to/image.png --fast

6. 运行结果与效果验证

代码写完之后，最关心的就是运行起来效果如何。下面用一个实际场景来验证。

6.1 准备测试图片

假设我们有一张系统截图screenshot.png，截图内容包含一段中文文字和一段英文文字：

你好，世界。 Hello, World. 这是一个 macOS 原生 OCR 测试。

用sips命令可以快速生成一张测试图片。比如，我们可以把一段文本渲染成图片再识别。不过更简单的方式是直接用“抓图”工具截取屏幕内容。

6.2 运行命令

执行以下命令：

cd OcrTool ./ocr.sh /tmp/screenshot.png

6.3 预期输出

识别成功时，输出类似：

识别完成，共找到 3 个文本区域： ---------------------------------------- 你好，世界。 [置信度: 0.98] Hello, World. [置信度: 0.97] 这是一个 macOS 原生 OCR 测试。 [置信度: 0.95]

从结果可以看出，中英文混合文本都能被正确识别，置信度通常在 0.9 以上。如果遇到识别不准的图片，输出中的置信度会明显降低，比如低于 0.7，这时需要检查图片质量、文字大小和背景复杂度。

6.4 如何判断识别成功

判断识别是否成功，不能只看有没有输出文字，还要看三个方面：

• 文本内容是否和原图一致：重点检查中文标点、英文字母大小写、数字和特殊字符。
• 文本顺序是否合理：如果识别出多行文本，顺序是否符合从左到右、从上到下的阅读习惯。
• 置信度是否达标：一般来说，置信度 0.9 以上代表识别很可靠，0.7 到 0.9 需要人眼复核，0.7 以下很可能有错误。

6.5 失败时的第一步排查

如果程序报错或者没有输出，先按这个顺序排查：

• 检查图片路径是否正确，文件名是否包含空格或中文。
• 检查图片格式是否是 macOS 支持的常见格式，如 PNG、JPEG、TIFF、HEIC。
• 检查系统版本是否在 macOS 11 及以上。
• 检查终端权限和文件访问权限。
• 把--fast参数移除，使用更准确的.accurate模式再试。

6.6 批量识别脚本

如果有多张图片需要处理，可以写一个简单的 Shell 循环：

#!/bin/bash # 文件路径：OcrTool/batch_ocr.sh for img in /path/to/images/*.png; do echo "===== 正在处理: $img =====" ./ocr.sh "$img" echo "" done

这个脚本会遍历指定目录下的所有 PNG 图片，逐个执行 OCR 并输出结果。配合tee命令，还可以把输出同时保存到文本文件：

./batch_ocr.sh | tee result.txt

7. 常见问题与排查思路

在实际使用过程中，你可能会遇到不少问题。下面整理了我在类似项目中常见的几个问题，以及对应的排查方式。

7.1 关于识别顺序的深入处理

Vision 框架返回的VNRecognizedTextObservation自带boundingBox属性，它表示文本区域在图片上的归一化坐标。坐标原点在图片左下角，y值越大表示越靠近图片顶部。

如果你希望输出顺序符合人类阅读顺序，可以按这种方式排序：

let sortedObservations = observations.sorted { a, b in let ay = a.boundingBox.origin.y let by = b.boundingBox.origin.y // 如果 y 坐标接近（同一行），则按 x 排序 if abs(ay - by) < 0.02 { return a.boundingBox.origin.x < b.boundingBox.origin.x } return ay > by }

这段代码先把同一水平线上的文本排在一起，然后按从左到右的顺序排列。加入这个逻辑后，输出会更接近视觉阅读顺序。

7.2 关于--fast和--accurate的选择

从实际体验来看，.accurate模式虽然更慢，但对混排文本、小字号文字、模糊截图的识别效果提升明显。如果是自动化脚本批量处理，不追求实时性，建议始终使用.accurate。

.fast模式更适合实时场景，比如你想写一个“鼠标悬浮就取词”的工具，或者做一个实时视频帧的 OCR 采集器。在这类场景中，识别速度比微小精度差异更重要。

8. 最佳实践与工程建议

完成一个能运行的命令行 OCR 工具只是第一步。如果要把这个能力融入真实工作流，有几点工程经验值得分享。

8.1 图片预处理的正确姿势

不做过任何处理就扔给 Vision，很多时候能工作，但效果受图片质量影响很大。推荐在识别前做一次基础预处理：

• 图片分辨率过高（比如超过 4000 像素）时，先缩放，这可以显著提升处理速度。
• 图片文字区域过小时，先裁剪放大。
• 图片有透明通道时，注意转成不透明背景，避免识别异常。

macOS 系统自带 sips 命令可以完成上述操作：

# 缩放图片到最长边 2000 像素 sips -Z 2000 input.png --out output.png # 转换格式 sips -s format jpeg input.png --out output.jpg

8.2 输出格式的标准化

从工程角度，命令行工具的输出格式非常重要。不只是打印给人看，还要方便后续脚本解析。推荐增加一个--json参数，输出结构化结果：

if CommandLine.arguments.contains("--json") { let results = observations.compactMap { obs -> [String: Any]? in guard let candidate = obs.topCandidates(1).first else { return nil } let box = obs.boundingBox return [ "text": candidate.string, "confidence": candidate.confidence, "x": box.origin.x, "y": box.origin.y, "width": box.size.width, "height": box.size.height ] } let jsonData = try? JSONSerialization.data(withJSONObject: results, options: [.prettyPrinted, .sortedKeys]) if let jsonData = jsonData, let jsonString = String(data: jsonData, encoding: .utf8) { print(jsonString) } }

有了 JSON 输出，你就可以把 OCR 能力嵌入到自己的 Python、Shell、Node.js 脚本中，让下游程序直接消费识别结果。

8.3 与系统“快捷指令”的整合

如果你的目标是减少手工操作，还可以把编译好的 OCR 工具接入 macOS 的“快捷指令”（Shortcuts），实现“选择图片 → 运行 Shell 脚本 → 把结果写入剪贴板”的自动化流程。

具体做法是在快捷指令里添加“运行 Shell 脚本”操作，脚本内容如下：

#!/bin/zsh # 这里填写 OcrTool 的编译结果路径 OCR_BIN="$HOME/Projects/OcrTool/.build/release/OcrTool" INPUT_PATH="$1" "$OCR_BIN" "$INPUT_PATH" | grep -v "^-" | tail -n +3

然后搭配系统输入项，这样每次只要右键点击图片，选择快捷指令，OCR 结果就能直接进入剪贴板。

8.4 性能优化与内存管理

如果你要批量处理大量图片，注意控制内存占用。Vision 的 OCR 在识别大分辨率图片时会消耗较多内存，推荐在循环中加上自动释放池：

for imgPath in imagePaths { autoreleasepool { // 处理单张图片 guard let image = NSImage(contentsOfFile: imgPath) else { return } guard let cgImage = image.cgImage(forProposedRect: nil, context: nil, hints: nil) else { return } // ... 执行 OCR ... } }

autoreleasepool确保每张图片处理完后，临时对象立即释放，避免多张图片叠加导致内存暴涨。

8.5 安全与隐私边界

使用原生 OCR 的最大优势就在隐私和安全性上。但要注意，即便识别过程在本地完成，你生成的识别文本文件如果存放在不安全的目录，仍然会有泄露风险。建议在生产流程中遵循最小权限原则：只在需要识别时读取图片、只在需要保存时写入结果文件、定期清理临时文件。如果是处理涉密文档，建议在隔离环境中运行工具。

8.6 错误处理与日志记录

命令行工具最容易忽略的是错误处理。真实使用中，图片路径可能写错、文件可能损坏、系统权限可能受限，所有异常情况都应该输出清晰的错误信息。推荐的错误处理思路是：先给用户一个便于理解的中文提示，再附带 Linux/Unix 的标准错误码。Shell 脚本可以根据退出码决定是继续还是终止：

if ! ./ocr.sh "$img"; then echo "处理失败，跳过: $img" continue fi

9. 总结与后续学习方向

这篇文章从“Mac 上图片文字无法复制”的真实痛点出发，完整还原了如何利用 macOS 原生 Vision 框架实现 OCR 文字识别工具。我们深入拆解了VNRecognizeTextRequest的核心概念，从环境准备、流程设计到代码实现，再到结果验证和常见问题排查，形成了一条完整的技术链路。

这个工具的最终形态可能很简单——一个命令行程序，输入图片路径，输出文字。但它的意义并不在于“能用”，而在于它把隐藏在系统深处的原生 OCR 能力变成了一个可以自由组合的积木。你可以把它接入文档管理流程、自动化测试、知识库构建，甚至做成一个实时取词的效率工具。原生方案带来的隐私优势和离线可用性，是任何在线 OCR 服务都无法替代的。

学完本文后，你可以从这几个方向继续深入：

• 尝试从boundingBox重建文本在图片中的位置关系，做成一个“图片文字排版还原工具”。
• 把工具接入 Python 生态，通过subprocess调用命令行，让数据可以直接进入 pandas 或数据库。
• 研究 Vision 框架中其他能力，比如文字追踪（VNRecognizeTextRequest的追踪变体）、人脸检测、图片相似度匹配，看是否能组合出更有价值的功能。
• 如果你的需求是处理 PDF 扫描件，可以研究如何先用 PDFKit 渲染页面为图片，再调用 OCR 识别，完整流程并不复杂。

最后提醒一句：任何 OCR 工具都不可能达到 100% 正确率。在高价值场景中，比如合同、证件、财务单据处理，一定要设计人工复核环节。把原生 OCR 当作“大幅提高效率的助手”，而不是“完全取代人眼的工具”，这才是最理性的工程判断。

建议把本文收藏备用，在遇到“图片文字提取”相关需求时，直接按步骤操作，几分钟就能搭好一个属于自己的本地 OCR 服务。