企业官网建设流程全解析

简介：《手稿》（Manuscript）是一份与字体设计相关的RAR压缩资源，面向需要手写风格字体的平面设计师、文档排版人员及个人创作者，用于解决正文或标题中营造自然手写质感的问题。包内共3个文件，包含TTF字体文件、GIF格式的字体效果预览图以及一份HTM格式的说明文档，整体体积仅45KB，小巧易下载，适合快速试用手稿体并了解其应用场景。资源目前已有293人学习，说明其在字体下载与排版应用方面具备一定参考价值。解压后用户可直接安装TTF字体，通过预览图直观查看字形风格，并依据说明文档的提示在Word、Photoshop等软件中调用该字体，适合需要为个人笔记、海报标题或创意文案增加手写温度的轻量设计需求。

1. Manuscript 在科研工作流里到底是什么：一个比“写稿”大得多的工程问题

如果只看字面意思，Manuscript 就是“手稿”，很多刚从 Word 切换到学术写作的研究者会以为它指某个写作软件或模板。但当你真正蹲在一个项目的输出阶段——实验做完了、图表画好了、剩下的是把 60 页内容整理成一篇能投出去的论文——你会发现“手稿”两个字被严重低估了。它其实涵盖了从 Markdown 写作草稿、LaTeX 源码、参考文献库到编译脚本、图表文件、版本历史、投稿格式定制这一整条生产线。我见过某实验室的 A 同学，论文返修时因为找不到上一版图表的源文件，硬是在最终 PDF 里截了一张低分辨率图贴回去，差点被审稿人打回。Manuscript 要解决的正是这种混乱：把一篇论文从草稿到定稿之间的版本管理、格式转换、编译排错、引用同步全部收口到可复现的工作流里。

我们团队现在跑一个模拟项目 X 的时候，内部的写作规范就是“所有正式输出都从 Manuscript 流程走”。这套流程的核心不是某个软件，而是一套约定：纯文本源文件、统一目录结构、脚本化编译、Git 版本控制。这篇文章我会把从零搭起这套手稿生产线的步骤、必调参数和踩过的坑全部摊开讲。适合正在写毕业论文、准备投稿、或维护多篇在写论文的人；新手能照着命令跑通，熟手可以重点看格式转换和避坑部分。

2. 从无到有搭手稿生产线：为什么选型的顺序决定后面少走多少弯路

2.1 先想清楚“手稿”要管哪些事，再谈工具选型

动手写第一篇论文时，我犯过一个典型错误：一上来就在网上找模板，模板套进去后开始写，写到第三章发现图表编号全乱，参考文献格式不对，想换模板又怕字全没了。后来我复盘，为什么 Word 写论文总是越改越乱的根源——Word 把内容、样式、排版、版本这四件事揉在一起，任何一处的改动都会牵连其他三处。而 Manuscript 思路的第一步就是把这些职责拆开：内容放纯文本，样式交给模板，排版交给编译引擎，版本交给 Git。

具体到一篇学术手稿，你需要管理的资产通常包括：正文源文件、图表文件（矢量图源文件和导出文件都要留）、参考文献库（BibTeX 或 CSL 格式）、编译脚本、投稿所需的元数据（作者、摘要、关键词）、以及每一轮的修改记录。选型前先用一张表把这七类资产列下来，比先选编辑器靠谱得多。我当时是拿 OneNote 先把这些列出来，再决定用什么工具，整个过程两小时，但后面写稿时几乎没有因为“找不到某样东西”而中断过。

我的常规选型是：正文用 Markdown 写初稿、用 Pandoc 转 LaTeX 出最终 PDF；如果需要出版社强制 LaTeX 模板，就纯 LaTeX 写；参考文献统一用 BibTeX 管理；图表用 draw.io 和 matplotlib 出矢量格式；版本管理用 Git。这套组合的好处是每一步的工具都足够“傻”，坏了你知道去哪修，而不是打开一个黑匣子无从下手。

