同一份稿件同時出 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 寫作場景方案合集：按你的工作流找到合適的入口