企业官网建设流程全解析

MinerU：3步完成法律PDF解析到Markdown转换的全流程

【免费下载链接】MinerUTransforms complex documents like PDFs and Office docs into LLM-ready markdown/JSON for your Agentic workflows.项目地址: https://gitcode.com/GitHub_Trending/mi/MinerU

法务同事丢来一份扫描版合同时，多半是耐心考验：价格表被拆成散乱文本行，条款编号混进正文，公章上的字被识别成乱码。手工转成 Markdown 要半天，转完还不能直接喂给模型。MinerU 就是为解决这件事而生的开源文档解析工具——它能把 PDF 和常见 Office 文档转换成 LLM 可用的 Markdown 与 JSON，常规情况下，一份 30 页的合同 2 到 5 分钟就能出结果。

📄 为什么合同PDF总让普通工具翻车

普通转换工具做的是「导出文字」：把 PDF 里的文本层按从上到下的顺序读出来。问题在于，合同是二维排版的。

手工处理必挂的3个地方

第一个是表格。合同里的价格清单被平铺导出后，变成「金额、币种、日期……」排成一串，你得自己猜哪些数属于同一行。第二个是条款层级。「第一条、1.1、（一）」这些编号和正文在文本层里是平的，转出来的时候段落之间看不出从属关系。第三个是扫描件。纸质合同扫描件经常底纹模糊、印章压字，字本身看不清，结构更无从谈起。

这三类问题，恰好是「文档解析」和「文本提取」的分界线：解析要先看懂页面上每个块是什么、块和块之间什么关系，再按阅读顺序输出，而不是一股脑倒出来。

🧩 能力总览：MinerU的文档解析全家桶

一种输入，多种输出

MinerU 支持 PDF、图片、DOCX、PPTX、XLSX 五类输入，可以指一个文件，也可以直接指一个目录批量处理。输出不止一个文件：有人读的 Markdown、有结构化 JSON、有裁剪出来的图片，还有逐块的 content_list。同一次解析的结果，人、程序、模型各取所需，不用二次加工。

三套后端，精度和硬件可以换

它内置三套解析后端：默认 hybrid 是精度与速度的平衡点；vlm 走视觉语言模型路线，精度最高，需要 8GB 以上显存的 GPU；pipeline 可以纯 CPU 运行，兼容性最广，老机器、无卡服务器都能跑。硬件够就选默认，硬件不够有退路，这是它比单一方案工具省心的一点。

官方架构总览把流程摊得很开：预处理做文档分类和扫描版识别，模型层做 layout 检测、公式检测与文本 OCR，管线层负责表格合并、阅读排序、无用块过滤，最后统一输出 Markdown 与 JSON。

🚀 第一次跑MinerU：只需要做3件事

装：一条pip命令

先执行pip install "mineru[all]"。这个带 all 的安装包包含全部核心功能，Windows、macOS、Linux 装法一致，不需要自己搭环境。

解析：只记两个参数

装完以后要记的只有一条：mineru -p 输入路径 -o 输出目录。-p接收单个文件或整个目录，-o指定结果放哪。仓库里自带几份示例 PDF，可以先拿它们练手。首次运行会自动下载模型，比平时慢一些；之后的每次运行都走本地缓存，30 页的合同在普通 GPU 机器上 2 到 5 分钟跑完。

收：一套完整的结果

跑完后输出目录里，每份文档对应一个 Markdown 和一份信息等价的 JSON，外加一张图片目录。想看「页面里每个块到底是什么」，content_list 按块给出了类型和顺序，具体文件构成建议先看 输出文件说明，拿到结果就不会对着目录发懵。

🔍 细节深挖：合同的硬骨头是怎么处理的

表格与公式：默认就是开着的

表格识别和公式解析在 MinerU 里都是默认启用，不需要额外配置。合同里的价格表会被还原成标准 Markdown 表格，跨页的表格会尝试合并；公式则保留为 LaTeX，而不是截图。如果你的文档确认没有任何表格，也可以在命令行参数里关掉表格解析，省下一部分解析时间。

扫描件还是文本层：工具自己判断

解析方法默认是 auto：MinerU 会先检查页面有没有可用的文本层，有就直接取，没有就转 OCR。对纯文本 PDF，这能省掉一轮 OCR 的时间；对扫描件，它不会在空文本层上硬抠出乱码。也可以强制指定只走文本提取或只走 OCR，并指定文档语言来提升小语种场景的识别准确率。

阅读顺序与分块：两栏不打架

合同解析真正的差距在阅读顺序上。双栏版式、页眉页脚、页码，一旦混进正文，模型读到后面就开始糊涂。MinerU 先把页面切成块、按阅读顺序编号，再逐块识别输出。

上面这张是解析示例：每个块都有独立编号，标题、正文、公式、图表互不粘连，你甚至可以按编号抽查输出是否正确，这在排查长文档时非常有用。

⚖️ 选型对照：一份合同，三种做法差多少

以「把一份 30 页合同变成可用的结构化 Markdown」为例，三种做法的差别相当直接：

首次运行包含模型下载，表中耗时按第二次起计算。

机器不够硬的时候

没有 GPU 就选 pipeline 后端，纯 CPU 一样能解析，代价是速度和精度略降。机器老但网络好，可以用 Docker 部署整套服务，或者让本地客户端通过 http-client 方式连上远处一台有卡的服务器，重活全部交给服务器干。模型默认托管在 huggingface，网络受限的环境切换一个环境变量就能改用 modelscope 镜像源，不用折腾代理。

什么时候升级到VLM

默认 hybrid 后端在公开基准上的端到端精度已经过 95 分，日常合同足够用。如果你处理的是密集排版的扫描合同、复杂嵌套表格，且手里有 8GB 以上显存的 GPU，把后端换成 vlm-engine 是明显的下一步：它对版面更「看得懂」，换一点速度换精度。

🌱 把结果接进现有工作流

接上Dify：合同问答机器人

解析出来的 Markdown 和 JSON 不是终点。MinerU 提供官方 Dify 插件，在 Dify 工作流里挂上它，上传合同 PDF 就能自动拿到解析结果，再顺势灌进知识库或交给大模型做条款问答。对法务团队来说，「新合同进来 → 解析入库 → 可检索」变成一条不用人盯的流水线。

JSON输出：给RAG和程序化调用留了口子

如果你在做 RAG，content_list 把标题、表格、公式、图片分块得明明白白，直接按块切 chunk 就行，不用自己再写版面规则。做程序化处理的话，JSON 中间态里保留了位置坐标和块级属性，表格、图片都能被代码进一步利用。两种输出都省掉了二次解析。

🎯 现在就动手

三个存下来的链接

想深入的话，先看这三处：

• 官方文档：安装方式、后端差异、FAQ 都在这里
• 快速开始指南：从装到跑通第一次解析，一页讲完
• 核心源码：pipeline、hybrid、vlm 三套解析后端全在这个目录

建议的第一步，是把你手边那份一直拖着没转的合同丢给它跑一遍。看完输出，你就知道自己库里还有哪些文档值得批量处理了。

【免费下载链接】MinerUTransforms complex documents like PDFs and Office docs into LLM-ready markdown/JSON for your Agentic workflows.项目地址: https://gitcode.com/GitHub_Trending/mi/MinerU