前言¶

处理一批扫描件时，常见做法是「整份 PDF 一律送 OCR」。后果是：那些本来带文本层的页面被反复重识别，耗时长、成本高；或者反过来，文本层残缺的页面被当作文本页直接抽取，字段丢掉。

PDF Inspector 就是为这个问题设计的：先读 PDF 的内部结构，逐页判断这一页是文本型、还是需要 OCR。它由社区开发者 user_1a99cb00 发布在 SkillHub，分类 office-efficiency，版本 1.0.0。

它是什么¶

一句话定位：一个用 Rust 写的 PDF 路由工具（router），输入一份 PDF，输出逐页的处置结论——文本型直接抽取，图像型才走 OCR。

它不负责 OCR 本身，也不负责最终的内容提取，只做「该走哪条路」这一步。

发布方：user_1a99cb00（community 来源，非官方团队维护）。页面标注的热度为 1.9M views、8.1K stars，评分 100000，下载 2027。

核心功能¶

1、读取 PDF 内部结构，而非只看文件后缀或文件大小。

2、按页（per-page）给出判断，不是整份 PDF 一个结论。一份混合文档里，前半是文本、后半是扫描页的情况很常见。

3、判定结果分两类：文本型（可直接抽取文本）或需要 OCR（内容在图像里，必须走识别）。

4、实现语言为 Rust，解析逻辑在本地完成，页面标注不需要 API Key（requires_api_key=false）。

5、坐标 @user_1a99cb00/pdf-inspector，分类 office-efficiency。

安装与启用¶

已抓取资料中没有给出安装命令、依赖清单或配置文件字段，这里不做推测。官方地址如下：

https://api.skillhub.cn/user_1a99cb00/pdf-inspector

SkillHub 页面：

https://www.skillhub.cn/skills/user_1a99cb00/pdf-inspector

这类 Skill 基于通用 SKILL.md 格式，装进 Agent 的 Skill 目录后即可被调用；具体目录位置和启用方式请以 SkillHub 页面的说明为准（本次抓取未拿到该页正文）。

需要说明的是，资料里没有区分 Cursor / Codex CLI / Claude Code 的安装差异，因此这里不给差异说明，避免写出未经核实的命令。

典型用法¶

资料中只给出了定位和能力描述，没有附带可复现的命令行示例或调用参数。下面这段是与其定位一致的调用意图，参数名以官方说明为准：

输入：一份混合型 PDF（部分页带文本层，部分页是扫描图像）

过程：逐页读取内部结构

输出：每页的判定结论 —— 文本型 / 需要 OCR

依据判定分流：文本型页直接抽取文本，需要 OCR 的页送 OCR 流程

需要留意的是，这个 Skill 只产出路由结论，后面的文本抽取和 OCR 识别要由调用方自己接。

适用场景与注意¶

适合的场景：

1、扫描件和电子稿混在一起的文档库，想按页分流处理。
2、想省 OCR 开销，把文本层完好的页面排除在识别流程之外。
3、批量处理前先摸清楚文档构成，再决定识别策略。

限制和坑：

1、版本 1.0.0，社区发布，功能边界和后续维护情况未知。
2、页面标注的分类是 office-efficiency，属于效率工具类，不是 OCR 引擎本身。
3、评分 100000、下载 2027 是页面当前显示的数据，会随时间变化。
4、OCR 能力不在 Skill 内，识别结果的准确率取决于你接的 OCR 服务。

小结¶

PDF Inspector 的价值在于把「该不该 OCR」的判断提前到处理流程之前，逐页给出结论，避免整份文档一刀切。如果你手上的文档来源混杂，它可以先把文本页筛出来。

官方地址：https://api.skillhub.cn/user_1a99cb00/pdf-inspector