Scroll 长篇创作指南：从构思、规划到沉浸写作

长篇写作很少真的停在“没有灵感”。更常见的情形是：你知道凶手是谁，却看不清三条时间线在哪里冲突；你知道下一章要写什么，脑中却同时挂着十几处待修订的问题；资料已经搜集得很完整，坐到正文前还是忍不住回头整理人物卡。

这些停滞看起来相似，实际需要的下一步并不相同。开始之前，不妨先问一句：我此刻需要看清故事、推进写作，还是处理研究、修订与版本？

Scroll 把 Story 规划、任务、研究资料与正文放在同一个本地 Project 中，但并不要求作者沿着一条固定流水线前进。你可以在构思、检查、起草和修订之间往返；重要的是让每个工作区回答它真正负责的问题。

构思与规划：先让故事资料参与正文

人物、地点、事件、时间与关系属于故事本身。面对一部跨三代的家族小说，你也许先用表格找出缺失字段，再用时间线核对年龄，用关系图确认亲缘与利益关系。它们观察的是同一组由作者记录的 Story data，不需要为每种视图各维护一份副本。

• 《同一个故事，为什么需要 11 种视图？》说明表格、时间线、关系图、地图与画布分别适合回答什么问题。
• 《模板不是故事公式》区分内容模板、Project 模型与故事公式，帮助作者只记录真正会反复使用的信息。
• 《世界观不是百科全书》讨论怎样让人物、地点、规则与历史回到场景选择，而不是在正文之外无限生长。

这些视图不会从正文里推断日期、关系或缺失事实。它们让已经明确记录的信息更容易检查，也把“什么是真的”这项判断留在作者手里。

推进与沉浸：把“继续写”缩小成今天能完成的工作

有时 Story 已经足够清楚，写作时段却仍然无法开始。“推进整本书”太大，复杂的跟踪系统又会把本来有限的时间消耗掉。更实用的做法，是把作品中发生的事件与作者接下来要做的工作分开。

• 《把“写完一本书”拆成看得见的工作》把起草与修订变成可以完成的任务，并用看板限制同时推进的事项。
• 《怎样建立可持续的沉浸写作时段》围绕明确目标、适量反馈和安全出口组织小黑屋，而不是把沉浸写作变成意志力竞赛。
• 《即阅模式还是源码视图？》说明怎样在流畅写作与 Markdown 源码检查之间切换，而不把它们当成两份稿件。

一部双时间线小说可以这样推进：先用事件卡和时间线核对冲突，把“修正第十二章的日期”写成任务，再用一段专注时间修改正文。第二天，作者完全可以因为新的发现回到 Story；创作路径不必假装是一条直线。

研究、修订与版本：让成熟稿件仍然可追溯

初稿越接近完成，问题越可能从“下一章写什么”变成“谁在何时知道什么”“这条资料来自哪里”“哪些章节都受同一条编辑意见影响”，以及“现在究竟哪一份稿件要进入出版准备”。这时需要的不是更多零散笔记，而是一条能串起资料来源、作者判断与正文的路径。

• 《线索没有丢，只是散在整本书里》把实际事件、人物知情范围与读者获得的信息分开，帮助悬疑作者人工核对公平性与时间顺序。
• 《“我记得看过这条资料”》区分外部原件、Project 副本、作者判断与正文表达；链接和搜索能找回上下文，却不会自动生成正式引用或证明资料可信。
• 《初稿写完以后，真正困难的是怎么改》把宽泛反馈收束成一个结构问题，再用跨章任务完成一轮边界清楚的修订。
• 《别再靠 final-final 找定稿》梳理作品、稿件版本、Publish Version、真实副本与完整 Project 备份各自负责什么。

Timeline 只能展示作者输入的日期，搜索结果也不能替作者判断一条资料的意义；版本标签更不是自动保存的历史快照。Scroll 的优势在于让这些问题留在同一个创作环境中，作者仍然负责完成编辑判断、备份与交付检查。

当稿件开始变成一本书

如果你只写一篇线性短文，文件树与编辑器也许已经足够，不需要为了显得“专业”而建立复杂资料。相反，当稿件版本已经稳定，真正的问题变成 Appearance、分页与出版输出，就应从创作工作转向Scroll 与 Scribe 的分工指南。Scroll 负责构思、正文、修订、版本组织与交付准备；作者在 Scribe 中核对识别结果后，再开始书籍制作。Scroll 不直接完成 PDF、EPUB 或印刷版式，准备好交付也不等于 Scribe 已成功识别。

今天只需要选择一个最接近当前卡点的入口。若想看看这些路径怎样围绕同一个本地 Project 工作，可以继续了解 Scroll；其余工作区可以等问题真正出现时再使用。