企业官网建设流程全解析

不需要主标题，直接从二级标题开始。

1. 为什么要先统一成 Markdown，再交给 AI

先说结论：直接拿原始格式的文件喂给大模型，无论是 PDF、Word、Excel 还是图片，命中率都不稳定，而且很容易"读一半、错一半"。我踩了几次坑之后，现在的工作流固定成一条：所有文档先统一转成 Markdown，再作为上下文交给 AI。用了小半年，输出质量明显上了一个台阶。

先说原理层面的原因。大模型处理文档，本质上不是"看"文件，而是把内容切成 token 序列。PDF 在 AI 眼里是一堆坐标、字体描述和渲染指令，Word 则带着大量样式标记和 XML 结构，Excel 的单元格关系也是隐藏的，图片就更是纯像素了。这些格式里，真正有语义价值的正文内容占比往往不到 50%，剩下全是布局、样式、渲染信息。把这些东西一股脑塞给模型，模型被迫在无关信息上消耗上下文窗口，理解精度自然下降。

Markdown 就不一样。它是纯文本，又带有轻量级的结构标记：标题、列表、表格、代码块、引用、加粗。AI 在训练过程中见过海量 Markdown 文本，对这种语法非常熟悉。你可以把 Markdown 理解成 AI 的"母语"之一——用母语沟通，理解成本低，输出也更对路。

我做过一个小实验，同一份表格型 PDF，分别直接传 PDF 和传转好的 Markdown，问 AI 几个数据问题。直接传 PDF 时，字段错位、漏数、张冠李戴的情况大概占四成；转成 Markdown 之后，准确率差不多到了九成。这个差距非常明显。

还有一点是 token 成本。同样一份文件，Markdown 版的 token 消耗通常只有 PDF 版的三分之一到一半。上下文窗口有限的情况下，把预算花在真正的正文上，而不是格式噪音上，这个账怎么算都是划算的。

所以这套流程适合谁？日常需要大量处理合同、论文、行业报告、表格数据、图文扫描件的朋友，比如做知识库整理的、做文档问答系统开发的、写材料需要反复检索引用的人。这篇文章就把我整套转换思路、工具选型、实操步骤和踩过的坑一次性梳理出来。

2. 四种文档的转换难点与分析

2.1 PDF：先分清是文本型还是扫描型

PDF 是所有格式里最麻烦的，因为它有两种完全不同的"体质"。

一种叫文本型 PDF，内容本身就是由文本字符构成的。这种在转换时可以直接提取文字和坐标信息，还原度高。另一种叫扫描型 PDF，本质是一页页图片，需要靠 OCR 先识别文字，再重建布局。

很多人在这一步就栽了。我以前也以为 PDF 转 Markdown 顶多用个工具直接转换就行，结果拿到的 Markdown 里全是乱码、错位表格、页面碎片。后来才搞清楚：转换前必须先判断 PDF 是文本型还是扫描型。

判断方法很简单，有一个小技巧：用 PDF 阅读器打开，试着选中一段文字。能选中并复制出正常文字的，是文本型；选不中或者复制出来是乱码、空白、逐字乱跳的，基本就是扫描型。严格一点的话，可以用工具检测页面是否包含字体资源或文本对象，但这个目测法已经能覆盖九成场景。

文本型 PDF 里面还分两种布局，单栏和双栏。双栏 PDF（很多论文就是这种排版）在转换时如果不做栏位识别，文字会左右两栏交错着混在一起，读起来完全没逻辑。这个问题在后面的实操环节我会给出具体处理方案。

2.2 Word：样式混乱才是主战场

Word 转 Markdown 看起来最简单，毕竟 Word 本身就带有标题样式、列表结构这些语义信息，理论上能一一映射到 Markdown。但实际操作中最大的麻烦是：绝大多数 Word 文档的样式用得很乱。

比如很多人不用 Word 的标题样式，而是手动加大字号加粗，看起来像标题，实际上只是普通文本。这种情况下机器没法判断层级。还有大量的手动缩进、空格对齐、制表符、从网页复制过来的残留样式、各种奇怪的嵌套表格、文本框中堆砌的文字、页眉页脚、批注和修订痕迹——这些在转 Markdown 时都会变成噪音或者错位。

之前接手过一份某跨平台系统项目的需求文档，原始 Word 文件一百多页，里面到处是文本框和嵌入截图。第一次直接转换，出来的 Markdown 前半部分全是空白（文本框内容没提取到），后半部分又重复出现页眉。折腾两次之后，我总结出一个原则：Word 转换前必须先做"样式规范化"，把文本框中内容想办法导出来，把标题重新映射为真正的标题样式，否则后面全是坑。

2.3 Excel：从二维表格到 Markdown 表格