2.2 目录结构和初始化命令：给手稿修一条“不会乱”的管道

选型定下来后，第一件事是搭目录骨架。我见过太多人把论文源文件、图表、参考文献、旧版本全堆在一个文件夹里，最后编译时引用路径一塌糊涂。一个干净的手稿项目目录应该是这样的：

manuscript-demo/ ├── content/ # 正文源文件（.md 或 .tex） │ ├── 00_abstract.md │ ├── 01_introduction.md │ ├── 02_method.md │ ├── 03_results.md │ └── 04_conclusion.md ├── figures/ # 图表的源文件与导出文件 │ ├── src/ # draw.io / matplotlib 源文件 │ └── pdf/ # 最终引用 PDF 版本 ├── references/ # BibTeX 库 │ └── refs.bib ├── templates/ # 期刊模板 / 自定义样式 ├── scripts/ # 编译脚本、转换脚本 ├── output/ # 生成的中间文件和最终 PDF └── archive/ # 历史版本快照

这个结构的核心思想：内容、资源、产物三分开。output/目录下的任何文件都可以随时删除重新生成，因为真正的源文件在另外三个目录里。真正动手创建时，我习惯写一个初始化脚本，而不是手动mkdir，这样多台机器、多个项目可以保持完全一致的结构：

#!/bin/bash # 初始化一个 Manuscript 项目骨架 # 用法: ./init_manuscript.sh project_name set -e # 任何一步出错就停止，避免半成品目录 PROJECT_NAME="${1:-my_manuscript}" mkdir -p "$PROJECT_NAME"/{content,figures/src,figures/pdf,references,templates,scripts,output,archive} touch "$PROJECT_NAME"/README.md touch "$PROJECT_NAME"/content/00_abstract.md touch "$PROJECT_NAME"/references/refs.bib echo "# $PROJECT_NAME" > "$PROJECT_NAME"/README.md echo "Project skeleton created at $PROJECT_NAME"

这段脚本有三个值得注意的参数。set -e很关键——如果中途磁盘空间不足或目录已存在导致mkdir报错，脚本会立即退出，不会留下一个缺了output/的残缺项目。${1:-my_manuscript}的意思是：传了第一个参数就用它做项目名，没传就用my_manuscript兜底。最后touch空文件和echo写入 README 是为了让 Git 能跟踪空目录——Git 本身不跟踪目录，只跟踪文件。

创建完目录后，我建议立刻执行git init并做第一次提交。这一步看似多此一举，但它的作用是给整个项目打第一个“后悔药”锚点。我一开始没做，写了两周稿子后才想起建仓库，结果无法区分哪次大改对应哪个实验版本，只能靠文件名里的v2_final_真final硬扛，那种体验经历过一次就不想再来第二次。

2.3 写作源文件选 Markdown 还是 LaTeX：别装，按场景切

Markdown 和 LaTeX 之争是手稿工作流里最没必要的争论。我的判断标准非常简单：团队协作和快速迭代时优先 Markdown，单作者定稿或出版社有硬性模板要求时直接 LaTeX。Markdown 写的草稿任何人打开都能读能改，diff 的时候干净到可怕；LaTeX 则是在你明确知道最终要两栏排版、要公式编号、要浮动体位置严格受控时，省去 Pandoc 中间层直接一步到位。

我经历过一个翻车现场：某投出去的期刊要求 Word 稿但图表必须是矢量图，我们用 Pandoc 从 Markdown 生成 docx，结果图全插入成功了，但公式全部变成了 OMML 对象，审稿人反馈某些符号渲染不对。后来排查发现是 Pandoc 的--mathml参数没加对，用--webtex老接口生成的是图片公式，放大就糊。从那以后我的习惯是：目标格式是 docx 就用 Pandoc 的 RTF/MathML 链路，目标格式是 PDF 就直接走 LaTeX，不硬让 Pandoc 扛所有转换。

