文档统一为Markdown，是AI高效读取PDF、Word与图片的关键-开发者社区

去年有个做知识库的朋友问我，为什么同一份 PDF 丢给 AI，有时候回答得又准又细，有时候却像是在“看天书”。我让他把原始文档发过来看了一眼，当场就明白问题出在哪了——文件本身是扫描版，AI 拿到手的是零散的图文块，连段落顺序都是乱的。这个场景我见过太多次了。很多人以为把 PDF、Word、Excel、图片直接扔给 AI 就万事大吉，其实真正有效的做法是：先统一成 Markdown，再交给 AI。

不是卖关子，Markdown 这种纯文本格式本身就是 AI 的“母语”之一。标题、列表、表格、引用在 Markdown 里有明确标记，AI 读取时能直接理解文档结构，而 PDF 的坐标、Word 的 XML 结构、Excel 的单元格引用、图片里的像素文字，AI 读起来都要额外绕一层。这篇文章不聊玄乎的理论，就说说我过去几个月在文档预处理上踩过的坑、验证过的流程，以及一套可以直接抄走的统一转换方法。

1. 为什么 Markdown 能成为人和 AI 之间的“通用语言”

1.1 先搞清楚 AI 到底是怎么“看”文档的

大多数人的误区，是把 AI 当成一个会翻页的读者。其实大语言模型接收的是文本序列，也就是一堆 token。无论是 PDF 还是 DOCX，最终都要想办法变成“文本”喂给模型。差别就在这个“变”的过程里。

PDF 看起来有版面有排版，但内部存的是“坐标定位”。文字在页面哪个位置、字号多大、颜色如何，这些都是视觉属性，而不是语义属性。AI 拿到纯提取的 PDF 文本，往往是一段被抽干结构的长文本，标题不像标题，表格不像表格，页码混在正文里。Word 稍微好一点，它本身有段落样式和表格节点，但提取时如果按“纯文本流”处理，同样会把 Heading 1 和正文混为一谈。Excel 更不用说了，直接转 CSV 后，单元格的层次关系变成了一堆逗号分隔的裸数据。

Markdown 恰好补上了这个缺口。它在纯文本之上增加了一层极轻的语义标记：#表示标题层级，|表示表格，-表示列表，>表示引用。这些标记不依赖任何软件，任何解析器都能识别，大模型训练时也见过海量 Markdown 语料，理解成本极低。用 Markdown 做中间格式，等于替 AI 把文档结构先拆明白了。

1.2 “统一格式”节省的不是存储空间，而是 AI 的理解成本

文档预处理这件事，表面上在做格式转换，本质上是在做“信息降噪”。同样一份内容，用四种格式投喂 AI，得到的回答质量会差很多。

原始格式	AI 看到的本质	常见问题
PDF	坐标 + 文本碎片	段落断层、表格错位、多栏顺序混乱
Word	XML 标记流	样式丢失、标题层级模糊、图片无法解释
Excel	二维网格坐标	合并单元格丢失、跨 Sheet 关联断裂
图片	像素矩阵	OCR 误差、阅读顺序不确定、表格难以还原

我做了一个很直接的对比实验：同一份产品说明文档，一份转成 Markdown，一份直接抽取 PDF 纯文本，然后分别让 AI 总结表格里的参数指标。Markdown 版本的回答基本能准确引用每一行，纯文本版本则把表头和表尾的数据搅在了一起。后来我把这个经验总结成一句话：给 AI 吃“已经整理好的菜”，别让它自己在垃圾堆里翻菜谱。

2. PDF 转 Markdown：最难的不是文字，是表格和多栏排版

2.1 为什么 PDF 转 Markdown 不能靠“复制粘贴”

PDF 看起来简单，其实是所有格式里最难处理的，没有之一。原因在于它存储的是“视觉结果”而不是“逻辑结构”。你在阅读器里看到的一行文字，底层可能是被拆分成了多个文本块；一个跨页表格，在数据层面是被硬生生切断的；双栏论文页面上，左栏末尾和右栏开头的文本在提取时还容易首尾相接。

早期我用最原始的文本提取工具处理 PDF，结果惨不忍睹：章节标题和正文混在一起，表格里的数字散落成孤立的词组，脚注跑到了段落中间。这就是典型的“有文字无结构”。

要真正转成可用的 Markdown，至少要在三个层面做处理，缺一不可：

文本层提取：把可见文字完整取出来，这一步解决“有没有”的问题。
版面分析：识别标题、段落、表格、图片、页眉页脚等区域，并重建正确的阅读顺序，这一步解决“结构对不对”的问题。
特殊元素还原：把表格转成 Markdown 表格语法，把公式转成 LaTeX 或纯文本描述，把图片做标注，这一步解决“细节真不真”的问题。

只做第一步，得到的是散装文本；三步全做，才能得到一份 AI 真正读得懂的 Markdown。

2.2 表格是 PDF 转 Markdown 的“硬骨头”

