目 录
用最简单，不绕弯的方式说清什么是 OCR
推荐一个“国服最强”的 OCR 工具
个人和团队，在效果、安全与便捷上的权衡
在上一篇文章时隔6年的续集：律师如何利用 AI 编程避免重复劳作里，我们聊了律师如何用 AI 协作写脚本，把重复劳作交给机器。文中提到，五大场景批量信息提取、批量文本处理、批量文件操作、批量数据分析和执行批量动作，文末还提到，发现提效机会的三个标准是高频、重复、有规则。
今天要介绍的，是最大公约数中的“万能牌”、扫描件的“克星”——OCR 工具。
OCR 的全称是 Optical Character Recognition（光学字符识别），即对拍摄 / 扫描的文字图像做降噪、倾斜矫正处理，逐个分割字符后完成字形匹配识别，最终输出可编辑文本。
OCR 的运作过程
律师工作中，绝大多数信息、材料会以扫描件的形式流转于团队、客户、法院等案件参与方之间。我们提到的五大场景，基础动作中几乎都有“上传扫描件”。最常见的，就是手里数百份对方的证据材料，全是复印件扫描所得，即是打开电子件，也是文字选不中、搜不了、复制不了。它们对你“可见但不可用”。
图源 PaddleOCR
从左至右呈现 OCR 工具对扫描件的矫正和最终文字提取情况
所以，需要一双“眼睛”来读取扫描件并转化成可被使用的数据。OCR 就是用来打破这层“图片封印”的。它把图片里的文字还原成真正的文本，让脚本能够继续处理——搜索、匹配、提取、统计、生成报告。
市面上 OCR 工具很多，百度智能云、腾讯云、阿里云的 OCR 接口都有成熟的产品线；微软 Azure Computer Vision、Google Cloud Vision 也提供了类似能力。最出名的是 Google 维护的 Tesseract OCR（诞生于 1985 年惠普实验室，刚度过40岁生日）。如果只想处理纯英文文本，Tesseract 是教科书级别的选择，但在中文识别场景，尤其是中文法律文书里常见的印刷体、繁简体混排、表格嵌套等场景，更推荐百度飞桨的 PaddleOCR 。几乎是唯一同时满足“中文识别好”和“完全离线可用”的选项。
图源网络
这里开始是下载方式和安装使用指引
（1）在哪下载
PaddleOCR 的代码和文档都托管在 GitHub 上，仓库名是 PaddlePaddle/PaddleOCR（打开GitHub 直接搜，或者，在任意搜索引擎都可找打，这里保账号安全就不上链接了）。如果你访问 GitHub 不太方便，也可以去 Gitee 找镜像。
（2）有哪些工具
下载后，可以读取项目包里的 README.md ，也就是这个工具的说明书。其中提到了三档 P addleOCR 的工具，包括 PP-OCR、PaddleOCR-VL、PP-StructureV3，分别代表不同体量的工具，针对不同需求场景（比如，文件内是否为纯文字、是否有表格、是否多语言等），针对性地使用挑选模型进行转化。比如，文字检测、文字识别、版面分析、表格解析、公式理解、多语言语义能力，每一个需求，其实都有对应的模型或集聚在一个模型上来解决。
具体安装过程，就是在终端里以命令行方式完成的多个步骤，各位可进一步阅读官方提供的材料来开展， 也可以交给 Kimi Work、WorkBuddy、Codex 等桌面端 Agent 来一步解决。
（3）如何与 AI 结合
VS code + Kimi Code 示例
这里要提到一个 AI 结合 OCR 的关键步骤，可帮助你在使用时提高识别后信息的质量及产出结果的速度，就是让 AI 对待提取素材进行抽样预分析，判断本次项目要用到的技术方案和路径。一般，直接在提示词里提到要进行抽样分析，AI 就能做到；或者，打开不同工具的 Plan 模式，也能起到类似效果。（要注意，此处用到的模型，建议是本地部署的，否则信息依然会传出）
PaddleOCR SKLL.md 节选
考虑到复用，也应该将使用好 PaddleOCR 的某次流程打包成 skill，直接把输入文件的预分析环节设置在里面，ta 也就可以自己跑起来。
（4）识别文件的信息安全
第一次运行时，PaddleOCR 会自动下载识别模型文件（大约几十到一百多兆，取决于你选用的模型版本）。这些模型文件会被缓存在你的电脑本地。下载完成后，后续运行完全不需要联网。也就是说，你完全可以在一个断网的环境里，让它持续识别你电脑上的扫描件。这完美契合了上一篇文章反复强调的原则：数据不出电脑。
上面我们介绍的，还只是 PaddleOCR 的本地版本，对高度关注隐私保护的律师个人而言足够安全，一旦真的要跑起团队、全所层面的工程级任务，还是需要用到更高能的概念工具。针对不同受众，我们可以做一个讨论和辨析：
方案 A：纯本地 PaddleOCR——推荐律师个人首选
这就是我们刚才介绍的方式。模型文件下载到本地，识别过程在本地 上完成，没有任何文件上传到外部服务器。
优点：
数据绝对安全，符合律师对客户信息的保密义务
一次配置，后续完全离线可用，只是要注意更新
没有 API 调用次数限制，没有费用
缺点：
首次安装需要配置环境（但 AI 可以帮你代劳）
对于特别复杂的手写体、艺术字体、严重污损的文档，识别率可能略逊于云端大模型
对表格结构、版面分析的能力不如一些商业化云端服务
方案 B：云端 OCR API（百度智能云、腾讯云、阿里云等）
这些云厂商提供成熟的 OCR 接口，通常有通用的文字识别、表格识别、票据识别、身份证识别等专项能力。你按照 API 文档把图片上传，云端返回识别结果。
优点：
识别效果通常更好，尤其是针对表格、发票、证件等专项场景做了优化
不需要自己配置环境，有现成接口
往往附带版面分析、表格还原等高级功能
缺点：
文件必须上传到第三方服务器，存在隐私泄露风险
对律师行业来说，客户合同、卷宗材料、身份信息等上传到任何第三方，都是职业伦理上的敏感地带
有调用费用（虽然通常不高，但量大时也是成本）
依赖网络，没有网就用不了
相信法律人的辩证思维，还是能帮助我们选择“因地制宜”，找到最务实的做法，即：
涉密材料、客户文件，一律用本地 PaddleOCR 处理
公开材料、非敏感信息（比如从公开网站下载的扫描版法规），可以用云端 API 获得更好的效果
或者在本地先用 PaddleOCR 做基础识别，如果效果不理想且材料不敏感，再考虑云端兜底
总的来说，我们的建议很简单：对律师而言，优先本地。PaddleOCR 的准确率对于绝大多数法律文书、印刷体文档已经足够好了。你不需要为了追求那最后几个百分点的精度，把客户的卷宗扫描件上传到别人的服务器。
星瀚直接将 OCR 工具接入内部工作平台供全所使用
写到这里，我其实已经能想象一些朋友的反应：为了处理扫描件，装了一个 OCR，又为了装 OCR，配了一个 Python 环境，最后发现自己不知不觉走上了“面向搜索引擎编程”的老路。
但相信在这个过程中，会有一款你心仪的 AI 助理，替你写代码、调环境、处理报错。而他顺带拆解技术逻辑的时候，又用“最简单不绕弯”的方式讲明白了“为什么先装框架再装本体”、“模型文件怎么缓存”，那些可能一辈子读不懂的技术文档像一部被重新配了字幕和解说音轨的老电影，原本晦涩的叙事突然重获新生。也还是不错的。
Always——请专业人士轻拍，希望能与爱好科技的斜杠法律人多多交流。
