2026 技术向：AI 对话转 Word 的格式问题与工具实测对比

本人技术文档民工，每周要处理大量 AI 生成的内容（ChatGPT、DeepSeek、Claude 混着用）。被格式坑过无数次之后，终于把这几个工具的脾气管明白了。

这篇文章不讲虚的，直接上技术细节：LaTeX 怎么保留、Mermaid 怎么批量转、Pandoc 的 filter 怎么写、在线工具到底有没有坑。

一、先搞清楚：AI 生成内容转 Word 为什么容易翻车？

Word 的底层是 Open XML，Markdown 是纯文本，两者之间没有天然映射。AI 输出的 Markdown 往往包含三类“危险元素”：

1. LaTeX 数学公式

• 常见写法：$E=mc^2$（行内）、$$ \int_0^1 x dx $$（行间）
• 风险点：Word 本身支持 OMML（Office Math ML），但不认识 LaTeX 语法。需要工具在转换时把 $$...$$ 翻译成 OMML，否则变成纯文本或乱码。

2. Mermaid 流程图

• 写法：` mermaid \n graph TD; A-->B; \n
• 风险点：Word 完全不能渲染 Mermaid。解决方案只有两条路：要么转换成图片（PNG/SVG）嵌入，要么安装第三方插件（极少见）。“能否自动将 Mermaid 转成图片”是分水岭。

3. 代码块与高亮

• 写法：` python \n print("hello") \n
• 风险点：Word 可以保留代码块样式，但语法高亮需要工具提前转换成带样式的 HTML 或直接应用 Word 样式。

另外还有隐藏坑：AI 生成的 Markdown 经常有不规范的 --- 分隔线、混合的 * 和 - 列表标记、多余的空白行——这些都会导致 Pandoc 等严格解析器产生意外的嵌套层级。

二、工具硬核对比（技术细节版）

下面从公式处理机制、Mermaid 处理路径、样式可控性、批量处理能力四个维度拆解。

1. Pandoc —— 可控性之王，但 Mermaid 需自己搭桥

公式：
Pandoc 原生支持 LaTeX 转 OMML，使用 --from markdown+tex_math_dollars 可识别 $...$ 和 $$...$$。推荐加 --to docx+raw_tex 参数，但实测直接用 pandoc input.md -o output.docx 已能处理大多数标准公式。

Mermaid：
Pandoc 不内置 Mermaid 渲染。标准做法：先用 pandoc-filter 或 mermaid-filter 把 Mermaid 代码块转成图片。示例流程：

# 安装 mermaid-filter
npm install -g mermaid-filter
# 转换
pandoc input.md -F mermaid-filter -o output.docx

或者更可控的方案：写一个 Lua filter，调用 Puppeteer 渲染 Mermaid 并插入 base64 图片。这对技术能力有一定要求。

样式：
可以通过 --reference-doc 指定参考 Word 模板，精确控制标题、正文、代码块的字体和间距。这是 Pandoc 最大的优势——适合团队统一交付标准。

批量能力：
完美。一行 for f in *.md; do pandoc $f -o ${f%.md}.docx; done 即可批量转换。

结论： 适合愿意写脚本、搭 filter 的技术向用户。如果只是临时转一两个文档，不值得折腾。

2. Typora —— 预览友好，但导出链路长

公式：
Typora 本身渲染 LaTeX 非常漂亮（底层使用 MathJax），但导出 Word 时，它默认调用 Pandoc（需要本地安装）。所以公式最终效果取决于你 Pandoc 的版本和参数，Typora 自己不做公式转换。

Mermaid：
Typora 预览区能实时渲染 Mermaid，效果很好。但导出到 Word 时，同样依赖 Pandoc + mermaid-filter。如果你没配置好 filter，Mermaid 在 Word 里会消失或变成代码块。

技术优势：
Typora 的真正价值在于导出前的人工修复。你可以在预览区快速发现：

• 公式分隔符不一致（比如有些用 $$`，有些用 `\( \)`） - 代码块语言标注缺失（```后面没有 python） - 列表缩进错位 这些在纯文本编辑器里很难一眼看出，但在 Typora 里无所遁形。 **批量能力：** 弱。Typora 是 GUI 应用，不适合批量。 **结论：** 把它当作“AI 内容质检器”+“人工润色环境”，导出交给 Pandoc 或其他工具。 --- ### 3. aitoword —— 专治 Mermaid 多段场景，公式无损 这是一个在线工具，打开网页即用。我重点测了它的技术边界。 **公式：** 测试用例：包含行内 `$a^2+b^2=c^2$`、行间 `$$ \sum_{i=1}^n i = \frac{n(n+1)}{2} $$、以及带有 \begin{cases}...\end{cases} 的复杂分段公式。导出 Word 后：
• 所有公式都变成了 Word 原生 OMML，可编辑、可重新渲染
• 没有出现公式转图片（图片无法编辑）的情况，这点比很多在线工具强

