简介《Manuscript》是一款以“手稿”为主题的字体资源包面向需要复古手写氛围的设计师、排版人员及日常文档处理者。压缩包为RAR格式共3个文件包含TTF字体文件、HTM说明页面与GIF预览图整体体积仅45KB轻量易用。其中TTF为TrueType标准字体兼容Windows与macOS系统无需额外配置即可在Word、Photoshop、Illustrator等主流软件中直接选用。在数字排版中字体决定文本的视觉风格手写体既适合用作封面标题、章节引文也能为演示文稿或个人笔记增添温度。资源附带的说明文档会给出字体安装与适用的基本信息预览图则展示不同字符的形态方便用户快速评估效果。目前已有293人学习下载适合在平面设计、文档美化、文创周边或自媒体配图中使用让普通文字呈现“手稿”般的自然质感是轻量级视觉素材的有益补充。1. 稿件管理不等于写 Word这套工作流在解决什么问题“Manuscript”这个词在技术写作里经常被提起但真正把它落地成一整套可复现流程的人并不多。我见过太多人在 Word 里把一篇稿件改上十几版文件名从“最终稿”变成“最终稿2”再变成“最终稿再改”最后合作方要的就是你最初那一版而你根本找不回来。问题的根源不是写作能力而是工具链Word 的 .docx 是压缩包里的 XML 加二进制对象没法做细粒度 diff多人同时编辑必然出现“谁改了哪一段”的混乱。文本化稿件工作流的核心就是把稿件当成源码来管理——用 Markdown 或 LaTeX 写正文用 Git 管版本用 pandoc 渲染投稿格式。它能解决的三个具体问题是修订可追溯每一次改动都有记录、格式可复现同一份源文件输出不同期刊格式、协作不打架改同一段落会有冲突提示。适合需要多轮修改、多作者协作而且对排版没有特殊执念的工程师和研究者不适合只写一次、直接交付终稿的短平快需求。2. 选型先行Markdown、LaTeX、BibTeX 各司其职在动手写稿件之前先把格式选型定下来你会少走至少一半弯路。很多人在第一步就纠结“要不要直接用 LaTeX 写”这个问题的答案取决于你的交付场景而不是别人的推荐。2.1 为什么不用 Word 做稿件源文件先解释一个最常被问的问题为什么源文件不用 Word三个字后悔药。Word 的 .docx 本质是压缩包里的 XML 加二进制对象Git 拿到它没法展示有意义的差异——你看到的是整行二进制差异而不是“第 47 行改动了一个单词”。这意味着你失去了版本控制最核心的能力精确回滚。你只能在 Word 自带的修订模式里改但修订历史的粒度是“人/时间”而不是“逻辑改动”多人协作时修订记录合并起来比源码冲突还难看。另一个问题是排版与内容耦合。在 Word 里文字的格式字号、间距、样式和内容混在一起。当你需要把同一篇稿件投给 A 期刊和 B 期刊而它们的模板各不相同你就得手工调整两遍格式如果被退回要求重投又是一个下午。文本源文件把内容和格式彻底分离Markdown 只承载内容LaTeX 模板只承载排版渲染时两者合在一起换期刊等于换模板正文一行不用改。我并不是说 Word 一无是处。如果最终交付必须上传 docx你完全可以从文本源渲染出 docx 交出去只是别把 Word 当作保存内容的源文件。2.2 三种源格式的分工与边界我一般会把稿件工作流拆成三层各管一件事Markdown 管正文标题、段落、列表、代码块、行内引用语法简单人眼可读适合日常写作和审阅。BibTeX 管文献只存著录信息作者、年份、标题、期刊、卷期页码正文只写引用键wang2024method换引用样式只换 CSL 文件不碰正文。LaTeX 模板管版式期刊要求的页边距、字号、图注格式、参考文献样式全部收进模板文件pandoc 渲染时调用。这里有个容易混淆的点LaTeX 并不是必须用来写正文的。很多人一上来就用 LaTeX 写全篇结果图表浮动、换行断裂、公式排版反复调试改到心态崩溃。我的建议是正文用 Markdown 写只有当数学公式特别多或者最终交付必须用 LaTeX 模板时才让 pandoc 在渲染阶段把 Markdown 转成 LaTeX。公式本身在 Markdown 里用$...$写pandoc 能识别。这个分工的好处是职责单一写作时你不会去想排版交付前你不会担心内容被格式搞乱。边界也清楚Markdown 里不出现任何与字体、间距、页边距有关的指令LaTeX 模板里只写版式规则不掺内容判断。具体场景怎么选可以参考这个简单对照你的情况推荐组合目标期刊收 Word公式不多Markdown 正文 BibTeX 渲染成 docx目标期刊有 LaTeX 模板公式较多Markdown 正文 BibTeX LaTeX 模板渲染 PDF数学公式密度极高全篇推导直接 LaTeX 写正文但仍然用 Git 管版本如果你落到了第三档下面两章的 Git 和渲染思路依然适用只是把 Markdown 换成.tex文件而已。2.3 一个可落地的仓库目录结构选型定完下一步是建目录结构。这是我常用的方式针对单个稿件manuscript/ ├── src/ # 正文源文件按章节拆分 │ ├── 00-abstract.md │ ├── 01-introduction.md │ ├── 02-methods.md │ ├── 03-results.md │ └── 04-discussion.md ├── figures/ # 插图按章节编号 │ ├── fig1-flowchart.png │ ├── fig2-loss-curve.png │ └── fig3-ablation-study.png ├── references/ │ ├── refs.bib # BibTeX 文献库 │ └── style.csl # 参考文献样式 ├── templates/ │ ├── journal-a.tex # 目标期刊 A 的 LaTeX 模板 │ └── journal-b.tex # 目标期刊 B 的 LaTeX 模板 ├── output/ # 渲染产物不入库 │ ├── paper-journal-a.pdf │ └── paper-journal-b.docx ├── README.md # 仓库说明和构建命令 └── Makefile # 自动化构建入口这个结构的逻辑是三段式src/放你真正要写的东西figures/和references/放不参与写作的素材templates/放版式规则output/是每次构建生成的导出文件。注意output/目录不纳入 Git 管理因为它是反复生成的入库只会让仓库越来越脏。初始化仓库时我用这几条命令cd manuscript git init . # 在当前目录创建仓库 git add src/ figures/ references/ templates/ README.md Makefile # 只纳入源码和素材 git commit -m 初始化稿件仓库结构参数说明git init后加.明确指明当前目录git add指定的路径里我刻意没有放output/对应.gitignore里要写一行output/。.gitignore至少要有下面四类output/ # 渲染产物不入库 *.aux # LaTeX 编译中间文件 *.log # 编译日志 *.out # LaTeX 辅助文件 .DS_Store # macOS 系统噪音.aux、.log、.out是 LaTeX 相关工具链编译时产生的中间文件DS_Store是 macOS 的目录索引文件这些都不该进版本历史。把这句话记下来仓库里只放能人工读懂的文件机器生成的东西一律不进去。3. 写稿与版本管理的日常操作提交、标签与三件套写法目录建好之后真正的写作开始了。这一章说的是每天怎么写、怎么提交、怎么保证几周后还能看懂自己在改什么。3.1 从大纲到章节拆文件与组合规则写稿件的第一个动作不是打开编辑器敲第一句话而是把大纲拆成文件。拆文件的标准我一般看两条按逻辑边界拆按合稿顺序排。逻辑边界指的是每一章引言、方法、结果、讨论天然是一个独立单元它们之间的依赖关系弱各自篇幅相对稳定适合放一个文件而如果一个章节超过 3000 字我宁愿拆成两三个子文件比如02-methods.md拆成02a-experiment-setup.md和02b-evaluation.md避免单个文件越来越难维护。组合规则靠文件名前缀按数字排序。pandoc 在接收多个文件时会按命令行顺序合并我直接用 shell 的展开符按名称排序传入# 按文件名顺序合并所有章节输出单个 Markdown pandoc src/*.md -o output/paper-combined.mdsrc/*.md会展开成按字母序排列的文件列表00-、01-、02-这种零填充前缀保证章节顺序稳定。不加零填充的话10-会排在2-前面顺序就乱了。写作时的段落不要贪长。Markdown 里段落之间用空行分隔每段四到六行逻辑上一个小节一个论点。这样做的直接收益是 Git 的 diff 更干净——你改一段diff 只显示那一段的改动而不是大块重写。3.2 用 Git 把修改记录从「一团乱麻」变成「提交历史」稿件的版本管理核心不复杂就是一条原则每次逻辑性改动一次提交每次提交一句能看懂的消息。我习惯的节奏是写完一段有实质内容的段落后就提交一次。提交信息按“动宾结构”写比如feat: 补充实验组设置的细节、fix: 更正结果章节的统计描述。不要写Update manuscript.md这种等于没写的信息——三个月后回看你根本不知道这次改了什么。# 只暂存真正改过的文件提交信息描述改动内容 git add src/03-results.md git commit -m fix: 更正结果章节的统计描述p0.05 改为 p0.032除了常规提交还有一个容易被忽略但很重要的动作打标签。稿件在演进过程中有几个关键节点——初稿完成、第一次投出、收到返修意见、修改稿完成——这些节点应该用 tag 固定下来git tag v1.0-draft # 初稿完成 git tag v1.1-submitted # 第一次投出 git tag v2.0-revision # 修改稿完成tag 的意义在于它给你一个永久的历史锚点。哪怕后来改得面目全非你随时可以用git checkout v1.0-draft回去看当初投出的版本——这正是 Word 时代做不到的“后悔药”。另外建议每轮大修改单独拉一个分支比如revision-round-2主分支永远保持“能编译、能渲染”的稳定状态。改崩了随时丢弃分支不会污染主线。3.3 图表、表格与公式三件套的基本写法写完文字接下来是稿件里最容易出问题的三个组件。先说图片。图片我建议全部放在figures/目录正文用相对路径引用{#fig:loss width75%}这里{#fig:loss}是交叉引用标签width75%是渲染时控制尺寸。重点说一个坑路径。如果你写成figures/fig2-loss-curve.png这是相对于项目根的路径pandoc 合并多文件时工作目录默认是项目根所以这个写法在任何章节文件里都能用不会因文件位置变化而失效。表格在 Markdown 里用管道语法写| 模型 | 准确率 | 参数量 | |------|--------|-------| | A | 92.3% | 1.2M | | B | 95.1% | 4.8M |这种写法在预览器里能看到大致形状渲染成 LaTeX 时由 pandoc 转成tabular环境。对齐方式需要微调的话我一般放到渲染阶段处理正文阶段不折腾排版。公式是最容易翻车的部分。行内公式用$...$独立公式用$$...$$损失函数定义为 $\mathcal{L} -\sum_{i} y_i \log p_i$ $$ \mathcal{L}_{total} \lambda_1 \mathcal{L}_{cls} \lambda_2 \mathcal{L}_{reg} $$pandoc 在把 Markdown 转成 LaTeX 时会原样保留$...$之间的内容所以你用 LaTeX 数学语法写是没问题的。但注意别在行内公式里放复杂分式或求和号渲染时容易被强制内联而溢出边界——我的习惯是凡是长度超过一行的公式全部改成独立公式块行内只留最简短的符号引用。4. 渲染与导出用 pandoc 把 Markdown 变成投稿格式正文写完了仓库里攒了一堆.md和.bib文件接下来要完成关键一跳把这些文本源文件渲染成编辑看得懂的投稿格式。这一章的三个小节分别对应渲染、版式和文献最后补充一个字数验证技巧。4.1 最小 pandoc 命令与输出目录规范我先把日常最常用的一条 pandoc 命令贴出来后面所有操作都从它扩展# 合并章节并渲染为 PDF处理中文需要 xelatex 引擎 pandoc src/*.md \ --pdf-enginexelatex \ --outputoutput/paper-draft.pdf \ --citeproc \ --bibliographyreferences/refs.bib \ --cslreferences/style.csl \ -V mainfontSource Han Serif SC \ -V geometry:margin2.5cm这条命令的逻辑是并入各个章节文件然后用 xelatex 引擎渲染 PDF。重点说三个参数--pdf-enginexelatex是处理中文稿件的关键。默认的 pdflatex 不识别 Unicode 字体只有 xelatex 能调用系统字体。后面的-V mainfontSource Han Serif SC指定正文中文字体这个字体名必须和你系统里安装的名字完全一致差一个空格都不行。Windows 上如果你装的是“宋体”或“微软雅黑”就填对应名称fc-list :langzh可以列出系统可用中文字体。--citeproc让 pandoc 调用内置引文处理器配合--bibliography和--csl完成参考文献格式化。--csl指定引用样式你想让参考文献变成编号制还是作者年份制完全由 CSL 文件决定不用动正文。CSL 文件可以从开源样式库下载你目标期刊对应的版本。--outputoutput/paper-draft.pdf把产物写到output/目录——既然是构建产物就留在仓库之外。统一走output/的另一个好处是跨平台协作时不会把临时文件混进源文件目录合作者一眼就能分清哪些是写的、哪些是生成的。4.2 用 LaTeX 模板控制版式pandoc 默认的 LaTeX 输出是比较朴素的样式想匹配某个期刊的模板你需要一个自定义模板文件。模板本质上是一段 LaTeX 代码里面定义了页边距、字号、标题样式、图注位置、参考文献格式等。pandoc 渲染时把你的 Markdown 内容嵌进模板的正文区最终生成完整的 LaTeX 文档。最常见的做法是找到目标期刊提供的 LaTeX 模板把它已有的\documentclass、页边距设置、标题宏包保留把写死的正文内容替换为 pandoc 的占位符$body$。% templates/journal-a.tex \documentclass[review]{article} \usepackage[utf8]{inputenc} \usepackage{graphicx} \usepackage[margin2.2cm]{geometry} \usepackage{booktabs} \usepackage[fontsmall]{caption} \usepackage{xeCJK} \setCJKmainfont{Source Han Serif SC} \begin{document} $if(title)$ \begin{center} {\LARGE \textbf{$title$}}\\[1em] $for(author)$ $author$ $endfor$ \end{center} $endif$ $body$ \end{document}说明$title$、$author$、$body$是 pandoc 模板变量渲染时自动替换。调用模板的命令是加一个--template参数pandoc src/*.md \ --templatetemplates/journal-a.tex \ --pdf-enginexelatex \ --citeproc \ --bibliographyreferences/refs.bib \ --cslreferences/style.csl \ -o output/paper-journal-a.pdf花十几分钟把模板调好之后每次投稿就只需要跑这一条命令。调整模板时最常见的迭代是调字号、间距和参考文献格式要有耐心。但换来的是同一篇稿件换期刊只换一行命令效率提升非常明显。这里有一个关键提醒拿到期刊模板后第一件事是先用原始 LaTeX 文件跑一遍确认它本身能编译。然后再动手改成 pandoc 模板。跳过这步出了问题你根本判断不了是模板原样就坏了还是你改坏了。4.3 参考文献与引用BibTeX 的接入参考文献是这套工作流里最值得投入的部分。维护好一个.bib文件你之后写任何稿件都直接从中取用不用再手工敲一遍参考文献列表。.bib文件的记录格式是article{wang2024method, author {Wang, Xiao and Li, Jun}, title {A Novel Method for ...}, journal {Journal of ...}, year {2024}, volume {15}, pages {100--120} }正文里引用就用键名[wang2024method]在 Markdown 里插入位置随意该方法的性能显著优于已有基线 [wang2024method]。渲染时--citeproc会把引用替换成正文中的编号或作者年份同时在文末生成完整的参考文献列表。换格式只改.bib换样式只换.csl正文永远不用动。养成一个硬性习惯.bib文件里每篇文献的唯一键名统一用“作者姓氏年份首词”的规则命名。否则攒到几百条时引用键混乱会让你花大量时间在库里翻记录。我见过有人在.bib里用paper1、paper2命名三个月后自己都不知道paper1是哪篇文献。4.4 验证输出字数与页数控制投稿前你需要知道两件事字数是否符合要求页数是否超出限制。字数统计直接用命令行# 统计所有章节文件的字数合计 wc -w src/*.mdwc -w统计的是空白分隔的词数对英文准确中文稿件建议用wc -m按字符数统计然后和期刊要求核对。页数控制则靠模板里的几何设置geometry:margin2.5cm改小页边距能增加每页容量fontsize11pt或12pt调整字号。这些参数放在模板文件里而不是正文里就是你修改页数时的第一调整对象。5. 稿件工作流避坑指南四个高频问题的现象、原因与解决工作流本身是简单的真正消磨意志的是各种边角问题。这一章列了四个我实际见过的坑都按“现象 → 原因 → 解决”写清楚。5.1 现象中文乱码PDF 里汉字变成豆腐块渲染出的 PDF 里中文全是方框或乱码。原因分两类一是--pdf-engine没切到 xelatex默认的 pdflatex 处理不了 UTF-8 中文字符二是 xelatex 找不到对应字体或者字体名写错。解决方法是先确认引擎再确认字体。# 列出系统中可用的中文字体名 fc-list :langzh | head -20运行结果是字体名列表把-V mainfont后面的值改成和你系统实际名称一致。注意字体名必须精确匹配大小写、空格都算。如果你在 Linux 服务器上部署这套工作流还需要先安装中文字体包否则fc-list结果为空。5.2 现象图片路径失效渲染出的 PDF 里图全是空的报错信息通常是File not found或者渲染出来只有一行路径文字。原因几乎总是相对路径基准搞错了。前面说过pandoc 连续处理多个文件时工作目录是项目根图片路径要基于项目根写。但当你把章节文件移动到子目录时相对路径会连带失效。# 让 pandoc 按多个目录依次搜索图片资源 pandoc src/*.md \ --resource-path.:src:figures \ ...--resource-path告诉 pandoc 去哪些目录找图:分隔多个路径顺序就是搜索优先级。加上这个参数后即使章节文件里的图片路径写的是局部相对路径也能被正确解析。如果你用了 4.1 的figures/约定其实已经规避了大部分问题但加这个参数仍是双保险。5.3 现象Git 合并冲突时中文内容没乱码但冲突标记看不懂多人改同一段时Git 会插入一个冲突提示中文字符被转义成\xE8这类序列根本没法直观对比。原因不是编码问题而是 Git 默认的冲突标记样式在中文场景下不友好。解决方法是换成 diff3 冲突样式# 让冲突标记包含公共祖先版本更容易理解三方差异 git config --global merge.conflictstyle diff3diff3风格的冲突标记会显示“我改的 对方改的 公共祖先”三个区域比默认的两段式多一个基准上下文。如果还是觉得乱我一般用带三方合并界面的编辑器打开冲突文件边看边手工合并。对比plain和diff3的区别时重点看公共祖先部分——它告诉你双方是基于哪个旧版本改的这是消除误解的关键。5.4 现象期刊模板自带宏包和 pandoc 生成的代码冲突这个坑最隐蔽表现是编译报错报错信息指向一个根本不显眼的宏。原因在于期刊模板往往自带大量宏包和文档类选项其中可能对figure、table环境做了自定义而 pandoc 生成的 LaTeX 代码走的是通用路径两者撞上后行为不可预测。我的解决策略是“最小化模板改造”不要拿期刊原版模板的完整代码做 pandoc 模板只取它的\documentclass行、页边距、标题宏包、参考文献样式这几个必要部分手工拼一个精简模板。这样既满足期刊对版式的要求又减少多余代码和 pandoc 发生冲突的可能。测试时每个改动单独编译一次确认无误再继续不要一次性堆叠所有修改。6. 把工作流收口自动化构建与交付前三分钟检查到这里工作流已经能支撑一个完整稿件的写作、修改和交付。最后一章说的是怎么让它自动跑起来以及交付前短时间内能做完的验证。6.1 用 Makefile 收口构建命令手敲 pandoc 长命令不是不行但每次都要输入一堆参数容易遗漏。我最终会写一个 Makefile 把命令收口PDF output/paper-target.pdf .PHONY: all pdf clean all: pdf # 渲染目标 PDF pdf: pandoc src/*.md \ --templatetemplates/journal-a.tex \ --pdf-enginexelatex \ --citeproc \ --bibliographyreferences/refs.bib \ --cslreferences/style.csl \ -o $(PDF) # 清理生成的产物 clean: rm -f output/*.pdf output/*.docxMakefile 的好处是合作者不需要记 pandoc 参数只需要会跑make pdf。如果你的团队里有不熟悉命令行的合作者把make pdf写在 README 的第一行就行。6.2 多作者协作从单人工作流到多人不慌单人工作流跑通之后多作者协作是很自然的下一步。核心原则是每个人在自己的分支上改合并时写清楚合并信息。git checkout -b feature/fix-results # 拉出功能分支 # 在分支上修改 src/03-results.md提交多次 git checkout main # 回到主分支 git merge feature/fix-results # 合并回主分支多人协作最怕的是同改一个段落Git 会报冲突。冲突不是错误而是 Git 在保护历史。解决冲突时用 5.3 节的 diff3 风格三方对照逐行决定保留谁的版本。如果双方改动的是不同章节Git 会自动合并连提示都不会有——这就是拆文件的回报。6.3 交付前三分钟检查清单临交付前我会跑一遍下面的检查清单每一项都有明确动作编译检查跑make pdf确认零报错警告清零或至少没有 undefined reference。字数检查wc -w src/*.md汇总和期刊限制比对。图片检查ls figures/对照正文里的图引用确认没有缺失图。引用检查渲染后的 PDF 里逐个点开参考文献位置确认没有 missing citation。版本记录git log --oneline | head -20看最近提交确认当前提交对应了心里的最终版本。我自己的习惯是每次投稿前把当前的 commit 短哈希写在投稿备注里比如submission-commit: a1b2c3d。这样哪怕几个月后收到返修意见我也能立刻git checkout a1b2c3d找回当初投出的那一版而不是在文件名后缀里迷路。这套稿件工作流本质上是用工程化的方式对抗写作中的不确定性。它不提高你的写作水平但它保证你不会在格式、版本和协作上消耗无谓的时间。希望这篇文章能让你少踩一些我踩过的坑也希望你从下一份稿件开始试着离开 Word 源文件把节奏掌握在文本和 Git 手里。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/11 2:48:44 · 阅读 1.2k 用Git和pandoc管理学术稿件：从Word到纯文本工作流
简介《Manuscript》是一款以“手稿”为主题的字体资源包面向需要复古手写氛围的设计师、排版人员及日常文档处理者。压缩包为RAR格式共3个文件包含TTF字体文件、HTM说明页面与GIF预览图整体体积仅45KB轻量易用。其中TTF为TrueType标准字体兼容Windows与macOS系统无需额外配置即可在Word、Photoshop、Illustrator等主流软件中直接选用。在数字排版中字体决定文本的视觉风格手写体既适合用作封面标题、章节引文也能为演示文稿或个人笔记增添温度。资源附带的说明文档会给出字体安装与适用的基本信息预览图则展示不同字符的形态方便用户快速评估效果。目前已有293人学习下载适合在平面设计、文档美化、文创周边或自媒体配图中使用让普通文字呈现“手稿”般的自然质感是轻量级视觉素材的有益补充。1. 稿件管理不等于写 Word这套工作流在解决什么问题“Manuscript”这个词在技术写作里经常被提起但真正把它落地成一整套可复现流程的人并不多。我见过太多人在 Word 里把一篇稿件改上十几版文件名从“最终稿”变成“最终稿2”再变成“最终稿再改”最后合作方要的就是你最初那一版而你根本找不回来。问题的根源不是写作能力而是工具链Word 的 .docx 是压缩包里的 XML 加二进制对象没法做细粒度 diff多人同时编辑必然出现“谁改了哪一段”的混乱。文本化稿件工作流的核心就是把稿件当成源码来管理——用 Markdown 或 LaTeX 写正文用 Git 管版本用 pandoc 渲染投稿格式。它能解决的三个具体问题是修订可追溯每一次改动都有记录、格式可复现同一份源文件输出不同期刊格式、协作不打架改同一段落会有冲突提示。适合需要多轮修改、多作者协作而且对排版没有特殊执念的工程师和研究者不适合只写一次、直接交付终稿的短平快需求。2. 选型先行Markdown、LaTeX、BibTeX 各司其职在动手写稿件之前先把格式选型定下来你会少走至少一半弯路。很多人在第一步就纠结“要不要直接用 LaTeX 写”这个问题的答案取决于你的交付场景而不是别人的推荐。2.1 为什么不用 Word 做稿件源文件先解释一个最常被问的问题为什么源文件不用 Word三个字后悔药。Word 的 .docx 本质是压缩包里的 XML 加二进制对象Git 拿到它没法展示有意义的差异——你看到的是整行二进制差异而不是“第 47 行改动了一个单词”。这意味着你失去了版本控制最核心的能力精确回滚。你只能在 Word 自带的修订模式里改但修订历史的粒度是“人/时间”而不是“逻辑改动”多人协作时修订记录合并起来比源码冲突还难看。另一个问题是排版与内容耦合。在 Word 里文字的格式字号、间距、样式和内容混在一起。当你需要把同一篇稿件投给 A 期刊和 B 期刊而它们的模板各不相同你就得手工调整两遍格式如果被退回要求重投又是一个下午。文本源文件把内容和格式彻底分离Markdown 只承载内容LaTeX 模板只承载排版渲染时两者合在一起换期刊等于换模板正文一行不用改。我并不是说 Word 一无是处。如果最终交付必须上传 docx你完全可以从文本源渲染出 docx 交出去只是别把 Word 当作保存内容的源文件。2.2 三种源格式的分工与边界我一般会把稿件工作流拆成三层各管一件事Markdown 管正文标题、段落、列表、代码块、行内引用语法简单人眼可读适合日常写作和审阅。BibTeX 管文献只存著录信息作者、年份、标题、期刊、卷期页码正文只写引用键wang2024method换引用样式只换 CSL 文件不碰正文。LaTeX 模板管版式期刊要求的页边距、字号、图注格式、参考文献样式全部收进模板文件pandoc 渲染时调用。这里有个容易混淆的点LaTeX 并不是必须用来写正文的。很多人一上来就用 LaTeX 写全篇结果图表浮动、换行断裂、公式排版反复调试改到心态崩溃。我的建议是正文用 Markdown 写只有当数学公式特别多或者最终交付必须用 LaTeX 模板时才让 pandoc 在渲染阶段把 Markdown 转成 LaTeX。公式本身在 Markdown 里用$...$写pandoc 能识别。这个分工的好处是职责单一写作时你不会去想排版交付前你不会担心内容被格式搞乱。边界也清楚Markdown 里不出现任何与字体、间距、页边距有关的指令LaTeX 模板里只写版式规则不掺内容判断。具体场景怎么选可以参考这个简单对照你的情况推荐组合目标期刊收 Word公式不多Markdown 正文 BibTeX 渲染成 docx目标期刊有 LaTeX 模板公式较多Markdown 正文 BibTeX LaTeX 模板渲染 PDF数学公式密度极高全篇推导直接 LaTeX 写正文但仍然用 Git 管版本如果你落到了第三档下面两章的 Git 和渲染思路依然适用只是把 Markdown 换成.tex文件而已。2.3 一个可落地的仓库目录结构选型定完下一步是建目录结构。这是我常用的方式针对单个稿件manuscript/ ├── src/ # 正文源文件按章节拆分 │ ├── 00-abstract.md │ ├── 01-introduction.md │ ├── 02-methods.md │ ├── 03-results.md │ └── 04-discussion.md ├── figures/ # 插图按章节编号 │ ├── fig1-flowchart.png │ ├── fig2-loss-curve.png │ └── fig3-ablation-study.png ├── references/ │ ├── refs.bib # BibTeX 文献库 │ └── style.csl # 参考文献样式 ├── templates/ │ ├── journal-a.tex # 目标期刊 A 的 LaTeX 模板 │ └── journal-b.tex # 目标期刊 B 的 LaTeX 模板 ├── output/ # 渲染产物不入库 │ ├── paper-journal-a.pdf │ └── paper-journal-b.docx ├── README.md # 仓库说明和构建命令 └── Makefile # 自动化构建入口这个结构的逻辑是三段式src/放你真正要写的东西figures/和references/放不参与写作的素材templates/放版式规则output/是每次构建生成的导出文件。注意output/目录不纳入 Git 管理因为它是反复生成的入库只会让仓库越来越脏。初始化仓库时我用这几条命令cd manuscript git init . # 在当前目录创建仓库 git add src/ figures/ references/ templates/ README.md Makefile # 只纳入源码和素材 git commit -m 初始化稿件仓库结构参数说明git init后加.明确指明当前目录git add指定的路径里我刻意没有放output/对应.gitignore里要写一行output/。.gitignore至少要有下面四类output/ # 渲染产物不入库 *.aux # LaTeX 编译中间文件 *.log # 编译日志 *.out # LaTeX 辅助文件 .DS_Store # macOS 系统噪音.aux、.log、.out是 LaTeX 相关工具链编译时产生的中间文件DS_Store是 macOS 的目录索引文件这些都不该进版本历史。把这句话记下来仓库里只放能人工读懂的文件机器生成的东西一律不进去。3. 写稿与版本管理的日常操作提交、标签与三件套写法目录建好之后真正的写作开始了。这一章说的是每天怎么写、怎么提交、怎么保证几周后还能看懂自己在改什么。3.1 从大纲到章节拆文件与组合规则写稿件的第一个动作不是打开编辑器敲第一句话而是把大纲拆成文件。拆文件的标准我一般看两条按逻辑边界拆按合稿顺序排。逻辑边界指的是每一章引言、方法、结果、讨论天然是一个独立单元它们之间的依赖关系弱各自篇幅相对稳定适合放一个文件而如果一个章节超过 3000 字我宁愿拆成两三个子文件比如02-methods.md拆成02a-experiment-setup.md和02b-evaluation.md避免单个文件越来越难维护。组合规则靠文件名前缀按数字排序。pandoc 在接收多个文件时会按命令行顺序合并我直接用 shell 的展开符按名称排序传入# 按文件名顺序合并所有章节输出单个 Markdown pandoc src/*.md -o output/paper-combined.mdsrc/*.md会展开成按字母序排列的文件列表00-、01-、02-这种零填充前缀保证章节顺序稳定。不加零填充的话10-会排在2-前面顺序就乱了。写作时的段落不要贪长。Markdown 里段落之间用空行分隔每段四到六行逻辑上一个小节一个论点。这样做的直接收益是 Git 的 diff 更干净——你改一段diff 只显示那一段的改动而不是大块重写。3.2 用 Git 把修改记录从「一团乱麻」变成「提交历史」稿件的版本管理核心不复杂就是一条原则每次逻辑性改动一次提交每次提交一句能看懂的消息。我习惯的节奏是写完一段有实质内容的段落后就提交一次。提交信息按“动宾结构”写比如feat: 补充实验组设置的细节、fix: 更正结果章节的统计描述。不要写Update manuscript.md这种等于没写的信息——三个月后回看你根本不知道这次改了什么。# 只暂存真正改过的文件提交信息描述改动内容 git add src/03-results.md git commit -m fix: 更正结果章节的统计描述p0.05 改为 p0.032除了常规提交还有一个容易被忽略但很重要的动作打标签。稿件在演进过程中有几个关键节点——初稿完成、第一次投出、收到返修意见、修改稿完成——这些节点应该用 tag 固定下来git tag v1.0-draft # 初稿完成 git tag v1.1-submitted # 第一次投出 git tag v2.0-revision # 修改稿完成tag 的意义在于它给你一个永久的历史锚点。哪怕后来改得面目全非你随时可以用git checkout v1.0-draft回去看当初投出的版本——这正是 Word 时代做不到的“后悔药”。另外建议每轮大修改单独拉一个分支比如revision-round-2主分支永远保持“能编译、能渲染”的稳定状态。改崩了随时丢弃分支不会污染主线。3.3 图表、表格与公式三件套的基本写法写完文字接下来是稿件里最容易出问题的三个组件。先说图片。图片我建议全部放在figures/目录正文用相对路径引用{#fig:loss width75%}这里{#fig:loss}是交叉引用标签width75%是渲染时控制尺寸。重点说一个坑路径。如果你写成figures/fig2-loss-curve.png这是相对于项目根的路径pandoc 合并多文件时工作目录默认是项目根所以这个写法在任何章节文件里都能用不会因文件位置变化而失效。表格在 Markdown 里用管道语法写| 模型 | 准确率 | 参数量 | |------|--------|-------| | A | 92.3% | 1.2M | | B | 95.1% | 4.8M |这种写法在预览器里能看到大致形状渲染成 LaTeX 时由 pandoc 转成tabular环境。对齐方式需要微调的话我一般放到渲染阶段处理正文阶段不折腾排版。公式是最容易翻车的部分。行内公式用$...$独立公式用$$...$$损失函数定义为 $\mathcal{L} -\sum_{i} y_i \log p_i$ $$ \mathcal{L}_{total} \lambda_1 \mathcal{L}_{cls} \lambda_2 \mathcal{L}_{reg} $$pandoc 在把 Markdown 转成 LaTeX 时会原样保留$...$之间的内容所以你用 LaTeX 数学语法写是没问题的。但注意别在行内公式里放复杂分式或求和号渲染时容易被强制内联而溢出边界——我的习惯是凡是长度超过一行的公式全部改成独立公式块行内只留最简短的符号引用。4. 渲染与导出用 pandoc 把 Markdown 变成投稿格式正文写完了仓库里攒了一堆.md和.bib文件接下来要完成关键一跳把这些文本源文件渲染成编辑看得懂的投稿格式。这一章的三个小节分别对应渲染、版式和文献最后补充一个字数验证技巧。4.1 最小 pandoc 命令与输出目录规范我先把日常最常用的一条 pandoc 命令贴出来后面所有操作都从它扩展# 合并章节并渲染为 PDF处理中文需要 xelatex 引擎 pandoc src/*.md \ --pdf-enginexelatex \ --outputoutput/paper-draft.pdf \ --citeproc \ --bibliographyreferences/refs.bib \ --cslreferences/style.csl \ -V mainfontSource Han Serif SC \ -V geometry:margin2.5cm这条命令的逻辑是并入各个章节文件然后用 xelatex 引擎渲染 PDF。重点说三个参数--pdf-enginexelatex是处理中文稿件的关键。默认的 pdflatex 不识别 Unicode 字体只有 xelatex 能调用系统字体。后面的-V mainfontSource Han Serif SC指定正文中文字体这个字体名必须和你系统里安装的名字完全一致差一个空格都不行。Windows 上如果你装的是“宋体”或“微软雅黑”就填对应名称fc-list :langzh可以列出系统可用中文字体。--citeproc让 pandoc 调用内置引文处理器配合--bibliography和--csl完成参考文献格式化。--csl指定引用样式你想让参考文献变成编号制还是作者年份制完全由 CSL 文件决定不用动正文。CSL 文件可以从开源样式库下载你目标期刊对应的版本。--outputoutput/paper-draft.pdf把产物写到output/目录——既然是构建产物就留在仓库之外。统一走output/的另一个好处是跨平台协作时不会把临时文件混进源文件目录合作者一眼就能分清哪些是写的、哪些是生成的。4.2 用 LaTeX 模板控制版式pandoc 默认的 LaTeX 输出是比较朴素的样式想匹配某个期刊的模板你需要一个自定义模板文件。模板本质上是一段 LaTeX 代码里面定义了页边距、字号、标题样式、图注位置、参考文献格式等。pandoc 渲染时把你的 Markdown 内容嵌进模板的正文区最终生成完整的 LaTeX 文档。最常见的做法是找到目标期刊提供的 LaTeX 模板把它已有的\documentclass、页边距设置、标题宏包保留把写死的正文内容替换为 pandoc 的占位符$body$。% templates/journal-a.tex \documentclass[review]{article} \usepackage[utf8]{inputenc} \usepackage{graphicx} \usepackage[margin2.2cm]{geometry} \usepackage{booktabs} \usepackage[fontsmall]{caption} \usepackage{xeCJK} \setCJKmainfont{Source Han Serif SC} \begin{document} $if(title)$ \begin{center} {\LARGE \textbf{$title$}}\\[1em] $for(author)$ $author$ $endfor$ \end{center} $endif$ $body$ \end{document}说明$title$、$author$、$body$是 pandoc 模板变量渲染时自动替换。调用模板的命令是加一个--template参数pandoc src/*.md \ --templatetemplates/journal-a.tex \ --pdf-enginexelatex \ --citeproc \ --bibliographyreferences/refs.bib \ --cslreferences/style.csl \ -o output/paper-journal-a.pdf花十几分钟把模板调好之后每次投稿就只需要跑这一条命令。调整模板时最常见的迭代是调字号、间距和参考文献格式要有耐心。但换来的是同一篇稿件换期刊只换一行命令效率提升非常明显。这里有一个关键提醒拿到期刊模板后第一件事是先用原始 LaTeX 文件跑一遍确认它本身能编译。然后再动手改成 pandoc 模板。跳过这步出了问题你根本判断不了是模板原样就坏了还是你改坏了。4.3 参考文献与引用BibTeX 的接入参考文献是这套工作流里最值得投入的部分。维护好一个.bib文件你之后写任何稿件都直接从中取用不用再手工敲一遍参考文献列表。.bib文件的记录格式是article{wang2024method, author {Wang, Xiao and Li, Jun}, title {A Novel Method for ...}, journal {Journal of ...}, year {2024}, volume {15}, pages {100--120} }正文里引用就用键名[wang2024method]在 Markdown 里插入位置随意该方法的性能显著优于已有基线 [wang2024method]。渲染时--citeproc会把引用替换成正文中的编号或作者年份同时在文末生成完整的参考文献列表。换格式只改.bib换样式只换.csl正文永远不用动。养成一个硬性习惯.bib文件里每篇文献的唯一键名统一用“作者姓氏年份首词”的规则命名。否则攒到几百条时引用键混乱会让你花大量时间在库里翻记录。我见过有人在.bib里用paper1、paper2命名三个月后自己都不知道paper1是哪篇文献。4.4 验证输出字数与页数控制投稿前你需要知道两件事字数是否符合要求页数是否超出限制。字数统计直接用命令行# 统计所有章节文件的字数合计 wc -w src/*.mdwc -w统计的是空白分隔的词数对英文准确中文稿件建议用wc -m按字符数统计然后和期刊要求核对。页数控制则靠模板里的几何设置geometry:margin2.5cm改小页边距能增加每页容量fontsize11pt或12pt调整字号。这些参数放在模板文件里而不是正文里就是你修改页数时的第一调整对象。5. 稿件工作流避坑指南四个高频问题的现象、原因与解决工作流本身是简单的真正消磨意志的是各种边角问题。这一章列了四个我实际见过的坑都按“现象 → 原因 → 解决”写清楚。5.1 现象中文乱码PDF 里汉字变成豆腐块渲染出的 PDF 里中文全是方框或乱码。原因分两类一是--pdf-engine没切到 xelatex默认的 pdflatex 处理不了 UTF-8 中文字符二是 xelatex 找不到对应字体或者字体名写错。解决方法是先确认引擎再确认字体。# 列出系统中可用的中文字体名 fc-list :langzh | head -20运行结果是字体名列表把-V mainfont后面的值改成和你系统实际名称一致。注意字体名必须精确匹配大小写、空格都算。如果你在 Linux 服务器上部署这套工作流还需要先安装中文字体包否则fc-list结果为空。5.2 现象图片路径失效渲染出的 PDF 里图全是空的报错信息通常是File not found或者渲染出来只有一行路径文字。原因几乎总是相对路径基准搞错了。前面说过pandoc 连续处理多个文件时工作目录是项目根图片路径要基于项目根写。但当你把章节文件移动到子目录时相对路径会连带失效。# 让 pandoc 按多个目录依次搜索图片资源 pandoc src/*.md \ --resource-path.:src:figures \ ...--resource-path告诉 pandoc 去哪些目录找图:分隔多个路径顺序就是搜索优先级。加上这个参数后即使章节文件里的图片路径写的是局部相对路径也能被正确解析。如果你用了 4.1 的figures/约定其实已经规避了大部分问题但加这个参数仍是双保险。5.3 现象Git 合并冲突时中文内容没乱码但冲突标记看不懂多人改同一段时Git 会插入一个冲突提示中文字符被转义成\xE8这类序列根本没法直观对比。原因不是编码问题而是 Git 默认的冲突标记样式在中文场景下不友好。解决方法是换成 diff3 冲突样式# 让冲突标记包含公共祖先版本更容易理解三方差异 git config --global merge.conflictstyle diff3diff3风格的冲突标记会显示“我改的 对方改的 公共祖先”三个区域比默认的两段式多一个基准上下文。如果还是觉得乱我一般用带三方合并界面的编辑器打开冲突文件边看边手工合并。对比plain和diff3的区别时重点看公共祖先部分——它告诉你双方是基于哪个旧版本改的这是消除误解的关键。5.4 现象期刊模板自带宏包和 pandoc 生成的代码冲突这个坑最隐蔽表现是编译报错报错信息指向一个根本不显眼的宏。原因在于期刊模板往往自带大量宏包和文档类选项其中可能对figure、table环境做了自定义而 pandoc 生成的 LaTeX 代码走的是通用路径两者撞上后行为不可预测。我的解决策略是“最小化模板改造”不要拿期刊原版模板的完整代码做 pandoc 模板只取它的\documentclass行、页边距、标题宏包、参考文献样式这几个必要部分手工拼一个精简模板。这样既满足期刊对版式的要求又减少多余代码和 pandoc 发生冲突的可能。测试时每个改动单独编译一次确认无误再继续不要一次性堆叠所有修改。6. 把工作流收口自动化构建与交付前三分钟检查到这里工作流已经能支撑一个完整稿件的写作、修改和交付。最后一章说的是怎么让它自动跑起来以及交付前短时间内能做完的验证。6.1 用 Makefile 收口构建命令手敲 pandoc 长命令不是不行但每次都要输入一堆参数容易遗漏。我最终会写一个 Makefile 把命令收口PDF output/paper-target.pdf .PHONY: all pdf clean all: pdf # 渲染目标 PDF pdf: pandoc src/*.md \ --templatetemplates/journal-a.tex \ --pdf-enginexelatex \ --citeproc \ --bibliographyreferences/refs.bib \ --cslreferences/style.csl \ -o $(PDF) # 清理生成的产物 clean: rm -f output/*.pdf output/*.docxMakefile 的好处是合作者不需要记 pandoc 参数只需要会跑make pdf。如果你的团队里有不熟悉命令行的合作者把make pdf写在 README 的第一行就行。6.2 多作者协作从单人工作流到多人不慌单人工作流跑通之后多作者协作是很自然的下一步。核心原则是每个人在自己的分支上改合并时写清楚合并信息。git checkout -b feature/fix-results # 拉出功能分支 # 在分支上修改 src/03-results.md提交多次 git checkout main # 回到主分支 git merge feature/fix-results # 合并回主分支多人协作最怕的是同改一个段落Git 会报冲突。冲突不是错误而是 Git 在保护历史。解决冲突时用 5.3 节的 diff3 风格三方对照逐行决定保留谁的版本。如果双方改动的是不同章节Git 会自动合并连提示都不会有——这就是拆文件的回报。6.3 交付前三分钟检查清单临交付前我会跑一遍下面的检查清单每一项都有明确动作编译检查跑make pdf确认零报错警告清零或至少没有 undefined reference。字数检查wc -w src/*.md汇总和期刊限制比对。图片检查ls figures/对照正文里的图引用确认没有缺失图。引用检查渲染后的 PDF 里逐个点开参考文献位置确认没有 missing citation。版本记录git log --oneline | head -20看最近提交确认当前提交对应了心里的最终版本。我自己的习惯是每次投稿前把当前的 commit 短哈希写在投稿备注里比如submission-commit: a1b2c3d。这样哪怕几个月后收到返修意见我也能立刻git checkout a1b2c3d找回当初投出的那一版而不是在文件名后缀里迷路。这套稿件工作流本质上是用工程化的方式对抗写作中的不确定性。它不提高你的写作水平但它保证你不会在格式、版本和协作上消耗无谓的时间。希望这篇文章能让你少踩一些我踩过的坑也希望你从下一份稿件开始试着离开 Word 源文件把节奏掌握在文本和 Git 手里。希望帮到你。本文还有配套的精品资源点击获取