OCR It 开源：把不可复制文档快速转成 LLM 能读的文本

截至 2026 年 8 月 24 日，GitHub 上的开源项目 OCR It 正在解决一个看似基础、但在 AI 工作流里经常卡住的问题：当文档里的文字无法复制时，怎样快速把它变成 LLM 可以处理的文本。

OCR（Optical Character Recognition，光学字符识别）是把图片或扫描页面中的视觉文字转换为机器可读文本的技术。OCR It 的定位并不是再做一个“扫描身份证”的传统 OCR 软件，而是把 OCR 放进 LLM 使用场景：用户先从不可复制的网页、PDF、扫描件或截图中提取文字，再交给大模型做摘要、问答、翻译、结构化整理或知识库入库。

项目地址：https://github.com/thiagotigaz/ocr-it

它的价值不在于“识别几个字”，而在于补齐了 LLM 工作流里经常被忽略的输入环节：模型能力再强，也无法直接理解一个你无法复制、无法导出、无法被解析器读取的页面。

一句话判断：它不是万能 OCR，但很适合做 LLM 前置处理

OCR It 更像一把“文本铲子”，负责把视觉内容铲出来，而不是替你完成最终的信息理解。

这一区分很重要。传统 PDF 解析器适合处理有文本层的 PDF；浏览器复制适合处理普通网页；OCR 则负责处理扫描页、图片、画布渲染文字、禁用复制的阅读器以及被截成图片的资料。OCR It 的实用价值，正是在这些工具失效的交界处提供一条低门槛路径。

不过，OCR 输出不等于原文。字体、分栏、表格、脚注、数学公式和手写内容都会引入误识别。把 OCR 结果直接当作事实来源，再让 LLM 二次加工，可能会把一个字符错误放大成一个错误结论。因此，OCR It 适合作为“采集层”，还需要校验、清洗和结构化步骤。

为什么“不可复制文档”会成为 LLM 工作流的瓶颈

很多用户以为网页上能看见文字，就意味着程序也能读取文字。实际上，浏览器显示内容和页面底层是否存在可复制文本，是两回事。

常见情况包括：

• 文档本身是扫描 PDF，每一页只是图片；
• 网页使用 Canvas 或图片渲染文字，页面上没有普通 HTML 文本节点；
• 在线阅读器禁用了选择和复制操作；
• 电子书、报告或票据只提供页面截图；
• 文档有文本层，但字符编码损坏，复制出来是乱码；
• 复杂表格、双栏排版或脚注经过普通解析后顺序混乱；
• 用户只能看到某一部分页面，无法直接下载完整文件。

对人来说，打开页面、放大、阅读并不困难；对 LLM 来说，输入必须先变成文本、图像或结构化数据。只要这一步没有完成，后面的总结、问答和检索都无从谈起。

这也是 OCR It 这类小工具值得关注的原因：它不试图替代整个文档智能平台，而是先把最现实的“拿不到文本”问题处理掉。

OCR It 的核心工作方式

OCR It 的基本流程可以概括为四步：获取页面图像、识别文字、整理输出、交给 LLM。

1. 获取可识别的视觉输入

第一步不是“读取文字”，而是获得页面的视觉内容。对于无法复制的材料，通常需要通过截图、页面渲染或图像文件完成输入。

输入质量直接决定最终效果。低分辨率截图会让字母 O 和数字 0 混淆，压缩严重的图片会让中文偏旁粘连，页面缩放过小则会让小字号脚注完全丢失。

建议优先使用：

• 原始 PDF 页面渲染，而不是聊天软件二次压缩后的截图；
• 300 DPI 左右的扫描图作为常见起点；
• 保持页面纵横比，避免截图时拉伸；
• 对长页面进行分段，避免一次输入过大；
• 对表格、公式和脚注单独截取高分辨率区域。

2. 对图像执行 OCR

OCR 引擎会根据图像中的文字形状、语言特征和版面信息生成文本。简单 OCR 只输出从左到右的字符序列；更复杂的文档 OCR 还会尝试识别标题、段落、列表、表格和阅读顺序。

这里要注意，OCR 和视觉语言模型并不是完全相同的东西。OCR 引擎通常专注于文字识别，速度快、成本低、输出稳定；视觉语言模型则可以理解图片中的语义和布局，但可能出现“看懂了大意、漏掉了细节”或生成原图中不存在内容的问题。

因此，OCR It 的最佳使用方式通常不是让模型凭印象复述页面，而是先尽量得到可检查的文字，再让 LLM 处理语义。

3. 整理成适合 LLM 的文本

LLM 更喜欢清晰的段落边界和稳定的结构。直接把几百张页面的 OCR 字符串拼成一个大文本，效果往往不如先做基础清洗。

建议至少处理以下问题：

• 删除重复的页眉、页脚和水印；
• 恢复明显断裂的段落；
• 保留页码，便于回查原文；
• 将标题、列表和表格转换为 Markdown；
• 对不确定字符使用标记，例如 [疑似：供应链]；
• 保留原始 OCR 输出，不要只保存 LLM 改写后的版本；
• 为每个页面添加来源信息，例如文件名和页码。

