企业官网建设流程全解析

每次看到学术群里有人问“LaTeX 写好的论文怎么转成 Word 给导师批注”，我就知道又一个头铁的朋友要开始渡劫了。作为一个前前后后帮实验室转过上百篇论文、也亲手写过四篇需要双版本投稿论文的老油条，我太熟悉这条路上的坑了：公式一夜之间变成高清大图、目录编号全部归零、引用标号乱成麻、发给导师后对方 Word 直接卡死，最离谱的一次是转出来的文档里居然带着我本地 LaTeX 编译器的完整路径信息，相当于把家底都泄露给对方了。

这篇文章不打算给你堆砌那些“用 A 软件点一下就行”的废话。我直接拆解从 LaTeX 源文件到 Word 的三种主流路线，把 Pandoc 和最近很火的 ai2word 放在同一张桌子上横评，再把公式乱码、表格错位、Word 关闭卡顿、隐私泄露这些高频事故的排查链路完整走一遍。无论你是被导师逼着交 Word 版的学生，还是帮期刊整理作者稿件的编辑，这篇都值得存下来。

1. 为什么每次 LaTeX 转 Word 都像拆盲盒：先搞懂三种转换路线

先说结论：市面所有转换工具的本质区别，不在于谁“转得好看”，而在于它从哪个层面理解你的 LaTeX 文档。这一层没想清楚，后面全是玄学。

1.1 从源文件直接转：Pandoc 的主战场

所谓“源文件直接转”，是让工具直接读取.tex源文件，解析 LaTeX 宏与语法树，再映射成 Word 的 Open XML 结构。Pandoc 就是这个阵营的典型代表——它本质上是一个文档格式转换的瑞士军刀，支持的格式多到夸张，但核心价值在于把结构转译过去，而不是把排版像素级搬运过去。

这个路线的特点非常鲜明：转换速度快、公式会被转成 Word 原生公式（Word 2007 之后引入的 OMML 格式，可编辑可重排），交叉引用的编号逻辑会被尽力保留。但它也有一个致命短板——它要求源文件足够“纯洁”。如果你在.tex里用了大量自定义宏、\newcommand封装、特殊文档类，或者依赖了只有某个期刊模板里才有的环境，Pandoc 就会开始摆烂：要么直接报错，要么输出一堆不三不四的纯文本。

我见过太多人抱怨“Pandoc 转出来和原文不是一个东西”，结果一问，源文件里塞了五六个自定义环境，这种锅确实不能全让 Pandoc 背。

1.2 从 PDF 反向还原：公式与版式的不可逆困局

另一条常见路线是把编译好的 PDF 当中间产物，再用 OCR/版面分析工具“还原”成 Word。这条路线的典型代表是各种“PDF to Word”在线工具，也包括现在一些号称“识别精度 99%”的 AI 工具。

坦率讲，这条路对纯文本和简单表格还能凑合，但一到公式密集的学术论文就非常尴尬。原因不复杂：PDF 里存的是矢量图形和文字轮廓，没有“这是数学表达式的一部分”这种语义信息。就算识别器把字符抠出来了，上下标、分数、积分上下限仍然极易错乱。更坑的是，公式在 PDF 里一旦被识别成图片，Word 里就只能看不能改，导师想给你改个符号都无从下手。

只要你的核心诉求是“保留公式的可编辑性”，PDF 反向还原这条路从一开始就走错了。它只适合那种“源文件已经搞丢了、只剩 PDF”的极端场景。

1.3 结构化中间件方案：以 ai2word 为代表的“检测-重建”思路

最近一两年冒出来的 ai2word 这类工具，走的是第三条路：先读取 PDF 或者源文件的版面结构，检测出标题层级、公式区域、表格框线、图表位置，再按照 Word 的样式体系“重建”一份文档。你可以把它理解为“先读懂内容，再重新排版”，而不是“把一种格式硬译成另一种格式”。

这个思路的好处是：对复杂版式的容忍度更高，能处理跨栏、浮动体、算法伪代码这类让 Pandoc 头疼的结构。但它也有明显代价——一是耗时明显比纯 Pandoc 长，二是“重建”出来的排版和原文常常只有“神似”，细节处需要人工回归检查。另一个很现实的问题是，这类工具多部署在云端，你的稿件要经过对方的服务器，在论文未发表、涉及一稿多投风险时，这不是所有人都能接受的。

