夜雨聆风我对 PDF 进大模型这条链路，最烦的一件事，不是 OCR 偶尔认错字，而是很多系统压根不判断，上来就把整份文档扔进 OCR。
论文、财报、产品手册，明明自带完整文字层，也要先渲染图片，再识别一遍。费时间、费算力，还可能把原本正确的文字认错。
Firecrawl 最近开源的 pdf-inspector，干的就是这件不起眼的脏活：先检查 PDF 到底是文字版、扫描版、图片版，还是混合文档。分类通常只要 10～50 毫秒，确认有文字层后，直接从 PDF 内部提取内容，不碰 OCR，本地处理可以压到 200 毫秒以内。
啧，这个思路其实比“又做了一个 PDF 解析器”实在得多。
以前做 RAG 或文档问答，最容易偷懒的方案就是统一走 OCR。等量一上来，延迟、接口费用、限流一起冒头。pdf-inspector 会直接返回哪些页面需要 OCR，不是粗暴地给整份文件判死刑。碰到一份 100 页的报告，只有中间几页是扫描件，那就只处理那几页。
这才叫前置路由。
文字提出来以后，它还能顺手转成 Markdown，处理标题层级、多栏阅读顺序和表格。表格不是单纯靠空格硬猜，而是同时看 PDF 里的绘图矩形和文字对齐关系；遇到字体编码已经坏掉的页面，也会主动标记，让后面的流程切回 OCR。
这块先别急着吹成“PDF 全解”。复杂公式、纯图片图表、奇怪编码，照样可能要靠 OCR 或视觉模型兜底。它真正值钱的，是先把根本不需要 OCR 的部分筛出去。
接口也没折腾得太封闭。Python、Node.js 和 Rust 都能接，浏览器端还有 WebAssembly 版本，PDF 可以直接在本地页面里解析，不必先上传后端。对隐私文档、小工具和桌面端应用，这个点挺香。
老鬼看这种项目，一般先想它能不能塞进现有链路，而不是功能表够不够长。pdf-inspector 很适合放在上传接口后面：先分类，文字页直接转 Markdown，剩下的再送 OCR。
做知识库、合同解析、论文问答或者批量文档入库的，可以扫一眼。
GitHub地址：firecrawl/pdf-inspector