真正讓你返工的，是時間、層級，還是世界觀？
年齡與日期衝突、層級大綱混亂、世界觀資料散落，需要的是不同工具。了解 Aeon Timeline、OmniOutliner、Fantasia Archive 與 Scroll 的專項深度和整合廣度。
一部長篇寫到十萬字後，最讓作者疲憊的往往不是沒有靈感，而是返工。
祖父在第一卷去世，第三卷卻又年輕了兩歲；非虛構書的大綱從四層長到八層，某個論據已經不知道屬於哪一章；為奇幻世界設計的貨幣、宗教與港口散落在幾十份筆記裡，每次寫到都要重新確認。它們都叫「規劃問題」，卻不是同一種問題。
如果角色年齡會讓推理崩塌，你需要的是時間計算；如果論證關係越寫越模糊，你需要的是層級；如果同一個世界要服務三部小說，你需要的是長期資料資產；如果人物、事件、地點、任務和正文不斷互相牽動，你需要的則是一個能保持上下文的主創作環境。
這也是為什麼 Aeon Timeline、OmniOutliner、Fantasia Archive 與 Scroll 不適合被放進一張打勾表裡。它們的價值，不是回答「誰擁有最多功能」，而是幫助不同作者少犯一次真正昂貴的錯誤。
當時間本身決定故事是否成立：Aeon Timeline
如果你寫的是跨越三代人的家族史、帶有旅行時間的歷史冒險，或使用自定義曆法的幻想系列，Aeon Timeline 的吸引力遠不止「畫一條時間軸」。它把事件、人物、地點、故事弧與敘事結構放進時間模型，讓作者同時關心事情實際發生的順序，以及讀者在章節中得知它們的順序。
這類作品真正困難的地方通常藏在算術裡。某人在事件發生時究竟幾歲？兩段旅程之間是否留出了足夠間隔？一場圍城持續多久，另一條人物線能否在同一時期抵達？Aeon 官方的 Story Math 進一步處理年齡、持續時間、依賴、相對或不確定日期與自定義曆法。對把時間一致性視為作品可信度核心的作者，這種專項深度不是一張普通事件表可以輕易替代的。
Aeon 還提供與 Scrivener、Ulysses 的官方同步路線。它同步的是結構與相關後設資料，不會改寫正文，並需要作者主動觸發；這恰好說明成熟的多工具工作流不必假裝「所有東西都在一個軟體裡」。如果你已經在 Scrivener 或 Ulysses 中形成穩定寫作手感，而時間模型又是最大的風險，繼續讓 Aeon 負責時間仍是合理選擇。
Scroll 的時間線更適合另一種處境：時間固然重要，但它只是人物關係、地點移動、劇情線、修訂任務與正文之間的一部分。作者可以在同一 Project 中換一個角度檢查這些資料，代價是不會得到 Aeon 對時間計算的全部專項深度。一個時間錯誤足以推翻全書時，先選深度；時間只是許多相互影響的問題之一時，再考慮整合。
當思考的形狀就是一棵樹：OmniOutliner
有些作品並不是從人物關係或事件網路開始，而是從層級開始。一本非虛構書可能先有中心命題，再分成幾個論點、章節、小節、證據和反例；一份課程或演講也需要不斷展開、摺疊和重新排列，直到結構本身變得可信。
OmniOutliner 在這裡不是「高階專案符號列表」，而是一套深入的層級思考環境。它可以建立無限層級、展開或摺疊內容、拖動重排、為行新增備註與附件，並用狀態、主題、篩選和目前版本相應的列能力，讓大綱同時承擔結構和資料角色。目前 OmniOutliner 6 覆蓋 Mac、iPad、iPhone 與 Apple Vision Pro；不同能力和平臺仍應以官方功能對照為準。
它最適合那些「大綱就是作品骨架」的作者。一位研究型作者可能每天都在比較第三章的證據是否其實應該支撐第一章；一位編劇也可能先把節拍與場景壓進極深的層級，再開始寫對白。在這種工作中，展開與收起不是顯示偏好，而是思考動作本身。
Scroll 的大綱與其他檢視更強調：當層級結構確定之後，它如何繼續與人物、事件、地點、任務和正文發生關係。對於結構簡單的小說，這可能比專門大綱器更順；對於一部以論證樹為核心的書，OmniOutliner 的專注反而更珍貴。
兩者也可以分階段共存：先在 OmniOutliner 中完成並凍結章節樹，再讓 Scroll 承接目前作品的正文與修訂，同時說明哪邊儲存正式大綱。
當世界觀本身是一項跨作品資產：Fantasia Archive
世界觀資料有時只是服務目前小說，有時卻比任何一部小說活得更久。語言、貨幣、種族、歷史、地點與角色關係可能被三部曲、短篇外傳，甚至桌面角色扮演活動反覆使用。把它們全部塞進「第一卷」的專案資料夾，未必是最自然的選擇。
Fantasia Archive 將自己定位為執行在電腦上的離線 worldbuilding/documenting 工具。官網連結的原作者頁面目前提供 Windows、macOS 與 Linux 下載；公開資料還列出了預定義的世界觀文件型別與欄位、雙向關係、文件層級、標籤、搜尋、排序、離線專案匯入匯出、多標籤頁和自定義鍵位等能力。
這些資訊足以解釋它為什麼會吸引「世界先於小說」的作者：設定不必依附某一章正文，它可以擁有自己的分類、關係與長期邊界。對於需要跨系列複用世界的作者，這種獨立性可能比把一切合併到目前作品更重要。
公開頁面能夠說明目前功能與下載選擇，卻不足以讓我們擅自推斷維護節奏、未來平臺或未公開能力。是否適合作為長期權威資料庫，需要作者根據目前版本、備份方式與自己的風險承受度判斷；未知並不是優點，也不該被營銷文章寫成缺點。
如果 Fantasia Archive 與 Scroll 共存，可以讓前者儲存跨作品的世界資產，讓 Scroll 只接管目前一卷會進入正文的人物、事件、地點和修訂任務；兩邊重複出現的事實仍需指定一處權威來源。
當真正的問題是：這些資料怎樣一起影響正文
一位歷史奇幻作者可能同時面對四件事：幻想曆法必須準確，三卷結構需要重排，跨卷世界設定要長期複用，而本週還必須完成第二卷的兩章正文。沒有任何原則要求她只用一款工具；也沒有任何原則要求她用四款。
她可以讓 Aeon 成為時間權威，讓 OmniOutliner 保留論綱，讓 Fantasia Archive 管理世界設定，再在寫作軟體中完成正文。這能獲得專項深度，也意味著她需要維護交接節點、命名規則和重複資料。只要這種維護成本低於返工成本，工具多並不是問題。
另一條路線，是把目前作品放進 Scroll。人物、地點和事件可以從時間、關係、空間或畫布角度檢視，正文、參考資料、寫作任務、作品與稿件版本留在同一個本地 Project。它的優勢不是每一項都做得比專項工具更深，而是作者在修改一個事件後，不必先猜「另外三套資料裡還藏著幾份舊說法」。
計劃繼續走向成書時，作者還可以讓 Scroll 中穩定的稿件沿 Scroll → Scribe 工作流進入書籍版式與出版階段；這仍是後續分工，不是 Scroll 的專項深度證明。
這就是 Scroll 更適合「多個問題互相牽動」的原因：它把規劃、正文、任務、版本與出版準備放在一條作者能解釋的路徑上。若你的時間問題需要特殊曆法推算，繼續用 Aeon；若大綱層級本身就是作品，繼續用 OmniOutliner；若世界觀獨立於任何一卷，保留 Fantasia Archive。整合不是把專項工具宣佈退役，而是決定目前作品的日常中心在哪裡。
讓最近一次返工，替你選擇工具
回想最近一次真正讓你停筆的錯誤：是角色年齡算錯，章節論證失序，設定找不到，還是同一件事在正文、任務與資料中出現了三個版本？答案比任何小說軟體榜單都更接近你的需要。
如果一個問題決定作品成敗，讓專項工具做深；如果多種資料需要在正文旁反覆互證，評估整合式工作台；如果現有組合已經成熟，就先計算交接與雙重維護成本。判斷的重點，是目前作品更依賴專項深度，還是更需要整合廣度。
想先理解 Scroll 的多檢視怎樣讀取同一組資料，可以閱讀《同一個故事，為什麼需要 11 種檢視？》；還不知道自己是構思、規劃還是寫作卡住了，可以返回比較指南或長篇創作指南。
如果你的主要成本已經來自上下文分裂，可以從 Scroll 官網了解多檢視 Story 規劃、本地 Project 與長篇寫作怎樣圍繞同一部作品工作，再判斷目前流程是否需要一個更整合的創作中心。