pdf-inspector 实测：14 页论文本机 51.342 毫秒变成 Markdown，0 页 OCR

已完成本地实测 pdf-inspector 1.17.0：样例 0.901/5.671 ms，14 页论文 8.296/51.342 ms，0 页 OCR。未执行 OCR。txt→Not a PDF。音频已由用户提供，视频待 15 项媒体通过后制作。外部平台未发布。

查看 GitHub 原项目 ↗进入作者的家

实验田正式路线

这项项目没有绕过实验田。

01种子区 · 已发现Trending 线索、GitHub 仓库和项目库档案已经绑定。

02种子区 · 已核验固定提交，核对 README、许可、版本、外部服务和数据边界。

03播种区 · 已实测2 次工作记录保留环境、命令、退出码、失败和修复。

04收成区 · 已产出3 项成果与同一实验绑定，阶段状态仍为进行中。

05收获记 · 已公开公开实验页、竞技场摘要与多平台发布证据回到同一条记录。

01 · 问题

我想解决什么

团队把每一份 PDF 都送去云端 OCR，页数一多，流水线就停在等待上。Firecrawl 开源的 pdf-inspector 先判断文件是不是本来就能读的文本，再在本机写成 Markdown。Jian AI Lab 今天在零 API Key、零费用的 Mac 上跑通：1 页样例 classify 0.901 ms、process 5.671 ms；14 页论文 classify 8.296 ms、process 51.342 ms；需要 OCR 的页数为 0。未执行扫描件 OCR。故意用 txt 做了非 PDF 边界测试，得到 ValueError: Not a PDF: file appears to be plain text。

02 · 过程

我是怎样做的

uv venv + pdf-inspector==1.17.0。classify_pdf / process_pdf。无 API Key。

03 · 结果

实际发生了什么

文本型 PDF 本机 Markdown。未执行 OCR。

04 · 避坑

哪些地方值得注意

扫描件 OCR 未跑。

05 · 最终评价

这次实验的结论

适合文本型 PDF 先分流再抽取。

实验日志时间线

这项实验是怎样一步步做出来的。

01
安装 pdf-inspector 1.17.0，对本机文本 PDF 和公开论文做分类与 Markdown 抽取，并用 txt 做非 PDF 边界测试2026年9月2日
第1次：uv pip install 得到 pdf-inspector==1.17.0，导入 classify_pdf / process_pdf 成功。第2次：自制 1 页文本 PDF（865 bytes）。classify 0.901 ms，pdf_type=text_based，confidence=1.0，pages_needing_ocr=[]。process 5.671 ms，Markdown 181 字符，抽出 Amount: 0 CNY。第3次：公开论文 PDF（1,016,315 bytes）。classify 8.296 ms，text_based，confidence=1.0，0 页 OCR。process 51.342 ms，Markdown 83,804 字符，page_count=14，tables=[2,3,12]。未执行 OCR。第4次：not-a-pdf.txt 三次调用均抛出 ValueError: Not a PDF: file appears to be plain text。换回真实 PDF 后成功。局限：扫描件 OCR 未跑；file 命令显示论文 6 pages，库返回 14，对外以库为准。
02
挂载 15 项媒体证据、口播原音频和成果文件到收成区2026年9月2日
本日收成区补档。图片 15 张互不重复，均来自本次真实本机实验或作者公开 README/仓库保存页。未执行 OCR。未制作视频。 01 项目首页/原作者介绍：保存的 GitHub 仓库页 firecrawl/pdf-inspector 02 核心功能：classify_pdf / process_pdf，默认不走 OCR 03 安装：uv pip install → pdf-inspector==1.17.0 04 首次运行：样例 PDF classify 0.901 ms text_based 05 关键操作：论文 process_pdf 51.342 ms 06 最终结果：1.17.0，0 页 OCR，无 API Key 07 输入输出对比：865 字节 PDF → 181 字符 Markdown Amount: 0 CNY 08 速度对比：0.901 / 5.671 / 8.296 / 51.342 毫秒 09 目录与核心文件：run_experiment.py 与 evidence/ 10 README 关键段：Built by Firecrawl，~54% 是作者陈述非本日统计 11 报错：not-a-pdf.txt → ValueError: Not a PDF: file appears to be plain text 12 换回真实 PDF 后成功，exit 0 13 使用场景：文本发票型 PDF 先分类再抽 Markdown 14 作者公开资料：README Firecrawl；创始人帖只引用未互动 15 结论：适合有文本型 PDF、想跳过默认 OCR 的人音频：用户提供口播原文件 pdf-inspector.aifc，原样归档，未改写未 TTS 未剪辑。约 205.248 秒。视频暂不制作。成果文件：实验报告、网站草稿、口播稿、YouTube 资料包、平台稿、每日 Review、交付清单。
experiment-report.mdMD · 2 KB · 打开或下载内部实验报告原文website-draft.mdMD · 4 KB · 打开或下载网站实验报告草稿narration.mdMD · 2 KB · 打开或下载口播稿正式版youtube-pack.mdMD · 4 KB · 打开或下载YouTube资料包，已关联口播原音频 pdf-inspector.aifcplatform-drafts.mdMD · 4 KB · 打开或下载各平台稿件草稿，未对外发布daily-review.mdMD · 4 KB · 打开或下载2026-09-02 每日Reviewdelivery-checklist.mdMD · 3 KB · 打开或下载15:00交付清单experiment-results.jsonJSON · 92 KB · 打开或下载本机实验原始 JSON

