从 Word 到 git+LaTeX:一位独立作家的图书出版流水线

书出版后想改一句话,得走下面这一串:

  • 改一遍 master DOCX
  • 在 InDesign 里改、导出 PDF、上传给经销商
  • 在 Calibre 里改、导出 EPUB、上传给经销商
  • 在 Kindle Create 里改、导出 KPF、上传到 KDP

四份格式、四个工具、四次上传。改一个错别字、加一句话,要在四个地方同步走完。

独立作家 D. J. Speckhals 既写历史小说,也是软件工程师。他写过基督教历史小说三部曲《Witnesses of the Light》(外加同系列中篇《The Outcast of Chivasso》),三本书都走这套传统流水线。第三本《Prince of Savoy》写完时,他终于动手把这套流水线 git 化——彻底替掉 Adobe 和 Microsoft,改一处自动构建多份格式。

他把整个演进过程写成了一篇博客(原文 / HN 讨论,2026 年 5 月 27 日的 HN 上 192 分 / 55 条评论)。每个决策点都讲清楚了:每一步用什么工具、解决什么问题、怎么衔接下一步、为什么没选别的。下面按他的演进路径走一遍——读完你就知道,想用 git 自己搭一套图书出版流水线,起步该做哪些选择。


起点的"三件套":Word + InDesign + Calibre + Kindle Create

每个工具都不可替代,所以最初这套组合是合理的:

环节 工具 解决什么
写作 + 编辑往返 Microsoft Word(DOCX) 编辑和校对都用 Word 的 tracked changes,几乎所有专业人员都靠这个
印刷版排版 Adobe InDesign 行业标准,microtypography 强(连字符规则、对齐、孤行寡行控制、drop-cap)
EPUB 制作 Calibre Kovid Goyal 写的开源工具,从 DOCX 导入很顺,HTML+CSS 改起来直接
Kindle 上架 Kindle Create Amazon 自家工具,能生成专有的 KFX 格式

Word 作为 master 文件挺合理。Speckhals 说自己"像个好孩子用 paragraph styles 而不是手动加格式"——这是后面所有结构化处理的伏笔。InDesign 在三本书里都用了。EPUB 用 Calibre 起步也顺。

瓶颈在 Kindle Create——KDP 接受 EPUB 但会转成自家的 KFX 格式,Speckhals 说他用 Calibre 生成的 EPUB 上传给 KDP 总是出问题,逼他必须维护一份 Kindle Create 单独的格式。"yet another format to maintain"(又一份格式要维护)——这是第一道裂痕。

加上 Linux 笔记本是他的日常机器,但 Kindle Create 和 InDesign 都不能跑(Wine 也不行),他得每次切到家里的 Macbook。


第一次撕裂:Standard Ebooks 替代 Kindle Create

Standard Ebooks 是 Speckhals 在 HN 上发现的项目——专门给公版书做高质量 EPUB 的志愿者社区。他读了几本,觉得品质比所有免费 EPUB 都高几个档次。等到第三部小说《Prince of Savoy》写完,他决定试试 SE 的流程。

SE 工具链的核心是命令行程序 standardebooks。装好后用 se build 就能从 XHTML 源文件构建 EPUB。但 SE 真正的杀手锏是它的 Manual of Style 和配套 linter——Speckhals 形容这个 linter 像"给电子书排版当 copyeditor,或者给代码当 linter"。

举几条 lint 错误示例(原文给的):

- Illegal unit used to set font-size. Hint: Use em units.
- Word count in metadata doesn't match actual word count.
- Header element with incompatible semantics.
  Hint: Headers should be either title or ordinal, not both.
- Possessive 's within name italics.
  Hint: If the name in italics is doing the possessing, 's goes outside italics.

总共几百条。第一次过完所有 lint 规则要花不少时间,但通过之后拿到的是一份干净的 XHTML 源文件目录、能进 git、se build 一行出 EPUB。这份 EPUB 转 Kindle 也兼容,所以 Kindle Create 直接被砍掉了。

判断这套适不适合你:你是不是软件工程师那种乐意被 linter 教做事的人?是的话 SE 是天作之合;不是的话你会觉得它"how strict, how pedantic, and how utterly opinionated"(多严格、多吹毛求疵、多固执己见)——Speckhals 自己第一次走流程也是边走边说"trust the process"(相信这套流程值得)硬撑过去的。


源文件改造:DOCX → ODT + 语义化样式

