2026 系列小說作者的專案與版本管理工具清單

系列小說最初常從一份大綱開始。等到第二卷進入修訂，作者手裡已經有第一卷出版稿、第一卷再版修改、第二卷編輯審閱版、第三卷設想，以及一套三本書共同使用的地名和人物資料。她搜尋「王都議會」時，找到五種說法；檔名則從 final 長成 final-final-真的定稿。

這並不只是命名失控。系列創作同時包含幾種不同內容：跨卷共享的世界事實、每一部作品自己的正文、同一作品的不同稿件版本、本次準備出版的正式來源，以及能在裝置故障後恢復的完整 Project 備份。把它們都叫「版本」，工具再多也難以回答哪個檔案負責什麼。

系列作者通常還要在不同時間尺度上工作。今晚，她正在修改第二卷的一場爭吵；這個月，她要把第一卷勘誤整理成再版稿；明年，她還要記得第三卷為什麼不能沿用某條舊設定。能看見整套系列固然重要，但真正讓工作繼續的，是每次回到書桌時都知道自己正在改哪一部、哪一版，以及這項改動是否應影響其他作品。

下面七款工具從視覺系列規劃、時間、長篇工程、寫作 Library、協作資料庫、模組化創作與本地 Project 切入。選擇時，不妨先確認你最常混淆的是「跨卷關係」，還是「本次到底交哪一稿」。

Plottr：先看見幾本書之間的情節結構

Plottr 的視覺時間線、場景卡、情節線與 Series View，適合從高處查看多卷結構。作者可以觀察一個人物弧跨過幾本書，某條伏筆在哪一卷埋下又在哪一卷回收，Story Bible 則為人物與地點提供規劃資料。

它適合視覺型規劃者，也適合在動筆前先確認系列節奏。正文進入多輪修訂後，作者仍要指定正式稿件來源，並決定視覺規劃裡的變化何時寫回各卷。

Aeon Timeline：讓跨卷年代保持可計算

跨越數十年、多人年齡互相牽制，或使用自定義曆法的系列，會把時間變成基礎設施。Aeon Timeline 圍繞事件、人物、地點、敘事順序、年齡、持續時間和相對日期建立專項模型，也能服務包含多個故事或書籍的規劃。

如果一處年代錯誤會影響整套系列，讓時間工具成為權威很合理。它解決的是「何時發生」；每卷正文、研究、修訂任務和正式出版稿仍需要其他邊界。

Scrivener：為每一部長篇建立成熟工程

Binder、Corkboard、Outliner、Research、Snapshots 與 Compile 讓 Scrivener 很適合管理單本長篇的結構、資料和輸出。作者可以讓每卷擁有自己的工程，也可以按照寫作習慣建立總工程，把系列資料與各卷稿件分層組織。

它的優勢是長篇工程成熟。系列增長以後，真正要提前決定的是工程邊界：共享世界資料放在哪裡，哪份 Compile 設定對應哪一版書，以及已經出版的內容如何與仍在變化的稿件分開。

Ulysses：在連續 Library 中保持寫作節奏

Ulysses 的 Library、Projects、Groups、Filters 與 Sheets 適合讓不同作品保持整齊，也讓作者在 Apple 裝置之間延續寫作節奏。Sheet 可以拆分、合併與排序，Project 和 Group 則幫助作者把目前系列與其他文字區分開來。

對以純寫作為中心、願意透過命名和分組管理系列的人，這種安靜很珍貴。隨著跨卷 Story data、研究資料、修訂任務與出版來源增加，作者可以再判斷 Library 層級是否足夠表達這些職責。

Notion：讓系列聖經與製作狀態共同可見

資料庫的多種檢視、評論、權限和共享 Workspace，使 Notion 很適合系列策劃、共同研究與製作進度。人物、地點、每卷狀態、封面任務和宣傳節點可以從不同 View 查看，合作者也能在對應頁面旁交流。

當主筆需要長時間完成正式正文，協作資料庫與本地稿件可以各有職責。Notion 目前提供 Offline Mode 和匯出路徑，但可下載頁面、匯出副本與作者直接管理的普通本地 Markdown Project 並不是同一形態；團隊最好明確哪一處儲存決定，哪一處儲存正式長稿。

Campfire：按系列需要組合寫作模組