但选 Markdown 还是 LaTeX 不是二选一。很多手稿项目是混合的——正文用 Markdown 写快速内容，图表用 LaTeX TikZ 画，最终用 Pandoc 拼装。这个组合适合方法部分包含大量公式和图，但叙述部分又需要频繁修改的场景。关键是把 Markdown 作为“母本”，LaTeX 作为“产物之一”，你自己决定什么时候把母本冻结掉转成 LaTeX 做最终排版。我在内部项目 X 里就规定：内容冻结前别碰 LaTeX，冻结后再开revision/分支去做模板适配，这样写作和排版两个阶段的焦虑不会互相污染。

3. 用 Git 和 Makefile 让 Manuscript 从头到尾“一键可复现”

3.1 版本管理与分支策略：把每一轮返修变成可回滚的提交

手稿的版本管理和代码有一个显著不同：代码的“编译”是跑起来看逻辑对不对，手稿的“编译”是生成 PDF 看排版和内容对不对。因为最终读者看到的是 PDF，所以 Manuscript 的版本策略必须保证任何一次编译都能对应到一组明确的源文件。我的实践是：main分支永远对应当前可提交的版本，dev分支存放未完成的内容，archive/目录存放历史快照的 PDF 和源文件。

具体操作上，每完成一轮修改就提交一次，提交信息按“动词+对象”的格式写，例如feat: add ablation study table或fix: correct equation 3 notation。我自己不强制写什么规范，但要求必须写上“为什么改”，而不是“更新了内容”。三个月后回来看提交历史，你能直接说清每一次改动的动机，而不是靠猜。

# 初始化仓库并设置用户（Mac/Linux 都适用） git init git config user.name "Your Name" git config user.email "you@example.com" # 创建主分支和开发分支 git checkout -b main git checkout -b dev # 日常流程：改完内容后走“提交-合并”小步快跑 git add content/ figures/references/refs.bib git commit -m "fix: correct equation 3 notation" git checkout main git merge dev --no-ff -m "merge dev: equation fix"

.gitignore必须把output/和可能的*.aux*.log*.synctex.gz排掉，这些编译中间文件会让仓库急速膨胀。.gitignore文件本身我放在项目根目录，内容至少包含这三类：output/、编译残留、还有编辑器缓存（.DS_Store、.vscode/）。因为图表源文件如果动不动几十 MB，我会用 Git LFS 去管，而不是硬塞进普通仓库，不然克隆一次仓库要喝一杯咖啡。

3.2 Makefile 统一编译入口：把 Pandoc、LaTeX、BibTeX 串成一条链

当手稿包含多文件时，手动敲 Pandoc 加 xelatex 命令是效率杀手，而且容易漏步骤。BibTeX 尤其折磨人——每次改引文后必须“xelatex → bibtex → xelatex → xelatex”跑两遍以上，漏一遍引用编号就变成问号。Makefile 可以把这串动作固化下来，让编译变成零思考的执行：

# 手稿编译配置 MD_FILES := content/00_abstract.md content/01_introduction.md \ content/02_method.md content/03_results.md content/04_conclusion.md BIB_FILE := references/refs.bib TEX_FILE := output/manuscript.tex PDF_FILE := output/manuscript.pdf # 目标：最终 PDF $(PDF_FILE): $(MD_FILES) $(BIB_FILE) templates/ieee.csl pandoc $(MD_FILES) \ --from markdown \ --to beamer+latex \ --citeproc \ --bibliography=$(BIB_FILE) \ --csl=templates/ieee.csl \ --output=$(TEX_FILE) 2>&1 xelatex -interaction=nonstopmode -halt-on-error \ -output-directory=output \ $(TEX_FILE) 2>&1 bibtex output/manuscript.aux 2>&1 || true xelatex -interaction=nonstopmode -halt-on-error \ -output-directory=output \ $(TEX_FILE) 2>&1 xelatex -interaction=nonstopmode -halt-on-error \ -output-directory=output \ $(TEX_FILE) 2>&1 # 清理编译中间文件 clean: rm -rf output/*.aux output/*.bbl output/*.blg \ output/*.log output/*.out output/*.synctex.gz .PHONY: clean