回头修第一本《Heretics of Piedmont》时,Speckhals 决定把源文件从 Word 切到 LibreOffice Writer 的 ODT 格式(Open Document Text)。理由:

  • 不想再用 Windows 或 Office 365 Online 编辑
  • ODT 是 XML 加文本,能解析、能被脚本处理
  • LibreOffice 写作够用,拼写检查、语法检查、样式都有

更关键的是他给 ODT 加了语义化段落样式 + 字符样式。书里出现的特殊段落都被分门别类标好:

  • 段落样式:歌词、信件、诗、题词、术语表条目
  • 字符样式:每种外语(《Heretics of Piedmont》里有 7 种外语,约 100 个非英语短语)、人物的内心独白、作品标题、祈祷文、强调

视觉上这些东西最后都是斜体,但在源文件里是有语义的。这样做有三个好处:

  1. 屏幕阅读器能识别——这种语义对 EPUB 的可读性很重要
  2. 样式可以全局换皮——一句"全部诗体改 1pt 字号"在 ODT 里就是改一处样式定义
  3. 下游脚本能精准匹配——比"找所有斜体"好用得多

读到这里有人会问:"为什么不直接用 LaTeX 或 Markdown 写?"Speckhals 的回答:"I considered each of those, but I prefer writing novels in a word processor, not a text editor."(这些我都考虑过,但我宁可在 word processor 里写小说,不是文本编辑器)

这是这套流水线的核心选择。word processor 没过时——它是写作工具。git 化的代价不应该是放弃 word processor。所以 ODT 留下来作 source of truth,下游格式都从 ODT 派生。


自己写转换脚本:Python + lxml + Claude Code

ODT 到 EPUB 和 PDF 之间需要一层转换。Pandoc 能转,但 LibreOffice Writer 的自定义样式过不去——Speckhals 加的那 30+ 种语义样式 Pandoc 都丢掉了。

所以他自己写了转换脚本,技术栈:

  • Python + lxml 解析 ODT 的 XML 结构
  • Claude Code 帮他起草脚本(他在博客里特别提了一句)
  • TOML 配置文件——做 ODT 样式到 XHTML/TeX 元素的映射

脚本拿到 ODT 后先映射成中间结构,然后出两份产物:

                  ┌─→ XHTML → Standard Ebooks 工具链 → EPUB
ODT (source) ─→ 脚本 
                  └─→ TeX  → LaTeX 编译 → PDF(印刷版)

XHTML 这条路输出后只剩几个 lint 错误要修。EPUB 这条搞定。

PDF 那条路是后来才接通的,关键在 LaTeX。


LaTeX 替代 InDesign:microtype 是决定性的一票

Speckhals 一开始很想让 LibreOffice Writer 直接出 PDF,2025 年 Writer 加了几个 microtypography 特性听起来跟 InDesign 类似。试了之后失望——页面右边缘排得不齐、底边不平、drop-cap 看着别扭。换 Scribus 也不行,200 多页的书让它慢得没法用,效果还不如 Writer。

LaTeX 是他犹豫了很久的选项——上学时是文科生,没碰过 LaTeX,听起来吓人。但他选一章试着排一遍,跟 InDesign 输出的对比:"nearly indistinguishable"(几乎看不出差别)。

LaTeX 替代 InDesign 的关键是几个 LaTeX 包:

\usepackage{memoir}      % "batteries included" 的文档类
\usepackage{fontspec}    % 支持 OpenType 字体(Adobe Garamond 这种)
\usepackage{polyglossia} % 多语言断字规则(Old Occitan、Latin 等)
\usepackage{graphicx}    % 图片排版(地图、作者像)
\usepackage{microtype}   % microtypography——最关键的一个

最关键是 microtype 包——它带来 InDesign 那套高级排版特性:character protrusion(字符突出,让标点在边缘外推一点让对齐看起来更齐)、font expansion(字符微微缩放让行长更顺)、tracking 调整等等。装上 microtype 之后印刷质量直接到 InDesign 水平——这就是他选 LaTeX 的最大理由。

Speckhals 在博客里贴了完整的 LaTeX preamble

ODT → TeX 这条路用的是同一个 Python 转换脚本,加一份不同的 TOML 配置——这是脚本结构的好处:换输出格式就换映射文件,不动核心逻辑。


完整流水线长什么样

