別再靠 final-final 找定稿：稿件版本、正式來源與完整 Project 備份

晚上十一點，三部曲作者收到排版師的訊息：「第二冊第十二章為什麼沒有上次確認的修改？」她正在同時做兩件事：把第二冊送去首次排版，根據讀者勘誤修訂第一冊。資料夾裡有「作者定稿」「編輯審閱」「final-final」，雲端硬碟還多出一份衝突副本。每個名字都像答案，卻沒有任何一處明確說明：這次進入排版的究竟是哪部作品、哪一版、哪一組章節。

排版師及時發現了問題，錯稿還沒有進入整本書的分頁與校對。作者卻意識到，final-final 試圖同時承擔三種完全不同的責任：說明目前採用哪份稿件，保留過去某個時點的實際內容，以及在裝置或操作出錯後恢復完整 Project。檔名再長，也無法獨自回答這些問題。

先讓這次交付能夠被準確指認

Scroll 的本地 Project 是作者自己選擇的普通資料夾。一個 Project 可以登記一部或多部作品，讓第一冊修訂版與第二冊初版擁有各自邊界。系列關係仍然存在，但每部作品不必共享一個模糊的「目前系列正文」。

這一區分在系列中尤其重要。同一位角色會出現在三本書裡，同一個地名也可能在再版時修正，但「共享設定發生變化」不等於「三本正文已經一起更新」。作者需要先知道這次決定屬於整個系列，還是只屬於某一部作品的某個版本，再安排其餘核對。Scroll 不會在不同 Project 間自動傳播設定，也不會替作者判斷舊版是否應當保留原寫法。

作者先在 Works 確認第二冊，再查看為它登記的稿件版本與正文來源。版本標籤幫助她說明「這是編輯審閱後修訂稿」，Publish Version 則記錄本次準備採用的版本和來源。她終於能對排版師說：「請以第二冊首次出版的這組章節為準；第一冊再版仍在另一項修訂裡。」討論從猜檔名，變成核對一個明確選擇。

如果交付期限就在週五，這種清楚會直接影響製作安排。排版師不必先下載三份附件逐章找差異，作者也能把仍在變化的第一冊留在創作階段，而不誤送給正在處理第二冊的排版流程。版本邊界沒有讓書更快寫完，卻減少了已經完成的校對因為錯稿而重新來過。

這種邊界不是給獨立作者增加行政工作。它讓第一冊讀者勘誤與第二冊編輯意見可以同時推進，而不會因為一個共享地名改變，就讓所有稿件失去身份。等跨卷決定穩定後，作者再按自己的規則更新相關資料；在此之前，每部作品仍有可解釋、可交付的正文來源。

版本名稱儲存決定，實際副本儲存內容

正文來源仍然是每天開啟、儲存和修改的 Markdown 檔案。Scroll 登記稿件版本時，不會複製或凍結這些檔案，也不會建立 Git 式歷史。作者如果繼續編輯來源，版本標籤不會跟著變成新快照；再次交付前，仍要重新檢查章節範圍、順序和未完成標記。

因此，重要編輯節點需要保留實際副本，例如「編輯返回前」「結構修訂完成後」或「交付校對前」。副本負責保住當時的文字，版本登記負責解釋它在作品流程中的意義。一個回答「內容是什麼」，另一個回答「我們為什麼採用它」。

實際副本也需要能被未來的自己讀懂。與其只複製一份 final-3，不如在副本旁保留簡短說明：它對應哪部作品、在哪次審閱後儲存、是否已經完成事實核對、後來為何被另一版取代。說明不必變成長日誌，卻能讓半年後的再版不再依賴當時參與者的記憶。

這也是那次錯稿事故的關鍵。作者發現排版師拿到的並非損壞檔案，而是一份真實存在、卻已經不再代表目前決定的舊稿。只看修改日期，兩份檔案都合理；回到作品、版本和本次 Publish Version，才知道哪一份算數。工具不替作者決定定稿，但可以把已經作出的決定留在 Project 裡。