这个 Makefile 有四个参数需要你按自己项目改：MD_FILES是正文文件的顺序列表，注意目录顺序就是最终论文的章节顺序；BIB_FILE指向 bib 库；--csl指定参考文献样式，用期刊的官方 CSL 替换ieee.csl；-interaction=nonstopmode -halt-on-error是 LaTeX 的黄金组合——前者让编译不因警告停下，后者确保真错误立刻退出，而不是生成一个半残 PDF 让你误以为成功了。

如果你觉得xelatex每次都跑四遍浪费，可以用latexmk替代，它内置了依赖跟踪和重跑逻辑。我在大型手稿项目——比如 15 章以上的毕业论文——用latexmk -pdf -xelatex -interaction=nonstopmode output/manuscript.tex一行搞定。但小文章我反而用显式四连，因为你能清楚看到每一步卡的哪个环节，排错更直白。

3.3 内容冻结与变更流程：防止“改着改着忘了原文长啥样”

手稿的第二次大坑是“内容反复横跳”——昨天删掉的段落今天又想加回来，但删之前没保存。为这个我尝过失而复得的甜头，也吃过找不回来的苦。现在规矩是：任何整段删除或大重构之前，先在archive/里存一份当前版本的 PDF 和源文件快照，然后才开始动刀。快照含义是冻结某个时间点的内容，不是每天备份。

我在项目里用一个简单脚本snapshot.sh归档当前状态。它本质上就是复制源文件到带时间戳的目录，然后提交一次 Git。执行时间两秒，但心理收益巨大——你不再怕改坏，因为总有最后一个干净的分岔口可以回去。另一个细节：图表源文件、参考文献和正文快照必须同时归档，缺一个，三个月后的你看到旧 PDF 也只能干瞪眼。

通常的节奏是：每周五下午做一次快照，同时清理掉archive/里超过三个月的中间版本，只留关键节点。这样归档目录不会膨胀到几百个文件夹，找东西也不用翻历史目录。

4. 格式转换与交叉引用的硬骨头：Pandoc 模板、引用与图表的四类坑

4.1 Pandoc 模板定制：从 Markdown 到 LaTeX 的“最后一公里”

Pandoc 默认生成的 LaTeX 是通用版式，直接投稿会被期刊模板打回。它的解法是--template参数，但大部分人的误区是“找个期刊模板，把内容塞进去”。正确的是：Pandoc 模板是你和期刊模板之间的粘合层，它负责把你的元数据和 Markdown 内容填充到期刊模板需要的位置。

我先解释机制。Pandoc 的默认 LaTeX 模板里有一组变量，比如$title$、$author$、$date$、$if(abstract)$，你把 Markdown 的 YAML 头注按这些变量名填，生成时就能自动对齐。但期刊模板往往不叫title而叫\@title或\journaltitle，所以你要在自定义模板里做映射，把$title$映射成期刊要求的命令。

--- title: "On the Efficiency of Manuscript Pipelines" author: - name: "某开发者" affiliation: "某实验室" email: "dev@example.com" date: "2025-01-15" abstract: "本文提出一套可复现的手稿生产...（省略）" keywords: [manuscript, pandoc, latex] ---

生成的 LaTeX 里，这些 YAML 字段会被填到模板变量位。我用 Pandoc 的--template参数时习惯先生成一份默认模板看变量结构：

# 导出 Pandoc 默认 LaTeX 模板 pandoc -D latex > my_template.tex # 用自定义模板生成 LaTeX 源文件 pandoc manuscript.md \ --template=my_template.tex \ --from markdown+yaml_metadata_block \ --to latex \ --output=output/manuscript.tex