收成区 · 与本实验绑定

报告、长文、视频材料和下载包都从上面的日志长出来。

“已产出”表示内容和文件已经形成，不代表核心 3D 界面的端到端验收已经通过。本实验仍保留为“进行中”。

长文章 · 已准备

pdf-inspector 实测：14 页论文本机 51.342 毫秒变成 Markdown，0 页 OCR · 长文章

# 发票还在排队等 OCR 时，Firecrawl 已经让本机 51 毫秒读完 14 页论文 Jian AI Lab 网站实验报告草稿｜2026-09-02 项目：[firecrawl/pdf-inspector](https://github.com/firecrawl/pdf-inspector) 状态：已实测并准备公开制度 SHA-256：`cd5841a52c23b9af1dc12a51fb4b2986e85474150b412627325816a84ba51879` 团队把每一份 PDF 都送去云端 OCR，页数一多，流水线就停在等待和账单上。Firecrawl 开源的 pdf-inspector 先判断文件是不是本来就能读的文本，再在本机写成 Markdown。Jian AI Lab 今天在零 API Key、零费用的 Mac 上跑通了这件事：14 页论文 51.342 毫秒抽完，0 页进入 OCR。 ## 作者把路已经铺好 Firecrawl 在 README 里把产品说得很清楚：这是给文本型 PDF 用的本地分类和抽取引擎，默认不走 OCR，目标是「本地处理文本 PDF，跳过那些根本不需要 OCR 的文件」。创始人 Nicolas Camara（[@nickscamara_](https://x.com/nickscamara_/status/2083295265793212827)）的宣传方向也一致：让 agent 处理 PDF 时不用干等 OCR，先分类，再本机出干净 Markdown。我们按这条方向做今天的实验，不改口，不另起一套评价。 ## 今天在这台 Mac 上实际发生的事安装只有一步：`uv pip install pdf-inspector`，装上的就是 PyPI 的 `1.17.0`。第一份文件是我们当场生成的一页文本 PDF，模拟发票场景。`classify_pdf` 用 0.901 毫秒给出 `text_based`，置信度 1.0，需要 OCR 的页列表是空的。`process_pdf` 用 5.671 毫秒写出 181 字符 Markdown，标题、日期和 `Amount: 0 CNY` 都在。第二份文件是公开的 TraceMonkey 论文 PDF（1,016,315 字节）。分类 8.296 毫秒，仍然是 `text_based`、置信度 1.0、0 页 OCR。完整抽取 51.342 毫秒，得到 83,804 字符 Markdown，开头就是论文标题 *Trace-based Just-in-Time Type Specialization for Dynamic Languages*，Abstract 在，表格页被标成 2、3、12。这就是作者承诺的使用方式：文本型文件在本机结束，不必为了「保险」把整份文档送去 OCR。 ## 它替谁省下什么适合每天要处理报告、论文、发票、合同的人，尤其是已经在写 agent 或文档流水线的开发者。以前这条链路常常是：上传 → 等 OCR → 再清洗。pdf-inspector 把第一刀放在本地：先问「这页需不需要 OCR」，文本页直接变成可检索 Markdown。替代价值很具体。云端 OCR 按页计费；今天这两份文本 PDF 的 OCR 页数都是 0。作者 README 还写过他们在 200 份语料上的对比数字——那是作者基准，不是我们今天的测量。我们今天能量的是：1 页 5.671 毫秒，14 页 51.342 毫秒，安装成本是一个 venv 里的一个包。 ## 冲突出现时，项目自己把边界说清我们故意丢了一个 `not-a-pdf.txt` 进去。三次调用都在 1 毫秒内抛出 `ValueError: Not a PDF: file appears to be plain text`。这不是项目「不行」，这是它把非 PDF 挡在门外，让调用方可以立刻改走别的解析器。换回真实 PDF 后，分类和抽取都回到成功路径。适用条件也写在这里，方便后来者：今天两份成功样本都是文本型 PDF，没有扫描件对照；本机 `file` 命令把论文显示成 6 页，库返回 14 页，我们对外采用库的 `page_count=14`，并保留这条差异；可选 OCR 模式今天没有跑，所以不讨论扫描件效果。 ## 谁现在可以开始如果你已经有 Python 3.11 和一批文本型 PDF，现在就可以： ```bash uv venv --python 3.11 .venv uv pip install --python .venv/bin/python pdf-inspector ``` ```python import pdf_inspector print(pdf_inspector.classify_pdf("document.pdf")) print(pdf_inspector.process_pdf("document.pdf").markdown[:500]) ``` 值得试，是因为作者要解决的等待被我们在这台机器上复现成了可核对的毫秒数：分类不到 10 毫秒，14 页论文不到 52 毫秒，OCR 页数是 0。仓库在 [firecrawl/pdf-inspector](https://github.com/firecrawl/pdf-inspector)，文档在 [firecrawl.github.io/pdf-inspector](https://firecrawl.github.io/pdf-inspector/)。 ## 实验边界（必须标明） - 已实测：pdf-inspector 1.17.0，零 API Key。样例 classify 0.901 ms / process 5.671 ms；论文 classify 8.296 ms / process 51.342 ms；OCR 页数 0。 - 未执行 OCR：没有跑 process_pdf_with_ocr，没有扫描件对照。 - 故意 txt 错误测试：not-a-pdf.txt → ValueError: Not a PDF: file appears to be plain text。 - 真实局限：file 命令显示论文 6 页，库返回 14 页，对外以库为准。下一步是扫描件 OCR，不是否定本机文本路径。