明白了这三条路线的本质区别，后面所有的工具选型、参数调优、坑位排查，你才有了判断坐标系。不然你跟风装了一堆工具，也只是在更大范围内撞运气。

2. 环境准备与最小可复现流程：Pandoc 从安装到跑通

既然 Pandoc 是自建工作流里性价比最高的起点，这一节我先带你把最基础的转换链路跑通，后面再谈高级玩法。

2.1 Pandoc 安装与版本选择

Pandoc 的安装没什么技术含量，但版本选择有一点讲究。官网发布的安装包有大版本之分，我建议优先选择 3.x 系列，不要再用 2.x。原因有两点：3.x 对 OMML 公式输出的处理更成熟，且内置了更多与 LaTeX 宏包兼容的解析规则；如果你写 Lua filter，3.x 的 API 也更稳定。

以 Windows 为例，三步装完：

• 前往 Pandoc 官网下载.msi安装包（或通过 winget 安装：winget install --id JohnMacFarlane.Pandoc）
• 安装完成后，打开命令行输入pandoc --version确认版本
• 顺便确认一下pandoc命令是否在 PATH 内，如果提示找不到，手动把安装目录加入系统环境变量

Mac 用户用brew install pandoc即可，Linux 用户直接用发行版仓库里的包也行，但 Ubuntu 仓库版本往往偏旧，需要新特性时建议手动装二进制。

2.2 最小命令与转换效果基线

先把输出做一个明确约定：所有转换都用 docx 作为目标格式，不要轻易尝试用.rtf过渡，后者在 Windows 和 Mac 上打开效果差异太大。

最简单的一条命令长这样：

pandoc paper.tex -o paper.docx

这条命令跑完，你会得到一份能打开、但大概率不完美的 Word 文档。我强烈建议在正式转换之前，先准备一份“最小可复现样例”——只包含标题、一段正文、一个公式、一个表格、一条引用，先把基线效果摸清楚，再对完整论文上手段。否则你拉一整篇论文进去，出了问题连定位都困难。

2.3 公式、交叉引用与表格：第一轮实测

基线跑完之后，我建议你立刻用样例检查三个关键点，这三处几乎决定了论文剩下的命数。

第一，公式是否转成了可编辑的对象。打开 Word，点击公式，看上方功能区是否出现“公式工具”设计选项卡。如果出现，说明是 OMML 原生公式；如果没有，只出现了图片工具栏，说明公式被转成了图片，这也是后续要重点规避的。

第二，交叉引用是否保持了动态编号。在 LaTeX 里写\ref{fig:xxx}的地方，Word 中最好能出现一个可以右键“更新域”的序号，而不是死文本。这一点 Pandoc 做得比较微妙，后面第三节细说。

第三，表格是否丢失了框线。Word 默认的表格样式可能和 LaTeX 来源差异明显，早期版本的 Pandoc 转出的表格甚至连竖线都没有，得靠--reference-doc指定模板来修复。

我把 Pandoc 转 Word 常见输出结果整理成了下面这张速查表，方便你对照判断自己当前处于什么状态：

3. 公式乱码、表格错位与模板崩溃：实战中的 Top 5 大坑与排查链路

这一节是全篇的重头戏，我把这些年高频踩中的坑按“从源头到结果”的顺序摆出来，每个都给出可复现的排查思路，而不是直接甩一个补丁让你贴上去。

3.1 公式从 OMML 变图片的隐藏开关

前文提到公式可能变成图片，但要命的是，很多时候你打开 Word 看到公式“长得挺像公式”，右键却发现没有“公式对象”的编辑能力，只能当成图来缩放。这个状况的本质原因，是 Pandoc 在解析某些 LaTeX 数学环境时选择了回退方案。

排查链路是这样的：