关键的参数是--from markdown+yaml_metadata_block。如果你不加这个扩展，Pandoc 会把 YAML 头注当普通文本，标题就会以奇怪的方式出现在正文里。我第一次就栽在这里，生成的 PDF 第一页顶部赫然印着---，整个心情都崩了。

4.2 图表跨目录引用：路径问题的玄学与正解

手稿项目里图表放在figures/pdf/，正文在content/，LaTeX 的\includegraphics路径默认是相对编译目录的。我的 Makefile 让xelatex从output/目录运行，于是figures/路径就全断了。Pandoc 转出来的 LaTeX 里图片路径是按 Markdown 里的相对路径写的，在output/里自然找不到../figures/pdf/figure1.pdf。

标准解法是终极处理器里加一层路径映射：要么给\graphicspath{../figures/pdf/}指令，要么给 Pandoc 加--resource-path参数，让它能找到资源文件。但这里有个隐藏坑：--resource-path只影响 Pandoc 读取 Markdown 中的图片，不影响 LaTeX 内的\includegraphics。换句话说，你要在两条链路里同时让路径正确。

pandoc manuscript.md \ --resource-path=.:figures \ --output=output/manuscript.tex

同时在生成的manuscript.tex开头（或模板里）加上\graphicspath{{figures/pdf/}}。如果你嫌麻烦，更稳的方案是：在content/里写相对路径../figures/pdf/xxx.pdf，Pandoc 生成时直接保留，LaTeX 在output/下编译时用\graphicspath{{../figures/}}把根目录指到正确位置。这种方式绕开了所有玄学路径报错。

4.3 参考文献与交叉引用：为什么会双倍编译，以及--citeproc的陷阱

手稿的参考文献有两条链路：Pandoc 的--citeproc把 Markdown 中的[@doe2020]直接解析成格式化引用条目，这适合快速生成 Word 或轻量 PDF；但如果你要转 LaTeX 再用 BibTeX 管理，就绝不能开--citeproc，因为 Pandoc 会把引用文本直接变成静态字符串，BibTeX 再跑一遍会 “double-format”——你的引用编号变成[12]（12）这种重叠样式。

