企业官网建设流程全解析

上周我处理一份行业研报，PDF 大概九十多页，图省事直接把文件拖进了某个大模型对话框。结果它思考了将近一分钟，最后把第三章的结论安到了第五章的案例上。换成 Markdown 版本之后，同样的问题十分钟内就完成了分析，而且关键数据没有再出错。

这个对比特别直观：PDF、Word、网页这类格式是给人看的，Markdown 是给 AI 读的。别再把原始文件随手丢给 AI，先转成 Markdown 再喂进去，往往又快又准，还省 token。

这篇文章会把背后的原因讲透，并给出不同文件的转换流程、清洗方法、切块策略和排查记录。适合这几类人看：经常让 AI 做文档摘要和问答的办公族，维护本地知识库的开发者，以及研究长文档分析的提示词工程师。

1. 为什么 AI 读原始文件总在翻车

1.1 token 视角下，AI 并不是真的“看见”了文件

先捋一个很多人忽略的事实：大语言模型的输入层不是文件，而是 token。所谓“让 AI 读 PDF”，本质上是模型服务方先把 PDF 解析成文本，再把文本切成 token，然后送入模型。

这个解析过程由黑盒管道完成，我们看不到中间产物，也无法修补出错的地方。PDF 里的表格错位、扫描件里的错字、网页里的广告导航，这些噪声会被原封不动地转成 token 喂给模型。模型要把这些噪声当成有效信息去推理，准确率自然会掉。

我做过一个简单的对照测试：同一份资料，一份直接从 PDF 导出的文本，一份清洗后的标准 Markdown。两者字数差不多，但前者的 token 消耗比后者多了将近三成。多出来的部分就是空格、孤立换行、制表符和无意义标点。转换这一动作，同时解决了准确率和成本两个问题。

类比一下：你要让一个速记员帮你整理会议纪要，你不给他一份带批注、修订痕迹的草稿，而是给他一份干净的结构化笔记，他做出来的东西当然更接近你想要的结果。

1.2 PDF 的三大坑：坐标画布、乱序文本流、无文本层

PDF 的排版逻辑更像海报设计软件：文字的位置是一个个坐标，格式强调的是“印出来什么样”，而不是“读起来什么顺序”。AI 从 PDF 提取文本时，按文件内部的指令顺序去拼句子，很容易把页眉、页脚、图注、正文全部混在一起。

第二个坑是多栏和表格。研究报告常用双栏排版，PDF 的文本流可能先读满左栏再读右栏，也可能按某种内部对象顺序交错跳动。AI 拿到的文本顺序和人的阅读顺序不一致，分析结果自然对不上。

第三个坑最隐蔽：扫描版 PDF 根本没有文本层，本质就是几张图片。AI 只能靠 OCR 去“认字”。OCR 对清晰印刷体还行，一旦遇到公式、浅色字体、特殊符号，错字率会明显上升。最可怕的是数字错——把“2.8%”识别成“2.3%”，后面所有结论都建立在错误数据上。

1.3 Word 和网页也有一堆隐形噪音

Word 的 docx 格式其实是压缩包，里面有大量的 XML 描述样式、批注、修订记录。某些转换器会把批注、修订里的旧内容一起输出，结果正文里穿插着七八种颜色标注的历史版本，AI 根本分不清哪句是最终稿。

网页的问题在于信息噪音。导航栏、推荐阅读、广告模块、Cookie 弹窗，这些元素的文本量常常比正文还大。如果不对 HTML 做清洗，AI 得到的是一锅大杂烩：正文还能识别，但搜索引擎的推荐烂文也一起进去了，严重干扰判断。

所以问题的根源很清楚：原始格式是给人设计的视觉产物，不是给模型设计的语义产物。AI 当然也能强行解析，但代价是速度慢、token 高、错误多。与其让它在最差的地基上盖楼，不如我们自己先把地基夯实。

2. Markdown 到底赢在哪里

2.1 纯文本是模型最舒服的信息组织方式

Markdown 最核心的优势是纯文本。它没有隐藏的样式标签、没有二进制结构、没有坐标信息。模型只用面对最干净的字符串，tokenizer 的负担也小很多。

而且 Markdown 的结构符号是“所见即所得”的语义标记。#代表一级标题，|代表表格单元格，```代表代码块，>代表引用。这些符号只多花几个 token，却给模型提供了极其明确的阅读理解路标。

比如同样一句话：“前三季度营收增长 12%。”在 PDF 里，它可能被拆成“前三季”“度营收”“增长”“12%”分布在不同的文本流位置。在 Markdown 里，它就是一个完整句子，前后还有标题指明这是“财务摘要”章节。模型理解后者几乎不费力气。

2.2 Markdown 和 AI 的训练语料天然同频

