合同、发票、扫描 PDF，为什么我更偏向本地处理
OCR 是个很小的功能，但它经常碰到最不适合“随手上传”的文件：合同、证件、账单、客户资料和内部扫描件。
做出海业务以后，PDF 会突然变得很多。海外供应商的报价、客户合同、付款凭证、税务文件、扫描件、签字版协议，几乎每天都能遇到。然后很快又会碰到另一个问题：这份 PDF 不能搜索，我只想把里面几行字拿出来。
最省事的办法当然是搜一个“PDF OCR online”，把文件拖进去。但对普通资料和敏感资料，我会分开处理。原因很简单：为了识别几行文字，默认把整份文件交给第三方服务器，并不是唯一选择。
真正敏感的往往不是文字本身，而是整份文件
一张发票里可能有公司名称、地址、金额、银行信息；合同里可能有联系人、邮箱、价格、签字；扫描证件更不用说。你真正需要的可能只是其中一个编号，但在线 OCR 通常需要拿到整份文件才能处理。
这并不代表所有在线 OCR 都不安全。很多成熟服务有完善的安全措施。问题在于，用户往往根本没看上传后保存多久、是否用于改进服务、处理区域在哪里。对不敏感文件无所谓，对客户资料最好别默认忽略。
本地 OCR 的价值，不只是“隐私”两个字
如果 OCR 在浏览器或者本机完成，最直接的好处是少了一次上传和下载。大 PDF、网络一般、跨国线路不稳定时，这个体验差别很明显。
第二个好处是流程更容易解释。团队内部可以明确规定：某些类型的文件只允许本地处理，不需要每个人分别判断某个陌生网站靠不靠谱。
当然，本地 OCR 也有代价。浏览器性能有限，低配设备跑大文件会慢；复杂表格、歪斜扫描、多语言混排也可能需要更强的模型。它不是所有场景都比云端强，只是多了一个很有用的选择。
现在可以直接在浏览器里做 OCR
CreatorPrivacyKit 的 Local OCR 已经可以处理图片和 PDF。识别在浏览器本地运行，支持英文、简体中文、繁体中文和日文；结果可以复制、导出 TXT / Markdown，也可以生成带文字层的可搜索 PDF。
如果 PDF 本身已经有可用文字层，工具会尽量直接读取，不必把每一页重新 OCR。扫描页再走识别。它也有明确的边界：加密 PDF 不会被绕过，OCR 准确率会受扫描质量、语言和版式影响，复杂文档仍然值得人工复核。
PDF 工具也一样：能在本地拆，就没必要为了拆两页先上传
很多 PDF 操作其实并不需要服务器。合并、拆分、抽取页面、旋转、重排，这类工作完全可以在客户端完成。CreatorPrivacyKit 的 Local PDF Toolkit 就是这个思路。
这里也要讲清楚边界：本地处理不等于“所有 PDF 特性都绝对保留”。复杂表单、签名、书签、嵌入文件、加密文档，各自都有兼容性问题。真正重要的商业文件，处理后还是要检查结果。
出海团队可以把“文档分级”写进工作流
很多团队的安全制度写得很大：数据安全、最小权限、合规。真正到日常操作时，员工还是会把 PDF 随手丢进搜索结果第一名的网站。
与其写一页没人看的规定，不如直接分三类。公开文件随便处理；内部普通资料优先使用可信工具；客户、财务、证件类文件优先本地。标准越简单，越容易执行。
小模型越来越强以后，本地文档工具会更实用
OCR 只是第一步。未来本地小模型能继续接摘要、字段提取、分类、简单问答。对独立开发者和小团队来说，这意味着越来越多“把文档传到云端再调用 API”的流程，可以变成可选项，而不是唯一答案。
我们也在持续关注这一类小模型。比如 MiniCPM5-2B 这种模型，真正有意思的地方不是拿来替代所有大模型，而是做那些边界清楚、重复度高、本地跑更划算的小任务。
如果你正在给出海团队搭工具链，我会优先把“文件是否必须上传”这个问题加进选型标准。很多时候，最好的隐私功能不是再写一条隐私政策，而是根本不把文件传出去。