1. 先用pandoc paper.tex -o debug.md把中间态导成 Markdown，看公式区域被解析成了什么形态。如果还是$$...$$，说明 Pandoc 根本没进入数学模式。
2. 检查源文件里是否用了\begin{equation}之外的非标环境，比如\begin{dcases}、\begin{rcases}，这些需要mathtools宏包支持，Pandoc 对它们的支持不完整，一旦解析失败就会退回图片或纯文本。
3. 检查是否有宏定义把数学环境重新包装过。Pandoc 解析的是“语法树”，如果你写了\newcommand{\eq}[1]{\begin{equation}#1\end{equation}}，它很可能只认识最外层的\newcommand而不知道内部的 equation 环境。

最常用的修复手段是在转换时追加--webtex或者--gladtex这类外部渲染参数——但注意，这会把公式渲染成图片，和我们的目标正好相反。所以遇到复杂宏，我通常优先选择预处理源文件，把自定义宏展开，而不是在转换参数上死磕。这一步很土，但非常好用，而且可预测。

3.2 交叉引用编号失效：label/ref 的“翻译”损失

LaTeX 的交叉引用依赖两次编译，第一次记录 label 位置，第二次把 ref 替换成编号。Pandoc 没有“两次编译”的概念，它只能在单次解析中尽量识别\label和\ref的关系。

如果你跑了基础命令之后发现所有引用编号都是 0，或者干脆原样输出了\ref{fig:xxx}字符串，大概率是以下原因：

• 源文件没有启用\section这类带编号的标题结构，Pandoc 无法建立编号上下文。
• 你用的是\autoref、\cref这类需要cleveref宏包的引用命令，Pandoc 原生不认识。
• 表格/图表的 label 写在\caption内部，解析顺序导致 label 没有挂到正确节点上。

我的做法是：转换后打开 Word，用快捷键Ctrl+A全选，再按F9手动更新全部域。如果更新后编号正确，那就说明交叉引用其实已经被翻译成了 Word 的书签域，只是预览没刷新。Pandoc 在这方面没有坏的那么彻底，多数时候是“静态数字 + 书签域”的组合，你只需要接受它不能像 LaTeX 那样自动双向同步的事实。

3.3 表格列宽失控与自动换行问题：一个隐藏的 XML 空间问题

这是热搜里“word 表格列宽无法拖动”的高频成因之一——不是 Word 抽风，而是转出来的表格列宽被固定死了。

LaTeX 里用tabularx自动分配列宽，到 Word 里对应的是“表格属性”中的“固定列宽”。Pandoc 在转译时并不会精确还原 LaTeX 的列宽算法，它只会把每个单元格的内容塞进宽度基本一致的列，结果就是中文论文里常见的现象：某一列被拉得特别宽，另一列文字堆成一根细线。

热词里还有一个很有意思的细节：“word关闭卡顿”。很多人没意识到，这跟表格也有直接关系。如果你转出的文档里表格内嵌了大量自动计算的高度和固定宽度，Word 在打开和关闭时要一遍遍重新布局这些表格，Windows 上老版本 Word 尤其明显。

排查和修复链路：

1. 打开 XML 检查器（把 docx 后缀改成 rar，打开word/document.xml），看<w:tblW>的w:type是auto还是dxa。
2. 如果是固定宽度，在 Word 里全选表格，右键“表格属性”，把“度量单位”改成“百分比”，再把“指定宽度”取消勾选。
3. 更好的做法是提前准备一个reference.docx，在模板里定义一种“全宽自适应表格”样式，让 Pandoc 输出时自动套用。

3.4 中文模板与字体回退：从“乱码”到“字体全变宋体加粗”

如果你和我一样处理中文论文，一定会撞上这个问题：正文里明明该用“宋体小四”，转出来的 Word 却把标题、正文、表格全部裁成同一种西文字体；黑体字变成加粗宋体；英文和数字在中文段落里的行距忽大忽小。

这事的根因不在 Pandoc 本身，而在它的默认reference.docx模板里只定义了少量西文样式。中文论文需要的“正文/标题/图表标题”多级样式，默认模板里根本没有对应物。如果什么都不配，Pandoc 会把所有段落映射到Normal和Heading 1-6，字体族则沿用默认的西文字体属性。

修复思路是造一个专属的reference.docx模板。你先用命令pandoc -o custom-reference.docx --print-default-data-file reference.docx导出默认模板，然后在 Word 里打开它，把“正文”样式修改为“宋体小四”、把“标题 1”改成“黑体三号居中”，保存为reference.docx。后续转换都加上：

pandoc paper.tex -o paper.docx --reference-doc=mytemplate.docx

这样转出来的文档从样式根上就符合中文排版习惯，而不是转完再逐段改字体。这个模板是一次性投入，之后整个实验室都可以复用——我也是把做好的模板扔到共享盘之后，师弟师妹们才真正开始觉得 Pandoc 好用。

3.5 Word 关闭卡顿的元凶可能在你转出的文档里

“Word 关闭时卡顿，打开正常”这个现象在收到转出来的 docx 时特别容易触发。我在一台老 Windows 10 上复现过，卡顿点最终定位到了文档里的修订记录和域代码上。

Pandoc 转出的 docx 虽然本身不带修订，但它转出的交叉引用域、目录域、书签域在 Word 关闭时会触发“更新文档信息”的操作。如果文档里嵌入了大量高分辨率图片（这些图片在 LaTeX 里被裁剪过但没压缩），Word 关闭时要重新计算缩略图缓存，就会卡好几秒甚至弹出“程序无响应”。

一个偏实用的排查链路：

1. 先把文档另存为.docx的“启用宏的副本”扩展名，再另存回普通.docx，确认卡顿是否仍复现。如果消失了，说明问题是域计算或宏残留。
2. 全选所有图片，压缩一次（Word 自带“压缩图片”功能，选“电子邮件（96 ppi）”即可），再测试关闭速度。
3. 在 Word 选项里关闭“保存时更新域”和“打开时更新自动链接”，这是个全局选项，改完之后对同一台机器上的所有文档生效。
4. 终极排查：复制文档到一台全新机器测试，排除是本地 Word 加载项冲突。

这一套走完，90% 的卡顿都能定位到原因，剩下的 10% 属于 Word 自身对超大文档的老问题，只能靠拆分为多文件来规避。

4. Pandoc 与 ai2word 深度横评：谁更适合你的论文场景

最近 ai2word 的热度确实高，很多没深挖技术细节的朋友直接把它和 Pandoc 放在一起比“谁转得更像”。这种比较其实不成立，它俩根本不是同一种工作方式。这一节我用三个核心维度做对比，最后给一份明确的选型建议。

4.1 转换质量对比：公式、图表、参考文献

先说结论：在“标准 LaTeX 论文”场景下（即使用常见宏包、普通 article 文档类、单栏或双栏），Pandoc 的公式转换质量依然是王者。原因我在第一节说过，Pandoc 是语法树级别的转换，公式是真正的 OMML 数学对象；而 ai2word 走的是版面识别，公式从识别器出来之后，即便是内嵌公式也会被拆成字符块，上标下标经常被降级成普通文本。

但反过来，在“复杂版式”场景下，ai2word 的优势就出来了。比如双栏论文、带算法伪代码的计算机论文、含复杂浮动体的排版，Pandoc 的裸转往往会把双栏变成单栏、浮动体乱跳，而 ai2word 因为先做版面切分，至少能保持“左右分栏”和“图表在原位附近”的观感。

参考文献是一个容易被低估的差异点。Pandoc 配合--citeproc能把你.bib里的条目转成 Word 尾注/脚注，并且保留超链接；ai2word 更多是识别 PDF 尾部的参考文献文本，直接拼成一段纯文本段落，条目之间的引用关系会丢失。如果期刊要求 Word 版必须带结构化参考文献索引，Pandoc 会省很多事。

4.2 批量处理与私有化部署：一个被忽略的分水岭

这一条对我来说是决定性因素：能不能批量跑、能不能本地跑。

Pandoc 是命令行工具，意味着它可以被嵌套进脚本、Makefile、持续集成流程。我写过一个脚本，把实验室 “uploads” 文件夹里的.tex每五分钟扫描一次，新文件自动转换并重命名后投到共享目录，全程不需要人盯。这种自动化能力，对服务多作者场景几乎是刚需。

ai2word 则往往是独立安装的客户端或者 Web 应用，一次处理一个文件。它最大的价值在“交互式调整”，比如你可以在界面上拉框修正识别区域，但对于“几百份稿件统一过一遍”这种需求，它就显得笨重。反过来，如果你只有一两份论文要转，且源文件已经丢了，那批量能力对你没有意义，交互式修正反而是刚需。

4.3 隐私与合规：为什么我不建议把未发表论文上传云端

这是必须摊开说的一点。LaTeX 论文在正式见刊前，往往涉及一稿多投的合规风险、同行评议的匿名性、未公开数据的敏感性。Pandoc 是纯本地工具，转换全程你的文件不出桌面，这点让我用得非常安心。而多数 ai2word 服务需要你把 PDF 或.tex传到云端处理，传上去之后数据怎么存储、是否用于模型训练、多久删除，服务条款里经常写得含糊。

我个人的底线是：未发表的、带审稿人编号的、含未公开实验数据的论文，一律不上传任何云端转换服务。真要用 ai2word 这类工具，我会先等到论文正式见刊、数据已公开，再拿公开版本去转换。这里面不存在技术问题，纯粹是风险偏好问题，但这一步选错，后面出了事故真的追悔莫及。

4.4 我给出的选型建议

直接给结论，省得你纠结：

5. 进阶实操：从 LaTeX 到 Word 的高保真工作流

横评完之后，我把自己实际跑通的整套流程放在这里。这套流程我用了两年，帮我从“转完就想删号”进化到“十分钟交付一份能看能改的 Word 版”。

5.1 参考文献：用 citeproc 而非硬编码

如果源文件用的是\cite{xxx}，别让 Pandoc 直接输出[1]这种死编号。正确姿势是配合 Citeproc 处理：

pandoc paper.tex --citeproc --bibliography=refs.bib \ --csl=ieee.csl -o paper.docx

--csl用于指定参考文献样式，可以从 Zotero 样式仓库下载你需要的期刊样式。这样转出来的 Word 里，参考文献是一个真正的编号列表，正文中的引用是超链接，点击能跳转。这一步看着不起眼，但评审专家真的要一个一个点过去核对文献时，体验天差地别。

5.2 用 Lua filter 修复自定义环境和跨引用

Pandoc 3.x 的 Lua filter 是救急神器。举个例子，很多期刊模板定义了\newcommand{\figref}[1]{Figure~\ref{#1}}，Pandoc 不认识，就会原样输出。你可以写一个极简 filter 把它翻译成Figure \ref{#1}：

function RawInline(el) if el.format == 'tex' and el.text:match('\\figref') then local ref = el.text:match('\\figref{(.-)}') return pandoc.Str('Figure '), pandoc.Str(ref) end end

再复杂一些的自定义环境，比如\begin{protocol}这种论文方法书写的套壳环境，你也可以在 filter 里把它展开成标准的 description 或 blockquote。这样源文件不需要动，转换时加上--lua-filter=fix.lua即可。

5.3 转换后的最终打磨清单

转换完成不代表结束，最后五分钟的检查直接决定交付质量。我每次都会打印下面这张清单，一项项打勾：

• [ ] 打开 Word，全选按F9强制更新所有域，确认目录不为空
• [ ] 点击 3 个代表性公式，确认能进入公式编辑器修改
• [ ] 检查图片是否全部显示，点击看路径里是否有本地绝对路径，有就说明嵌入失败
• [ ] 滚动到参考文献页，确认条目数、排序和正文引用能对上
• [ ] 随机跳转一个表格，右键“表格属性”确认列宽不是固定死值
• [ ] 把文档发给一个不装 LaTeX 工具链的同事，让他打开试一下关闭是否卡顿
• [ ] 检查审阅工具栏，确认没有残留修订记录和批注

这套清单跑下来，几乎能过滤掉我过去踩过的所有雷。

写在最后：别急着做“完美转换”，先想清楚交付目标

我和很多朋友聊过之后发现，大家之所以在 LaTeX 转 Word 上反复受挫，根源往往不是工具不行，而是没想清楚这次转换到底要服务哪个目标。如果目标是在 Word 里继续可编辑地写论文，那你必须优先保证公式原生可编辑，宁可牺牲一点视觉；如果目标是给导师快速批注，那只需要段落结构完整、批注方便，公式是不是原生反倒次要；如果目标是被期刊编辑部收走排版，那可能根本不该用自动转换，而是直接用他们提供的 Word 模板重新过一遍。

搞清楚这个前提，再去选 Pandoc、ai2word，还是干脆手动重建，你的决策成本会低很多。

最后分享一个自己用了很久的小技巧：我电脑上常备一个只包含“标题、正文、一个 equation 环境、一个 tikz 图和一份引用样例”的最小测试文件。任何新版本 Pandoc、任何新下载的模板，我先拿它跑一遍基线，确认没有引入新的退化再上完整论文。这个习惯救过我三次——有一次 Pandoc 更新后表格解析出了兼容性问题，我一跑基线就发现了，根本不用拿整篇论文去试错。工具会迭代，坑会翻新，但把返工成本前置的这套工作思路，什么时候都不过时。