同一份稿件同时出 EPUB 与印刷 PDF：indie 作者的单文件工作流
EPUB 与印刷 PDF 是两套排版逻辑，但稿件应该只有一份。这里给一条让源稿单一、产物多端的路。
同一份稿件同时出 EPUB 与印刷 PDF：indie 作者的单文件工作流
电子书与印刷书在 indie 出版生态里早已不是二选一。2026 一个常见的发布策略是同时上架两种形态——电子书走 KDP、Apple Books、Kobo Writing Life 等渠道，印刷书走 KDP Print、IngramSpark 或本地印厂。两种形态覆盖不同读者群体、不同购买场景、不同价格区间，加起来才构成一个 indie 作者完整的发行覆盖。
但 EPUB 与印刷 PDF 是两套很不同的排版逻辑。EPUB 是流式（reflowable）——读者会调整字号、行距、阅读宽度，文字流根据设备重新分页。印刷 PDF 是固定版面（fixed layout）——每一页的字符位置、行数、章节起始、对开页的左右关系都是预先决定的。在 EPUB 里设计的”每章新页”在印刷里要变成”每章起新页且必在右页”；在 EPUB 里的图片可以任意比例，在印刷里要考虑出血与色彩空间。
这种差异让很多作者走上”双源稿”的路径：写一份 .docx 在 Word 或 Scrivener 里编辑，导出后用 Calibre 转 EPUB；同时在 Vellum、Atticus 或 InDesign 里做印刷版本，过程中可能再回去改稿、需要在两个版本里同步。短期看可行，长期看每一处稿件改动都要同步两次，错位是迟早的事。
更合理的路径是单一源稿 + 模板分流：一份纯文本（通常是 Markdown 或 .docx）作为权威源稿，电子书与印刷版各自有一套排版模板，从同一份源稿渲染。这种模式在英文 indie 圈被 Vellum 与 Atticus 大力推广（虽然它们的源稿格式各异），在中文出版圈相对少见。下面从四个维度展开。
双源稿的代价：错位是迟早的事
很多作者在第一本书的时候不会感受到双源稿的代价——书出版前的两三个月，集中精力同时维护两份文件并不困难。问题出在书已经上架以后。
读者反馈某一段印错——你回去改稿，改了 .docx，但 Vellum 工程里的版本没动；下一次重印的时候你才发现这一节没改。或者你想出第二版，加一个新前言，前言加在了印刷工程里，但 EPUB 的源稿没同步，电子书读者拿到的还是老版本。这种”两个版本不同步”是 indie 作者在多次重印或长尾运营里反复踩到的坑。
更隐蔽的代价是心理负担。每一次想改稿，你脑子里要同时盘算”在两个地方改”，这种摩擦让”改一行字”这件事的心理门槛悄悄抬高，长期下来抑制了对稿件的持续打磨。
单源稿 + 模板分流：让源稿只有一份
更稳的路径是把稿件压缩到一份权威源稿，电子书与印刷版分别用模板渲染。Markdown 在这件事上有结构性优势：
- 它是纯文本，可以被任何编辑器打开；
- 它的结构（章节、强调、列表）是语义化的，模板可以根据语义渲染不同形态；
- 它体积小，便于版本管理与同步。
工作流大致是这样的：
- 用 Markdown 写作，每章一个
.md文件，项目元数据（书名、作者、ISBN、版权页）在一份 YAML 里。 - 选一个电子书模板——决定字体、行距、段首样式、章节起始页样式——渲染 EPUB 3。
- 选一个印刷模板——决定开本尺寸、页边距、装订侧、字体（与电子书可不同）、CMYK 色彩——渲染印刷 PDF。
- 改稿时只改 Markdown 源稿，下次渲染时两套产物同时更新。
这条路径的关键不在于”用 Markdown”——而在于模板能够吸收 EPUB 与印刷的差异化需求，让作者不必为每个产物分别调整稿件本身。
版本管理：把每一次发版固定下来
单源稿工作流的另一项好处是它与版本管理工具天然兼容。把 Markdown 项目放进 Git 仓库，每一次重大改动 commit 一次，每一次发版打一个 tag（如 v1.0、v1.1-typofix、v2.0-revised）。这样：
- 你随时可以切回到任何一个历史版本，重新渲染那个版本的 EPUB 与印刷 PDF；
- 你能精确知道某一处改动是什么时候做的、为什么改的（commit message）；
- 你能为不同语言版本、不同地区版本、特别版（精装、签名本）开 branch，互不污染主稿。
对于愿意花一两天熟悉 Git 的作者，这一层带来的稳定感远超 Word + 文件名加日期的命名法。如果你不想学 Git，把 Markdown 项目放在 Dropbox / iCloud / Google Drive 里也能获得基础的同步与历史回退——只是粒度比 Git 粗一些。
Catalpas Atelier Scribe：单源稿 + 同步预览
Catalpas Atelier Scribe 是围绕这条工作流设计的桌面应用。它的核心姿态是”Markdown 源稿 + 电子书与印刷模板并行 + 实时预览”。
源稿是文件夹里的 Markdown
每章一个 .md 文件，纯文本可被任意编辑器打开、可纳入 Git、可被任何同步工具识别。Scribe 不把稿件锁在专有数据库里。
写作面板 + 实时双产物预览 左侧写作面板用 Markdown，右侧预览面板可以切换”电子书预览”或”印刷预览”——同一份源稿、两种产物形态，毫秒级实时显示按下的每一个键所产生的版面变化。这比”导出后看 PDF”的循环显著缩短反馈周期。
Plus 起：EPUB 3 + 灰度/RGB PDF Plus 版本解锁 EPUB 3（含完整出版元数据，可直接上架 KDP / Apple Books / Kobo）与灰度/RGB PDF。绝大多数英文小说与一般非虚构的双轨发布在 Plus 层就走得通。
Pro：CMYK + ICC + 自定义印刷母版 + Ruby 对印刷品质有更高要求的项目（精装、艺术书、CJK 出版、彩页内文）需要 Pro 版本：CMYK 色彩空间、ICC 色彩管理、自定义印刷母版（对开页 + 装订侧切换 + 出血 + 内白边）、自定义字体导入、Ruby 注音。Pro 早鸟 79.99 美元/年，常规 129.99 美元/年。
三端原生 Windows、macOS、Linux 均有原生客户端，文件默认本地存储，云同步可选。
与 Vellum、Atticus 的对照
Vellum 与 Atticus 都实现了”单源稿、电子书与印刷模板分流”的设计哲学，它们在英文 indie 出版圈是经过反复验证的优秀工具。Vellum 提供精心打磨的预设主题、几乎无可挑剔的英文排版美感；Atticus 是 Web 原生、跨设备方便、有一次性买断价。
它们不在这条路径的候选范围内的，是不同的限制：
- Vellum 仅 macOS，且不支持 CJK 竖排与 Ruby 注音；
- Atticus Web 原生意味着稿件托管在云端、不支持 CMYK 印刷色彩空间、不覆盖 CJK 竖排；
- 两者源稿都不是开放的 Markdown，迁出时需要导出转换。
Scribe 在这三点上做了不同的取舍——三端原生、CJK 竖排默认可用、源稿是开放的 Markdown。它不会在英文 Mac 用户的体验维度上击败 Vellum，那不是它的目标；它把单源稿工作流延伸到 Vellum 与 Atticus 没有覆盖的场景。
如何做出你的选择
单源稿 + 模板分流是一种长期可持续的工作流，但不是所有作者都需要立刻切换。
如果你只打算出一本书、且 Word + Vellum/Atticus 已经走得通，没有必要为了”更优雅的工作流”强行迁移。优秀的工具不必非要换。
在以下情况下，单源稿 Markdown 工作流可能是更合适的选择：
- 你计划出版多本书、希望维护成本可控；
- 你重视稿件的长期可移植性，不愿意被任何工具的专有格式锁定；
- 你已经习惯 Markdown 写作；
- 你的项目涉及 CJK 竖排或 Ruby 注音，Vellum 与 Atticus 不在候选；
- 你打算用 Git 做精确的版本管理与协作；
- 你的设备组合横跨 Windows、macOS、Linux。
最好的工作流是”改一次稿件，两端同时更新”。从 Free 版本开始，用同一份 Markdown 源稿试着同时预览电子书与印刷版的形态，看看它是否融入你的节奏。
延伸阅读：
- 自出版作者的 EPUB 导出工具清单 2026
- 用 Markdown 写完一本书，并交出印刷级 PDF 的最短路径
- 平价的 InDesign 替代方案：用更小的预算做书籍内文
- Scribe 写作场景方案合集：按你的工作流找到合适的入口