还有一个很多人忽略的因素：大模型的训练语料里有海量的 Markdown 文档。开源代码仓库的 README、技术博客、知识库文件，几乎都用 Markdown 组织。模型在预训练阶段已经看过无数这种结构，它非常清楚# 标题后面通常跟着什么内容，| 表格 |应该如何解析。

换句话说，你拿 Markdown 跟它交流，用的是它的“母语”；你拿 PDF 跟它交流，相当于让它翻译一门结构混乱的外语。同样是总结文档，Markdown 输入的指令遵循成本更低，模型能把更多推理能力用在真正的问题分析上，而不是费力识别格式。

2.3 Markdown 天然适配知识库的切片需求

如果你在维护一个知识库或做检索增强生成，Markdown 的优势会被放得更大。目前主流的分块方法有两种：按固定 token 数切块，或者按语义边界切块。固定长度切块常常把完整段落拦腰截断，检索时容易漏掉关键信息。Markdown 则自带清晰的语义边界——标题。

按标题切块有几大好处：每个切片自带一个描述性标题，向量化后检索命中率更高；切片之间没有重叠和截断，信息完整性更好；做增量更新时，只需要替换对应标题下的内容块，不用全库重建。

我在一个内部资料库上做过实验：PDF 直接切片构建向量库，某类问题命中率大约七成；同样的内容转成 Markdown 后按标题切片，命中率提到九成以上。这背后不是魔法，只是把“模型需要猜测的边界”变成了“文档自己宣告的边界”。

3. 各格式转 Markdown 的实操方案

3.1 第一步：判断文件属于哪一类

不要看到一个 PDF 就开始转，先花十秒钟判断文件类型，能省下后面几小时：

这个分类思路非常重要。很多转换翻车都源于“拿扫描件去跑文本提取”，源头就错了。

3.2 文字版 PDF 的转换与检查

对于文字版 PDF，我常用的思路是命令行工具一把梭。某开源转换工具支持保留标题层级、把表格识别为 Markdown 表格、识别粗体和斜体。核心命令大致长这样：

pdf2md 输入.pdf -o 输出.md --with-headings --tables

转换完成之后，不要急着把内容喂给 AI，先做四个检查：

第一，抽查标题。找文档目录里的一级、二级标题，看 Markdown 里是否保留了#和##。如果标题全部变成了普通段落，说明源 PDF 没有标准的标题结构，需要手动补标记。

第二，对照表格。找一页含表格的内容，在原文和 Markdown 之间来回看。列数是否一致，合并单元格是否被拆开。如果表格显示错乱，宁可删掉这个表格，改成“表格内容以图片形式见images/table1.png”，也不要给 AI 一份乱码表。

第三，查乱码。搜索常见的乱码形态，比如连续的�符号、孤立的一串十六进制字符。出现乱码意味着字体编码映射出了问题，这部分内容直接放弃，重新截图处理更靠谱。

第四，看页眉页脚。报告的页眉通常包含公司名、章节名；页脚包含页码。转换器可能把它们当成正文内容插入段落中间。这一步要在清洗阶段统一处理。

3.3 Word 和 PPT 的转换注意点

Word 转 Markdown 比 PDF 简单，因为 docx 本身有结构信息。但有两个地方特别容易翻车：批注修订和目录页码。

批量处理前，一定记得先查看文档是否有批注。批注框里的内容经常会被转换器当成正文输出，造成段落撕裂。处理方式是先接受所有修订、删除所有批注，再执行转换。

目录页码的问题也很常见。有些文档自带目录页，转换器会将目录里的“第 1 章……1”“第 2 章……23”当成真实内容输出。这些数字会严重干扰 AI 对正文篇幅和结构的理解。建议在转换后，搜索“第”和“页”等关键词，把整块目录删掉。

PPT 转 Markdown 的思路不太一样：每页幻灯片对应一个二级标题，标题内容加粗表示，正文要点转成列表。演讲者备注是极其宝贵的上下文，可以放到引用块里。公式不要直接截图，优先用 LaTeX 语法$...$插入，AI 对公式文本的理解能力比 OCR 强得多。

3.4 网页文章的正文抓取与转换

网页转 Markdown 的关键不是转换，而是先去掉噪音。直接复制网页内容再转，你会收获满屏的导航链接、Cookie 提示、热门推荐，正文反而淹没在其中。

我的做法有两个：一是用浏览器的“阅读模式”打开文章，此时页面已经只剩下正文和配图，再复制下来转 Markdown；二是用某某网页转 Markdown 的浏览器插件，它内部做了正文提取，能自动过滤侧栏。

这里有个很常见的坑：某些内容平台的正文是懒加载的，往下滚动时才会加载新内容。如果直接复制，你可能只抓到首屏几百字。正确做法是先把文章完整滚动一遍，让所有分段都加载出来，再执行复制或插件转换。

