企业官网建设流程全解析

最近在做一个知识库类项目时，发现一个特别有意思的现象：同样的 PDF 喂给大模型，直接拖文件进去的效果，和先转成 Markdown 再投喂的效果，差距不是一点半点。前者经常出现答非所问、抓不住重点的情况，后者则能稳定给出结构清晰、定位准确的回答。

后来我认真复盘了一下，问题根源不在模型本身，而在输入数据的形态。这也是我写这篇博文的动机：如果你是经常跟大模型打交道的人，或者正在搭 RAG 知识库、做文档自动化处理的，建议你认真看完——把文件转成 Markdown 再交给 AI，这个习惯一旦养成，你会发现模型的输出质量能稳定提升一个档次，而且 token 消耗还能降下来。

1. 为什么把文件直接丢给 AI 是个坏习惯

很多人的使用习惯是：拿到一个 PDF 或者 Word，直接拖到大模型对话框里，然后开始提问。表面上模型好像“读”懂了，实际上它是在用极其低效的方式在处理你的文档。这背后有三个核心问题。

1.1 token 浪费比你想的严重

先算一笔账。一个 20 页的 PDF，假设每页 500 字，全文大约 1 万汉字。直接投喂 PDF 时，模型不仅要处理文字本身，还要解析 PDF 内部复杂的编码结构、字体信息、排版指令，这些字节都会占用上下文窗口。你感觉只是丢了一个文件进去，实际上塞进去的信息里掺了大量“杂质”。

这里有个粗略估算公式：1 个汉字大约等于 1~2 个 token，一篇 1 万字的文档至少要吃 1.5 万到 2 万 token。如果你用的是上下文窗口较小的模型，这部分开销直接挤压了有效问答空间。更麻烦的是图片型 PDF——扫描件或者带大量截图的文档，每张图片进入模型都要按视觉 token 计费，一张高清图可能相当于几百甚至上千个文本 token。有些人在不知情的情况下把整本扫描书喂给模型，一次对话烧掉几十万 token，结果答案质量还很差。

转成 Markdown 之后，纯文本内容以最精简的形态呈现，token 消耗能压缩相当可观的比例。同一个 PDF，转出来后如果是 1.2 万字符，那么 token 数大概在 6k~9k 之间，比直接投喂省了至少三分之一。

1.2 排版信息在流转中全丢了

PDF 格式有一个根本性问题：它本质上是一份“打印描述”，描述的是字符出现在页面哪个位置，而不是文档的结构。同样一段文字，PDF 里记录的可能是几十个绘制指令，而不是一个完整的段落元素。

Word 的 docx 结构上其实比 PDF 好，它内部是 XML 语法树，标题、段落、表格都有明确标签。但问题在于，当你把 docx 直接拖给模型时，很多模型对二进制格式的解析能力并不稳定。实测下来，同一个 docx 文件在不同模型手里的解析结果差异很大，有的能识别标题层级，有的干脆把整份文档当成一大坨连续文本处理。

HTML 网页的问题更明显——页面上有导航栏、侧边栏、广告位、页脚信息，这些噪声和正文混在一起。模型面对这种输入时，经常被无关信息干扰，提取出来的答案也容易跑偏。

Markdown 是结构最干净的中间格式之一。标题就是#、##、###，列表就是-或者1.，表格就是管道符和短横线。这些标记符把文档的逻辑结构直接展示给模型，相当于你提前帮模型做了一遍“阅读理解”，它不需要再从混乱的排版中自己摸索结构。

1.3 看不见的上下文污染最要命

我在实际项目中踩过一个大坑：把一篇双栏排版的学术 PDF 直接丢给模型，让它提取核心结论。结果模型输出的内容里出现了大量莫名其妙的“文本串行”——两个栏目的文字被横向拼在了一起，一句话读到一半突然跳到了另一栏的句子。

这就是 PDF 解析过程中的“文本流乱序”问题。PDF 里文字的物理位置和逻辑阅读顺序并不总是一致，双栏页面的阅读顺序是从左栏顶部到底部、再从右栏顶部到底部，但底层字符流往往是按某种内部顺序排列的，模型在读这个流的时候根本分不清该按什么顺序重组。

更隐蔽的污染源还有页眉页脚。很多 PDF 每一页顶部都有重复出现的标题或者章节名，这些内容在解析时会被当成正文的一部分反复出现。模型看到“某某系统使用手册”在上下文里出现二十多次，有可能会误判这是重点信息，然后围绕它做文章，完全偏离你的真实问题。

转成 Markdown 的过程，其实就是一次人工介入的文档净化。你可以顺手把页眉页脚删掉，把双栏结构修正为线性阅读顺序，把多余的重复信息清干净。这一步做得好不好，直接决定后面模型输出的准确率上限。

2. Markdown 到底好在哪

