别再靠 final-final 找定稿：稿件版本、正式来源与完整 Project 备份

晚上十一点，三部曲作者收到排版师的消息：“第二册第十二章为什么没有上次确认的修改？”她正在同时做两件事：把第二册送去首次排版，根据读者勘误修订第一册。文件夹里有“作者定稿”“编辑审阅”“final-final”，网盘还多出一份冲突副本。每个名字都像答案，却没有任何一处明确说明：这次进入排版的究竟是哪部作品、哪一版、哪一组章节。

排版师及时发现了问题，错稿还没有进入整本书的分页与校对。作者却意识到，final-final 试图同时承担三种完全不同的责任：说明目前采用哪份稿件，保留过去某个时点的实际内容，以及在设备或操作出错后恢复完整 Project。文件名再长，也无法独自回答这些问题。

先让这次交付能够被准确指认

Scroll 的本地 Project 是作者自己选择的普通文件夹。一个 Project 可以登记一部或多部作品，让第一册修订版与第二册初版拥有各自边界。系列关系仍然存在，但每部作品不必共享一个模糊的“当前系列正文”。

这一区分在系列中尤其重要。同一位角色会出现在三本书里，同一个地名也可能在再版时修正，但“共享设定发生变化”不等于“三本正文已经一起更新”。作者需要先知道这次决定属于整个系列，还是只属于某一部作品的某个版本，再安排其余核对。Scroll 不会在不同 Project 间自动传播设定，也不会替作者判断旧版是否应当保留原写法。

作者先确认第二册对应的 Work，再查看为它登记的稿件版本与正文来源。版本标签帮助她说明“这是编辑审阅后修订稿”，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 产品页。