Word迁移LaTeX：日常文档写作的高效工作流实践

我第一次动真格从 Word 迁移到 LaTeX是在一份项目报告被格式反复折腾到第 17 版的时候。那不是学术写作就是一份需要长期维护、反复评审、改数字、插图表、最后还要转 PDF 给客户看的日常文档。Word 确实能完成但每次“看起来差不多了”之后又有人改了一句图表位置、目录页码、表格宽度全都要手动再排一遍改到后面已经不叫写作叫拼图。后来我把整个写作流切到 LaTeX一口气用了两年现在连技术方案、会议纪要、学习笔记都跑在同一套流程上。这套流程的核心并不玄妙用 TeX Live 做编译引擎用 VS Code 写源文件用 Git 管版本用 BibTeX 管参考文献。它并不是学术论文专属任何需要长期维护、频繁修改、多版本输出的文档其实都适合。数学公式、交叉引用、自动目录这些 LaTeX 的天然优势只是附加值真正改变体验的是“内容”和“排版”终于分家了。下面我把从 Word 到 LaTeX 的完整迁移过程拆开讲包括环境搭建、VS Code 配置、内容迁移和一堆实测后躲开的坑所有操作都按我自己的使用顺序来。1. 为什么我在写了十年 Word 之后切换到 LaTeX1.1 排版失控当文档变成“改动一下就崩”的脆弱系统被 Word 折磨过的人应该都懂这个场景一份一百多页的文档图表、公式、三线表混排某天需要在大段落里插入两句话按下回车之后后面的图片全部漂到下一页图题编号乱掉目录页码对不上甚至正文里的某条表格被拉到页面外。问题是 Word 在每次保存时都保留了你手动调整的“痕迹”但这些调整之间没有稳定的逻辑关系。图片位置是偏移量表格宽度是拖拽结果间距是用回车和空格“垫”出来的任何一个小改动都可能引发连锁反应。我在很长一段时间里把它归咎为“自己用得不够熟练”。后来经验多了才意识到这是可视化排版工具的结构性缺陷你把“内容”和“样式”揉在一起看着所见即所得实际上每次编辑都要在不同层级之间维持微妙的平衡。LaTeX 换了一种思路源文件里只有语义化标记比如\section{背景}、\begin{figure}、\label{fig:架构图}版式由文档类和宏包统一控制。你不需要关心某个图具体拖到哪一页编译器会按照浮动体规则给出稳定的结果。当然LaTeX 不是没有学习曲线刚上手时那种“为了一个空格找半天”的感觉也很真实。但当你手里是一个跨月甚至跨年维护的文档时LaTeX 的确定性就完全值回票价。同一个源文件今天编译和三个月后编译版式是一模一样的你修改了标题长度目录自动重新生成你删掉两张图所有引用编号自动更新。这种“编译后始终保持一致”的体验是 Word 无论如何微调都很难做到的。1.2 Word 的隐形协作成本很多人忽略的另一个痛点是协作。Word 的协作方式通常是“你把文件发给我我改完发给你你再改完发回给我”。如果两个人同时改最后只能面对两个分叉的版本再痛苦地手动合并。更常见的是文件名变成“最终版 v3修订.docx”“最终版 v4 又改.doc”这种天文命名法等到第五天你根本不知道哪个才是最新的。LaTeX 的源文件是纯文本这个问题被降维解决。你可以把.tex文件丢进 Git 仓库每个人在自己的分支上改最后合并或者把文档托管到支持 Git 的平台上所有历史版本都留下记录。甚至不需要 Git只用一个最原始的方法——两个版本的.tex文件丢进 diff 工具也能迅速看到每一行的增删改。相比之下Word 的“修订模式”虽然能追踪改动但真正到了比对两个独立版本的时候体验依然很痛苦。我并不是说所有人都要立刻学会 Git而是想强调日常写作中“协作”发生的频率比你想象的高。报告要发给同事补数据方案要给领导提意见论文要给导师修改——LaTeX 配合 Git 后改动变成一条条清晰的提交记录谁改了什么、为什么改打开历史一目了然。这种透明度对个人写作也有好处你能看到自己一周前写的内容和今天有什么不同而不是对着一个不可逆的 Word 文件后悔。1.3 LaTeX 解决问题的思路其实是为写作建立确定性说到底LaTeX 的核心不是“排版更漂亮”而是让整个写作过程变得更可预测。Word 把写作和排版揉在一起你一边写一边排写到一半往往被格式打断LaTeX 让你先专注内容写完之后编译一次版式自动生成。哪怕你中途需要插入一行复杂公式也不需要像在 Word 里那样反复调对齐、设制表位、处理公式与文字的间距直接写$Emc^2$就完事。这种确定性的另一个表现是错误会被显式地暴露出来。Word 里图片错乱、编号错误你可能肉眼都看不出来LaTeX 遇到问题通常会在编译日志里给出提示找不到图、缺宏包、引用未定义都有明确线索。诚然编译报错一开始会吓退新人但当你熟悉日志后会发现这比“排版莫名其妙坏了但不知道坏在哪”要高效得多。我也理解很多人担心 LaTeX 写“日常文档”太重。但今天的工具链已经把门槛降得很低VS Code 里装一个 LaTeX Workshop 插件保存后自动编译PDF 预览就在旁边Synctex 还能让你双击 PDF 跳回源码。它不再是你印象里那个只能在校样系统里运行的古老工具而是一个完全适合日常写作的工作流。下面我就从环境搭建开始把它一步步落地。2. 环境搭建TeX Live、清华镜像和 VS Code 的一次到位配置2.1 TeX Live 还是 MiKTeX日常写作怎么选搭建环境最常见的问题是选发行版。如果你搜“latex 安装教程”大概率会看到 TeX Live、MiKTeX 和 MacTeX 几个名字。MacTeX 本质上是 macOS 下的 TeX Live 套件不用多说真正的选择往往落在 TeX Live 和 MiKTeX 之间。对比项TeX LiveMiKTeX跨平台Windows / Linux / macOSWindows / Linux / macOS包管理tlmgr内置包管理器缺包策略全量安装基本不缺包按需自动安装安装体积较大但省心较小按需下载日常写作推荐度高中我自己的选择是 TeX Live而且是全量安装。理由很简单日常写作最怕的就是“编译器提示缺宏包”。TeX Live 装完后绝大多数常见宏包都已经在本地不需要装到一半去 CTAN 下载。MiKTeX 的按需安装很方便但第一次编译时可能临时下载宏包遇到网络缓慢会很烦躁。而且 TeX Live 的版本一致性更好团队协作时大家用同一个版本踩坑概率更低。2.2 清华镜像加速下载每条命令都值得讲清楚在国内安装 TeX Live最省心的方式是用清华大学的 CTAN 镜像。官网默认服务器在国外直接下载容易慢到让人失去耐心。用清华镜像可以把数 GB 的安装包下载速度提到本地宽带的极限。在 Windows 上你只需要到镜像站下载install-tl-windows.exe双击运行后把安装源切到https://mirrors.tuna.tsinghua.edu.cn/CTAN/systems/texlive/tlnet接着选方案安装即可。注意安装过程中有一个“调整 PATH 环境变量”的选项一定要保持开启如果安装完之后在命令行敲latex提示找不到命令多半就是这一项没勾上。Linux 和 macOS 上用命令行更直接。以 Linux 为例wget https://mirrors.tuna.tsinghua.edu.cn/CTAN/systems/texlive/tlnet/install-tl.zip unzip install-tl.zip cd install-tl-* sudo perl install-tl --repository https://mirrors.tuna.tsinghua.edu.cn/CTAN/systems/texlive/tlnet安装结束后记得把 TeX Live 的 bin 目录加入 PATH。一般默认位置是/usr/local/texlive/2025/bin/x86_64-linux如果你用的是较新版本目录名里的年份会变。然后执行latex --version xelatex --version两条命令都能输出版本信息说明环境已经通了。Ubuntu 上安装还有一个常见坑系统可能自带了老的texlive-base和手动安装的 TeX Live 冲突。我建议先把系统包里的 texlive 相关包卸载干净再走镜像安装否则latex命令指向哪个版本会变得不可控。2.3 为什么我选择 VS Code 而不是 TeXstudio环境就绪之后要选编辑器。TeXstudio、TeXmaker、Overleaf 各有支持者但我最终固定在 VS Code 上。原因不是 VS Code 这个编辑器本身有多强而是它把“写文章”和“写代码”统一成了一个入口。我日常要写 Python、搞数据处理、维护 Markdown 笔记再开一个 TeXstudio 反而像来回切系统不舒服。VS Code 里装一个 LaTeX Workshop 插件就具备了一站式能力左侧能看到 PDF 预览右侧是源码保存自动编译带 SyncTeX 双向定位。它的配置项很多但日常用只需要关心几件事编译 recipe、PDF 查看器、同步开关。这个组合对初学者足够简洁对老手也能通过自定义命令和片段snippet扩展出无限可能。唯一需要接受的是它不会像 TeXstudio 那样“开箱即用”第一次配置大概要花十分钟但换来的是一个统一、可扩展的环境后面写中文、写公式、贴代码都顺滑不少。3. 日常写作流的核心一份能直接用起来的 VS Code 配置3.1 LaTeX Workshop 的核心参数与 settings.json 参考我直接贴一份我常用的.vscode/settings.json配置字段不多但每条都踩过坑才留下的{ latex-workshop.latex.recipes: [ { name: latexmk, tools: [latexmk] } ], latex-workshop.latex.tools: [ { name: latexmk, command: latexmk, args: [ -synctex1, -interactionnonstopmode, -file-line-error, -pdf, -outdir%OUTDIR%, %DOC% ] } ], latex-workshop.view.pdf.viewer: tab, latex-workshop.synctex.afterBuild.enabled: true }latexmk是很多人推荐的一套编译调度工具它会在后台处理多轮编译、索引、参考文献这些复杂顺序。-synctex1用于生成同步定位数据-interactionnonstopmode是让编译在出错时不要停在交互界面而是继续跑下去并输出日志这对日常写作很重要。-pdf表示输出 PDF-outdir可以指定生成目录避免 aux/log 文件堆在源码目录里。有一点需要注意LaTeX Workshop 的默认 recipe 可能使用pdflatex对于中文文档我建议在.tex文件第一行加上魔法注释% !TEX program xelatex这样latexmk就会知道用xelatex引擎编译中文支持也更稳定。如果你是英文文档用默认的pdflatex反而更快。这个魔法注释可以写在每个文件头部不影响正常编译。3.2 用 snippets 把高频公式和结构固化成快捷键日常写作里最高频的操作不是排版而是输入那些反复出现的结构。比如技术方案动辄要写几十个行内公式论文模板每章都要section、subsection。手动敲一遍太浪费VS Code 的 snippets 正好解决这个问题。在 VS Code 里按下 CtrlShiftP输入Preferences: Configure User Snippets选择latex然后加入我自己常用的一组{ Inline math: { prefix: mk, body: $${1:$0}$, description: 行内公式 }, Display math: { prefix: dm, body: \\[\n$1\n\\], description: 独立公式 }, Bra-Ket: { prefix: bk, body: \\langle ${1:\\psi} | ${2:\\phi} \\rangle, description: 左矢右矢 }, Section: { prefix: sec, body: \\section{${1:标题}}\n\n$0, description: 一级section } }这个bk片段就是解决“latex 怎么打出左矢和右矢”的快捷方式。如果你是物理或量子信息方向\langle和\rangle才是正确的尖括号而不是用。更省事的做法是在导言区加braket宏包\usepackage{braket}然后直接用\ket{\psi}\bra{\phi}\braket{\phi|\psi}。用 snippets 之后写结构的动作几乎变成了本能输入mk再按 Tab公式骨架就出来了不需要想命令名。3.3 行内公式、行距和中文渲染的细节处理在使用 LaTeX 写日常中文文档时行内公式经常会把行距撑大这和 Word 里公式导致行距变宽的体验很像。原因在于 TeX 在计算每行文字高度时会为公式保留比普通文字更大的高度导致行与行之间的间距看起来不均匀。有一个简单的全局调整手段\linespread{1.15}这个命令会把所有行距的整体比例拉大一些让公式带来的“突刺”没那么明显。如果你希望更精细可以单独调整公式间距\setlength{\abovedisplayskip}{6pt} \setlength{\belowdisplayskip}{6pt}需要注意\abovedisplayskip和\belowdisplayskip控制的是独立显示公式\[ \]在正文中的上下间距而不是行内公式。行内公式的行距问题最粗暴但有效的方式是用\linespread把整体行距调大一点让公式和文字之间不再打架。另一个常见问题是有人会把\everymath{\displaystyle}加进导言区希望所有行内公式都显示成大型运算符的样式。我劝你别这么做一旦公式变“大”行距无处可逃。日常写作里行内公式就该保持行内样式只有真正需要强调的推导才用\[ \]独立显示。中文渲染方面用ctex宏包基本可以解决\documentclass[12pt]{ctexart}它会自动配置中文字体和排版风格。如果系统中没有合适字体在 Linux 下可以安装fonts-noto-cjk来补充。4. 从 Word 迁移内容的实操公式、表格、图片与文档结构4.1 公式从 Word 到 LaTeX手打、转换与符号速查把 Word 里的公式搬到 LaTeX最常见的方式是手打。很多人一听“手打”就头大实际上 Word 公式编辑器包括 MathType内部也是用类似 TeX 的线性语法保存的。你看到的一个分式在 Word 的公式线性模式下会显示为类似a/b的样子而 LaTeX 只是把它写成\frac{a}{b}。多打几次肌肉记忆就建立了。另外现在有很多 OCR 工具可以直接把截屏公式转成 LaTeX 代码比如 Mathpix 这类不过免费额度有限。还有一个实用路径先用 Pandoc 把 Word 文档整体转成 Markdown公式会被转换成 LaTeX 风格的代码片段。我试过对一个 50 页的 Word 报告做 Pandoc 转换正文和目录基本干净公式大部分能识别但个别嵌套公式需要人工修一遍。转换后一定要抽查特别是\left\right配对和矩阵环境因为 Word 公式里的括号层级有时表达得不严格。这里列几个高频符号方便从 Word 迁移时快速对照语义LaTeX左矢\langle \psi \vert右矢\vert \psi \rangle求和\sum_{i1}^{n}分式\frac{a}{b}偏导\frac{\partial f}{\partial x}矩阵\begin{pmatrix} a b \\ c d \end{pmatrix}无穷小\mathrm{d}x4.2 表格单元格宽度与对齐告别 Word 里拖拽的噩梦Word 表格最折磨人的就是单元格宽度和对齐。你明明拖好了第一行紧接着在第二行输入一段长文本整个表格马上被撑变形。LaTeX 里处理这类问题有不同的思路用tabular做基本表格用p{宽度}指定固定列宽用tabularx让表格自适应页面宽度。举一个我在日常技术报告里常用的三线表写法\usepackage{tabularx} \renewcommand{\arraystretch}{1.2} \begin{tabularx}{\linewidth}{l X l} \toprule 项目 说明 优先级 \\ \midrule 日志系统 记录全部关键操作便于问题回溯 高 \\ 监控告警 针对核心指标配置阈值 中 \\ \bottomrule \end{tabularx}这里的X列会占据剩余宽度并自动换行不会因为内容长而把整张表撑爆。对列间距\setlength{\tabcolsep}{4pt}可以压缩左右 padding对行高\renewcommand{\arraystretch}{1.2}增加垂直留白。如果你是从 Word 表格迁移过来的我建议不要把已经有固定宽度的列直接照搬而是根据页面尺寸重新设计列宽比例效果会好很多。4.3 图片与浮动体如何让图和引用“听话”Word 里“图片动了”是高频崩溃点。LaTeX 里图片默认是浮动体会自动找合适的位置但第一次用的人经常抱怨图老跑。解决办法不是手动定位而是理解浮动机制htbp只是允许的位置选项编译器会综合排版压力决定最终位置。如果你希望图片严格出现在某一段落之后可以在导言区加载float宏包然后\begin{figure}[H] \centering \includegraphics[width0.8\linewidth]{figures/architecture.png} \caption{系统架构图} \label{fig:architecture} \end{figure}[H]表示“就在当前位置”几乎不会漂移。但不要全文到处用[H]否则图片会打散普通段落的连续感。更好的做法是给浮动体指定[htbp]然后在正文里用\ref{fig:architecture}引用它这样无论图标最终跑到哪读者都能通过“见图 3-2”快速找到。图片文件推荐统一放在figures/目录用相对路径引用方便整体复制到其他设备。我还建议把图片优先转成 PDF 或高分辨率 PNG。Word 里粘贴屏幕截图很简单但在 LaTeX 中模糊的位图放到 300dpi 以上会显得很难看。如果是画图工具导出的矢量图直接导出 PDF 再\includegraphics印刷级别也够用。5. 踩坑实录LaTeX 日常写作中绕不开的几个问题5.1 下划线在打字时保持不动LaTeX 里没有这么简单我看到检索热词里有“word 下划线上打字保持下划线不动”这个需求这其实是一个典型的 Word 使用习惯。在 Word 里你要做一条固定长度的下划线输入几个空格再加下划线格式然后在上面打字时下划线保持不动。对应的场景是表单、填空题、合同模板。在 LaTeX 里这个需求需要换一种思路下划线不是一个可以“持续输入”的格式而是一个排版元素。如果你的需求是“在一条固定长度的线上填字”可以用\underline{\hspace{3cm}}这会生成一条 3cm 的下划线但你不能直接在上面打字因为字符不会和这条线联动。如果想让文字出现在线的上方一个常见方案是用ulem宏包的\uline命令\usepackage{ulem} \uline{这是一段带下划线的文本}这里的\uline可以自动换行且在下划线底下不会断行比原生的\underline更适合长文本。如果你真的需要模拟“填空横线”可以使用\newcommand{\fillblank}[1][2cm]{\underline{\hspace{#1}}}调用\fillblank生成一个默认 2cm 的空白横线需要更长时传参\fillblank[4cm]。但你的答案内容要写在上方就得用\stackrel或\mathop这类数学环境的技巧日常文档里我通常直接把答案写在括号里而不是追求和 Word 一模一样的交互感受。这个差异是思路层面的不是技术层面。5.2 中文排版与字体的兼容问题LaTeX 新手最常栽的坑是中文乱码或编译失败。问题的根源大多是没有用xelatex或lualatex以及没有加载ctex宏包。如果你按照“latex 安装教程”装完 TeX Live然后新建一个文本文档直接写中文用默认的pdflatex编译大概率会报一堆字体错误。正确做法非常固定\documentclass[12pt]{ctexart} \begin{document} 中文写作测试。 \end{document}用xelatex或latexmk -xelatex编译。如果你是在 Linux 上系统里没有 Windows 宋体编译时可能提示找不到SimSun之类的字体。这时可以设置成系统已经安装的中文字体比如\setCJKmainfont{Noto Serif CJK SC}如果你使用 Obsidian、VS Code 或 Overleaf 远程编译尽量用ctex提供的默认字体方案它会根据操作系统自动选择合适的字体。另一个需要注意的点是中文文档的段落缩进和行距ctexart默认首行缩进两个汉字宽度这个规则符合中文排版习惯不需要额外调整。你只需要学会“用文档类而不是用一个宏包去解决中文问题”这个思路。5.3 编译报错后的排查路径从日志到最小示例LaTeX 的报错信息一开始确实晦涩但掌握了基本路径之后排查效率会远高于 Word 里“凭感觉修格式”。我的操作习惯是在文件头设置-interactionnonstopmode这样编译不会卡在某个错误上等待输入而是完整跑完并输出日志。出现问题时先在终端里搜索!开头的行比如! Undefined control sequence.它会告诉你报错的位置和涉及的命令。如果错误信息指向某个宏包先检查导言区是否漏了\usepackage如果指向某个命令比如\begin和\end不匹配检查环境的嵌套顺序。还有一种高频问题图找不到、路径错误这时日志里会出现File xxx.png not found而不会告诉你整个排版崩了。用 VS Code 时LaTeX Workshop 会在 Problems 面板列出解析后的错误点击可以跳到源码对应行。我的最后手段是创建最小示例MWE。如果一段代码单独放可以编译合到大文档里就报错大概率是宏包冲突或环境嵌套导致。我会复制一页左右的代码到新文件逐步注释掉宏包二分法定位出问题的那一行。这个方法看起来笨但可以节省大量时间而且也是向别人提问时的基本礼仪。掌握这套排查路径后LaTeX 学习曲线中最陡的一段就走过去了。6. 让写作流真正高效模板管理、Git 版本化与多人协作6.1 论文模板与期刊模板的选择策略如果你从 Word 写作切换到 LaTeX 是为了投稿模板选择格外重要。很多期刊和会议会直接提供.cls文件下载后放在源文件同目录然后用对应的\documentclass{xxx}和\usepackage就能开始写。不要自己去修改那份.cls文件模板里的样式常量往往已经经过编辑部验证改坏之后可能连审稿系统都会报错。中文期刊和学位论文方面通常可以搜到基于ctex的模板比如用ctexbook或ctexart做基础再配置页眉页脚、字体字号。选择模板时我只看三点一是最近有没有维护二是编译环境是否兼容我本地的 TeX Live 版本三是模板文档里有没有给出README或示例 PDF。看完这三个条件基本能避开八成“明明装了 LaTeX 但跑不通模板”的灾难。对于非学术的日常写作不需要追求复杂模板。自己维护一个main.tex和structure.sty就够了把常用的宏包、颜色、超链接配置、标题格式全放到.sty文件里。以后新建文档只需要\input{structure}写作流会非常轻盈。6.2 用 Git 管理写作回滚、分支和 diff 的威力用 LaTeX 写长文档如果不配合 Git等于只学会了一半。Git 对写作的价值在我这里甚至超过了对代码的价值。某天你删掉了整段论证、隔几天又想找回在 Word 里如果没留着历史版本基本没救在 Git 里一次git checkout就能回到任意提交点。建立仓库只需要几条命令git init git add main.tex structure.sty ref.bib figures/ git commit -m 初稿完成之后每完成一轮修改再提交一次。日常不用记太多 Git 命令会commit、diff、checkout这三个就够用了。git diff能直观展示两次提交之间每一行文本的变化这在检查“我到底改了什么”时极其好用。多人协作时每个人开一个分支写自己的部分写完合到主分支合并冲突会比 Word 里手工合并两个文件轻松得多。如果你的团队成员不熟悉 Git你也可以把 TeX 源文件放到一个共享网盘上配合编译出来的 PDF 进行版本管理。最理想的状态是大家只维护同一个.tex编译由一个人统一做避免“你编了一版、我编了一版”的混乱。6.3 与 Word/PDF 工作流共存交付给不需要 LaTeX 的人切换到 LaTeX 不代表你要和 Word 世界老死不相往来。很多合作方、客户、导师还是需要 Word 或 PDF 交付而这种交付其实很简单LaTeX 编译出来的 PDF 可以直接发出去排版和字体都足够专业。如果你必须提供 docx 格式Pandoc 是可以救场的pandoc main.tex -o output.docx不过对复杂文档「LaTeX 转 docx」并非完美无损公式可能变成图片浮动体位置可能要重新调。我的经验是对外交付以 PDF 为唯一正式版本如果对方坚持要 word我再单独用 Pandoc 生成一版初稿然后基于它做最后调整。反过来如果你收到别人给的 Word 文档也可以用 Pandoc 转成 Markdown 或 LaTeX再纳入自己的写作流。在真实团队里最终目标不是“全员学会 LaTeX”而是“写作者能在一个稳定可靠的工作流里产出内容交付给下游时不产生额外负担”。我的做法是团队内部统一用 LaTeX 写初稿定稿后自动编译 PDF任何人需要查看或批注都可以直接改用 Foxit 或 Acrobat 的注释功能批注反馈再回到.tex源文件修改。这套流程跑顺之后Word 里的“另存为 v3 改 v4”彻底消失团队协作也从混乱的版本整理中解放了出来。最后分享一个我自己一直在用的小技巧如果你最终仍然需要把内容交给一个只认 Word 的人不要尝试把一份已经排得很漂亮的 PDF 反推成 Word那样只会得到一堆混乱的文本框。更可靠的方式是在 LaTeX 里保持内容结构简单干净然后从源文件用 Pandoc 生成 docx再在 Word 里做最后的轻微调整。写作流这件事不一定非要非此即彼能灵活切换、让内容稳定沉淀下来的那一套才是真正适合你的那套。