视频制作包 · 已准备

pdf-inspector 实测：14 页论文本机 51.342 毫秒变成 Markdown，0 页 OCR · 视频制作包

# YouTube 资料包｜pdf-inspector｜2026-09-02 预制草稿未生成付费配音、未剪辑成片、未上传。用户负责 YouTube 发布。 ## 标题发票还在等 OCR，这篇 14 页论文本机 51 毫秒就变成了 Markdown 备选：Firecrawl 把 PDF 分流留在本地：0 页 OCR，83,804 字符进编辑器 ## 封面提示词（供用户自己出图，本日未调用付费生图）暗色工作台，左侧是一份打开的论文 PDF，右侧是滚动的 Markdown，中间大字「51.342 ms · 0 OCR pages」，左下小字「pdf-inspector by Firecrawl · Jian AI Lab」，不要出现失败、翻车、惊恐表情。 ## 口播稿（约 2 分 55 秒）发票和论文已经躺在硬盘里，团队却还在为每一页 PDF 排队等云端 OCR。Firecrawl 把 pdf-inspector 开源出来，就是为了先问一句：这份文件到底需不需要 OCR。今天我们在这台 Mac 上，用零 API Key、零费用跑通了同一条路。14 页论文，51.342 毫秒抽成 Markdown，需要 OCR 的页数是 0。 GitHub 今天还能在 Trending 里看到它。作者 README 写得很干脆：文本型 PDF 在本地处理，默认不走 OCR。创始人 Nicolas Camara 的原帖方向也一样——让 agent 处理 PDF 时不用干等 OCR，先分类，再本机出干净 Markdown。安装只有一个包，版本 1.17.0。我们先丢进去一页自己生成的文本 PDF，模拟发票。classify_pdf 用 0.901 毫秒给出 text_based，置信度 1.0。process_pdf 再用 5.671 毫秒写出标题、日期和 Amount: 0 CNY。金额还是零，因为今天这条链路根本没有去买 OCR。再换一份公开论文，一百多万字节。分类 8.296 毫秒，还是 text_based，OCR 页列表仍是空的。完整抽取 51.342 毫秒，8 万多字符的 Markdown 开头就是论文标题，Abstract 在，表格页被标出来。作者答应的使用场景，在这台机器上变成了可以暂停、可以核对的画面。中间我们故意扔了一个 txt。项目没有含糊，它直接说：Not a PDF，file appears to be plain text。换回真 PDF，成功路径立刻回来。这是给流水线的边界，不是给作者的差评。所以谁现在可以开始？手里已经有文本型 PDF、想先分流再抽取的人。一条 uv pip install，两行 classify 和 process。扫描件和可选 OCR 今天没有跑，那是下一步，不是今天的否定。值得试，是因为等待被量化成了毫秒，OCR 页数被量化成了 0。仓库链接放简介，Jian AI Lab 只记录今天这台机器上真实发生的事。 ## 逐镜头分镜 | 镜号 | 时间 | 画面 | 口播摘要 | |---|---|---|---| | R1–R3 | 0:00–0:12 | 三雷达快照 | 痛点 + 结果 51.342 ms / 0 OCR | | 1 | 0:12–0:22 | GitHub 仓库页 | Firecrawl 开源 | | 2 | 0:22–0:32 | README 功能段 | 作者方向：分类 + Markdown | | 3 | 0:32–0:42 | 安装终端 | 1.17.0 | | 4–5 | 0:42–0:58 | 发票 PDF → md | 0.901 ms / 5.671 ms / 0 CNY | | 6–8 | 0:58–1:38 | 论文 PDF → md 对照与耗时 | 14 页 51.342 ms | | 9–10 | 1:38–1:58 | 包目录 + README 原句 | 不把作者基准说成今天测的 | | 11–12 | 1:58–2:20 | txt 报错 → 真 PDF 成功 | 适用条件 | | 13–15 | 2:20–2:55 | 场景 + 创始人帖 + 行动 | pip install 现在就开始 | ## 真实素材清单 - `03-experiment/evidence/input/jian-ai-lab-sample.pdf` - `03-experiment/evidence/input/tracemonkey.pdf` - `03-experiment/evidence/output/jian-ai-lab-sample.md` - `03-experiment/evidence/output/tracemonkey.md` - `03-experiment/evidence/output/experiment-results.json` - `03-experiment/sow/播种区记录.md` - `01-radar/github-trending-today.html` - `02-verification/pdf-inspector-README.md` - 官方链接：仓库、文档、创始人帖 - 不存在：MP4 成片、浏览器 PNG、TTS 音频

实验报告 · 已准备