在我处理过的文档里，PDF 表格的还原难度远超普通段落。因为 PDF 里的表格往往没有“单元格”概念，只有横线、竖线和文字坐标。转换工具要自己判断哪些文字属于表头、哪些属于数据行、哪些是跨行单元格。遇到斜线表头、合并单元格、竖排文字的时候，绝大多数工具都会直接缴械。

我试过几条路子，最后固定下来这样的处理策略：

先判断 PDF 是文本型还是扫描型。文本型直接用解析工具读文本层；扫描型就需要走 OCR 识别，多一道拐弯。
表格区域单独切割出来做结构识别，不要和普通文本混在一起处理。把表格区域交给专门的表格结构还原模块，输出成行、列、单元格坐标。
坐标还原后，再按“表头行—数据行”的顺序输出成 Markdown 表格。如果单元格合并严重，宁可拆分成多个独立表格，也不要强行保留合并效果。
对于跨页表格，我会在每一页生成一个子表格，并在两个子表格之间插入注释标记，方便后续人工检查。

2.3 一套我实测过比较稳的 PDF 转 Markdown 流程

整个流程看起来长，但真的值得。我把步骤整理成清单，你可以直接照着搭：

检查 PDF 是否有文本层。最简单的办法是用 PDF 阅读器搜索任意一段文字，搜得到说明有文本层，搜不到就按扫描件处理。
有文本层的文件，先进版面分析，输出区域坐标和阅读顺序。
对表格区域做表格结构识别，对图片区域单独裁剪保存，对公式区域做公式识别。
按 Markdown 语法重组：标题用##，正文直接输出，表格用管道符，图片用![]()占位并记录文件路径。
最后跑一遍自动巡检脚本，检查每个表格的列数是否一致、行数是否合理、是否存在明显的连续空格。

这里有个细节：别迷信“全自动”。目前市面上没有哪个工具能百分之百还原复杂 PDF。我在流程里保留了“人审兜底”环节，尤其是带复杂表格的合同、财务报表，转完后人工扫一遍，确认结构没问题再喂给 AI。这一步虽然费点时间，但比让 AI 吐出错误数据再返工高效得多。

3. Word 和 Excel 别当普通文件处理：提取结构比提取内容更重要

3.1 Word 转 Markdown，关键是“标题树”而不是“字符流”

Word 文档其实有很好的结构化基础，段落样式（标题 1、标题 2、正文）就是现成的层级信息，只是很多人提取时没用起来。我见过不少自动化脚本，用最简单的库把 Word 里的文字一股脑读出来拼成纯文本，结果 Heading 1 和正文毫无区别，AI 拿到手后分不清章节边界。

正确做法是逐段遍历文档，判断每个段落的样式名。样式名以 Heading 开头的，转换成对应层级的 Markdown 标题；正文段落直接输出；列表按编号级别处理；表格则拆成单元格遍历。

有个容易忽略的细节是 Word 里的“文本块”现象。很多文档从网页复制过来，表面上是一个段落，实际上内部塞了十几个小文本块，甚至换行符是手动Shift+Enter生成的。转换时要先把这些碎块合并成真正的段落，再判断样式。否则转出来的 Markdown 会莫名其妙出现大量单字成行，AI 读起来头大。

3.2 Excel 转 Markdown：不要一上来就转 CSV

Excel 是另一种极端。CSV 虽然也能被 AI 读取，但它把数据类型、合并单元格、多级表头全部拍扁了。比如日期列，Excel 里是2024-03-15，转成 CSV 可能变成一串序列号；数字列保留的小数位也可能改变。更重要的是，带合并单元格的表头，在 CSV 里会变成一堆空字符串，AI 根本不知道这些空行是什么。

我的做法是：先用表格处理库按“行列坐标”读取单元格位置，再按以下几个原则重组：

把多级表头拆成“上级表头 + 下级表头”的组合字段名，例如2024年预算 / Q1。
合并单元格以左上角的值填充整个合并区域，避免出现空值。
每一个 Sheet 单独生成一个 Markdown 表格，并在表格前用 H3 标题注明 Sheet 名称。
多个 Sheet 之间如果有关联字段，用文字补充一句“关联说明”，而不是干巴巴丢一堆表格。

这样处理后，Excel 里的二维关系就变成了 Markdown 中上下文连续的表格块，AI 能明确知道哪一列是什么含义、哪些内容属于同一个表。

3.3 一个亲测有效的组合场景

我之前处理过一个某渠道项目的月度数据报表，原文件是一个三层的 Excel 工作簿，里面有汇总表、明细表、对比表，还带颜色标记。如果直接转 CSV，那基本是一场灾难。后来我先把每个 Sheet 转成独立表格，然后在外层包了一个 Markdown 文档，开头写上总述段落，接着按“汇总—明细—对比”的顺序排列，表格之间用 H2 标题分隔。AI 拿到这份文档后，不仅能把每个 Sheet 的数据分开引用，还能在回答中主动关联汇总和明细的差异。这就是“结构先行”的好处。

4. 图片转 Markdown：OCR 只是起点，语义重建才是关键

4.1 图片文档不能只做文字识别