正确做法在 Markdown 里写裸引用键@doe2020，Pandoc 只负责把它转成\cite{doe2020}，不要加--citeproc，然后让 BibTeX 统一处理格式。记得在 Markdown 里把需要交叉引用的公式或章节用{#eq:sample}打上标记，Pandoc 转成 LaTeX 时自动对应\label{eq:sample}和\ref{eq:sample}。这样你的引用链路是纯 LaTeX 的，逻辑完全可控。

如公式 @eq:mse 所示，均方误差定义为... $$ MSE = \frac{1}{n}\sum_{i=1}^n (y_i - \hat{y}_i)^2 $$ {#eq:mse}

Pandoc 生成后，LaTeX 里就是\eqref{eq:mse}，BibTeX 和交叉引用互相独立、互不干扰。这个选择牺牲了一部分 Pandoc 的一键省事，但换来了投稿前的确定性——你不会在最后一刻发现引用编号是 Pandoc 写的、期刊模板不认。

4.4 数学公式与字体嵌入：PDF 交付前必须做的一次体检

用xelatex编译时，中文字体嵌入是另一个容易爆雷的点。默认的 LaTeX 字体引擎不会自动处理中文，你的 PDF 会出现空白、方块或字体重叠。我的模板里固定用ctex文档类配合fontset=fandol，这样不需要系统预装任何中文字体，Linux 和 macOS 都能编译通过：

\documentclass[fontset=fandol, 12pt]{ctexart}

字体嵌入的体检方法：生成 PDF 后用pdffonts命令检字体列表，如果看到某字体显示no embed或语法有subset的百分比不足，说明某些字符可能用错了字体，投稿系统很可能拒收。这步不是可有可无的洁癖，某次我按标准流程提交手稿，编辑部反馈 PDF 内嵌字体不合规，直接被退回修改，后来就再不敢跳过体检。

5. Manuscript 常见踩坑指南：五个“现象 → 原因 → 解决”的血泪账

5.1 Pandoc 转换时报unexpected symbol near '<'

现象：pandoc manuscript.md -o output.tex时终端直接弹unexpected symbol near '<'，或生成的.tex文件里全是奇怪的 HTML 标签。

原因：这个报错九成是因为 Markdown 的 YAML 头注里---和标题之间缺了空行，或头注里的某个字段值包含了未转义的<字符，Pandoc 误以为你写了 HTML 代码块。还有一成因是 Markdown 文件用了 CRLF 换行符，Pandoc 解析器在跨平台时会抽风。

解决：先检查 Markdown 文件开头是否有干净的三段式结构（---空行 字段 空行---）。其次，用file manuscript.md查看换行符，如果是 CRLF，用sed -i 's/\r$//' manuscript.md转成 LF，重新编译。我一般还会在 Makefile 里加一个lint目标，用pandoc -f markdown -t native manuscript.md预解析，能提前暴露语法问题。

5.2 BibTeX 编译后所有引用变成?问号

现象：跑完bibtex manuscript.aux后，PDF 里所有\cite位置都是一个粗体问号，参考文献列表空白。

原因：bib 库路径没对上，或 BibTeX 找不到.aux文件的位置。Makefile 里我写的是bibtex output/manuscript.aux，但 BibTeX 在output/之外运行时，默认去当前目录找.aux，如果当前目录没有，它就什么都不干，直接报“I couldn't open file”。

解决：进到output/目录再跑 BibTeX，或者用-include-directory=output参数。我最后的做法是压根不手动跑，在 Makefile 的clean目标里删掉.aux.bbl.blg，然后让latexmk自动调度 BibTeX 运行顺序，人只负责输入make。

5.3 图表正确但 PDF 里的图全部错位或消失

现象：Pandoc 正常生成 LaTeX，Pandoc 日志也输出 “Fig 1 processed”，但最终的 PDF 里没有图，或图表跳到了完全不相关的章节。

原因：最常见的根因是\includegraphics里的路径末端缺少默认扩展名。如果你的图片是figure1.pdf，但 Markdown 里写的是figure1.png的引用，Pandoc 不会自动帮你改扩展名，生成的 LaTeX 就指了一个不存在的路径。另外，LaTeX 的浮动体位置参数[htbp]没加，图会被推到最后几页。

解决：给 Pandoc 传图片时确认扩展名正确，并在 Markdown 里明确.pdf后缀。浮动体位置问题在模板里统一加\floatplacement{figure}{H}强制就地放置。这种方法对页面拥挤的论文不友好，但它能让你快速定位是哪一张图断链，而不是整篇 PDF 末尾冒一堆孤儿图。

5.4 参考文献样式和期刊要求的[1]差一点

现象：引用编号格式对，但作者名大小写、期刊缩写、页码格式有一项和期刊指南不一致，投稿系统反馈“formatting not compliant”。

原因：你的 CSR 或 BST 文件和期刊要求有细微差别。Pandoc 的--citeproc能输出 APA/Chicago 等常见样式，但很多期刊有自己的定制 CSL，出发点是从官方给出的样式文件手动改成你要的格式。

解决：去期刊官网下他们的 CSL 文件，放到templates/下并固定引用。如果是自定义 BibTeX BST，没关系，用\bibliographystyle{unsrtnat}和natbib宏包重排，再对着期刊指南逐条核对作者名缩写、期刊名缩写规则。这个核对虽然枯燥，但它是提交前唯一的保险。

5.5 LaTeX 编译卡死或内存不足

现象：xelatex在中途挂起不退出，或报! Emergency stop，终端日志最后几行是main_memory相关字样。

原因：手稿中文档类、宏包和超链接组合导致 TeX 内存不足；更常见的是图片数量巨大且分辨率超高，每个 PDF 图几 MB，LaTeX 排版时反复做边界盒计算，直接压爆默认内存上限。还有一个隐蔽源是\includegraphics反复加载同一张量大图而没有用\includegraphics的trim参数裁剪空白。

解决：在xelatex调用前设置环境变量ulimit -v不是正道。正确做法是在模板的\documentclass后加几行：\usepackage{etex}提升内存管理，并给\includegraphics统一加\graphicspath{}和\DeclareGraphicsExtensions{}限制扫描范围。如果图实在太多，把矢量图导入时先导出成压缩后的 PDF 版本，一张图控制在 500KB 以内，编译速度能快一倍。

6. 进阶技巧：给 Manuscript 上自动化体检、批量旧稿回收与自定义模板组装

到这一步，你的 Manuscript 工作流已经能稳定生成 PDF 了。进阶的目标是把它变成“少盯着也能跑”的产线。我会用两个手段：第一，在 Makefile 的lint目标里加入拼写检查、引用完整性和图表路径验证；第二，用 Git 的 pre-commit 钩子跑一次 Pandoc 预转换，确保每次提交的源文件都可编译。

lint: pandoc -f markdown -t native $(MD_FILES) > /dev/null 2>&1 && echo "MD syntax OK" python3 scripts/check_citations.py $(MD_FILES) references/refs.bib python3 scripts/check_figures.py content/ figures/

check_citations.py的逻辑很简单：扫描 Markdown 里的[@key]引用，对照refs.bib里是否存在@key。check_figures.py解析 Markdown 中的![]()路径，逐个os.path.exists()检查文件是否真实存在于figures/下。这两段脚本加起来不到六十行，但它们把“手稿能不能编译”从手动玄学验证变成了每次提交前的自动闸门。

批量旧稿回收是我处理历史遗留问题的常用手段。某同事手上有二十多篇 Word 版毕业论文，想统一改成 LaTeX 工作流，我建议的做法是解析 Word 转 Markdown 时只用 Pandoc 的一次性转换，并小心处理 Word 中的表格、交叉引用和多级编号。注意转换后不要直接编译 PDF，而是要先进 Our 目录结构：把 Word 内容按章拆成多个.md文件，手动核对公式和插图路径后再走正式流程。这个验证步骤不能跳，因为 Pandoc 的 docx 解析器对样式复杂的 Word 文件依然脆弱，跳过了后面排错成本更高。

组装自定义模板是我最后想强调的经验。我维护了一套journal_template.tex，它包含一个简单的「输入是 Markdown、输出符合期刊要求 PDF」的完整模板，字段包括期刊名、投稿编号、版权行、DOI 等。替换模板里对应的宏包和参数就能适配不同期刊。我自己的习惯是三个月迭代一次模板，每投一次期刊就吸收一次它的样式细节到维护的模板里，而不是每次从头写。这个习惯坚持下来，一个模拟项目 X 的返修三审只需要改三行模板变量，不用动正文任何内容。

最后说句实在的：Manuscript 这套流程的精髓不是某个命令或某段脚本，而是“源文件唯一可编译、产物可复现、历史可追溯”这三个习惯。你可以不照搬我的目录结构，但你至少要给自己定一条规矩——任何投出去的版本都必须在三个月后还能完美重编译。这条规矩救过我一次返修：审稿人要求补两幅实验对比图，我用归档快照二十分钟找回了实验参数和图表源文件，第二天就把修改稿交出去了。如果你现在手里还有一篇用v2_final_最终版命名法在管理的论文，不妨从今天开始把它迁移进这套手稿流程，第一周可能会慢，但一个月后你会感谢当初这个决定。希望帮到你。

本文还有配套的精品资源，点击获取