企业官网建设流程全解析

上周有个朋友发我一份40多页的PDF，问为什么AI读完以后总是答非所问。我问他是怎么喂给AI的，他说：直接拖进去啊。我说问题就出在这里。一个月前我自己也是直接拖，后来做了几组对比测试才发现，把文件先转成Markdown再丢给AI，不仅回答准确率高得多，token消耗也明显下降。这篇文章就把我的处理流程、踩过的坑和实测数据一次说清楚，想提高文档问答质量的朋友可以直接照着抄。

先说结论：我不是让你在每次提问前都手动折腾一遍转换，而是建议你养成一个固定习惯——凡是超过几页的文档，先转成结构清晰的Markdown，再进入AI的工作流。下面从原理讲到实操，再给你看一组我自己的对比数据。

1. 直接丢文件给AI的三大隐藏成本

1.1 你的文件在模型眼里不是“整齐的文档”

很多人以为把PDF、DOCX直接拖给AI，模型就能看到和你屏幕上一样的排版。实际上不是。模型读取这些文件时，走的是程序化解析路线：PDF要经过文本抽取，DOCX要经过文档结构解包，PPT则要把每个文本框拆出来。这个过程中，文件里的视觉信息——字号大小、加粗、缩进、分栏、页边距——几乎全部被丢弃，只剩下一串按物理位置排列的字符流。

麻烦就出在这里。PDF的文本抽取是按“页面对象”顺序来的，不是按“阅读顺序”来的。一个双栏排版的PDF，抽取结果经常是先读完左边栏再到右边栏，甚至一段话被腰斩成几截散落在不同位置。而扫描版的PDF更夸张，模型拿到的根本不是文字，而是图片，很多AI助手会启动视觉识别那一套流程，token消耗直接翻倍。

我自己试过一份双栏排版的行业报告，直接丢PDF给AI，让它总结第一章内容，结果模型把第二栏的内容混了进来，因为文本流顺序乱掉了。这不是模型笨，是喂进去的数据本身就是乱的。

1.2 结构信息在纯文本流里全部丢失

还有一个容易被忽略的点：文档的“结构”才是真正有价值的信息。文章里有章节标题、有小标题、有列表、有表格、有代码块，这些结构在读者眼里是导航，在模型眼里是推理的骨架。当你直接把一个PDF丢给AI时，这些结构绝大部分会被压平成纯文本。

举个例子。原文档里有一个三列的表格，列标题分别是“参数”“默认值”“说明”。PDF抽取文本后，表格里每一行的内容会被拆成一连串独立文本片段，列与列之间本来靠坐标对齐的关系消失了。AI拿到之后根本分不清哪个数据对应哪一列，回答时就只能猜。我实测过好几次，直接喂PDF问“这个表中的默认值是多少”，模型经常把“说明”栏的文字当成参数值。

Markdown就不一样。表格在Markdown里有明确的语法标记，竖线和表头定义了完整结构，AI不需要靠坐标去“脑补”对齐关系，直接就能读出“这是一个表，有三列，每行对应哪些值”。这种差异不是某个模型的问题，是所有纯文本解析方式的通病。

1.3 上下文窗口被噪音和重复内容吃掉了

第三个隐藏成本是token。现在的大模型都有上下文窗口限制，窗口里的空间是有限的。你丢进去一份40页的PDF，里面每页都重复出现的页眉页脚、页码、目录里的密集圆点、分页符残留、莫名其妙的空行，全都在消耗token。

我自己测试时记录过一组数字：某份40页的技术文档，直接解析出来的原始文本大约有25000个字符，其中页眉页脚和分页残留至少占掉两成，而真正有用的正文大概只有八成。这两成噪音不仅浪费token，还会干扰模型的注意力。模型得先“识别”出这些东西是噪音，然后才能聚焦正文，识别过程中就可能出错。

更麻烦的是上下文耗尽问题。文档太长时，AI会自己截断或压缩前文。如果你在一个会话里同时读了好几份PDF，后面的内容很容易被挤出窗口，模型回答时只看到了前面的内容，后面的关键信息一概不知，回答自然不完整。

2. 转成Markdown，本质是给AI画了一张“结构地图”

2.1 一个井号和一个表格符号意味着什么

