夜雨聆风我对 PDF 处理链路最烦的一件事，就是不管三七二十一先跑 OCR。
一份本来能直接复制文字的研究报告，上传、转图片、排队识别，折腾半天，最后还把原本正常的表格和段落顺序弄乱。延迟上去了，OCR 账单也没少付。
Firecrawl 开源的 pdf-inspector，干的就是这件脏活：PDF 进来后，先快速判断它到底是文字版、扫描版、纯图片，还是两种页面混在一起。文字版直接本地提取，确实需要识别的页面再交给 OCR。
不是整份文档一刀切。
它通过检查 PDF 内容流里的文字和图片操作符完成分类，通常几十毫秒能给出结果，还会返回具体哪些页面需要 OCR。Firecrawl 给出的数据是，大约 54% 的 PDF 本来就不需要 OCR；文字版文档从分类到 Markdown 提取，整条链路可以压在 200 毫秒以内。
这就有点现实了。
老鬼以前做文档问答 Demo，最怕的不是模型读不懂，而是前面解析链路不稳定：双栏论文顺序串了、表格拆烂了、标题全变正文，最后 RAG 检索出来一坨碎片，还得怀疑是不是模型的问题。
pdf-inspector 不只吐纯文本。它会根据坐标恢复多栏阅读顺序，通过字体大小推断 H1 到 H4 标题，也会尝试识别列表、代码块和表格。浏览器端还能通过 WebAssembly 本地跑，不需要为了传一份 PDF 再搭个解析后端。Python、Node.js 和 Rust 也都有接口。
命令行直接：
pdf2md document.pdfdetect-pdf document.pdf --json
不过先别急着把现有 OCR 服务全删了。
仓库目前仍有人反馈中文 PDF 崩溃、分类错误、Markdown 为空，以及复杂表格被拆开的情况。它更适合当“前置分流器”，而不是所有 PDF 的万能解析器。日志、置信度和失败回退最好都留着，解析为空就自动切 OCR，不然线上迟早有人背锅。
做知识库、论文解析、合同抽取或者批量文档入库的，可以拿它先挡在 OCR 前面。能直接提的就别费劲巴拉跑识别，混合 PDF 再按页处理。
Github地址：Firecrawl / pdf-inspector。