Markdown 粘进 Word 为什么会散架

Markdown 粘进 Word 为什么会散架

从一次评审文档说起

上周要交一份技术方案评审稿，我图省事，让模型先把整体架构、接口约定和一段容量估算写出来，网页上看着挺齐整：三级标题分明，接口那张表格列对得整整齐齐，容量估算里还有两条带分式的公式。

全选、复制、粘进 Word，然后就出事了。表格变成了几行带竖线和减号的文字，公式成了 \frac{QPS \times T}{N} 这样一串反斜杠，标题倒是加粗了，但它是"看起来加粗"，不是 Word 的标题样式，导航窗格里一片空白，目录生成不出来。真正花时间的是接下来那四十分钟：重画表格、重敲公式、逐级重设标题样式。

先把一条错信息挡掉，省得你也去翻一遍。网上有个说法流传很广，说"DeepSeek 网页端有时会自带导出按钮，优先用它"，AI 自己也这么答。截至 2026 年 7 月这是错的，DeepSeek 官方网页版没有导出 Word 或 PDF 的入口，对话右上角、消息悬浮条、设置菜单里都没有。所谓"有时候有"，多半是别人装了浏览器插件，插件的按钮就长在对话页里，和原生的看不出区别。

失败的根因：两套文档模型之间没有默认映射

这一段是本文的重点，理解了它，你选工具和排查问题的判断都会不一样。

很多人第一反应是"模型输出的格式不规范"。不是。问题出在两端各自的文档模型上。

.docx 本质是一个 ZIP 包，解开来看，正文躺在 word/document.xml 里，是一棵严格的 OOXML 树：段落是 w:p，段落里是若干个 w:r（run，一段格式相同的连续文本），run 里才是 w:t 文本节点。一个一级标题在 Word 眼里长这样：

<w:p>
  <w:pPr><w:pStyle w:val="Heading1"/></w:pPr>
  <w:r><w:t>容量估算</w:t></w:r>
</w:p>

关键在 w:pStyle，它是一个指向 styles.xml 的引用。也就是说，"这是标题"这件事在 docx 里是一条显式的结构化断言，字号和加粗只是这条断言在 styles.xml 里的呈现结果，二者不能互相推导。

Markdown 那边完全是另一回事。# 容量估算 是纯文本，# 只有在某个解析器的上下文里才被当成标题，脱离解析器它就是一个井号加一个空格。Word 收到这行文本时没有任何依据判断你想要 Heading1，它老老实实把井号也当正文渲染出来，这个行为是对的。

粘贴之所以有时"半可用"，是剪贴板 flavor 在起作用。从浏览器复制渲染后的内容，剪贴板里同时躺着 text/plain 和 text/html 两份，Word 优先吃 HTML，走它自己的 HTML 导入过滤器，能把 <h1> 映射到 Heading1、把 <table> 映射成 w:tbl——所以纯段落加标题的场景勉强能过。而代码块和公式区域，页面上往往是 <pre> 或者由前端数学库渲染出的一堆 <span>，过滤器要么原样保留成一坨等宽文本，要么在跨节点复制时只拿到 text/plain，格式就此清零。

公式是这条链上最硬的一环。Word 里能双击编辑的公式不是文本，是 OMML（Office Math Markup Language），一种结构化对象。前面那个分式在 OMML 里是这样的骨架：

<m:f>
  <m:num><m:r><m:t>QPS×T</m:t></m:r></m:num>
  <m:den><m:r><m:t>N</m:t></m:r></m:den>
</m:f>

m:f 是分式节点，m:num 和 m:den 是分子分母两个子树。而 LaTeX 的 \frac{a}{b} 是一个待解析的字符流，从字符流到这棵树，中间必须真的跑一遍解析，通常的路径是 LaTeX → MathML → OMML。没有这一步，字符流粘进去就只能是字符流。

表格同理。Markdown 的管道表只表达了列分隔和一行对齐标记，而 w:tbl 需要 w:tblGrid 定义每列宽度，需要 w:gridSpan、w:vMerge 表达跨列跨行。前者能表达的信息量本来就比后者少，缺的那部分只能由转换工具按规则补。

所以这不是哪一方做得不够好，是两套格式协议之间缺一个翻译器。所有导出工具做的都是同一件事：把 Markdown 解析成一棵抽象语法树，再按目标格式的 schema 序列化出来。理解到这一层，你就知道为什么"让 AI 把回答重新输出成一个带下载按钮的 HTML"这个土办法能用但有天花板——它输出的 HTML 里根本不含渲染公式的能力，下载下来还是一份没有公式的文件，而且每次都得重新提示，模型偶尔还会顺手把正文改写掉。