Markdown的语法极简，但信息密度极高。一个#号告诉AI“下面是一个一级标题”，一个|组成的表格告诉AI“这里有完整行列结构”，三个反引号告诉AI“下面是代码块，不要当普通文字解读”。这些标记对模型来说是极强的先验知识，它不用再从字符流里反推结构，省下的推理成本会直接体现在回答质量上。

我习惯把这个过程叫作“给AI画结构地图”。你直接丢PDF，等于把一座城市航拍图丢给AI，让它自己找路；你转成Markdown，等于先给AI标好了主干道和地标，它只需要沿着地图走。

2.2 Token消耗的直观对比

很多人担心转Markdown会增加token，因为Markdown带了一堆符号。这个担心其实多虑了。Markdown符号本身确实占token，但它省掉了更多不必要的东西。

我用同一份文档做过Token消耗对比，结果如下：

可以看到，转Markdown的token消耗比直接丢PDF低不少，比纯文本也只多一点点，但结构信息完整得多。这点多出来的代价，换来的是准确率的明显提升，非常划算。

2.3 对RAG分块和检索的额外红利

如果你的场景不是一次性问答，而是做知识库检索（也就是常说的RAG），Markdown的价值会更大。做RAG时要把文档切块，普通做法是按固定字数硬切，比如每500字切一块。这种切法经常把一句话、一个表格拦腰截断，检索时找不到完整信息。

Markdown天然把文档组织成了标题层级，你可以按标题去切块，每一块就是一个完整的章节或小节。检索时命中一个片段，往往就是一段逻辑完整的话，模型拿到的上下文质量高很多。我在自己的知识库项目里验证过，用Markdown标题切块后，检索命中率和回答完整度都明显好于固定长度切块。

2.4 模型输出质量的变化：从“猜”到“查”

直接丢PDF时，AI面对杂乱文本流，很多回答其实是“猜”出来的。它猜对了段落重组方式，答案就靠谱；猜错了，就张冠李戴。转了Markdown之后，AI能从清晰的层级关系里确定“这段是结论”“那段是背景”，引用时也更准确。我发现喂Markdown后，模型在回答里能明确给出“根据第3章第2节的说明……”这类引用，这在之前直接喂PDF时很少出现。

3. 扫描件、复杂表格和公式：三类最容易翻车的输入

3.1 扫描件：OCR的错字会一路污染到回答

扫描版PDF本质是图片，必须先经过OCR（光学字符识别）才能变成文字。OCR的字准确率通常在95%到99%之间，听起来很高，但一页400字的文档错5%就是20个错字，40页文档累积下来就是几百个错字。

关键是，这些错字是“合理”的错误。比如“耐压值”被识别成“耐压植”，模型读到时并不会觉得异常，它会一本正经地沿用这个错误术语去推理。如果错的是数字，比如“12.5A”被识别成“12.6A”，后续所有计算和结论都会跟着错。数字型的OCR错误是问答场景里最危险的，因为模型没有外部校验手段，只能信你给的内容。

所以扫描件必须先单独处理，我一般先做OCR，检查一遍关键数字后再转Markdown，绝不把原始扫描件直接丢给模型。

3.2 复杂表格：结构错位比丢字更致命

表格是所有文件类型里最容易在转换中翻车的内容。特别是跨页长表格、带合并单元格的表格、表头重复出现的表格，在PDF抽取时几乎必然出问题。表头和数据行错位、单元格内容互相串行、列数不一致，转出来的Markdown表格七零八落。

我的经验是，转换完成后不要只看开头，专门找2到3个关键表格检查。看表头是否对齐、列数是否一致、合并单元格是否被凑成了占位符。如果表格太复杂，我会考虑把表格单独截图，在提问时把图也一起喂给AI，让多模态能力来兜底，文本用Markdown，图用原图，两者互补。

3.3 数学公式：既要专门工具，也要接受取舍

公式是另一个重灾区。PDF里的公式，一种情况是以图片形式嵌入，一种是用特殊字体渲染，还有的是文本框叠加。普通文本抽取会把公式变成乱码，比如积分符号变成一串奇怪的ASCII，转成Markdown之后依然是一堆乱码。

