本人技术文档民工，每周要处理大量 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 的总耗时（含格式修复时间）：
| 工具 | 公式问题 | Mermaid 处理 | 代码块 | 人工修复耗时 | 总耗时 |
|---|---|---|---|---|---|
| Pandoc（配置好 filter） | 完美 | 自动转图 | 无高亮 | 15 分钟（调样式、加高亮） | 25 分钟 |
| aitoword | 完美 | 自动转图 | 无高亮 | 20 分钟（样式微调） | 22 分钟 |
| Typora + Pandoc（无 filter） | 完美 | 全丢失 | 无高亮 | 90 分钟（重新截图 9 张） | 105 分钟 |
| 手动复制到 Word | 乱码 | 消失 | 保留文本 | 180 分钟 | 180+ 分钟 |
结论：
- Pandoc 和 aitoword 在第一梯队，差别主要在样式控制 vs 上手速度
- 没有 Mermaid 自动处理的方案，在多图表文档上就是灾难
五、最后的技术建议
把你常用的 Markdown 样式固定下来
无论是 Pandoc 的reference-doc还是 Word 的样式集，统一定义好“标题1/2/3”“代码块”“表格”的字体、字号、间距。能省去 80% 的后期调整。Mermaid 一定要走自动化
不要相信“我就截图几张而已”——当你遇到第十张的时候会崩溃的。提前配好 Pandoc filter 或者用 aitoword.chat 这类工具，一劳永逸。公式检测方法
导出后快速检查：随机选中几个公式，看是否能激活 Word 的“公式工具”选项卡。如果能，说明转成了 OMML（可编辑）；如果不能且显示为图片，说明工具走了捷径，长期维护会很痛苦。代码块高亮的妥协方案
Pandoc 本身不提供代码高亮到 Word 的功能。折中方案：导出 HTML 再复制进 Word，或者用 VSCode 的“复制 with syntax highlighting”插件。aitoword 和 Typora 也不做高亮。如果要高亮，可以试试pandoc-highlight这类第三方脚本，但稳定性一般。