Excel 转 Markdown 的核心难度在于表格模型的对齐。Excel 有合并单元格、多个 Sheet、隐藏行列、公式计算值、单元格富文本、批注、浮动图表这些东西。

合并单元格在 Excel 里是视觉上很好用的功能，但转成 Markdown 表格是个大麻烦。Markdown 表格是一个严格的二维网格，每一行必须有相同数量的单元格。Excel 中跨多行跨多列的合并，转换后要么留空，要么需要拆分成多个虚拟单元格，语义很容易丢失。

多 Sheet 的处理也是一个问题。一个 Excel 文件有四五个工作表，每个表作用不同。如果全都堆到一个 Markdown 里，AI 读的时候会搞混；如果只转第一个 Sheet，别的数据就丢了。后面我会给一个实际的取舍方案。

公式处理也很关键。Excel 里很多单元格存的是公式，比如=SUM(B2:B10)，直接提取出来给 AI 的是一串函数字符串，AI 根本不知道该单元格的实际值是多少。转换时必须先让程序计算存好的缓存值，或者用库读取计算后的结果，再写入 Markdown。

2.4 图片：OCR 只是第一步，版面分析才是关键

图片转 Markdown，很多人以为就是跑一遍 OCR 识别文字，然后扔给 AI。但实际效果通常很差，因为 OCR 出来的文字是"流水账"式的——没有标题层级，没有列表结构，没有表格关系，甚至图片里的公式、图表、流程图都毫无处理。

我踩过的坑是：用 OCR 工具识别一张含表格的截图，结果输出是一长串文字，字段和字段之间只有空格分隔，表格的"行"和"列"的关系完全丢失。让 AI 去理解这个表格，等于让它猜。一次两次还行，文件多了根本没法用。

所以图片转 Markdown 的正确路径是：OCR 识别文字 + 版面分析（版面分析）+ 结构化重建。OCR 负责把像素变成字符串，版面分析负责识别页面上的区域类型——哪些是标题、哪些是正文、哪些是表格、哪些是图片注释、哪些是页眉页脚——然后按照 Markdown 的语法重新组织这些元素。

做这个方向的现有工具不少，有的是基于规则的版面分割，有的是基于深度学习的目标检测模型来识别版面区域。版面分析模型的精度直接决定了转换质量，尤其是那种双栏排版、有复杂页眉的扫描件，模型不行的话，识别结果会非常凌乱。

3. 实操：一套完整的文档统一化流程

3.1 工具选型对比

我试了一圈之后，留下了下面的组合，这套方案全部基于开源工具，适合本地离线批量处理，也适合改造后接入自己的服务流程。

提示：工具选型不是越强越好，而是要看自己的文件类型是不是匹配。如果你的 PDF 几乎都是网页导出的文本型 PDF，那么根本不需要上 OCR，用轻量级方案就够；如果全是扫描件，那 OCR 能力就是核心。

3.2 文本型 PDF 转 Markdown 的操作步骤

这里给一个我自己整理的处理流程，针对的是文本型 PDF。核心思路就是提取文字块及其坐标，然后按顺序组织成 Markdown。

第一步，提取文字块坐标。用 PyMuPDF（也就是 fitz 库）遍历每一页，把页面上的文字块连同坐标、字体大小、字体名称一起提取出来。

import fitz doc = fitz.open("sample.pdf") for page_num in range(len(doc)): page = doc[page_num] blocks = page.get_text("dict")["blocks"] for block in blocks: if "lines" not in block: continue for line in block["lines"]: for span in line["spans"]: text = span["text"].strip() if not text: continue # 这里可以拿到每个文本片的坐标、字号、字体 print(span["bbox"], span["size"], span["font"], text)

第二步，识别标题层级。字号和字体特征可以用来推断标题级别。比如正文是 10.5 磅，那 14 磅以上的可能是一级标题，12 磅左右的可能是二级标题。还需要根据标题所在的位置判断是否居中。这个规则不绝对，但大部分文档能覆盖。

第三步，重建段落。PDF 提取出来的文字是碎片化的，同一段落经常被拆成多个行、多个 span。需要根据字号的连续性、行间距、左边界坐标，把碎片拼接回完整的段落。这个拼接逻辑是整个转换过程最容易乱的地方，所以我一般在代码里维护一个"当前段落缓冲区"，当检测到新段落的起始特征（比如间距超过阈值、缩进变化）时，才把缓冲区的内容作为一个段落输出。

第四步，识别表格区域。用坐标和线条信息来判断页面中哪些区域属于表格。pdfplumber 在表格识别这块更成熟，可以检测到单元格边框线，我在实际处理中会把 pdfplumber 抽取的表格结果与 PyMuPDF 的文字流结果做拼接，按表格区域把文字替换为 Markdown 表格语法。

