让 AI 写文档，它总是先甩给你一段 Markdown；想要 Word/PDF，还得再转一道。这不是 AI 偷懒，而是能力边界和格式底层逻辑决定的。这篇文章用一张转换链路图讲清：为什么 Markdown 是天然默认，Word/PDF 又为什么必须由确定性程序”翻译”过去。

「一、为什么 AI 默认输出 Markdown」

【LLM 的本质：只能可靠地吐字符】

大语言模型的本质是生成 token。人话解释：模型一次吐一个”词块”，底层只是一串字符流。

所以它只能可靠输出文字，没法直接”写”出二进制文件——比如 .docx 内部是 XML 压缩包加各种字节结构，一个字节出错，文件就打不开。

Markdown 恰好是”结构化纯文本”：用 #、**、-、[文字](链接) 这些可见符号，把标题、加粗、列表、链接等结构信息，显式写进文本里。

好处很朴素：人类能直接读、任何编辑器能打开、Git 能做差异对比、零依赖。

【关键点：结构已经编码在文本里】

正因为结构写在文本里，转成其他格式时，AI 不需要”重新理解”一遍内容，只需要一个”结构翻译器”。

一句话总结：Markdown 是”AI 能写的结构文本”，Word/PDF 是”程序能做的成品格式”，中间靠解析器+渲染器连接。

「二、转换的本质：解析 → 结构树 → 渲染」

这段在做什么：Markdown 到 Word/PDF 的两条出口路径，画成一张图：

Markdown 文本
│ ① 解析（Parsing）
 ▼
结构树（AST：标题/段落/列表/加粗/链接）
 │ ② 渲染（Rendering）
 ├──► .docx（OOXML）
 └──► HTML/CSS
         │ ③ 浏览器排版（分页）
         ▼
      .pdf（版式快照）

【① 解析：纯文本变结构树】

把 Markdown 字符串拆成一棵结构树。人话解释：结构树就是把文档拆成”标题、段落、列表”的树状骨架，程序按骨架逐层处理。

这一步是纯文本处理，任何语言都有现成解析器（比如前端常用的 marked）。

【② Word 路线：结构树映射成 XML】

.docx 本质是一个 zip 压缩包，里面是 OOXML 文档。人话解释：OOXML 是 Word 文档内部的 XML 描述语言，相当于文档的”建筑图纸”。

转换器把结构树的每个节点翻译成对应 XML：标题 → 标题样式、** 加粗 → 、[x](url) → 。

python-docx 这类库，就是帮你封装、生成这套 XML 的”翻译官”。

【③ PDF 路线：先 HTML，再交给浏览器分页】

PDF 不是”文档结构格式”，而是”排版好的版式快照”。人话解释：它像给每一页拍了张固定坐标的照片，内容位置全部定死。

所以常见做法不是直接写 PDF，而是 Markdown → HTML/CSS → 交给浏览器排版引擎分页渲染 → 打印导出。

你看到网页怎么排版，PDF 就怎么排版——中文字体、换行、链接都走浏览器的真实规则。我用的无头 Edge 调 page.pdf()，就是这条路径。

▸ 小贴士：即使是最强的多模态模型，给你 .docx 文件时，本质也是”内部先写文本 + 外部工具转换”，并没有绕开这条链路。

「三、为什么这样做，而不是让 AI 直接生成 Word/PDF」

【可靠性：一个字节错了，文件就坏了】

LLM 生成二进制/压缩格式很容易出错——一个字节不对，整个文件打不开。

而”先生成纯文本 + 程序转换”是确定性的：同样的输入，永远得到同样的输出。

【分工清晰：AI 管内容，程序管排版】

AI 负责”内容和结构”，程序负责”格式和排版”。

这也是为什么业界流程基本都是 Markdown 为源、按需导出：内容在源头维护，格式在出口定制。

【可逆与可维护：.md 是源文件，.docx/.pdf 是成品】

.md 随时能改一句话再重新导出；.docx/.pdf 是成品，改起来要开专门软件，还容易破坏版式。

当然，这里有一个前提：如果文档只是打印一次、以后不再编辑，让 AI 直接生成 HTML 再导出 PDF 也够用；但如果要求像素级排版（杂志、海报、标书），Markdown 就力不从心，得交给 InDesign 这类专业排版工具。

写在最后

一句话收束：AI 只负责把内容写成带结构的文本，剩下的格式活儿，交给确定性的程序。

如果你正在纠结”AI 写的 Markdown 怎么变成客户要的 Word/PDF”，下一步很简单：以 Markdown 为源格式，接一个 pandoc 或 python-docx 转 Word，再配一个无头浏览器转 PDF，半天就能打通双出口。

你平时是直接复制 AI 的 Markdown，还是每次都让它给 Word 版？评论区聊聊你的用法。