处理公式多的文档，我建议选择那些专门做过公式识别优化的转换工具，它们至少能把公式转成可读的LaTeX语法。LaTeX本身不是Markdown，但Markdown的代码块可以包裹它，AI看到$...$或$$...$$就能识别公式语义。如果工具实在转不好，备选方案是把公式截图，用![公式1](assets/formula1.png)的形式插到Markdown里，让AI用视觉能力去读。

3.4 双栏排版：文本流的顺序陷阱

双栏排版的学术论文、杂志、行业报告，文本抽取时顺序最容易乱。模型从左上角开始读取，但PDF对象存储的顺序未必是阅读顺序，经常出现先读完左栏再读右栏、或者一段话被分到两栏各自后面。转换成Markdown时，一定要选开启“按阅读顺序重排”功能的工具，转换后再抽查两三段，确认段落顺序正确。

4. 从原始文件到Markdown：我的处理流程和自查清单

4.1 文字版PDF：优先选带版面还原能力的工具

遇到文字版的PDF，我一般优先找那些专门做“版面还原”的开源解析工具。这类工具通常有两大核心能力：一是把PDF页面重新排列成阅读顺序，二是把识别到的表格、标题、列表转成对应的Markdown结构。我选工具只看三个点：表格支持是否到位、页眉页脚能否自动滤除、双栏排版是否处理正确。

至于那些只能把PDF转成“一堆带换行的纯文本”的简单工具，我基本不用。它们只能去噪，不能重建结构，转出来的Markdown只有标题和段落，表格还是乱的，没有实际意义。

4.2 扫描版PDF：先OCR还是直接转

扫描件我的流程是先做OCR，输出带位置信息的文本，再交给版面还原工具转成Markdown。OCR时要注意几个参数：语言模型要选对，中文文档不要选“自动”，直接指定简体中文，避免简繁混排导致的误识别；DPI建议300起步，低于200时识别率下降明显；开启动态阈值处理，可以减轻纸张底色不均带来的噪声。

OCR完成后，我会先扫一眼那些包含型号、数字、产地、日期的区域，和原图对照一下，确认无误再往下走。这一步看起来多此一举，实际上能省去后面反复纠错的成本。

4.3 DOCX、PPTX和网页：三种常见来源的处理差异

DOCX本身是带结构的XML格式，转换Markdown相对干净，用通用文档转换命令行工具一条命令就能搞定，标题层级、列表、粗斜体基本都能保留。需要注意的只有一件事：转换成Markdown后再确认一遍标题层级，有些工具会把Word里的“标题1、标题2”样式映射成“#、##”，如果样式用得乱，映射也会乱。

PPTX转Markdown时有个特殊点：演讲者备注的内容也会被提取出来。如果你的PPT里备注写得很详细，这些备注对理解课件逻辑反而很有帮助。我在处理某次培训课件时，备注内容甚至比页面正文还有价值，因为它们解释了每个页面的设计意图。

网页转Markdown我一般走“网页正文提取”这个方向，而不是复制粘贴整个页面。直接复制网页内容会带上导航栏、侧边栏、广告、页脚版权信息，这些噪音对AI同样有干扰。用浏览器阅读模式把正文提干净，再转成Markdown，才是想要的输入。

4.4 转换完成后的十秒自查清单

每次转完Markdown，我会花十秒快速检查几个关键点，不检查就直接喂AI，迟早会踩坑：

• 标题层级是否合理？有没有所有文字都变成一级标题的情况？
• 目录和页眉页脚是否被清除干净？
• 表格的表头是否对齐、行列是否完整？
• 代码块有没有被截断？
• 公式有没有变成乱码？
• 扫描件里的关键数字是否和原文档一致？

这六项检查用眼睛扫一遍最多十几秒，但能避免绝大多数“AI答非所问”的问题。把检查当成习惯之后，你会发现AI回答的稳定性高了一个台阶。

5. 实测对比：同一份40页文档，三种喂法的差距有多大

5.1 实验设置：文档选择与提问设计

为了验证“转Markdown再喂”到底有多大价值，我做了一个相对可控的测试。测试文档是一份40页的设备操作手册，来源是某客户提供的扫描后OCR版本，里面包含双栏排版、三张复杂参数表格、若干公式、十几处数字参数。我向同一个AI助手的同一个会话实例提问，温度调成0，连续问了10个同一类型的问题，只改变喂给它的文件处理方式。