第五步，双栏 PDF 的栏位处理。双栏文档的页面文字，如果直接按坐标排序输出，会串栏。我的做法是：基于文字块的 x 坐标分布，利用投影确定页面垂直中线，然后按"先左栏后右栏"的顺序输出。也可以用两阶段的聚类算法来判栏，但对于常见的双栏模板，中线法已经能稳定工作。

3.3 Word / Excel 转 Markdown 的实操

Word 转 Markdown 我这里分两条路走。

第一条路，文档样式本身规整的情况下，直接用 pandoc 一条命令搞定：

pandoc input.docx -t gfm -o output.md

这里-t gfm表示输出 GitHub 风格 Markdown，它支持表格、任务列表等扩展语法，适合给 AI 用。

第二条路，样式混乱的文档，先做预处理再转。我写过一个 Python 脚本，用 python-docx 打开文档，遍历所有段落，检查是不是标题样式，如果不是但文本特征像标题（比如短文本、粗体、字号更大），就重新标记。文本框里的内容要单独提取出来，排在最近的正文附近。页眉页脚直接滤掉，批注全部删掉，修订内容接受并展平。

import docx doc = docx.Document("messy.docx") for para in doc.paragraphs: style_name = para.style.name text = para.text.strip() if not text: continue # 这里可以基于样式名映射到 markdown 标题 if style_name.startswith("Heading"): level = style_name.replace("Heading ", "") print("#" * int(level), text) else: print(text)

Excel 转 Markdown，推荐用 pandas 读取并输出，前提是要先处理好合并单元格和公式缓存问题。

import pandas as pd df = pd.read_excel("data.xlsx", sheet_name=None, header=None) for sheet_name, data in df.items(): print(f"## Sheet: {sheet_name}") # pandas 可以直接把 DataFrame 输出为 markdown 表格 print(data.to_markdown(index=False))

需要注意几个点。第一，如果需要读取公式计算后的值，pd.read_excel默认读取的是 Excel 文件里缓存的值，一般 OK。如果遇到缓存缺失或为空的单元格，可以考虑用其他库强制计算。第二，合并单元格在读取后会变成 NaN，需要按"前向填充"逻辑补全，再决定是把重复值保留还是置空。第三，多个 Sheet 不要盲目拼接，正确做法是把每个 Sheet 转换成独立的 Markdown 二级标题小节，Sheet 名称作为标题，这样 AI 能明确区分数据的不同区块。

3.4 图片（扫描件）转 Markdown 的实操

图片转 Markdown 这条路，我目前的处理链路比较长，但效果稳定：预处理 → OCR → 版面分析 → 结构化组装 → 二次清理。

预处理阶段主要是为了提升后续的 OCR 和版面分析准确率。比如把彩色图片转灰度、调节对比度、纠正倾斜。扫描照片拍歪了的话，要先做透视校正或旋转矫正。这一步看着简单，但实际对识别结果的影响巨大，我见过因为图歪了 2 度导致识别率下降三成的例子。

OCR 阶段可以根据需要选择开源引擎，比如 PaddleOCR 这类支持中英文的模型。对于包含表格的图片，OCR 不仅要识别文字，还要输出文字坐标和置信度。

版面分析阶段的目的是判断页面每个区域是什么类型。这个可以用基于检测的版面分析工具来做，能够输出每个区域的位置、类别（文本、标题、表格、图、页眉等）和内容。拿到这些区域之后，就可以做结构化组装：按坐标从上到下排序，标题区域转成# / ## / ###，文本区域合并成段落，表格区域按照单元格坐标关系重建 Markdown 表格，图表区域则保留标题或说明，必要时插入一段文字描述，告诉 AI"此处是一个图表，包含的数据如下"。

整个链路如果用手工脚本跑，一张 A4 扫描件大概需要十秒左右，批量的话可以串成流水线。

4. 常见问题与排查技巧实录

4.1 PDF 表格变乱，数据串位

这个属于高发问题。很多人转完 PDF 后，表格在 Markdown 里变成了一堆竖线加错位的文本。原因基本有两个：一是 PDF 里的表格本身没有严格的线条边界，是靠坐标对齐的，文字识别顺序和视觉顺序不一致；二是表格区域和正文区域没有被正确分离，正文文字混进了表格行里。

排查思路是先看转出来的一行有没有固定数量的分隔符，如果没有，说明单元格坐标对齐失败。我的解决办法是：针对表格这一块单独抽取，而不是走整体文字流。先检测页面的表格区域，再把区域内文字按"行"分组，同行内按 x 坐标排序，最后组装成 Markdown 表格。pdfplumber 的extract_table方法可以辅助，但遇到跨页表格要自己拼接列头。