最后这套拓扑:

                     master ODT
              (在 LibreOffice Writer 里写)
                         │
                         │  Python + lxml 转换脚本
                         │  + 不同 TOML 配置映射样式
              ┌──────────┴──────────┐
              ▼                     ▼
            XHTML                  TeX
              │                     │
              │ se build           │ xelatex
              ▼                     ▼
            EPUB                   PDF
        (SE Manual of           (microtype 包做
         Style 合规)              microtypography)
              │                     │
              │                     ▼
              │                 印刷版上架
              ▼
        Kindle / 其他
        EPUB 经销商

git 在哪?目前作者每本书有两个独立 git 仓库:一个跟踪 XHTML、一个跟踪 TeX。ODT 作为 source of truth 不进 git——这是他承认的妥协,因为 ODT 是 zip 打包的 XML,git diff 看不出改了什么。他的目标是有朝一日 XHTML 和 TeX 完全是 artifacts,但目前还没做到。

最大的 quality-of-life 提升是 git diff 能直接看到改了哪些字。从 .docx.indd 的不透明二进制切到 .xhtml.tex 的纯文本,校对一遍下来 git 告诉你具体改了什么——这是 Word + InDesign 那套永远做不到的。


备选路径(来自 HN 评论区)

如果你不想完全照 Speckhals 这套走,HN 评论区给了几条替代路径:

VellumTheOtherHobbes 推荐):fiction 作家专用工具,250 美元一次性买断,EPUB 单独版或 EPUB+PDF 全套都有。可定制性差,但开箱即用,能省掉 Speckhals 这套 80% 的工作量。代价是 Mac only、闭源、不能 git 化。适合"我就要好用,不想自己搭"的作者。

Typsthuijzermoopieraybb 提到):比 LaTeX 现代很多的排版语言,已经能用来排论文和书。Speckhals 自己试过没选——理由很具体:"window/orphan 控制只是开关式(binary on/off),LaTeX 是 penalty 加权计算"。这条理由对 fiction 排版很关键,因为 fiction 几乎每页都要做寡行寡字的 trade-off。如果你写技术书或论文,Typst 可能就够了,而且语法比 LaTeX 友好。

Pandoc + WeasyPrint + ghostscriptdiamondap 推荐):源文件用 Markdown,生成 HTML 后 WeasyPrint 出 PDF/X-1a,ghostscript 做最后的合规检查。CSS 控制样式。完全 git 化、跨平台、开源。Speckhals 没选这条因为 Markdown 不带语义化字符样式(人物内心独白和普通强调都只是斜体,分不开),他要写小说不是技术书。

Asciidoctormeonkeys 推荐):单一格式源,能出 PDF/HTML/EPUB。Speckhals 的回应:"Asciidoctor was in the running months ago. I like the idea of a single set of files, but yes, word processors are my weakness."(几个月前 Asciidoctor 也在我考虑范围里。我喜欢单一文件源的想法,但 word processor 对我来说就是放不下)

InDesign Place 命令Exoristos 推荐——他在商业印刷干了 6 年):InDesign 可以"链接"外部 Word 文档,理论上 Word 改了 ID 同步更新。但 TheOtherHobbesmunificent 都反驳了——最近版本的 InDesign Place 命令不再自动同步,得手动点一下;而且就算自动同步你也不想要,因为改一句话可能让整本书的页码全错位。这条算"理论可行实操坑很深"。

The Sourdough FrameworkHanClinto 提到):一本讲做酸面包的书,整套 git+CI/CD+TeX 流水线公开在 GitHub 上,是这类"图书工程化"的早期范本。Speckhals 评论:"这是我早期的灵感来源,文章里漏提了。"想看完整范例的可以读这本书的源码。


选择指南

按 Speckhals 这套和评论区的备选路径,给一张挑选地图:

你的需求 推荐路径 主要代价
我就要好用,不想自己搭 Vellum($250) Mac only、闭源、不可 git
想 git 化、不想写脚本、写技术书或论文 Typst fiction 排版细节差一截
想 git 化、写小说、不想写脚本 Standard Ebooks 工具链 + 直接写 XHTML 学 SE Manual of Style 要时间
想 git 化、保留 word processor 写作体验 Speckhals 这套(ODT + 自写脚本 + SE + LaTeX) 要自写转换脚本
想给开源/技术书做完整流水线 Asciidoctor 或 Pandoc + CI 必须用文本编辑器

Speckhals 自己的话:"My process certainly isn't for everyone."(这套流程肯定不适合所有人)——但他把每个决策点的来由都讲清楚了,让读者拿到一张真实的地图,不是一句"用 LaTeX 就好了"的口号。怎么走、走多远,对照上面那张挑选地图按自己情况定。


关键链接汇总