Scribe 與 Reedsy Studio：共編平臺與本地稿件的版本邊界
Reedsy Studio 適合與職業編輯在雲端共編，Scribe 適合作者主導的長稿與印刷鏈路。本文給出兩邊的分工、匯出路徑上的樣式斷層、以及印刷參數回到 Scribe 這一側的理由。
Scribe 與 Reedsy Studio：共編平臺與本地稿件的版本邊界
Reedsy Studio（前稱 Reedsy Book Editor）是 2026 與職業編輯做雲端共編時最常用的免費平臺之一。它的強項很明確：一個統一的 Web 編輯器、內建追蹤修訂與批註、與 Reedsy 平臺上經過稽核的編輯、設計師、文案人員的工作流無縫對接。如果你的下一本書計劃走”找一位職業編輯、由 ta 在雲端逐章審稿”這條路徑，Reedsy Studio 在協作端體驗上是相當順暢的。
但 Reedsy Studio 不是一個完整的”長稿到成書”平臺。它的匯出能力做得相對剋制——EPUB 與 PDF 都能生成，但版式選項有限、印刷參數（出血、紙張尺寸、ICC、字型嵌入）的可控性遠不及專業排版工具；它的本地化（CJK 排版、豎排、注音）支援非常有限；它的稿件儲存在 Reedsy 的雲端，作者對”我的稿件檔案躺在哪裡”的控制感不如本地工具。這些都不是缺陷，而是 Reedsy Studio 把自己定位為”作者與編輯協作的介面”而非”作者全程的稿件家”所做出的取捨。
Catalpas Atelier Scribe 在這條鏈路上的角色不是替代 Reedsy Studio，而是承接它之前與之後的兩段：協作開始之前的”獨立創作期”，以及協作結束之後的”印刷與發行準備期”。兩個工具之間的關鍵是版本邊界：什麼時候稿件的”最新版本”住在 Scribe 這邊、什麼時候住在 Reedsy 那邊、不能兩邊同時維護。
Reedsy Studio 的強項與邊界
強項——和編輯共編時的體驗確實順暢。追蹤修訂、批註、版本對比、對話氣泡都在一個統一的 Web 介面裡，編輯不需要在 docx 與郵件之間反覆跳。如果你和編輯都熟悉這個平臺，溝通成本會比 Word + 郵件那一套低不少。Reedsy 平臺上的編輯大多接受這種工作方式，對方也不需要你額外解釋怎麼操作。
邊界一：匯出路徑——Reedsy Studio 的 EPUB 與 PDF 匯出走的是平臺內建模板，版式不是高度可定製的。這對大多數英文小說夠用，對帶特殊版式需求的稿件（CJK 豎排、雙語對照、複雜腳註、ruby 注音）則覆蓋不到。
邊界二：印刷參數——印刷級 PDF 涉及到的出血、紙張尺寸、自定義印刷母版、字型嵌入與 CMYK 轉換，這些參數在 Reedsy Studio 裡要麼不可調、要麼顆粒度不夠。送印到 KDP Print、IngramSpark、本地印廠時，這一層的精度不夠會帶來真實代價。
邊界三：稿件歸屬感——稿件存在 Reedsy 的雲端，匯出的是渲染產物而不是”工程檔案”。對希望”稿件最終歸我所有、躺在我硬盤裡”的作者，這一點需要單獨安排定期匯出與本地備份。
知道這些邊界之後，就能判斷什麼階段把稿件交給 Reedsy Studio、什麼階段把它接回來。
版本邊界：協作期與本地期的切換
協作期——你和職業編輯在 Reedsy Studio 上做內容編輯（content edit / line edit）的那一段。這一段稿件的最新版本住在 Reedsy 平臺上：編輯改、你接受或拒絕、雙方留批註討論。你本地的 Scribe 工程在這段時間裡降格為”參考態”，不動它，避免兩邊版本錯位。
切換回 Scribe——內容編輯輪次結束、最終文字版本敲定之後，把 Reedsy 平臺上的稿件匯出（通常導成 .docx 或 .epub），手動把”協作期內的文字修改”落實到 Scribe 工程裡。從這一刻起，稿件的最新版本回到 Scribe，Reedsy 那邊的專案降為”已完成”。
為什麼需要這個明確的切換——印刷級 PDF 的所有參數（CJK 排版、字型嵌入、出血、紙張、母版）在 Scribe 這邊更可控；EPUB 的版本控制與本地歸檔在 Scribe 這邊更穩定。如果讓稿件長期住在 Reedsy 平臺上，作者就把”成書”這一步交給了平臺模板的邊界，失去了對印前細節的真實掌控。
切換不需要複雜工具——把最終 docx 或 epub 拉下來、對照 Scribe 工程逐章把文字差異手動落實即可。這個”手動落實”聽起來麻煩，實際比想象中省時間，因為協作期的修改往往是文字層面的（用詞、句子節奏、刪冗餘），落實起來明確而快速。
匯出路徑上的樣式斷層
從 Reedsy Studio 把稿件搬回 Scribe 時，有幾類樣式落差是幾乎一定會出現的，提前知道可以省去現場排查的時間。
版式參數不攜帶——Reedsy 平臺的字型、行距、段間距是平臺模板控制的，匯出 docx 之後這些設定不會保留為可讀的”版式工程”。回到 Scribe 這一側，正確的做法是不要試圖復刻 Reedsy 的版式，而是讓 Scribe 工程的版式設定接管——你在協作期就應該和編輯約定”只看文字、版式我這邊定”。
章節邊界——Reedsy Studio 的章節邊界通過其內建的”Chapter”塊標記，匯出 docx 時會變成 Heading 1。Scribe 這邊能識別 Heading 1，但需要核對一次是否有章節被合併或拆開（特別是有”序章”或”番外”這類非標準章節時）。
批註與追蹤修訂——匯出時這兩類後設資料大機率會丟失或簡化。請在 Reedsy 平臺關閉專案之前把所有需要保留的批註手動謄抄到一份獨立的筆記裡——你不需要把它帶回 Scribe 工程，但可能需要在後續修訂或寫下一本書時回顧這些反饋。
印刷參數回到 Scribe 這一側的理由
成稿完成、最終文字版本敲定之後，“出 EPUB + 印刷 PDF”這一段為什麼應當回到 Scribe？
第一是印刷參數的顆粒度。出血、紙張尺寸、字型嵌入、CMYK、ICC 這些在送印環節幾乎都需要逐項確認，Scribe（特別是 Pro 版本）把這些設定作為工程的一部分長期儲存；Reedsy Studio 的模板路徑在這一層抽象較高，做不到逐項調。
第二是本地化與 CJK。如果你的專案涉及中文 / 日文 / 韓文，豎排、注音、斷行規則這些都是真實問題；Reedsy 在英文向稿件上做得不錯，對 CJK 投入有限。
第三是長期可重生成。一本書出版之後，過幾年想做”修訂版”或”精裝版”，是希望稿件躺在你硬盤裡、版式工程隨時能再跑一遍 PDF，還是希望它躺在某個第三方平臺上、看那個平臺 N 年後還在不在？本地工程的可重生成性，是獨立出版者的一項隱性資產。
與編輯協作的版本邊界：一句話總結
協作期稿件住 Reedsy、印前稿件住 Scribe、不允許兩邊同時維護——這一條規則是這一整套工作流真正的核心。其他都是細節。把它放在工作流檔案的第一行，每次開始新專案時和編輯明確一次切換點，就能避開 80% 的版本錯位與匯出格式問題。
你可能也想看
- Scribe 協作指南合集 — 與其他寫作 / 筆記 / 審校工具的協作工作流入口
- Scribe 與 Word：docx 橋接的來回審校工作流 — 如果你的編輯流程不在 Reedsy 上而是走傳統 docx 來回