从 Markdown AST 到 OOXML：彻底理解代码格式崩塌的底层原因
最近一年，越来越多人开始用 GPT 写技术文档、接口说明、课程教程、开发报告。但很多人都会遇到同一个问题：GPT 里排版完美的代码，一复制到 Word 就彻底乱了。
最典型的问题包括：
- Python 缩进错乱
- Word 自动替换智能引号
- 三个反引号
```原样显示 - 等宽字体丢失
- 代码和正文混在一起
- 行内代码无法区分
- JavaScript 粘贴后直接报错
很多人第一反应是："是不是 GPT 输出有问题？"或者"是不是 Word 太垃圾了？"其实都不是。
真正的问题是：GPT 输出的是 Markdown 结构，而 Word 使用的是 OOXML 文档体系。两者根本不是一个世界的东西。
这篇文章，我们从底层机制彻底讲清楚：为什么 GPT 内容转 Word 时代码会乱。
一、问题本质：你复制的不是"代码块"，只是字符串
很多人误以为下面这段是"带格式代码"：
```python
print("hello")
```
实际上不是。GPT 输出的本质仍然是纯文本（Plain Text）。Markdown 只是"约定好的标记语言"——那三个反引号对于 GPT 来说，只是三个普通字符。
真正让它变成"代码块"的，是 Markdown 渲染器，比如 Typora、VSCode、GitHub、Obsidian。这些工具会解析 Markdown、构建 AST（抽象语法树）、识别 CodeBlock 节点，并应用灰色背景、等宽字体、语法高亮、缩进保留。
但 Word 不做这件事。
二、Word 为什么无法识别 GPT 代码块？
因为 Word 根本不理解 Markdown。Word 使用的是 OOXML（Office Open XML）——.docx 本质上是一堆 XML 文件压缩后的容器。
在 Word 里，一个代码段落实际长这样：
<w:p>
<w:pPr>
<w:pStyle w:val="Code"/>
</w:pPr>
<w:r>
<w:rPr>
<w:rFonts w:ascii="Consolas"/>
</w:rPr>
<w:t xml:space="preserve"> print("hello")</w:t>
</w:r>
</w:p>
这里包含：段落样式、等宽字体、空格保留、行间距、底纹。而你从 GPT 复制时，剪贴板传递的只有普通字符串。Word 看到的只是一串普通字符，所以：
```被直接显示- 字体变成正文
- 缩进被吞
- 代码结构丢失
这就是根本原因。
三、真正致命的问题：缩进丢失
很多语言里，缩进不是"格式"，而是"语法"。Python 最典型：
def test():
print("hello")
def test():
print("hello") # IndentationError
为什么会这样？因为 Markdown 中的缩进，本质是原始空白字符；而 Word 的缩进是段落属性。这是两个完全不同的机制，无法自动对应。
四、等宽字体为什么如此重要？
代码排版依赖 Monospace Font（等宽字体），比如 Consolas、Courier New、JetBrains Mono。等宽字体意味着每个字符宽度完全一致，i 和 m 占相同宽度，代码列才能对齐。
但 Word 默认正文使用宋体、微软雅黑、Times New Roman——这些都是比例字体（Proportional Font），字符宽度不同。于是：表格错位、对齐崩塌、缩进混乱——整个代码视觉结构直接毁掉。
五、为什么 Pandoc 能解决问题？
因为 Pandoc 真正做了 Markdown AST → OOXML 映射，而不是"复制 → 粘贴"。流程如下：
六、很多人忽略的核心细节：xml:space="preserve"
真正专业的转换器，一定会处理 xml:space="preserve"——这是 Word 中保留空格和缩进的关键属性。没有它，前导空格会被 Word 自动吞掉，Python 缩进直接失效。这也是很多"伪 Markdown 转 Word 工具"仍然会代码错乱的原因。
七、我踩过的坑：团队文档灾难
我们团队曾经有一次用 GPT 批量生成技术培训文档，总共 200 多页、80 多段代码，Python + SQL + Shell 混合。一开始直接复制到 Word，结果：缩进错乱、代码无法运行、培训现场大量报错、文档维护彻底失控。
后来重构了整个流程：
问题才彻底解决。真正理解底层机制之后，代码格式问题其实完全可控。
八、正确方案到底是什么？
真正正确的解决方案只有一个：不要直接复制粘贴，而是做结构化转换。
方案一：Pandoc（开发者推荐）
pandoc input.md -o output.docx
优点：结构正确、可定制样式、支持语法高亮。缺点：有学习成本。
方案二：Markdown 编辑器导出
例如 Typora、Obsidian，适合普通用户直接导出 Word。
方案三：专用 Markdown → Word 工具
适合 GPT 长文、技术教程、企业文档、AI 批量生成场景。核心要求：必须完成 AST → OOXML 映射。
九、最终结论
GPT 转 Word 代码乱，根本不是 GPT 的问题。真正原因是：Markdown 与 OOXML 属于完全不同的文档体系。
直接复制粘贴只会传递纯文本，不会传递：
- CodeBlock 语义
- 等宽字体
- 缩进规则
- 样式绑定
真正正确的方法，是通过结构化转换，完成 Markdown AST → Word OOXML 的映射。只有这样，代码格式、缩进、字体、结构，才能真正稳定。