CODEX KNOWLEDGE

应付论文工作流

2026/04/24 13 min read CODEX KNOWLEDGE 目录 CODEX KNOWLEDGE 类 工具工作流 项目 毕业论文 形态 规范 应付论文工作流

应付论文工作流

把论文、汇报稿、长文档和最终归档文件，压成一条可重复的流水线。

这篇不是“怎么把文件另存为 PDF”的入门说明，而是我现在更认可的一套做法：

  • 先用 Markdown 做唯一真源
  • 再按需要导出为 Word、PPT、EPUB、PDF
  • 所有格式都从同一份内容重新生成
  • 图片、图表、目录和引用都跟着源文件走

如果你也经常遇到这些情况，这套流程会比较省心：

  • 论文要交 Word 版
  • 答辩要 PPT 版
  • 长文阅读要 EPUB 版
  • 定稿存档要 PDF 版
  • 同一篇内容还要不断小修、加图、改标题、换版式

一张图先看懂

flowchart LR
    A[Markdown 真源] --> B[Word / DOCX]
    A --> C[PPT / PPTX]
    A --> D[EPUB]
    A --> E[PDF]
    A --> F[图片 / 图表 / 流程图]
    F --> B
    F --> C
    F --> D
    F --> E

我现在默认把这条链路理解成：

  1. Markdown 负责内容真源
  2. DOCX 负责论文协作和批注
  3. PPTX 负责答辩和口头汇报
  4. EPUB 负责长文阅读和移动端浏览
  5. PDF 负责最终归档和稳定分发

先定一个原则

不要把 Word、PPT、EPUB、PDF 当成并列真源。

它们只是同一份内容的不同出口。

如果反过来做，后面就很容易变成：

  • Word 改了，PPT 忘了改
  • PDF 早就过期，EPUB 还是旧标题
  • 论文正文和答辩稿讲的是两个版本的事实
  • 图片路径和图注在不同格式里各改各的，最后没人知道哪个是真的

所以我现在只接受一种结构：

  • 一份源 Markdown
  • 一套固定图表资源
  • 一组可重复导出命令
  • 一次导出，多端同步

为什么这套方式适合“应付论文工作流”

1. 论文不是一次性文档

论文类材料最麻烦的地方，不是第一次写，而是反复改：

  • 导师改一轮
  • 同学看一轮
  • 答辩意见再改一轮
  • 格式要求再改一轮

如果每种格式都手工维护，就很容易失控。

2. 论文通常要同时面对不同读者

同一份内容往往要给不同人看：

  • 自己做记录
  • 导师看逻辑
  • 答辩老师看结论
  • 同学看摘要
  • 存档系统看 PDF

所以应该先把“内容”和“展示形式”拆开。

3. AI 很适合做结构，不适合做多份分裂真源

Vibe coding 在这里最有用的地方，不是让模型替你胡写一堆内容，而是让它帮你：

  • 生成初始提纲
  • 整理章节顺序
  • 提炼每页 PPT 的主结论
  • 生成图示草案
  • 统一术语和标题

但最后还是要回到同一份 Markdown。

我现在推荐的工具栈

下面这几个工具最实用，也最适合开源工作流。

工具 作用 开源链接
Pandoc Markdown 和多种文档格式之间的核心转换器 https://github.com/jgm/pandoc
LibreOffice Word / PPT / PDF 的桌面编辑与导出补刀 https://github.com/LibreOffice/core
Calibre EPUB 检查、转换和电子书整理 https://github.com/kovidgoyal/calibre
ImageMagick 批量处理图片、压缩、裁边、转格式 https://github.com/ImageMagick/ImageMagick
Mermaid 直接在 Markdown 里写流程图和结构图 https://github.com/mermaid-js/mermaid
draw.io 结构图、流程图、架构图的可视化补强 https://github.com/jgraph/drawio
python-pptx 需要程序化生成 PPT 时很有用 https://github.com/scanny/python-pptx

如果你只想保留最少组合，我建议是：

  • Markdown
  • Pandoc
  • LibreOffice
  • Calibre
  • Mermaid

这五个已经足够撑起大部分“论文工作流”。

本地技能和写作规范

这篇文档的写法，参考了我现在本机上的几个写作约束：

  • 图文文档写作规范
  • myblog-posting
  • plan-history-recall

其中：

  • 图文文档写作规范 负责图文分工、截图规则、导出前检查
  • myblog-posting 负责博客类 Markdown 的落点和可发布结构
  • plan-history-recall 负责先回忆最近路径，避免重复踩坑

这几个不是公开仓库链接，但它们决定了这篇文章的组织方式：

  • 先讲真源
  • 再讲出口
  • 再讲工具
  • 最后讲验证

推荐工作流

第 1 步：先写 Markdown 真源

先只写一份主文档，比如：

paper.md

这份文件里应该包含：

  • 标题
  • 摘要
  • 目录
  • 正文
  • 图注
  • 参考链接
  • 附录

不要一开始就去写 Word、PPT、EPUB、PDF 四份不同内容。

第 2 步：把正文拆成“主文”和“演示文案”

论文正文和答辩 PPT 不是同一种材料。

建议先拆成两层：

  • 正文层：给论文和归档
  • 演示层：给答辩和汇报

正文层重逻辑完整，演示层重结论密度。

第 3 步：先出 Word，再收 PPT

如果学校或者老师明确要求 Word，那就先导出 DOCX。

Word 的作用主要是：

  • 便于批注
  • 便于目录
  • 便于格式检查
  • 便于最终走学校模板

PPT 的作用主要是：

  • 只保留关键结论
  • 一页只讲一个判断
  • 用图替代长段文字
  • 把论文里的“过程”压缩成“结果”