一个适合后续 LLM 处理的文本结构可以是：

[文档：annual-report.pdf]
[页码：12]
[OCR 置信问题：表格第 3 列数字可能存在误识别]

## 原始文本
……

4. 让 LLM 负责理解，而不是替 OCR“脑补”

将 OCR 文本交给 LLM 时，提示词应明确要求模型区分“原文”和“推断”。例如，可以要求模型：

• 只根据提供的 OCR 文本回答；
• 对无法确认的数字、日期和专有名词标记不确定性；
• 引用页码或段落位置；
• 不要自动修正原文中的数字；
• 输出摘要时同时列出可能影响结论的识别错误。

这比简单输入“总结这份文档”更可靠。因为 OCR 阶段最危险的错误，不是漏掉一个形容词，而是把 3.5% 识别为 35%，把负号漏掉，或者把公司名称识别成另一个实体。

实战：如何在本地跑通 OCR It 工作流

OCR It 是开源 GitHub 项目，具体安装方式、依赖和运行入口应以仓库当前 README 为准。开源项目更新后，命令行参数可能变化，直接照搬旧教程往往比看官方文档更容易出错。

一个稳妥的上手流程如下。

第一步：获取项目并检查运行环境

git clone https://github.com/thiagotigaz/ocr-it.git
cd ocr-it

接着查看仓库中的 README、依赖文件和示例目录，确认项目采用的是哪种运行方式。常见入口可能包括 Python 脚本、Node.js 命令、容器配置或桌面应用启动文件，但不要在没有确认 README 的情况下自行假设参数。

建议先检查：

1. 项目要求的 Python、Node.js 或其他运行时版本；
2. OCR 引擎是否需要单独安装；
3. 是否需要模型文件或系统级字体；
4. 输入文件支持哪些格式；
5. 输出是纯文本、Markdown、JSON 还是其他格式；
6. 是否默认调用第三方云端服务。

第二步：准备一份小样本文档

不要一上来就处理 500 页报告。先选择 2 到 5 页样本，最好覆盖不同版式：普通正文、双栏页面、表格页面和包含脚注的页面。

样本测试能快速回答三个问题：

• 中文和英文混排是否正常；
• 页面顺序是否正确；
• 表格、数字和专有名词是否值得人工复核。

如果样本阶段已经出现严重漏字，继续扩大批量只会增加返工成本。应先提高截图分辨率、调整裁剪区域、分离复杂页面，或者更换 OCR 后端。

第三步：建立“原图—OCR—修订稿”三层目录

建议把文件按以下结构保存：

project/
├── input/       # 原始 PDF、网页截图或图片
├── ocr_raw/     # OCR 原始输出，不做覆盖
├── cleaned/     # 清洗后的 Markdown 或纯文本
├── reviewed/    # 人工复核后的版本
└── metadata/    # 页码、来源、处理时间和错误记录

这一步看起来有些繁琐，但对于研究报告、合同、财务材料和内部文档非常必要。没有原图和页码，后续无法判断是 OCR 错了、LLM 改错了，还是原文本身就存在歧义。

第四步：按页面或章节切分输入

上下文窗口变大，并不意味着应该把所有页面一次性塞给模型。长文档一次处理会带来三个问题：前后文稀释、错误定位困难、模型更容易遗漏中间内容。

更可靠的策略是：

1. 先按页面执行 OCR；
2. 按章节或主题合并文本；
3. 对每个章节生成局部摘要；
4. 最后再进行跨章节汇总；
5. 关键数字回到原图核验。

对于表格，最好将表头和数据放在同一张裁剪图中，并要求输出 Markdown 表格，同时保留原始页码。对于公式和代码，OCR 往往不如专门解析器可靠，应单独标记并人工检查。

OCR It 适合哪些场景

研究资料和论文阅读

很多论文、会议材料和扫描档案并没有高质量文本层。OCR It 可以先把页面变成可搜索文本，再让 LLM 提取研究问题、数据集、实验设置和结论。

但论文中的公式、上下标和双栏排版是高风险区域。对于实验数字，不建议只看摘要；应让模型返回页码，并抽查原图。

财报、合同和票据处理

这类文档的价值通常集中在数字、日期、金额和条款上，而这些恰好是 OCR 最不能出错的部分。OCR It 可以帮助完成初步采集，但不适合直接作为财务入账或合同审核的唯一依据。

建议采用“双重校验”：先 OCR，再让视觉模型或人工对高风险字段进行二次比对。金额、税率、币种、合同期限和违约责任等字段，都应该进入人工确认清单。

网页截图和在线阅读器

当网页文字以图片或 Canvas 形式呈现时，OCR 是比复制脚本更通用的办法。对于需要整理的公开资料，可以按页面截取并添加 URL、标题和时间戳。

这里要特别注意版权、网站使用条款和访问权限。OCR 技术可以识别屏幕上的文字，但不代表用户获得了重新分发、批量抓取或绕过访问控制的权利。对于受限内容，应遵守法律法规和平台规则，避免将工具用于规避付费墙、权限控制或版权保护。

本地知识库构建