很多人以为图片转文字就是跑一遍 OCR，把识别出来的文字堆在一起就完事。实际上，OCR 只解决“像素里的字是什么”这个问题，完全没解决“这些字属于段落还是表格、阅读顺序是什么”的问题。

我处理一份扫描版行业报告时就踩过这个坑。直接用 OCR 转出来的文本，第一段报告摘要被拆成了三行，图表标题插进了正文，表格数据错位到了一起。后来我改用“OCR + 版面分析 + 表格还原”的组合流程，才把报告转成像样的 Markdown。

完整的图片文档转换流程，我现在一般是这么走的：

图像预处理：去噪、纠偏、增强对比度，尤其是手机拍的白板或纸张照片，拍歪了要先做透视校正。
文字识别：按识别模型支持的语言配置，中文文档用中文模型，混排文档要开双语模式。
版面布局分析：把图片按区域划分成标题区、正文区、表格区、图片区、页眉页脚区，然后按阅读顺序排序。
表格结构还原：单独对表格区域做行列识别，输出成 Markdown 表格。
语义校正：根据上下文修正易混字符，比如0和O、1和l，同时把识别不确定的词标记出来。

这一步做完，图片里的内容才真正变成 AI 能够稳定理解的结构化文本。

4.2 几个特殊图片场景的处理心得

不同的图片文档，难度天差地别。我把常见类型和推荐策略整理成了一张表：

图片文档类型	主要难点	推荐处理策略
扫描版书籍/报告	版面复杂、双栏、插图多	版面分析优先，按栏重建阅读顺序
手机拍摄的表格照片	透视变形、反光、阴影	先透视校正，再走表格还原
带公式的论文页面	公式识别容易错	公式单独识别并转为 LaTeX 标记
手写笔记/表单	OCR 误识别率高	保留原图路径，Markdown 中加“存疑”标记

这里特别想提醒一点：不要为了“统一”而丢掉原图。在 Markdown 里为图片保留路径或文件名，让 AI 需要时能对着原文核对，对准确率很有帮助。我之前做某合同审核项目，就是把每页扫描件转成 Markdown 后，在文档末尾附上原图文件名列表。AI 遇到不确定信息时，可以按文件名回到原图区域二次确认，整个流程的可信度高了不少。

5. 喂给 AI 之前的最后一步：清洁、验证、切分

5.1 Markdown 转完之后不等于直接能投喂

格式转换只是第一关，转换完的 Markdown 不等于直接可以丢给 AI。我习惯在投喂前跑一轮“清洁检查”，尤其是下面几类问题：

隐藏字符：从 PDF 转出来的文本经常带不可见控制字符，肉眼看不到，但会影响 token 分句。我用脚本把这类字符统一清除。
全角半角混杂：中文标点和英文标点混在一起，虽然 AI 能看懂，但会影响检索匹配。统一成中文语境下的全角标点更规整。
表格破损：自动转换的表格经常出现某一行列数不一致，Markdown 渲染后表格乱掉。检查每行的竖线数量是否相等，是最快的验证方法。
多余空行和自动编号：有些工具会自作聪明给段落加编号，反而干扰原文结构。手动清理一次最稳妥。
公式与特殊符号：如果原文有数学符号，建议统一转成 LaTeX 形式，避免 AI 把≤当成普通字符漏读。

5.2 投喂时的切分，要尽量贴合 Markdown 的语义边界

文档预处理还有一个常被忽略的环节：切分。整篇超长文档一次性丢给 AI，既受上下文长度限制，又容易让 AI 抓错重点。但切分不是按固定字数硬切，而是应该顺着 Markdown 的结构走。

我通常的做法是：优先以 H2 或 H3 标题为切分点，一个章节作为一个独立块；如果某个章节过长，再按段落和表格边界继续切分。数据表格尽量不切断，实在要跨块，也要在下一块开头重复一遍表头。这样既能保证每一段语义完整，又能让 AI 在每个块内看到相对完整的上下文。

关键技巧：切分后的每个块，在开头加上“来源章节标题”信息。比如（来源：第三章实施计划）》，这样 AI 在回答时能知道自己在处理哪一块内容，回答的上下文指向性更强。

5.3 针对 RAG 场景的一点补充

如果你是把 Markdown 文档往向量数据库里送，结构化的优势会更明显。Markdown 的标题、列表、表格本身就能作为切分锚点，减少语义割裂。我在实际搭知识库时发现，基于标题切分出来的块，检索命中率明显高于按字符数硬切的块。而表格如果转成 Markdown 后保持结构完整，查询“某产品的参数是多少”这类问题，命中率会非常高。这就是“给 AI 看结构化内容”最直接的收益。

6. 几个关于正确姿势的最终建议与认知

6.1 优先保住结构，再谈转换速度

很多人在转文档时第一关心的是“快不快”，但我更关心“结构全不全”。一份 50 页的 PDF，全自动快速转换可能只需要几十秒，但表格错位、标题丢失这些问题，后期让 AI 返工的代价远高于多花两分钟做版面分析。我的习惯是：普通文本文档用快速通道，复杂排版和表格密集的文档走精细通道。两者并行，比指望一个工具通吃所有场景靠谱得多。