讲完了直接投喂的坏处，再来正面拆解为什么 Markdown 是当前最适合喂给大模型的文本格式。这不是偶然，而是由它的三个底层特性决定的。

2.1 一个文档只用几种符号

Markdown 的语法集小到可以用一页纸讲完：井号代表标题层级，短横线代表列表，管道符代表表格，反引号代表代码。这恰恰是它最大的优势——信息密度极高，每一字节都在表达语义。

对比一下 HTML：表达一个二级标题需要<h2>标题内容</h2>，算上标签符号一共 20 多个字符，而 Markdown 只需要## 标题内容，6 个字符就够了。三倍以上的压缩率。在 LLM 的上下文窗口里，字符越少意味着有效信息的占比越高，模型在推理时受到的干扰也越少。

而且这些符号的含义是跨平台一致的。##在任何解析器里都代表二级标题，不会出现像 PDF 那样“同一个文档在不同解析器里层层拆解结果不一样”的情况。你在某款工具里写的 Markdown，换一个工具读，语义完全不会丢。

2.2 给 AI 的“电梯简报”

想象一下你要在电梯里用 30 秒向老板汇报项目的核心内容，你会怎么讲？你肯定会先说结论，再讲依据，然后列关键数据。Markdown 本质上就是这个逻辑——它的标题层级天然构造了“结论先行”的信息结构：#是最高层级的论点，##是分论点，###是支撑论据，列表是细节。

这种结构与 LLM 的注意力机制高度契合。模型在预测下一个 token 时，会不断参考上下文里的关键位置信息。标题行因为以#开局，形态上非常显眼，模型能快速定位到你问题的相关内容区域。我在测试中发现，把一份调研报告的 Markdown 版喂给模型，它定位到对应章节并组织答案的准确率，明显高于投喂纯文本版——因为纯文本里章节标题和正文之间没有任何区分度。

表格在 Markdown 里也有天然优势。| 项目 | 数值 |这种固定格式，模型很容易识别出每行是一条记录、每列是一个字段。很多模型对 Markdown 表格的理解能力强到可以直接做聚合计算，比如我让它从一张 50 行的 Markdown 表格里统计某个分类的总和，它给出的结果基本零误差。

2.3 能直接进知识库的格式

现在做 RAG（检索增强生成）架构的人越来越多，知识库里存的文档切片质量，直接决定检索效果。Markdown 在这个环节的优势更加明显。

向量化嵌入时，Markdown 文本切出的 chunk 天然带结构边界。你可以按##标题切块，每个 chunk 就是一个逻辑完整的章节，而不是像纯文本那样硬按字符长度切，切出来的内容支离破碎，检索时还经常匹配到驴唇不对马嘴的片段。很多向量数据库和知识库工具已经原生支持 Markdown 解析，切片时能自动保留标题层级作为 chunk 的元数据。

这意味着你后面做召回时，可以借助标题层级做更精准的过滤。比如用户问题涉及“部署环境配置”，你可以直接把## 环境配置这个标题下的内容作为高优先级检索范围，而不是在全库范围内做模糊匹配。这种结构化检索的精准度，是纯文本方案很难达到的。

3. 常见文件格式怎么转成 Markdown

明确了目标，接下来是实操环节。不同来源的文件有不同的转换路径，选对工具能少踩很多坑。我按 PDF、Word、网页和其他特殊场景分别展开，每一步都是实测验证过的，你可以直接照着做。

3.1 PDF：先分清电子版还是扫描版

PDF 分两大类，处理方式完全不同。第一类是电子版 PDF，也就是通过 Word、LaTeX、排版软件直接导出的文件，里面的文字是真实存在的文本层，可以直接提取。第二类是扫描版 PDF，本质上是图片集合，每页是一张照片或者扫描图，需要 OCR 识别才能出文字。

如何快速判断？用鼠标在 PDF 里拖选一段文字，能选中的就是电子版，选不动的就是扫描版。这一步很基础但是关键，因为很多人拿扫描件直接去跑文本提取工具，折腾半天出来的全是乱码。

对于电子版 PDF，我目前的推荐方案是分场景选择工具：

• 简单场景：纯文字排版、无复杂表格、单栏结构，直接用pdftotext或者pymupdf，速度快，输出干净。这类文本本身结构就相对线性，转换后基本就是标准 Markdown 雏形，稍微补一下标题符号就能直接用。
• 复杂场景：多栏排版、含表格、含公式、有页眉页脚，推荐用基于端到端深度学习模型的转换工具，比如marker或者minerU。这类工具有版面分析能力，能自动识别标题区域、表格区域、正文区域，并按阅读顺序重组内容，输出质量远超传统 PDF 解析库。