完整備份保護的不只是章節

只複製正文資料夾，也許能保住小說文字，卻可能遺漏任務、儲存檢視、畫布、Project 設定與交付記錄。完整備份應當在關閉 Scroll 後複製整個 Project 資料夾，並讓隱藏檔案與資料夾一同保留。目前做法與注意事項應以資料安全與恢復文件為準。

本地 Project 帶來的優勢，是作者能夠選擇備份位置和策略。關閉應用後儲存的完整副本，可以放在另一塊磁碟、外接裝置，或作者信任的雲端備份位置。這不代表「本地就不會丟」，也不代表同步服務會理解小說版本；真正有用的恢復點，要能找到、能說明日期，並且確實包含整套 Project。

在結構大修、裝置更換或正式交付前，作者可以做一次小規模恢復檢查：把備份複製到臨時位置，確認 Scroll 能正常開啟該 Project，且首章、末章、任務和作品資訊都在。無需每晚演練，但比只看一個完成同步的圖示更能說明「我確實回得去」。

恢復檢查還會揭示「只有正文回來」與「作者能夠繼續工作」的差別。章節全部存在，卻丟了跨章任務、儲存檢視和本次交付來源，作者仍要花數日重建修訂現場；完整 Project 能讓她在故障之後重新看見工作進行到哪裡、哪些判斷尚未完成、下一步準備交哪一稿。備份的目標不是收藏更多副本，而是縮短從事故回到創作的距離。

對於長期連載或持續再版的作者，可以把恢復點與作品節點繫結：在結構修訂結束、交給編輯、進入 Scribe 前，各保留一次恢復點。頻率由專案風險決定，不需要把每次儲存都包裝成正式版本。少數有意義、經過抽查的恢復點，比一串無法說明用途的自動副本更容易在真正需要時使用。

外部編輯器或多個裝置同時修改同一檔案時，仍可能產生衝突。此時先保留雙方副本，再人工比較內容；不要讓「最後修改時間」替作者判斷哪一段文字正確。衝突副本是需要處理的實際檔案，不會因為更新就自動成為正式稿件，Scroll 也不會替作者合併兩邊的創作決定。

從寫作進入成書，仍有一次人工交接

稿件穩定後，Scribe 負責 Appearance、分頁、PDF、EPUB 與其他出版輸出。Scroll 記錄作品、本次準備採用的稿件版本和來源；作者再用 Scribe 開啟同一個 Project，並核對它識別出的作品、Publish Version、來源資料夾、章節數量與順序。

這不是上傳，也不是 Scroll 自動把稿件變成書。準備狀態說明上游登記已經就緒，不代表 Scribe 已完成識別，更不代表頁面已經正確。作者在 Scribe 中確認來源後，才開始處理書頁表現；若結果與預期不同，問題可以回到具體作品、版本或資料夾核對，而不是重新翻找全部歷史副本。

明確交接也能減少實際損失。一次舊稿進入排版，往往不只需要替換檔案，還可能造成重新分頁、重複校對、樣書作廢或發行延期。把創作階段的來源說清，讓 Scribe 從一份可解釋稿件開始，並不能消除所有錯誤，卻能避免讓一個模糊檔名把錯誤帶進整個製作流程。

完整交付檢查可見《什麼時候稿件算準備好交給 Scribe？》；兩款產品的職責見Scroll → Scribe 工作流。完成結構修訂但尚未建立版本邊界時，可以先讀《初稿寫完以後，真正困難的是怎麼改》；系列作者也可參閱《系列小說作者的專案與版本管理工具清單》。

當作者能夠清楚回答「我正在改什麼、這次採用什麼、出錯後回到哪裡」，final-final 就會退回一個普通檔名，不再被當作定稿證據。回到Scroll 長篇創作指南可以繼續進入研究、修訂與版本入口；想了解 Scroll 怎樣管理本地 Project、作品和正式來源，可查看 Scroll 產品頁。