Mermaid：
测试用例：一篇文档里嵌了 8 段不同图表（流程图、时序图、状态图、甘特图）。aitoword 的处理方式是：在服务端调用 Mermaid CLI 渲染成 SVG，然后嵌入 Word。实测结果：

• 所有图表完整保留，矢量质量，可无限放大
• 图表顺序与原 Markdown 一致，没有错位
• 处理时间：8 个图表，从粘贴到导出完成约 15 秒（含预览渲染）

代码块：
它会对代码块套用 Word 中的等宽字体（Courier New 或 Consolas），但没有语法高亮。如果需要高亮，导出后需要在 Word 里手动套用样式。

样式可控性：
较弱。没有提供参考文档模板功能，只能使用默认的 Word 样式（标题1/2/3、正文等）。如果你的公司有严格的样式规范，可能需要在 Word 里二次格式化。

批量能力：
不支持。单次一个文档，适合临时任务。

结论： 技术文档中 Mermaid 密集、公式复杂的场景，aitoword 是目前在线工具里处理最干净的。但若你需要精确控制样式，还是得上 Pandoc。

4. Quarto —— 文档工程，杀鸡用牛刀

Quarto 是 Pandoc 的超集，增加了项目管理、输出格式统一、交叉引用等能力。

公式：
与 Pandoc 一致，支持 LaTeX，且能配合 crossref 实现公式编号和引用（如 @eq-1）。对学术论文非常友好。

Mermaid：
Quarto 原生支持 Mermaid，无需额外 filter。在渲染为 Word 时，会自动将 Mermaid 转为图片嵌入。但有一个注意点：Quarto 默认使用 pandoc 作为引擎，所以实际上还是走了类似 Pandoc 的路径，只是配置被封装了。

技术优势：

• 支持 _quarto.yml 配置文件，一套配置批量渲染多个文档
• 支持输出 Word、PDF、HTML 同时生成，格式一致性高
• 支持 Lua filter 和扩展

学习成本： 需要了解 YAML frontmatter、项目目录结构、渲染命令（quarto render）。如果你只是临时转一两个 Markdown 文件，这个学习成本不划算。

结论： 适合长期维护的技术文档库（例如产品手册、API 文档集合），不适合单次转换。

三、技术场景选型决策树

用伪代码帮你决策：

if 你需要批量处理（>10 文档/周）:
    if 你能写脚本 and 愿意搭环境:
        选 Pandoc
    else if 你已经有 Quarto 项目结构:
        选 Quarto
    else:
        建议先优化工作流，否则硬上会很痛苦

else if 你的文档包含 5+ 段 Mermaid:
    if 你不想手动截图:
        if 你对 Word 样式要求不高:
            选 aitoword（最快）
        else:
            选 Pandoc + mermaid-filter（可控但慢）
    else:
        手动截图 + 任意工具

else if 你的文档主要是 LaTeX 公式:
    if 需要公式在 Word 里可编辑:
        选 Pandoc 或 aitoword（都转 OMML）
    else if 可以接受公式转图片:
        任意工具都行

else if 你只是偶尔转一篇纯文本 Markdown:
    任意在线工具（MarkdownToWord.app、aitoword 等）都够用

四、实测数据：一个真实案例

上周处理一份 AI 生成的系统设计文档，包含：

• 37 个行内公式 + 12 个行间公式
• 9 段 Mermaid（架构图、时序图、ER 图）
• 22 个代码块（Python、Java、Bash）
• 6 个表格

分别用 Pandoc、aitoword、Typora+Pandoc 处理，记录从原始 Markdown 到可交付 Word 的总耗时（含格式修复时间）：

结论：

• Pandoc 和 aitoword 在第一梯队，差别主要在样式控制 vs 上手速度
• 没有 Mermaid 自动处理的方案，在多图表文档上就是灾难

五、最后的技术建议

1. 把你常用的 Markdown 样式固定下来
   无论是 Pandoc 的 reference-doc 还是 Word 的样式集，统一定义好“标题1/2/3”“代码块”“表格”的字体、字号、间距。能省去 80% 的后期调整。

2. Mermaid 一定要走自动化
   不要相信“我就截图几张而已”——当你遇到第十张的时候会崩溃的。提前配好 Pandoc filter 或者用 aitoword.chat 这类工具，一劳永逸。

3. 公式检测方法
   导出后快速检查：随机选中几个公式，看是否能激活 Word 的“公式工具”选项卡。如果能，说明转成了 OMML（可编辑）；如果不能且显示为图片，说明工具走了捷径，长期维护会很痛苦。

4. 代码块高亮的妥协方案
   Pandoc 本身不提供代码高亮到 Word 的功能。折中方案：导出 HTML 再复制进 Word，或者用 VSCode 的“复制 with syntax highlighting”插件。aitoword 和 Typora 也不做高亮。如果要高亮，可以试试 pandoc-highlight 这类第三方脚本，但稳定性一般。