第 4 步：再出 EPUB 和 PDF

EPUB 适合：

  • 长文阅读
  • 移动端查看
  • 章节跳转
  • 个人知识库归档

PDF 适合：

  • 最终提交
  • 统一分页
  • 固定版式
  • 跨设备稳定展示

一个可直接用的转换思路

下面这组命令不是唯一答案，但很适合做起点。

pandoc paper.md -o paper.docx
pandoc paper.md -o paper.epub
pandoc paper.md -o paper.pdf

如果你要把 DOCX 再喂给 LibreOffice 做最后的视觉调整，也可以这样接：

libreoffice --headless --convert-to pptx paper.docx

如果图很多，建议给 Pandoc 加上资源路径，避免图片丢失：

pandoc paper.md --resource-path=. -o paper.docx

如果你有封面图、章节图、流程图，最好统一放在一个目录里，比如：

assets/paper/

然后在正文里统一引用，不要散在桌面、下载目录和临时缓存里。

PPT 这一层怎么做才不累

答辩 PPT 最容易做坏的地方，是把论文正文直接复制进去。

正确做法是把 PPT 当成“提炼版”，不是“搬运版”。

每一页只保留一个主动作：

  • 这页讲什么
  • 这页证明什么
  • 这页和上一页的关系是什么
  • 这一页的图到底在帮我解释什么

我现在更倾向于这样的节奏：

  1. 先写正文
  2. 再从正文抽出每章的核心句
  3. 每页 PPT 只放一个核心句加一张图
  4. 其余内容放备注，不放页面主体

这样你答辩时就不会拿着一堆密密麻麻的卡片念稿。

EPUB 这一层不要忽略

很多人只做 Word 和 PDF，忽略 EPUB。

但 EPUB 实际上很适合：

  • 自己在手机上翻
  • 长文分章节阅读
  • 论文类内容做归档
  • 把同一份内容放进电子书阅读器里快速回看

如果你的内容本来就有清晰章节，EPUB 会让你很容易检查：

  • 目录是不是合理
  • 标题层级是不是乱了
  • 图注是不是跑位了
  • 某些长段是不是应该拆小

我现在把 EPUB 当作一种“结构体检”格式，而不只是阅读格式。

PDF 这一层是最终收口

PDF 的价值在于固定。

它适合拿来做：

  • 提交
  • 存档
  • 发送
  • 版本冻结

所以 PDF 不应该是你手工拼出来的最后一份文件，而应该是从真源自动导出的最终形态。

一旦你接受这个思路，后面就很简单：

  • 修改都回到 Markdown
  • 版式都在导出阶段处理
  • 内容和样式分层
  • 不同格式各司其职

我建议的目录结构

如果你打算真的长期这么做，目录最好收紧成这样：

paper-workflow/
  paper.md
  assets/
    figures/
    tables/
    cover/
  exports/
    paper.docx
    paper.pptx
    paper.epub
    paper.pdf

这里面最重要的是：

  • paper.md 是唯一真源
  • assets/ 是统一素材池
  • exports/ 只是输出结果，不要反向编辑

一个适合 vibe coding 的操作顺序

如果你想用 AI 辅助整个流程，我建议按这个顺序来：

  1. 先让模型帮你写提纲
  2. 再让模型把提纲扩成正文
  3. 再让模型帮你把正文压缩成 PPT 大纲
  4. 再让模型帮你生成图表说明和图注
  5. 再做一轮术语统一
  6. 最后导出 Word、PPT、EPUB、PDF

这个顺序的关键不是“让 AI 写更多”，而是：

  • 让 AI 先处理结构
  • 让人类最后收口
  • 不把真源散成多份

这类文章最容易踩的坑

1. 图片在不同格式里走散

所以图片必须集中管理，不要临时插。

2. 标题层级混乱

Word 和 PPT 最常见的问题就是标题层级不一致，最后目录和分页都会乱。

3. 文本在不同出口里被改成不同版本

这是最危险的。

一旦 Word、PPT、EPUB、PDF 不是从同一份 Markdown 生成，内容很快就会分叉。

4. 只看一种输出

很多人只看 PDF，结果 EPUB 里目录坏了，PPT 里图注丢了，Word 里标题断层。

我的建议是：

  • Word 看可编辑性
  • PPT 看提炼能力
  • EPUB 看结构
  • PDF 看最终展示

四个出口都要过一遍。

一个最小可行版本

如果你现在只想先做一个能跑通的版本，我建议先做这个：

  • 1 份 Markdown 真源
  • 3 个章节
  • 2 张图
  • 1 个流程图
  • 1 份 DOCX
  • 1 份 PPTX
  • 1 份 EPUB
  • 1 份 PDF

不要一上来就追求“全自动极致完美”。

先把链路跑通，再慢慢加模板、加封面、加目录、加样式。

可以直接开源的仓库链接

如果这篇文章要正式对外发布，我会优先落到这个公开仓库：

  • https://github.com/emptyinkpot/emptyinkpot.github.io

对应的内容源位置是：

  • apps/web/src/content/posts/

也就是说，这篇文档如果要变成博客正文，最终应该被整理成一个新的 Markdown 文章文件，然后通过这个公开仓库发布出去。

结语

我现在对“应付论文工作流”的理解已经很简单了：

不要用四份文件做一份内容。

正确方式是：

  • 用 Markdown 作为唯一真源
  • 用 Pandoc、LibreOffice、Calibre 这些开源工具做多格式导出
  • 用 Mermaid、draw.io、ImageMagick 补图和结构
  • 用 Word、PPT、EPUB、PDF 分别承担各自职责

这样你最后得到的不是四份互相打架的文件，而是一条可重复、可解释、可开源的内容生产链路。