验证网页转换是否成功也很简单：看 Markdown 开头是否就是文章标题，结尾是否就是正文最后一段。如果中间夹了“相关阅读”“免责声明”，说明正文提取失败了，换一种方式抓取。

3.5 扫描版 PDF 的 OCR 处理流程

扫描件处理相对繁琐，但也不是无解。先说结论：不是所有扫描件都值得转 Markdown。如果内容以图表、复杂表格为主，直接把整页转成图片交给多模态模型，比 OCR 转换成文字再交给纯文本模型靠谱得多。

如果确实需要转文字，流程是这样的：先把 PDF 渲染成 300dpi 的图片，方向不正的先摆正；然后调用 OCR 引擎识别文字；最后把识别结果整理成 Markdown。300dpi 是一个平衡点，太低会丢失细节，太高会让图像体积膨胀，反而影响 OCR 速度。

OCR 完成之后，摘要一个诊断原则：断言越关键，越要回到原文核对。数值、百分比、人名、产品名，这些属于高风险内容。OCR 把它们识别错的概率并不低。比如某个实验报告里把“显著性水平 0.05”识别成“0.005”，这个错误足以推翻整个结论。数字化时代，这种错误的隐蔽性极强。

3.6 转换后的通用清洗三步曲

不管是从 PDF 还是网页转出来的 Markdown，都要经过清洗。这里分享我的三步流程。

第一步清页眉页脚。如果整份文档每页页眉重复某种模式，用正则把它们删掉。比如中文文档常见第 X 页，可以用^第\s*\d+\s*页\s*$匹配删除。注意 Haskell 风格的换行：匹配时要带上^和$，避免误删正文。

第二步合并断行。很多文档转换后会出现“一个段落□□□换行□□□一个段落”的状态，即句子中间被插入了换行符。合并的逻辑是：如果一行末尾没有句号、问号、感叹号，而下一行开头是小写字母或正常中文，则应该合并为同一段落。可以用一系列正则把行尾的换行符替换为空格，但要注意不要破坏列表和代码块。

第三步修复表格。如果 Markdown 表格的列数不一致，模型会看不懂。一个简单的修复策略是：找出所有以|开头的连续行，统计每行列数，把列数不一致的行单独挑出来人工处理。绝大多数情况下，这类问题源于跨行单元格或空白字符，修起来不快，但值得做。

4. 喂给 AI 的最终姿势

4.1 按标题切块，比按字数切块靠谱得多

Markdown 转好之后，还要考虑怎么喂给模型。如果只是一两份文档，全文发送没有太大问题。但如果你要处理几十份资料，或者搭一个检索知识库，切块策略就直接影响效果。

我的经验是：二级标题是最佳的切块边界。一份研究报告的大章节点往往是“行业概述”“市场规模”“竞争格局”，每块内容完整、主题明确。以##为界切成小块，每块单独交给模型处理，既能避免输入长度超限，又保留了该块完整的语义上下文。

下面是一个简单的切块函数思路，用 Python 表达：

def split_markdown_by_h2(md_text): lines = md_text.splitlines() sections = [] current_title = "" current_lines = [] for line in lines: if line.startswith("## "): if current_title: sections.append((current_title, "\n".join(current_lines))) current_title = line[3:].strip() current_lines = [line] else: current_lines.append(line) if current_title: sections.append((current_title, "\n".join(current_lines))) return sections

这样切出来的每个块都是一个独立叙事单元。如果做向量检索，块的标题可以作为 metadata 一并存储，检索命中时直接带上“当前块属于哪一章”的信息，模型回答时会更有依据。

4.2 摘要先行，精读随后

这是我自己用大模型读长文档时最重要的方法论：不要一上来就让 AI 通读全文。即使上下文窗口支持百万 token，信息密度过低时模型依然容易“走神”——前文看了后文忘，或者前后矛盾。

我的固定流程是这样的：

第一步，只把 Markdown 的大纲（保留前三级标题）发给模型，请它生成一份两百字左右的摘要，并列出最值得精读的五个章节。

第二步，根据摘要中模型判断的重点，从原文里找到对应章节的 Markdown 文本，单独发送并深入提问。

这种方法在几十页甚至上百页的研究报告上效果特别明显。模型只读大纲时，token 消耗极小；精读时上下文窗口聚焦在一个高信息密度区域，准确率显著提升。实测下来比让模型一口气读完整个文档的出错率低很多。

4.3 图文混合方案，专治复杂表格和图表

有一类文档特别难处理：大量图表、复杂表格、组织结构图混合在一起。这种情况下纯粹转成 Markdown 会丢失大量信息，纯粹截图给模型又丢弃了文字脉络。

