这帖有个一以贯之的滑动：把"文档"悄悄换成"页"。54% 的原始出处是 README 第 10 行，原话是"~54% of PDFs that don't need them"——54% 的 PDF 不需要 OCR，说的是 Firecrawl 自家的工作负载，方法学从没公布过。帖子把它写成"54% 的 PDF 页面是文本型"，还配了"200 页里 108 页"的开头。单位错了。这个 108 是从错位里长出来的数字。
36 倍那张表错在同一处。数字真实，但 README 表头写的是"Speed (200 docs)"——200 份文档，不是一份 200 页的 PDF。更要命的是对照组：pymupdf4llm 根本不做 OCR，它是 PyMuPDF 的原生转 Markdown 库，README 自己注明"OCR was disabled"。所以那 36 倍是两个原生解析器比谁快，从头到尾没演示"跳过 OCR 省了多少"。Firecrawl 给自家完整管道报的加速是 3.5–5.7 倍。
10-50ms 也安错了单位：那是判断整个 PDF 的耗时，README 写着"This detects 300+ page PDFs in milliseconds"。按页算的话，帖子把工具说慢了两个量级。"只依赖 lopdf"是 v0.2.0 的旧话，原话还是"PDF 解析上单依赖 lopdf"；现在的 Cargo.toml 里非可选依赖十来个。v1.x 连提取和 Markdown 转换都自己做了，"只做分类"这条局限也过时了。
真的部分也摆出来，免得冤枉人：18,924 颗 star，代码 96% 是 Rust，Python/Node/WASM 三路绑定都在，三个分类信号（字体编码、文本操作符、图像覆盖率）两篇博客原文可查。连螳螂虾都是真的——Science 2025，DOI 10.1126/science.adq7100，Bouligand 排列的声子屏蔽。但"5 亿年前进化出来"论文里没有，常见口径是 4 亿年上下，这个数我不知道从哪来的。
Firecrawl 自家的 AnyDoc 博客里有句话，比整篇帖子都清楚："多数 PDF 管道下了同一个错注：把每一页都当成可能被扫描过，于是全部送进 OCR。又慢又贵，还常常不如 PDF 里本来躺着的原生文本准。"
先看一眼再动手，这个道理成立。看的时候，带上单位。