如果企业把扫描合同、设备手册或历史档案导入 RAG（Retrieval-Augmented Generation，检索增强生成）系统，OCR 是入库前的基础步骤。

一个简单的知识库流水线通常是：

原始文档
  ↓
页面渲染或截图
  ↓
OCR It 提取文字
  ↓
清洗、去重、保留页码
  ↓
按语义切分
  ↓
向量化与关键词索引
  ↓
检索增强问答

其中最容易被忽略的是元数据。文档名称、版本、页码、部门、发布日期和访问权限，都应该与文本一起保存。否则，检索系统即使找到了正确答案，用户也无法回到原文确认。

和传统 PDF 解析、视觉模型相比，它处在什么位置

| 方案 | 主要输入 | 优点 | 短板 | 更适合的场景 | |---|---|---|---|---| | 传统 PDF 文本解析 | 有文本层的 PDF | 速度快、成本低、保留字符准确 | 处理不了纯扫描页和图片文字 | 普通电子 PDF、报告导出 | | OCR It 类工作流 | 截图、扫描页、不可复制页面 | 能处理视觉文字，容易接入 LLM | 分辨率、排版和数字识别会影响准确率 | 不可复制文档、扫描档案 | | 视觉语言模型 | 图片或页面截图 | 能理解布局、图表和语义 | 可能漏字、改写或生成不存在的信息 | 图片问答、复杂页面理解 | | 文档智能平台 | 批量文件和业务字段 | 表格、版面、字段抽取能力较完整 | 成本、部署复杂度和数据合规压力较高 | 企业级批处理、流程自动化 |

我的判断是：OCR It 的竞争力不在“识别准确率一定最高”，而在于它把不可复制内容快速接入个人 LLM 工作流。对于每天只处理几十页资料的开发者和深度用户，它可能比部署一套完整文档智能平台更轻；对于数百万页档案、强合规场景或复杂表格抽取，它则不应被当作最终方案。

影响效果的四个关键变量

图像分辨率

分辨率是最直接的变量。小字号文字在低分辨率下会丢失细节，继续让模型“猜”通常不会解决问题。与其重复运行 OCR，不如先重新渲染页面或放大关键区域。

版面复杂度

单栏正文最容易识别，双栏、脚注、侧边栏和表格会显著增加阅读顺序错误。复杂页面可以拆成多个区域分别识别，再根据页码和位置合并。

语言和字体

中英文混排、繁简体混排、旧字体、艺术字体以及专业符号都可能降低结果质量。金融、法律和医学文档中的专有名词尤其需要词表或人工复核。

后处理规则

OCR 之后的清洗决定了 LLM 能否稳定使用结果。删除重复页眉、保留页码、识别标题层级、修复断行，这些看似简单的操作，往往比再换一个模型更能改善最终问答质量。

不要忽略隐私与合规

本地开源不等于天然安全，是否本地处理取决于 OCR It 实际使用的后端和配置。使用前应确认图像是否会被上传到第三方服务、日志是否保存原文、临时文件是否自动删除，以及模型文件来自哪里。

处理身份证、合同、病历、财务报表或内部研发资料时，建议：

• 默认关闭不必要的联网功能；
• 使用脱敏后的样本测试；
• 清理临时截图和缓存文件；
• 为输出文件设置访问权限；
• 保存处理时间和工具版本，方便审计；
• 不把 OCR 结果直接发送到未经批准的外部模型。

如果项目依赖外部 OCR 服务，开源代码本身也不能改变数据出境、第三方处理和行业监管要求。真正的安全边界在于数据流向，而不是“项目是否开源”这四个字。

最后：把 OCR 当作数据采集层，而不是答案生成器

OCR It 解决的是一个明确问题：把人眼能看到、但程序无法复制的文字，转换成 LLM 可以继续处理的输入。它适合个人研究、资料整理、截图问答和小规模知识库构建，也适合开发者快速验证“视觉文档能否接入现有 AI 流程”。

但它并没有消除 OCR 的固有风险。错误的数字、缺失的符号、混乱的版面和无法识别的手写字，仍然需要检查。最稳妥的工作流不是“截图后直接让 LLM 总结”，而是：

1. 保存原始页面或图片；
2. 用 OCR It 生成原始文本；
3. 对高风险字段和复杂页面进行复核；
4. 清洗成带页码和来源的 Markdown；
5. 再交给 LLM 做摘要、问答或结构化提取；
6. 最终结论回链到原图或原文档。

如果你的痛点是“资料明明就在屏幕上，却无法复制给模型”，OCR It 值得立即试用。它不是企业级文档理解平台，也不是准确率神话，但作为 LLM 输入链路中轻量、实用的一环，方向是对的：先把文本拿出来，再谈模型理解。

参考来源

• OCR It GitHub 仓库：项目源码、README、安装方式与最新使用说明；本文涉及的具体参数和运行入口应以仓库当前版本为准。
• GitHub Topics：OCR：GitHub 上 OCR 相关开源项目的分类页面，可用于比较不同识别工具和后端。
• GitHub Topics：document-ai：文档智能与文档理解相关开源项目集合，可进一步了解 OCR、版面分析和信息抽取工具链。