夜雨聆风如果你做过知识库、RAG 或 Obsidian 资料整理，大概率会遇到同一个问题：
PDF 很多，但真正能用的 Markdown 很少。
尤其是行业报告、白皮书、测评报告这类文件，看起来只是“转成 md”，实际难点却在于：标题层级、表格、图表、图片、图注、页内排版，能不能一起保留下来。
我最近连续测试了 MarkItDown 和 MinerU，用真实 PDF 做知识库入库。结论很直接：
MarkItDown 适合快速拿文字；MinerU 更适合把报告型 PDF 转成可长期维护的知识库 Markdown。
先看网上大家怎么评价
我查了一圈相关资料，基本共识是：
- MarkItDown 的定位是轻量、多格式、面向 LLM 的 Markdown 转换。
微软官方 README 说得很清楚，它重点是把 PDF、Word、PPT、Excel、HTML 等内容转成适合文本分析和 LLM 使用的 Markdown，但不一定适合高保真文档转换。
- MarkItDown 胜在快和简单。
一行命令就能跑，格式支持广，做批量文本抽取很顺手。
- 它的弱点也很明显：复杂 PDF 的版面、图片、表格保真度有限。
有对比文章提到，MarkItDown 对 PDF 往往更像“抽文字”，复杂图片、公式、表格的效果一般。
- MinerU 更偏文档解析系统。
MinerU 官方文档强调复杂版式、多模态内容、表格、公式、图片、多栏布局等结构化解析能力；API 模式还支持 pipeline、vlm、MinerU-HTML 等模型版本。
- 代价是部署和首次运行更重。
本地 MinerU 需要安装依赖、下载模型，首次启动没有 MarkItDown 那么轻。
这和我自己的实测结果基本一致。
我的真实测试：同样是 PDF，结果差很多
这次我主要处理的是产业互联网、工业大模型测评这类 PDF 报告。
这些报告不是纯论文，也不是简单合同，而是典型的“知识库难题”：
有封面和目录 有大量图表 有复杂版式 有表格 有图注和数据来源 有很多页面的视觉信息比正文更重要
一开始我用的是 MarkItDown 和 MarkItDown OCR 思路。
它的优势很明显：安装快、调用简单、文本很快出来。
但问题也很快暴露：对于报告型 PDF，它更像把能抽到的文字拿出来。图片、图表、表格和版面关系，经常需要额外补救。对于知识库来说，这会造成一个很麻烦的结果：
Markdown 是有了，但报告里的“信息结构”丢了。
后来我测试 MinerU API，转换同类 PDF 的效果明显更好。表格、图表、图片资源和 Markdown 的结构保留都更接近原文。
再后来，我又在本地部署 MinerU，用 pipeline 模式跑 CPU 测试。
本地 MinerU 跑 81 页 PDF：结果如何？
我用一份 81 页的产业互联网报告做了完整测试。
第一次运行前，最慢的是模型下载。这个过程比较久，因为 MinerU pipeline 需要布局分析、OCR、公式、表格等模型。
但模型下载完成后，实际转换速度并不夸张。
我先跑了前 3 页样例：
首次模型初始化约 5 分多钟 真正处理 3 页只用了几十秒 封面、目录、基础框架页主要输出文字
随后我又抽取中间图表页测试，效果明显更接近我的需求：
表格被转换成 HTML table 图表被抽成图片 Markdown 中自动插入图片引用 正文、图表标题、数据来源基本能衔接起来
最后我跑完整 81 页：
Markdown 约 3126 行 提取图片 162 张 表格保留为 HTML table 图表页生成了图片引用 本地 CPU pipeline 在模型缓存后，全量转换约 2 分钟多完成
这已经不是“抽文字”，而是比较接近“把 PDF 拆成可维护的知识库材料”。
MarkItDown 和 MinerU 的真正差别
我现在会这样理解两者：
MarkItDown 是文件转 Markdown 工具。
它适合：
快速把 Word、PPT、Excel、HTML、PDF 转成文本 给 LLM 做初步输入 处理结构简单的文件 对图片和版面要求不高的场景 快速批量跑一遍资料
MinerU 是文档解析工具。
它更适合：
PDF 报告 论文 白皮书 扫描件或半扫描件 多栏排版 图表很多的行业报告 表格、图片、图注需要保留的知识库入库
一句话总结：
如果你只要文字，MarkItDown 很香；如果你要“图文结构”，MinerU 更靠谱。
为什么我最后把知识库 ingest 流程改成 MinerU
我的知识库是 Obsidian llm-wiki体系，资料会进入 raw/00-inbox，再被整理成 wiki sources、entities、concepts。
这类流程最怕两件事：
第一，Markdown 看似生成了，但信息缺失。
第二，图片路径混乱，后续迁移、归档、Obsidian 打开都出问题。
所以我最后把 ingest 规则改成：
非 md 文件先移动到临时目录，不在 inbox 原地转换。 使用本地 MinerU pipeline 转 Markdown。 把图片统一整理到 Obsidian vault 的 assets/<同名>/pages-NN.png。改写 Markdown 图片路径，避免出现 ../../assets/...或临时目录路径。转换质量验收通过后，再删除原始 PDF、PPTX、DOCX 等非 md 文件。 生成 Markdown 时遵循 Obsidian Markdown 习惯，比如 frontmatter、wikilinks、图片引用等。
这样做以后，整个流程从“把 PDF 变成一坨文本”，变成了“把报告变成可追溯、可检索、可维护的知识库材料”。
什么时候还应该用 MarkItDown？
我并不是说 MarkItDown 不好。
相反，它在很多场景仍然是首选：
你只是想快速读取一个文件 文件主要是文字 你要处理多种格式 你不关心图片和版面 你希望工具尽可能轻 你只是给 LLM 临时喂材料
比如一个普通 DOCX、一篇 HTML、一份简单 PDF，MarkItDown 足够好，而且更省事。
但如果你的目标是长期知识库，尤其是行业报告、咨询报告、白皮书、扫描 PDF，我会优先选 MinerU。
我的最终建议
可以用一个简单标准判断：
临时阅读，用 MarkItDown。
正式入库，用 MinerU。
MarkItDown 的价值在“快”。
MinerU 的价值在“完整”。
对于个人知识库和企业知识库来说，真正稀缺的不是转得快，而是转完以后还能不能用。
这次测试之后，我最大的感受是：
PDF 转 Markdown 不是格式转换问题，而是知识保真问题。
如果只是把文字抽出来，很多工具都能做。
但如果要让一份报告在 Obsidian 里继续保持标题、表格、图表和上下文关系，MinerU 这类文档解析工具才更接近答案。
参考资料
Microsoft MarkItDown GitHub README MarkItDown OCR README MinerU 官方 API 文档 PDF转换工具 Marker、MinerU、Markitdown 对比分析 深度调研开源 PDF 转 Markdown 工具：Marker、MinerU 与替代方案