推荐做法是“Markdown 为主干，图片为补充”。在 Markdown 中保留叙事性文字，遇到复杂的图表内容时，把图片插入引用位置：![](images/table3.png)。如果你的模型支持多模态视觉理解，它会自动读取图片内容来补充回答。

为什么纯文本方案不行？因为当表格跨行跨列、单元格合并严重时，转 Markdown 之后的行列对应关系基本无法恢复。你做再多的人工修复，都不如直接让模型看原图来得准确。

使用图片时记得压缩。一份 300dpi 的截图可能几个 MB，直接塞进提示词会拖慢响应。先缩放到宽度 1000 像素左右，质量选中等，视觉信息基本不损失，传输和解析都更高效。

4.4 给 Markdown 加一行元信息，AI 理解力再上台阶

很多 Markdown 转换之后直接就是正文文本，没有说明文档背景。我建议在文件开头补一段元信息，让 AI 快速建立上下文。推荐用 YAML front matter 格式：

--- 标题: 某行业年度发展报告 日期: 2025-01-15 来源: 某研究机构公开资料 说明: 本文档由 PDF 转换而来，表格数据以原文为准 --- ## 1. 行业概述 ...

这段信息看起来简短，但对模型的理解很重要。它相当于告诉模型：现在要读的是一份什么性质的文件、发布时间是什么、有哪些注意点。特别是在对比多份文档、判断信息时效性时，日期元信息能避免模型把旧数据当成新结论。

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

5.1 表格转换后错列严重

现象：Markdown 表格的列数和原表对不上，三维表格变成一维列表。

原因：源 PDF 中的表格跨行合并了单元格，转换器处理不了这种结构；或者表格内包含多行文本，被粗暴拆成多列。

对策：先尝试转换工具的“表格增强”选项；如果仍然错乱，把这个表格截图放到 Markdown 的同级位置，并在文字说明里写“详细数据见图片”。不要纠结于把每一个表格都修成规范 Markdown，能读懂的表格才值得保留。

5.2 代码块被拆得七零八落

现象：技术文档里的代码片段从保留缩进变成连续文本，或者缩进被吞掉一半。

原因：源文档可能用制表符或全角空格做缩进，转换器默认把它们折叠了。

对策：转换前先统一缩进——把制表符替换为四个空格；转换后检查代码块是否被围栏包围。如果代码内容确实无法恢复，可以考虑回到原始文档，将代码部分直接复制为纯文本并手动包装进代码围栏，准确率反而高。

5.3 OCR 错字污染正文，尤其是数字

现象：扫描件转换后出现明显的同音错别字，比如“磋商”变成“搓商”，“盈利”变成“营利”。

原因：OCR 引擎依赖字形匹配，遇到低分辨率、艺术字体时，会把相似字识别成替代字。

对策：建立高危词清单。凡是文档里出现统计数字、百分比、货币符号、公司专有名词，在喂给 AI 之前回到原图核对。如果文档数量很大，可以在提示词里加一条：“以下文本由 OCR 生成，遇到关键数据和专有名词时请标注置信度，不要猜测。”至少能让模型给出不确定提示，避免自信地输出错误结论。

5.4 图表表现为“图片”而非文字，提取失败

现象：PDF 里的柱状图、折线图、流程图在转换成 Markdown 后完全消失，只留下一个空行。

原因：图表本身是矢量或位图对象，没有文本内容可提取。

对策：转换时保留图片导出，把图片文件保存在与 Markdown 同级的 images 目录中。需要 AI 分析图表时，直接把图片视觉信息交给多模态模型处理。文字描述永远无法精确还原一张数据图的趋势关系。

5.5 超长文档把上下文塞满

现象：一份三百页的合规文件转成 Markdown 后有几十 MB，直接发送导致请求失败或响应极慢。

原因：模型上下文长度有限，任何输入都要先经过 tokenizer 切分。

对策：先估算 token 量。一个简单公式：中文字符数乘以 1.5 大概就是 token 数；如果超过模型上下文能力的三分之一，就别全文发送了。正确做法是使用上面的“摘要先行”流程，让模型先建立全局图景，再针对关键章节做精读分析。宁可多轮交互，不要一次性超载。

这里给一份速查表，方便日常查阅：

写在最后

现在拿到一份新文档，我的第一反应不再是“直接丢给 AI”，而是问三个问题：它有没有原生文本层？标题层级是否完整？里面有没有明显的噪声？然后花几分钟转成 Markdown、清洗干净、按标题切好块，再开始提问。

这个习惯刚开始会觉得多了一步，但用久了会发现，它把“让 AI 猜我手里的文件到底是什么”变成了“让 AI 在我整理好的信息基础上工作”。前者是开盲盒，后者是精确操作。对于每天要和大量文档打交道的人来说，这是一笔投入产出比非常高的时间投资。希望这套流程也能帮你省下那些浪费在纠错上的时间。