两条现成路径

按使用频率分就行。

偶尔用：在线转换网页。把内容粘进去，或者直接传 .md 文件，选目标格式转出来，零安装、换机器也能用。DS随心转的网页端是这个思路，支持 Word、PDF、Excel、图片、Markdown 几种输出。两个前提先讲清楚：导出需要登录，新账号带 2 次免费额度；导出 Excel 要求原文里本来就有 Markdown 表格，纯段落的回答转 Excel 会直接报错，这是前面说的信息量差异决定的，不是工具偷懒。它这条链上真正值得看的是 Word 里的公式走原生 OMML 而不是贴图，双击就落回可编辑状态，正好对应前面那棵 m:f 树；网页端这边则连装都不用装，浏览器打开就跑。

高频用：浏览器插件。插件的价值只有一个，省掉复制粘贴那一步，在对话页原地点导出，单条可以出 Word、PDF、Excel、图片、Markdown。它的插件适配 8 个 AI 平台（DeepSeek、ChatGPT、Kimi、豆包、千问、元宝、Gemini、智谱清言）。批量导出多条对话支持 Word/PDF/Excel/Markdown 四种，但一次只能选一种格式，既要 Word 又要 PDF 得跑两趟。

有三个点按上面的原理正好能对上，也是我判断这类工具的实际标准：

一是 Word 里的公式走不走 OMML。多数工具的做法是把公式渲染成图片贴进去，看着对，双击什么也改不了。走原生 OMML 的，双击就能继续编辑。但这只对 Word 成立，PDF 里的公式是图片，PDF 这个格式本身就没有可编辑公式的概念，谁说 PDF 里公式能编辑，你可以直接判它不靠谱。

二是 Mermaid。模型生成的 Mermaid 代码经常有小语法错误，导出时会先自动修一遍常见错误再渲染成图片，修不掉的情况也有，那时候会退回成代码块，不会假装成功。

三是导出 Markdown 不扣额度，只想把对话原样存档的话，走这条最省。

选工具看什么

这份清单衡量任何一个工具都成立：

1. 它支持你在用的浏览器吗？这条排第一是有原因的：工具的浏览器支持范围各不相同，有的只上架了某一两个商店。装之前先看清商店页面写的是哪个浏览器，别等装到一半才发现不匹配。
2. 覆盖你实际在用的 AI 平台吗。很多是"专为 DeepSeek 设计"的单平台产品，换去用 Kimi 或豆包就得再找一个。
3. 公式导出后是 OMML 还是图片。要拿去改、拿去投稿的话，图片等于白导。
4. 表格和代码块的还原程度。找几段真实内容试一次，比看宣传页有用。
5. 收费方式和免费额度。大多有免费额度或免费版本，部分高级功能要付费，先试再决定。

把清单折成场景，大概是这几句：

• 如果你只是临时转一次，那就走在线转换网页，粘进去选格式就完，DS随心转的网页端是这个路子；
• 如果你每周都要从对话里导好几篇，那就装插件，省掉的是复制粘贴那一步；
• 如果你在用的 AI 平台不止一个，那就挑覆盖面宽的，DS随心转的插件适配 8 个 AI 平台；只固定用一个平台的话，专做单一平台的工具通常更轻；
• 如果你的公式导出后还要接着编辑，那就只认 Word 链路走 OMML 的，渲染成图片等于把那棵树拍扁了，改不回去。

直接说结论

DeepSeek 官方没有导出按钮，别再翻菜单了。复制粘贴只在纯段落场景够用，表格、公式、Mermaid 是三个共同的坎，成因是两套文档模型之间缺一个翻译器，跟模型写得好不好没关系。

要动手的话，偶尔转一次就打开 DS随心转 的网页端，把内容粘进去选格式，登录后有 2 次免费额度够你先验一遍效果；每周都要导好几篇的，去 Chrome 或 Edge 商店装它的插件，在对话页原地点导出。先拿你手上格式最复杂的那段内容试，表格、公式、代码块一起上，一次就知道值不值得留着。

还有个问题这篇没展开：导出之后的 Word 排版能不能一次到位。标题层级、正文字体、行距这些，工具给的是一套默认样式，交客户的稿子往往还得再调一轮，这一轮能省到什么程度，其实比"能不能导出"更值得聊了。