4.2 OCR 识别率不稳定，关键数字经常错

OCR 在印刷体上准确率尚可，但遇到模糊复印件、手写批注、小字号数字、公章覆盖字迹这类情况，错误率会直线上升。尤其是数字，"0"和"O"、"1"和"l"、"8"和"3"经常混淆。

我的应对方案是：首先在预处理阶段尽量提升图像质量，比如二值化、去噪、放大两倍后再做 OCR。其次给 OCR 引擎加上领域字典和版式约束，比如日期、金额、编号这些字段用正则约束候选字符集。最后，也是最重要的一条：转换结果必须人工抽检。别指望 OCR 一次做对，在做知识库或合同问答之前，至少抽查 20% 的页面，重点看数字、表格、金额这些高敏感内容。抽检发现错误率超过可接受范围，就得考虑换更强的模型或人工修正流程。

4.3 Excel 多 Sheet 合并后 AI 越读越乱

我之前遇到一个场景，一个工作簿里包含四个 Sheet：基础信息、明细流水、汇总报表、指标说明。如果全部拼成一个 Markdown 大表，AI 根本分不清哪些是明细哪些是汇总，问出来的答案往往让人哭笑不得。

正确做法是先把每个 Sheet 抽成独立小节，在 Markdown 里给清晰的二级标题和表头说明。另外建议在每个表前面加一句概括性注释，描述这个表是什么、统计粒度是什么。这对 AI 理解表格语义有非常大的帮助。我还习惯在每个 Sheet 的第一行注明数据来源和时间范围，这些上下文信息对 AI 回答正确性影响极大。

4.4 转换结果的长度暴增和信息丢失同时出现

这个现象很怪，但确实同时存在：某些扫描件转出来的 Markdown 动辄几十 KB，里面有大量 OCR 错误碎片、重复的页眉、无意义的空行；而真正的表格关系和逻辑结构却丢了。这说明版面分析和结构化提取没有做好。

遇到这种情况，我一般先跑内容清洗脚本，删除页眉页脚、页码、异常短行、重复的纯空白行，然后把连续的空行压缩为单个空行。清洗逻辑要小心，别把有意义的短文本（比如表格里的单位、序数词）也删掉了。清洗完之后再做人工目检一次，确认没有大块信息丢失。

5. 转换后的内容清洗与 AI 输入优化

转完 Markdown 不等于可以直接投喂给 AI，中间还差一道"质检和优化"工序。我推荐按下面几步走，能明显提升后续问答效果。

首先，清理转义噪音。很多转换工具会在正文里塞入大量转义符号，比如\#、\\、不必要的硬换行。这些符号看着小，但在 AI 阅读时会干扰语义颗粒度。可以用脚本统一做一次正则清理，把多余的空格、硬换行、制表符整理干净。

其次，补充结构化元信息。我习惯在转换好的 Markdown 最顶部加一个> 来源：xxx文件，共X页，生成日期：xxxx-xx-xx的引用块。别小看这几行，它让 AI 知道当前的文本来自什么性质的文档，在回答时会多一分谨慎，尤其是涉及时效性、来源可靠性判断时非常有用。

再次，给复杂内容加"导读说明"。特别长的表格、图表密集的段落，我建议在内容前加一句自然语言的导读，比如：

> 下表为 2024 年度各季度营收明细，统计口径为含税收入，单位：万元。

AI 结合导读再看表格，理解偏差会明显减少。原理其实很简单，导读把"表格外"的语义讲清楚了，AI 就不用猜。

最后，控制单次投喂的长度。如果一份文档转出来超过 20 万字符，别想着一次性塞进上下文。按章节拆分成多个片段，一个一个问，或者分批检索后投喂。这比一次性全量丢给 AI 稳定得多，token 成本也低得多。

6. 一点补充：解析失败的兜底策略

即使流程做得很完整，也总有解析失败的文件。我现在的兜底策略是：转换失败或质量过低的文档，保留原文件，单独打标签，不混入正常转换结果。处理知识库检索时，先用 Markdown 做召回，如果召回不到，再用原始文件让支持的解析引擎做单独处理。这个混合策略比一条路走到黑可靠得多。

我个人的体会是，文档预处理这件事，表面上是格式转换，本质上是在给 AI 营造一个"可读性好、噪音低、结构清晰"的输入环境。花在清洗和质检上的时间，最后都会以输出质量的形式赚回来。把这套流程做成半自动脚本之后，我处理文档的速度从最初的一份折腾半小时，降到现在一百份文件批量跑完加抽检一轮控制在十几分钟。这套流程我现在已经固化下来，后续如果遇到新的文件类型，把对应的解析模块挂到流水线上就行。