我用一个实际测试来说明差距：一份双栏排版的技术白皮书，直接pdftotext提取出来的文本是两栏内容交错的状态，完全没法读；用minerU转出来之后，标题层级清晰、正文顺序正确、表格也还原成了 Markdown 表格，基本等于人工整理过的效果。

扫描版 PDF 的路径是 OCR。小规模场景用tesseract就够，中文识别精度尚可；如果文档量大、精度要求高，建议用PaddleOCR，对中英文混排、表格结构的还原能力都更强。OCR 出的结果一般是自身带空格的纯文本，需要再手动补标题层级符号——这一步没有全自动的完美方案，因为扫描件的标题和正文排版千差万别，机器确实没法判断哪个是标题哪个是正文。

3.2 Word 和网页：转换工具对比

Word 文档转 Markdown 最简单，pandoc一行命令搞定，前提是你的 Word 文档用了规范的内置标题样式。如果你的文档是拿不同字号手动调的“伪标题”，pandoc 无法识别成标题，输出就全是平铺的段落文本。这种情况下，我建议先把文档里的标题统一改成 Word 内置的“标题 1”“标题 2”样式，再跑转换，一级标题对应#，二级对应##，层层对应很清晰。

如果你不想动原文档，也可以用python-docx写个几十行的小脚本，遍历文档的段落样式来做针对性提取。这种方式的优点是可以自由控制输出——比如只提取正文、删除文本框、把特定的列表转成 Markdown 列表。缺点是脚本得维护，通用性不如 pandoc。

网页转 Markdown，核心目标是去噪。一个新闻页面里，真正有价值的正文可能只占全部 HTML 内容的 30%，其余都是导航、侧栏、推荐位、页脚。我用过比较顺手的是trafilatura，它能自动识别页面的正文区域，把标题、段落、列表抽取出来，输出基本是干净的 Markdown 结构。简单场景用readability-lxml配合html2text也可以，前一个负责提取正文主区域，后一个负责把 HTML 转成 Markdown。

这里分享一个个人偏好：抽取网页正文时，我一般会保留原文链接。因为 AI 在回答引用类问题时，如果能看到来源 URL，可以显著降低编造风险。你在转换脚本里顺手把 URL 拼到标题后面，成本几乎为零，收益却很实在。

3.3 表格、公式和图片的兜底方案

表格是文件转 Markdown 的重灾区。很多 PDF 里所谓的表格，实际上是各种文本框拼出来的视觉效果，没有真正的表格结构。转换后经常出现列错位、合并单元格丢失、表头行消失。

应对策略是分级处理：如果表格结构简单、行列规整，常规转换工具一般能还原成标准 Markdown 表格；如果表格有合并单元格、跨行列结构、嵌套内容，我建议放弃自动转换，直接把表格截图剪下来，单独喂给多模态模型识别，让模型按 Markdown 表格格式回归文本结构，然后再人工校一遍。这个方案在处理复杂表格时，效率反而比全自动转换高。

公式的处理也有讲究。Markdown 本身不直接支持公式，约定俗成的做法是转成 LaTeX 语法，用$包裹行内公式、$$包裹独立公式。大模型对这种格式的理解力普遍不错，转换工具minerU对公式的支持尤其好，能识别常见数学符号并输出 LaTeX 表达。如果目标文档是理工科教材或论文，建议选带公式识别能力的转换工具，避免公式变成乱字符流。

图片类内容走另一条路：不追求转成文字，保留图片并在 Markdown 里用相对路径引用。RAG 系统在检索到该 chunk 时，可以把图片路径作为附加信息一并返回，让大模型结合图片内容回答。这种方式在图文混排文档里很实用，既避免了 OCR 识别的信息损耗，又保留了视觉信息。

4. 实操流程：一次完整的转换投喂

前面讲了不少原理和工具，现在用一个完整的实操案例把这些串起来。假设手头有一份 40 页的产品技术文档 PDF，目标是让 AI 回答“部署配置有哪些步骤、依赖哪些环境变量”。下面是我实际跑过的工作流。

4.1 先说清需求再做转换

很多人拿到文档就会直接开始转，但我想强调：转换之前的“需求拆解”这一步，影响极大。你问的问题类型不同，转换策略也不同。

如果目标是摘要归纳，只需要提取全文标题和正文，不重要的图片可以丢弃；如果目标是精确问答（比如某个参数的值），必须保证表格内容完整无损；如果目标是做知识库长期存储，还要额外考虑分词、切块策略，以及是否保留原文件的页码映射。需求决定转换的精细度，先想清楚 AI 要帮你做什么，再决定文档怎么处理，这个顺序别搞反了。

在示例场景里，核心诉求是提取部署配置和步骤，那么转换时关注点就是：章节标题层级要准、列表步骤不能乱、参数表格必须完整。

4.2 分步操作实录

