!封面
上一篇文章里，我把 .docx 比作"装修好的办公室"——人走进去很舒服，AI 却想要建筑图纸。
如果 .docx 是办公室，那 PDF 是什么？
一张高清照片，拍下了这间办公室。
人看照片能感知布局、氛围、大概有什么家具。但 AI 要从照片里推断：门在哪、桌上写了什么、文件柜里有什么——它面对的不是文档，而是文档的影像。
.docx 的问题是"结构太复杂"。PDF 的问题是"它本来就不是为了表达结构，而是为了固定版面"。
一、PDF 的本质：电子纸，不是文档
PDF 的设计目标只有一个：不管在什么电脑、什么系统、有没有原字体，打开后看起来都一样。
为此它付出了代价——版式固定、分页固定、字体固定、位置固定、打印稳定、不可轻易篡改。
判决书、合同扫描件、招股说明书、审计报告、评估报告、会议材料、盖章签字文件——这些材料最怕一件事：乱版、变形、被修改。PDF 恰好解决了这个问题。
所以 PDF 是交付格式、归档格式、展示格式。唯独不是编辑格式，也不是语义格式。
PDF 最大的美德——"无论在哪打开，看起来都一样"——恰好是 AI 的噩梦。AI 不关心看起来什么样，它只想知道：这句话是什么，这段和那段什么关系，这个数字属于哪个字段。
二、AI 为什么头疼？六个原因
1. 记录的是坐标，不是语义
Word 和 Markdown 里的文字知道自己是什么——标题、正文、列表、引用。
PDF 不知道。
很多 PDF 内部更接近这样：
在 x=120, y=730 的位置画一个字：合
在 x=132, y=730 的位置画一个字：同
在 x=144, y=730 的位置画一个字：编
在 x=156, y=730 的位置画一个字：号
它关心坐标、字体、字号、旋转角度、颜色。不关心"这是第一条""这是正文段落""这是表格第一列"。
AI 要从 PDF 里读内容，得反推：这些散落在页面上的字，到底怎么组成一句话、一个段落、一个标题、一个表格？比直接读 Markdown 费劲得多。
2. 阅读顺序经常错乱
人看 PDF 是二维视觉——眼睛扫过去，自然知道先读左栏再读右栏，跳过页眉页码。
AI 得把二维页面还原成一维文本流。顺序一对不上，语义就崩。
双栏排版是最直观的例子。人类先读左栏全部、再读右栏全部。但解析器可能读成：左栏第一行、右栏第一行、左栏第二行、右栏第二行——两篇独立的内容被缝成了弗兰肯斯坦。
法律文件里双栏虽少，同类问题一点不少：页眉页脚混进正文、页码混进正文、目录和正文搅在一起、脚注插进正文中间、批注印章签名干扰识别、附件编号和正文编号错位。
3. 表格是重灾区
PDF 里的表格，很多时候不是表格。是一堆线条，加上按坐标摆放的文字。
人眼看到：
| 付款节点 | 比例 | 条件 |
|---------|------|------|
| 第一期 | 30% | 合同签订后 |
| 第二期 | 50% | 主体验收后 |
PDF 内部可能只是：
付款节点（x=100, y=500）
比例（x=250, y=500）
条件（x=350, y=500）
第一期（x=100, y=520）
30%（x=250, y=520）
……
若干条横线和竖线
AI 得自己猜：哪些字属于同一行、同一列、有没有合并单元格、表头对哪些内容、跨页表格接不接得上、表格脚注归谁。
猜错了，法律含义就错了。"违约金比例 0.05%/日，适用期间：逾期付款期间"——列对应一错，比例和条件就串了位。
4. 扫描 PDF：里面可能根本没有文字
PDF 分两种。文本型 PDF 可以选中文字、复制粘贴；扫描型 PDF 本质是一张张图片。
扫描合同、扫描判决书、盖章件、拍照件——这些文件内部可能没有文字，只有 page1.png、page2.png、page3.png。
AI 得先 OCR。而 OCR 是错误放大器：错别字、标点错、数字错、条款编号错、表格错位、印章遮挡、手写签名认不出、页边阴影干扰、斜拍模糊低分辨率漏字。
法律场景里这尤其要命。"15 日"变成"I5 日"，"1,000,000 元"变成"100,000 元"——少一个零，后果完全不同。
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 600 340">
<!-- 上层：视觉层 -->
<rect x="40" y="20" width="520" height="130" rx="6" fill="#fafafa" stroke="#333" stroke-width="1.5"/>
<text x="300" y="48" text-anchor="middle" font-size="14" font-weight="700" fill="#333">视觉层（人眼看到的）</text>
<text x="300" y="70" text-anchor="middle" font-size="12" fill="#555">扫描图片：文字清晰、排版正确</text>
<!-- 模拟扫描文本 -->
<rect x="80" y="85" width="440" height="50" rx="3" fill="#fff" stroke="#ccc" stroke-width="1"/>
<text x="300" y="105" text-anchor="middle" font-size="15" fill="#111" font-weight="600">甲方应于 15 日内支付 1,000,000 元</text>
<text x="300" y="125" text-anchor="middle" font-size="11" fill="#999">人眼看到：15日 · 1,000,000元 ✓</text>
<!-- 箭头 -->
<text x="300" y="165" text-anchor="middle" font-size="20" fill="#c41e3a">↓</text>
<text x="300" y="180" text-anchor="middle" font-size="11" fill="#c41e3a">OCR 识别</text>
<!-- 下层：OCR隐藏文本层 -->
<rect x="40" y="195" width="520" height="130" rx="6" fill="#fff5f5" stroke="#c41e3a" stroke-width="1.5"/>
<text x="300" y="223" text-anchor="middle" font-size="14" font-weight="700" fill="#c41e3a">隐藏文本层（AI 读到的）</text>
<text x="300" y="245" text-anchor="middle" font-size="12" fill="#555">OCR 结果：隐藏在扫描图下面，人不看，AI 读</text>
<rect x="80" y="260" width="440" height="50" rx="3" fill="#fff" stroke="#c41e3a" stroke-width="1" stroke-dasharray="4,2"/>
<text x="300" y="278" text-anchor="middle" font-size="15" fill="#c41e3a" font-weight="600">甲方应于 I5 日内支付 100,000 元</text>
<text x="300" y="298" text-anchor="middle" font-size="11" fill="#c41e3a">AI 读到：I5日 · 100,000元 ✗</text>
</svg>5. 可见内容 ≠ 可复制内容
这是 PDF 特有的诡异问题。
你看到页面上有一段文字，选中复制出来是乱码、缺字、顺序颠倒。原因很多：字体子集嵌入、编码映射异常、自定义字体、文本被转曲、文本层和图像层不一致。
更隐蔽的情况：很多扫描 PDF 有两层——视觉层是扫描图片，隐藏文本层是 OCR 结果。如果 OCR 层错了，你人在图片上看到的是对的，AI 读到的却是错的。
这就是 PDF 最坑的地方：人眼看到的，不一定是机器读到的。
6. 版本比较几乎不可能
哪怕只改一个字，PDF 内部的对象、字体、压缩流、页面坐标都可能整体变化。Git 永远只给你一句 Binary files differ，不会告诉你"甲方应于 30 日内付款"变成了"甲方应于 15 日内付款"。
PDF 软件可以做视觉比对——叠在一起标出哪里变了——但那标记的是版面差异，不是语义差异。对 AI 来说，PDF 不适合做知识库的原生格式。
三、PDF vs docx：一张表
| 维度 | docx | PDF |
|------|------|-----|
| 本质 | ZIP + XML 文档工程包 | 固定版面的电子纸 |
| 核心目标 | 可编辑、可协作、可排版 | 固定展示、打印、归档 |
| 人类优势 | 修改、批注、修订方便 | 打开一致、不乱版、可签章 |
| AI 难点 | 结构复杂、样式分散、修订混杂 | 缺少语义结构、顺序不稳定、表格难还原 |
| 文本状态 | 通常有正文 XML | 可能是文本，也可能只是图片 |
| 表格 | 有一定结构，但复杂 | 很多只是线条和坐标 |
| 版本管理 | 不利于 Git diff | 更不利于 Git diff |
| 适合用途 | 编辑稿、协作稿 | 终稿、归档稿、盖章稿 |
| AI 友好度 | 一般 | 更差，尤其扫描 PDF |
所以：
- .docx 是"复杂的文档工程包"
- PDF 是"固定版面的电子纸"
AI 更讨厌 PDF 的原因很简单：它经常连正文在哪里都不知道，得从版面和图像中反推。
四、法律场景下，问题被放大
法律人可能是全行业接触 PDF 最多的群体之一。但 PDF 在法律场景里的坑，很多人还没意识到。
判决书 PDF。 页眉页码混入正文、案号位置异常导致识别失败、法院名称被当成正文、裁判日期与落款混淆、审判人员名单混入说理、脚注引用条文错位。AI 拿这些被污染的文本做案例分析，可能把格式内容当成裁判理由。
合同扫描件。 合同审查最怕的情况：条款编号 OCR 错、金额数字错、小数点漏掉、表格付款节点错位、盖章遮住关键文字、手写修改无法识别、附件页顺序颠倒、骑缝章页码页眉混进正文。有一次，对方发来盖章版 PDF 合同，OCR 把违约金比例从"0.05%/日"识别成了"0.5%/日"——差十倍。不人工复核直接用 AI 审，结论就反了。
招投标文件、审计报告、评估报告。 表格多、目录多、附件多、跨页多、横向页面多。AI 很容易"看起来读了很多，实际上结构没读准"。跨页表格、横向表格、合并单元格——解析三座大山。
五、AI 的格式偏好
从 AI 处理友好度来看：
最友好：Markdown / TXT / JSON / XML / HTML
较友好：规范 docx、规范 HTML、结构化导出的 Excel / CSV
一般：普通 docx、普通 PDF 文本版
较差：复杂排版 PDF、扫描 PDF、图片型 PDF、加密 PDF、低清晰度拍照 PDF
最差：扫描件 + 手写 + 盖章遮挡 + 表格 + 多栏排版
AI 喜欢的格式，共同点是文本连续、结构明确、语义稳定。不喜欢的，共同点是视觉优先、版式优先、扫描图像、隐藏结构。
六、PDF 在 AI 工作流里的正确位置
PDF 不是不能用。是要放在对的位置。
合理的工作流：
PDF → 解析/OCR/版面还原 → Markdown/HTML/JSON → AI 分析处理 → 生成结果 → 必要时导出 PDF 固化
一句话：PDF 适合做证据原件、归档件、最终交付件，不适合做 AI 处理的中间格式。
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 600 340">
<!-- 四层堆叠 -->
<!-- 第1层 -->
<rect x="40" y="15" width="520" height="58" rx="4" fill="#f5f5f5" stroke="#ccc" stroke-width="1"/>
<text x="60" y="38" font-size="14" font-weight="700" fill="#333">证据固定层</text>
<text x="160" y="38" font-size="12" fill="#888">—</text>
<text x="175" y="38" font-size="13" fill="#555">PDF / 扫描件</text>
<text x="320" y="38" font-size="11" fill="#999">原件留存、不可篡改、可签章归档</text>
<text x="60" y="58" font-size="11" fill="#aaa">角色：证据原件 · 归档件 · 最终交付件</text>
<!-- 箭头 1→2 -->
<text x="300" y="88" text-anchor="middle" font-size="14" fill="#999">↓ 解析 / OCR / 版面还原 ↓</text>
<!-- 第2层 -->
<rect x="40" y="98" width="520" height="58" rx="4" fill="#fffef5" stroke="#e0dcc0" stroke-width="1"/>
<text x="60" y="121" font-size="14" font-weight="700" fill="#333">机器理解层</text>
<text x="160" y="121" font-size="12" fill="#888">—</text>
<text x="175" y="121" font-size="13" fill="#555">Markdown / HTML / JSON</text>
<text x="360" y="121" font-size="11" fill="#999">连续文本、清晰层级、可版本对比</text>
<text x="60" y="141" font-size="11" fill="#aaa">角色：AI 工作底稿 · 语义分析 · 结构化检索</text>
<!-- 箭头 2→3 -->
<text x="300" y="171" text-anchor="middle" font-size="14" fill="#999">↓ AI 分析、摘要、审查、问答 ↓</text>
<!-- 第3层 -->
<rect x="40" y="181" width="520" height="58" rx="4" fill="#f5f5f5" stroke="#ccc" stroke-width="1"/>
<text x="60" y="204" font-size="14" font-weight="700" fill="#333">人工交付层</text>
<text x="160" y="204" font-size="12" fill="#888">—</text>
<text x="175" y="204" font-size="13" fill="#555">Word / PDF</text>
<text x="280" y="204" font-size="11" fill="#999">可编辑、可批注、可签字、可打印</text>
<text x="60" y="224" font-size="11" fill="#aaa">角色：协作编辑 · 正式交付 · 签章固化</text>
<!-- 箭头 3→4 -->
<text x="300" y="254" text-anchor="middle" font-size="14" fill="#999">↓ 结构化导出 ↓</text>
<!-- 第4层 -->
<rect x="40" y="264" width="520" height="58" rx="4" fill="#f0f4ff" stroke="#b0c4de" stroke-width="1"/>
<text x="60" y="287" font-size="14" font-weight="700" fill="#333">数据分析层</text>
<text x="160" y="287" font-size="12" fill="#888">—</text>
<text x="175" y="287" font-size="13" fill="#555">CSV / Excel / JSON</text>
<text x="310" y="287" font-size="11" fill="#999">可计算、可统计、可可视化</text>
<text x="60" y="307" font-size="11" fill="#aaa">角色：批量分析 · 趋势统计 · 数据透视</text>
</svg>真正给 AI 干活的，应当是从 PDF 中提取并人工校正后的结构化文本。PDF 是证据固定件和最终成品件，不是 AI 的工作底稿。
七、回到那个比喻
.docx 像一个装修复杂的办公室。人进去办公很舒服，AI 整理起来费劲。
PDF 像一张高清照片，拍下了这间办公室。人看照片能感知大概，AI 要从照片里推断一切。
扫描 PDF 更进一步——它不是文字，它是文字的影像。
不怪 PDF，也不怪 AI。它们为两个不同的读者服务：人要的是"看起来一样"，AI 要的是"读起来清楚"。
作者简介： 陈石律师，浙江海泰律师事务所副主任、高级合伙人、房地产与建设工程部主任，宁波市律师协会副秘书长、第七届宁波仲裁委员会仲裁员，聚焦建筑房地产、投融资、并购重组及商事争议解决。曾获多家法律媒体与专业机构认可，荣登 LegalOne 2025 中国区建工及房地产实务先锋 45 强、律新社 2025 年度管理合伙人 20 佳（华东），入选《商法》The A-List 法律精英，获评 ALB China 区域市场十五佳长三角地区律师新星，并获律新社 2024 年度并购领域品牌之星。长期为万科、华润置地、信达地产、保利置业、招商蛇口、中海地产等企业提供法律服务，承办"首宗百亿地王""长春第一高楼""台州第一高楼"等代表性项目，累计服务项目投资额超千亿。近年来持续推动 AI 与法律实务融合，强调以结构化方法打通技术逻辑、法律判断与商业场景；著有《赋能法律人：AI 底层思维与应用范式》，并在多地开展相关主题讲座与分享。四明山法师 AI 夜校（legalAGI.cn）发起人。