Campfire 將 Manuscript、人物、時間線與世界構建等能力放入模組化創作環境。系列作者可以按專案規模選擇關注的資料，而不必讓每本書繼承一份完全相同的重型表格。

模組化特別適合需求隨卷變化的系列：第一卷需要世界介紹，第二卷可能更關注派系關係，第三卷才出現複雜年代。規劃時仍要寫清共享資料與單卷事實的邊界，避免一處修改在各卷留下不同解釋。

Scroll：把作品、稿件版本與出版來源說清楚

Scroll 讓一個本地 Project 可以登記一部或多部作品，並讓 Story data、正文、參考資料和任務留在清楚的 Project 邊界內。Works 用來說明「這是哪一部作品」，稿件版本用來區分同一作品的不同版本語義，Publish Version 則記錄本次準備採用的正式來源。它們幫助作者表達邊界，但不會自動複製、凍結或生成另一份稿件。

舉例說，作者可以在約定的位置維護系列總設定，在目前 Project 中儲存這部作品真正使用的人物、地點與事件；如果不同卷分屬不同 Project，它們不會自動同步共享資料。「編輯審閱版」和「再版修訂版」透過版本語義分開；準備成書時，再由作者指定本次 Publish Version 所對應的來源。這個選擇不等於匯出了出版檔案，也不代表下游已經完成識別。

當第一卷讀者勘誤與第二卷編輯意見同時到來時，這些邊界會讓作者少做一次危險的猜測。她可以在第一卷的修訂來源裡改正地名，在第二卷任務中記錄同一名稱需要核對，卻不必立刻把所有檔案混成一個「系列最新版」。等決定穩定，再把共享事實更新到約定的權威資料。每一部作品仍有自己的可交付正文，系列關係則幫助作者看見哪些變化需要跨卷傳播。

版本記錄也不是 Git 式歷史。若作者覆蓋了正文，版本名稱不會憑空還原舊內容；重要階段仍需要實際副本和備份。完整 Scroll Project 可能包含隱藏的專案資料，因此備份時要複製整個 Project 資料夾，而不是只挑可見 Markdown。Scroll 目前也不提供把所有 Project 一次性全域匯出的內建按鈕。

本地 Project 讓備份位置由作者選擇：關閉 Scroll 後複製的完整 Project 副本，可以放在另一塊磁碟、外接裝置，或作者信任的雲端備份位置。這裡的優勢是控制權，不是「本地就不會丟」。同步衝突也不會被 Scroll 自動合併，處理前應先保留雙方副本，再由作者判斷。

當本次稿件穩定後，作者可以用 Scribe 開啟同一個 Project，核對作品、Publish Version、來源資料夾與章節順序，再處理 Appearance、分頁和出版輸出。Scroll 負責創作資料、正文、修訂、版本語義和正式來源；Scribe 負責把已確認的稿件做成書。Scroll 不直接輸出 PDF、EPUB 或印刷版式，Publish Version 也不代表 Scribe 已經成功識別章節。

這套邊界特別適合再版與自出版作者：她不必在寫作階段提前處理書頁細節，卻能在進入製作前清楚回答「這是哪部作品、哪一版、來自哪些章節」。完整交付檢查可見《什麼時候稿件算準備好交給 Scribe？》。

它也讓作者與編輯之間的溝通更具體。「請看最新版」很容易失去上下文；「請審閱第二卷首次出版稿的這一組來源，第一卷再版另有版本」則把討論留在同一個邊界內。工具不會替團隊建立命名規則，但一旦規則寫清，作品登記、稿件版本與實際副本就能共同儲存這次決定。

如果你的核心問題是跨卷視覺結構，Plottr 會提供直觀入口；若日期必須精確，Aeon 的專項模型更重要；若每卷主要是一項成熟長篇工程，Scrivener 值得繼續使用；若你珍惜連續寫作，Ulysses 有清楚價值；團隊策劃可保留 Notion，模組化世界構建也可交給 Campfire。Scroll 更適合需要讓目前作品、修訂任務、稿件版本、本地來源與成書下游保持同一條責任鏈的作者。

進一步可讀《別再靠 final-final 找定稿》；想從其他創作難題選擇工具，可回到年度工具合集。若要了解 Scroll 怎樣組織作品與版本，可查看 Scroll 產品頁。