三条路径分别是：路径A直接把PDF文件拖给AI，不做任何预处理；路径B先用普通文本抽取工具把PDF转成纯文本，再喂；路径C先转成Markdown，并人工修正了一次表格错位，再喂。

5.2 准确率：转Markdown后提高了两成

10个问题里，路径A答对了7个，路径B答对了7个，路径C答对了9个。路径A和路径B的准确率几乎一样，但错的题目不同。路径A错在双栏文本顺序混乱导致张冠李戴；路径B错在表格结构丢失导致参数对应错误。

路径C唯一错的那道题，是因为手册里一个公式转成LaTeX后仍有一点残缺，AI按残缺公式推理出了偏差。这个结果说明，纯文本抽取只能去噪，对结构还原没有帮助；真正改变结论的是Markdown带来的结构信息。

5.3 Token与上下文占用：省下来的都进入了“有效阅读区”

同一份文档，路径A在会话里占用了大约2.4万token，路径B约1.4万，路径C约1.6万。路径A多出来的那1万token，大部分被页眉页脚、页码、目录页残留和视觉识别流程吃掉了。路径C比路径B多约2000 token，换来的是完整标题层级和可读表格。

在上下文窗口有限的前提下，这1万token的差距意味着后面的内容能不能被看到。我看过很多次这样的情况：同一份文档，直接丢PDF时问后面的章节，AI回答“找不到相关信息”；换成Markdown后，同一个问题能回答得清清楚楚，因为内容没有被挤出去。

5.4 边界情况：双栏、扫描书、PPT生成的PDF

测试后我又补了几组边界情况。双栏排版论文，直接丢PDF时第一章总结就出错，转Markdown重排后正常。扫描版旧书，OCR后数字错误率偏高，转Markdown救不回来，只能靠人工校对关键数据。PPT转PDF再转Markdown，效果反而很好，因为PPT每页文字逻辑相对独立，标题结构清晰，转换后几乎不用修正。

6. 哪些情况不必转Markdown？

6.1 单张图片和多模态场景

如果你手里是一张产品图、一页图表或者一个数据可视化截图，想直接问AI“这是什么”“帮我描述一下”，那就没必要转Markdown，直接丢图给多模态模型反而最快。多模态模型看图的能力已经足够好，硬要把图片转成Markdown文字，反而丢失了视觉信息。

6.2 已经结构化的源文件

如果你手里本来就是一份漂亮的Markdown或者HTML文件，直接喂就好，不需要任何转换。HTML转Markdown也只需要一条命令，但如果你已经在用支持直接读HTML的AI工具，跳过转换也可以。这里的原则是：已经结构化清晰的内容，不要再加工一遍，加工只会引入新错误。

6.3 超短文本和纯文本

一两页的纯文本说明、几百字的摘要，直接复制粘贴就行，不需要转任何格式。结构化的收益主要体现在长文档和复杂结构文档上，短文本的收益可以忽略不计。

6.4 转换工具的局限与我的最终建议

需要承认，目前没有任何转换工具是完美的。复杂表格总有错位风险，公式总有个别漏网，合并单元格偶尔丢内容。正因如此，我把转换Markdown看成“大幅提高准确率的手段”，而不是“一次到位的神器”。喂给AI之前瞄一眼关键部位，是成本最低的防错手段。

我现在的工作流已经固定下来：收到一份文档，先判断类型——文字版PDF/docx/pptx/网页走转换工具，扫描件先OCR再转换，公式多就选带公式还原的工具；转换后十秒自查；最后再和文档一起喂给AI。整个过程比直接丢文件多花两三分钟，但换来的是回答质量的全面提升。

最后再分享一个小技巧。如果你经常要处理同一类文档，完全可以写一个简单的批处理脚本，把“转Markdown”做成双击即用的固定操作，每次拿到文件丢进去，自动输出一个干净的Markdown文件。我现在的习惯是新建一个docs_md目录，所有要喂给AI的文档统一放进去，文件名和原始文件一一对应，找起来方便，AI回答时引用也更准确。