别再把所有 PDF 都交给 OCR:这个开源工具先判断,再转成 Markdown

阅读预计耗时 约 4 分钟 · 按最终可见正文每分钟约 400 个中文字估算

完整阅读版

很多人处理 PDF 的第一反应是：先 OCR，再说。问题是，PDF 里本来就有文字时，OCR 反而可能把清楚的文本变成错字、乱序和多余空格。

PDF Inspector 的思路很朴素：先看清楚手里的 PDF 是什么，再决定下一步。

PDF Inspector 是 firecrawl/pdf-inspector，核心用 Rust 编写，提供 Python、Node.js、WebAssembly、Rust 和 CLI 入口。它会把文档分成 TextBased、Scanned、ImageBased 和 Mixed 四类，并返回哪些页面需要 OCR。

这意味着一份 100 页的混合 PDF，不必 100 页全部送进 OCR。文字页走原生提取，扫描页再交给外部 OCR，流程从“全量重做”变成“按页分流”。对批量知识库尤其有用：先低成本分类，再把贵的步骤留给少数页面。

先分类型，再把真正需要识别的页面送去 OCR。

只抽出字符不算完成。项目的提取器还处理位置感知文本、多栏阅读顺序、表格、列表、标题、代码块、链接和字体编码。换句话说，它试图回答的不是“页面上有哪些字”，而是“读者应该按什么顺序读”。

README 给出的 200 份 PDF 基准里，整体分数为 0.875，阅读顺序为 0.915，表格为 0.814，标题为 0.788；200 份文档耗时 0.470s。这是项目方在 2026 年 7 月 31 日、Apple M4 Pro、关闭 OCR 条件下的自报数据，适合用来理解方向，不能当成你的电脑和你的 PDF 的承诺。

抽出字符只是第一步，阅读顺序和结构同样重要。

核心是本地纯 Rust、无模型、无外部服务，主要依赖 lopdf。它可以把“文档分类—文本提取—Markdown 转换”放进自己的管线里，减少先上传再判断的动作。对隐私敏感的合同、论文和内部手册，这是一个实际的工程收益。

但本地不等于全自动。扫描版、图片版仍需要外接 OCR；复杂表格、损坏文件、特殊字体和不常见版式，仍然要抽样打开原 PDF 对照。最稳的做法是保留原文件、分类结果和转换结果，给异常页留下回退入口。

本地分流负责减少浪费，外部 OCR 和人工复核负责兜底。

适合： 正在搭建文档搜索、RAG、网页抓取或批量归档流程的人；手里同时有文字 PDF、扫描 PDF 和混合 PDF，希望降低 OCR 量的人；重视本地处理和可复核结果的团队。

不适合： 只想靠一个库直接识别扫描件的人；PDF 版式高度复杂、却没有人工抽查预算的生产流程；把 benchmark 数字直接当成上线 SLA 的团队。

项目地址：https://github.com/firecrawl/pdf-inspector

我是 AI趋势老王，持续分享 AI、Agent 和效率工具的实测观察。

END