企业官网建设流程全解析

简介：《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 模板里只写版式规则，不掺内容判断。

具体场景怎么选，可以参考这个简单对照：

如果你落到了第三档，下面两章的 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.md

src/*.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: 更正结果章节的统计描述，p<0.05 改为 p=0.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/目录，正文用相对路径引用：

![损失曲线随训练轮次的变化](figures/fig2-loss-curve.png){#fig:loss width=75%}

这里{#fig:loss}是交叉引用标签，width=75%是渲染时控制尺寸。重点说一个坑：路径。如果你写成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-engine=xelatex \ --output=output/paper-draft.pdf \ --citeproc \ --bibliography=references/refs.bib \ --csl=references/style.csl \ -V mainfont="Source Han Serif SC" \ -V geometry:margin=2.5cm

这条命令的逻辑是并入各个章节文件，然后用 xelatex 引擎渲染 PDF。重点说三个参数：

--pdf-engine=xelatex是处理中文稿件的关键。默认的 pdflatex 不识别 Unicode 字体，只有 xelatex 能调用系统字体。后面的-V mainfont="Source Han Serif SC"指定正文中文字体，这个字体名必须和你系统里安装的名字完全一致，差一个空格都不行。Windows 上如果你装的是“宋体”或“微软雅黑”，就填对应名称，fc-list :lang=zh可以列出系统可用中文字体。

--citeproc让 pandoc 调用内置引文处理器，配合--bibliography和--csl完成参考文献格式化。--csl指定引用样式，你想让参考文献变成编号制还是作者年份制，完全由 CSL 文件决定，不用动正文。CSL 文件可以从开源样式库下载你目标期刊对应的版本。

--output=output/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[margin=2.2cm]{geometry} \usepackage{booktabs} \usepackage[font=small]{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 \ --template=templates/journal-a.tex \ --pdf-engine=xelatex \ --citeproc \ --bibliography=references/refs.bib \ --csl=references/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/*.md

wc -w统计的是空白分隔的词数，对英文准确；中文稿件建议用wc -m按字符数统计，然后和期刊要求核对。页数控制则靠模板里的几何设置：geometry:margin=2.5cm改小页边距能增加每页容量，fontsize=11pt或12pt调整字号。这些参数放在模板文件里而不是正文里，就是你修改页数时的第一调整对象。

5. 稿件工作流避坑指南：四个高频问题的现象、原因与解决

工作流本身是简单的，真正消磨意志的是各种边角问题。这一章列了四个我实际见过的坑，都按“现象 → 原因 → 解决”写清楚。

5.1 现象：中文乱码，PDF 里汉字变成豆腐块

渲染出的 PDF 里中文全是方框或乱码。原因分两类：一是--pdf-engine没切到 xelatex，默认的 pdflatex 处理不了 UTF-8 中文字符；二是 xelatex 找不到对应字体，或者字体名写错。解决方法是先确认引擎，再确认字体。

# 列出系统中可用的中文字体名 fc-list :lang=zh | 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 diff3

diff3风格的冲突标记会显示“我改的 + 对方改的 + 公共祖先”三个区域，比默认的两段式多一个基准上下文。如果还是觉得乱，我一般用带三方合并界面的编辑器打开冲突文件，边看边手工合并。对比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 \ --template=templates/journal-a.tex \ --pdf-engine=xelatex \ --citeproc \ --bibliography=references/refs.bib \ --csl=references/style.csl \ -o $(PDF) # 清理生成的产物 clean: rm -f output/*.pdf output/*.docx

Makefile 的好处是合作者不需要记 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 手里。希望帮到你。

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