第一步：判断 PDF 类型。用鼠标拖选几处文字，能选中，确认是电子版 PDF，走文本提取路线。

第二步：跑版面分析工具。我用的是minerU的命令行模式，指定输入输出路径，它自动完成页面解析、结构识别、表格还原和公式转换。整个过程在本地 CPU 上耗时约 5 分钟，GPU 机器上大概 1 分钟不到。

mineru-cli -p input.pdf -o output_dir

第三步：检查输出文件。打开生成的 Markdown，重点检查三处：

• 标题层级是否准确对应原文结构；
• 表格每行列数是否一致；
• 步骤类列表是否保持了正确的先后顺序。

实测中我发现一个常见问题：原文的标题是用图片形式嵌入的，工具会把图片识别成普通图片而不是标题，导致这一章的标题层级丢失。遇到这种情况，直接手动在对应位置补一个##符号就行。

第四步：轻量清洗。这一步是很多人容易忽略的。我写了一个脚本，把页眉页脚文字、重复出现的公司名、连续空行统一清理掉。不要小看这一步，页眉页脚在整篇文档里可能出现几十次，不清洗干净，模型就会被这些高频重复信息带偏。

清理效果对比很直观：清洗前，模型生成的摘要里频繁出现文档版权信息；清洗后，摘要焦点全部落在技术内容上。

4.3 投喂方式与上下文管理

文档转好了，接下来的投喂方式同样有讲究。我见过不少人把 40 页转换后的 Markdown 一次性全部塞进上下文，然后问部署步骤——结果模型被过长的上下文拖累，速度变慢不说，答案还经常引入后面的内容，造成混淆。

更合理的做法是分块投喂：按二级标题切块，每次只喂相关章节。比如要问部署配置，先通过检索（或者人工定位）找到“部署配置”相关章节，只把这一段 Markdown 放入上下文，模型专注度会高很多，回答也更精准。

切块时我习惯用##作为分界符，因为二级标题一般对应完整的主题单元，切出来的 chunk 自带标题语义。chunk 之间不要重叠太多，控制在 200~500 行左右比较合适，既能保证信息完整，又不会超出模型的处理窗口。

还有一个技巧值得分享：在投喂时用一句话给模型“框定角色”——在 Markdown 内容前加一句“以下是产品文档的部署章节，请基于内容回答问题”。别小看这种定位语，实测下来，有这层定位和没有，模型回答的规范程度是有差别的。

5. 常见问题与排查笔记

这套工作流跑多了以后，我把高频问题整理成了一份排查表。你遇到类似情况时，可以按表里列的思路快速定位，省掉不少试错时间。

5.1 几条绕不开的经验

有几个问题不怎么起眼，但踩过坑之后影响很大，单独拿出来强调一下。

第一，工具的“版面分析”能力和“文本提取”能力要分开看。有些库文本提取很快，但版面分析能力很弱；有些工具版面识别很准，但提取速度偏慢。没有全能的工具，实际工作中我的做法是：速度快、结构简单的文档用轻量方案；结构复杂、对准确率要求高的文档用重方案，哪怕多花几分钟转换也是值得的。

第二，清洗这一步永远不要省。很多人在转换后就直接投喂，觉得“转换过了就干净了”。实际上转换只是把格式从二进制变成了文本，并不等于内容变干净。页眉、页脚、水印、重复出现的公司版权信息、脚注编号，这些噪声仍然存在。我在长期实践中养成了固定习惯：每份文档转换后至少跑一遍轻量清洗脚本，删除重复的和无关的高频文本块，这个动作大概花十几秒，但换来的是模型回答质量的明显提升。

第三，不要对 OCR 的能力产生不切实际的期望。扫描件的识别结果，在手写体、艺术字体、复杂排版面前依然不可靠。如果你想长期做文档投喂，但手头有大量扫描件，我的建议是优先考虑找到原始电子文件，或者人工录入关键信息，而不是指望 OCR 完全替代人工。

6. 我的投喂习惯沉淀

现在我的工作流已经固定下来了：凡是需要进入大模型处理流程的文档，九成以上会先过一遍 Markdown 转换和清洗。这套流程不仅帮我稳定了模型输出的质量，还让 token 开销更可控，知识库检索更精准。

最后再分享一个实用的小技巧：把转换和清洗流程做成一个固定脚本放在本地，遇到新文档就跑一遍，输出一个干净的 Markdown 文件。文件命名建议保留原文名称和版本号，方便后续追溯。存储时我会按“原始文件/转换后文件/清洗后文件”三类分开管理，这样即使后续发现转换有问题也能回溯到上一步，不需要重新跑整套流程。

如果你还在用“直接拖文件进对话框”的老办法，建议你下一份文档就试试先转成 Markdown 再投喂。这个动作不会花你超过五分钟，但对后续问答质量的提升是立竿见影的。