被PDF解析逼疯?这款本地开源神器完美保留公式表格,直接喂给大模型!

MinerU 把 PDF 变成 Markdown 时，公式和表格居然没乱

手里拿着几份带公式的技术 PDF，或者扫描的合同和带手写批注的资料。你想把它们喂给本地模型做总结、生成代码，或者直接塞进 RAG 检索。结果试了几个在线工具，表格数字对错位，公式变成乱码或图片，段落顺序全乱，还得花时间手动修。更别提敏感内容上传云端的隐忧。

这种情况在做 AI 项目的人里不算少见。文档解析这一步经常成为整个工作流的隐形瓶颈：输入质量低，后续检索和生成就跟着跑偏。

MinerU 提供了一个本地开源的解决方案。它把 PDF、Word、PPT、Excel 和图片转成结构化的 Markdown，公式保留为 LaTeX，表格保持原生结构，图片单独提取成文件，全程在自己机器上跑，没有数据外传。它还带 MCP 服务，能直接接进 Claude Desktop 或 Cursor 里，让文档解析成为编码工作流的一部分。

为什么通用 OCR 经常把结构搞砸

普通人处理文档时，最直观的感受是“能看懂就行”。但一旦要给 AI 用，问题就暴露了。表格里的数字和列对不上，公式符号跑偏，图片和文字混在一起，布局信息完全丢失。这些在人工阅读时可能只是小麻烦，在 RAG 或 agent 场景里却会直接导致检索召回错误、生成内容不可靠。

很多人把精力放在调模型参数上，却忽略了输入数据的结构质量。结构乱掉后，即使模型再强，也只能在错误上下文里推理。

MinerU 的思路是把任务拆成几个专门模块，而不是让一个模型包打天下。布局检测交给 LayoutLMv3，负责找出页面上文字块、图片区、表格区的位置。公式识别用 UniMERNet，专门把数学内容转成 LaTeX。文字识别用 PaddleOCR，支持 109 种语言，包括扫描件和手写。表格结构重建用 RapidTable，负责单元格合并关系和内容对齐。最后把所有结果按人类正常阅读顺序组装成 Markdown。

这种分工让每个模型只在自己最拿手的任务上发挥作用，减少了通用模型容易出现的“顾此失彼”。理论上，在复杂排版或低质量扫描件上，模块化流水线的容错空间比端到端模型更大。我之前判断视觉大模型一统天下就能解决文档转换，直到实际处理带密集表格和公式的技术文档时，才发现通用模型经常在结构上妥协，而这种拆分方式在保留原始格式上更有针对性。

流水线分工带来的实际差异

把文档解析想象成快递分拣中心。一个人既要识别地址、又要判断易碎品、还要决定装箱顺序，累了就容易出错。MinerU 的做法是每个环节交给最专业的“师傅”：布局检测只管页面结构，公式模块只管数学符号，OCR 只管文字内容，表格模块只管行列关系。结果拼起来后，Markdown 里的表格能直接复制进 Excel，公式能直接进 LaTeX 编辑器，图片路径是相对引用，预览时自动显示。

这对 AI coding 工作流特别有用。以前解析一份 API 文档或技术规范，得手动修格式才能喂给 Cursor 或 Claude。现在转换结果基本能直接用，agent 可以更准确地引用表格里的参数或公式里的变量。隐私方面也彻底放心——敏感合同、内部报告、个人资料都不用离开本地机器。

当然，模块化也不是没有代价。布局检测那一步如果在极端规文档上出错，后续步骤都会受影响。这也是为什么实际项目里还是需要根据文档类型做简单验证。顺便一提，PaddleOCR 支持的手写识别，在处理带笔记的扫描 PDF 时特别能派上用场。

一行命令 plus 工具集成，文档解析直接嵌入编码环境

想在本地跑起来，最直接的方式是命令行。打开终端，执行下面这行：

# -p 后面接输入文件路径，支持 PDF/Word/PPT/Excel/图片# -o 指定输出目录# --return_images true 让图片单独提取，Markdown 里会用相对路径引用mineru -p doc.pdf -o ./output --return_images true

跑完后，output 目录里会生成对应的 Markdown 文件和 images 文件夹。Markdown 里图片路径已经写好，直接用 Typora 或 VS Code 预览就能看到效果。

如果更喜欢图形界面，可以先启动 API 服务，再开 Gradio 前端：

# 启动 APImineru-api --host 127.0.0.1 --port 8000# 再开 Gradio 界面mineru-gradio --server-name 127.0.0.1 --server-port 8808 --api-url http://127.0.0.1:8000

浏览器打开 http://127.0.0.1:8808 就能上传文件转换。

更进一步，它自带 MCP server，能直接接进 Claude Desktop 或 Cursor。在 coding 时遇到参考文档，不用切换窗口，让 agent 自己调用解析并读取内容。这对经常处理技术资料的开发者来说，相当于把文档解析变成了 IDE 里的原生能力。

从社区反馈看，它对 IELTS 试题这类带特殊格式的材料也能处理，因为是本地小模型，没有云端内容过滤的限制。类似的其他标准化考试材料或复杂排版文档，实际效果也值得一试。

它适合什么人，不适合什么人

MinerU 的核心优势在于本地 + 结构保留 + 开源可扩展。适合三类人：需要处理敏感文档又不想上传云端的团队；把大量技术资料做成 RAG 知识库的开发者；已经在用 Claude Desktop 或 Cursor 做 AI coding，想把文档解析也纳入工作流的 builder。

它不是万能的。纯视觉大模型在随意聊天式问答上更灵活，而 MinerU 的强项是高保真结构提取。如果你的文档全是普通文字且不care格式，云端通用工具可能更省事。本地运行也意味着速度受硬件影响，复杂文档可能需要等待几分钟（具体取决于你的 CPU/GPU 配置）。

但在隐私和结构准确性这两点上，它给出了一个清晰的本地替代方案。GitHub 项目地址是 https://github.com/opendatalab/MinerU，完整安装和使用说明在社区里能找到。

我原来觉得云端 OCR 已经够方便，直到开始大量处理需要保密的内部资料，才真正体会到本地工具在信任链上的价值。结构保留这件事，看起来是小细节，实际影响的是整个 AI 工作流的输出质量。

在你用过的文档工具里，结构保留最差的是哪种情况？💬