Scrivener 和 Campfire 的差异，不只是谁的功能比较多
搜寻 Scrivener vs Campfire，通常不是因为其中一套明显比较差。
而是因为两者都能协助小说创作，却从不同地方开始理解作者的工作。
Scrivener 先看见的是一份正在成长的长篇。
它把书拆成章节、场景、文件、研究资料与可以重新排列的结构，让作者不用在一份巨大文件里来回移动。
Campfire 先看见的则是一个由许多元素组成的故事。
角色、地点、物品、关系、文化、时间线、地图与正文，都可以用不同模组整理，再依照专案需要互相连结。
简单来说，Scrivener 擅长把一本书变成容易控制的写作专案。
Campfire 擅长把一个故事世界变成容易整理的知识结构。
但这个比较还少了一个问题。
当角色在正文里移动、物品转手、地点毁灭、阵营重组之后，这些变化只是被作者分别记在不同地方，还是会真正改变故事走到那一刻的世界？
这个问题不是功能数量可以直接回答的。
它涉及的是正文与世界观之间，究竟只是放在同一个专案里，还是真的属于同一条因果。
Scrivener 把长篇变成可以操作的文件结构
Scrivener 最成熟的地方，是它知道一本长篇不应该只是一份从第一页延伸到最后一页的文件。
作者可以把正文拆成卷、章节、场景或更小的片段，再透过 Binder 管理整个专案。
Corkboard 可以把文件变成索引卡。
Outliner 可以让作者从较高的角度查看章节顺序、摘要、字数与自订资料。
研究资料、图片、网页与笔记也能放在正文旁边，需要时直接分割画面参考。
作品完成后，Compile 则负责把分散的章节重新组合，输出成 Word、PDF、电子书或其他格式。
Scrivener 也提供 Snapshots，让作者在大幅修改一段文字以前保留旧版本。
这些功能共同处理的是一个很实际的问题：
一本书越长，作者越不能只靠卷动页面来理解它。
Scrivener 的功能设计很清楚地把产品定位在长篇写作、研究整理、结构调整与最终输出上。
角色表和地点表当然也可以放进 Scrivener。
作者可以建立文件范本、自订中继资料、使用关键字，或者替每个角色建立独立资料页。
它并不是只能写正文的纯文字编辑器。
只是这些设定资料仍然主要以文件、笔记、标签与作者自己设计的结构存在。
Scrivener 很擅长让作者找到资料。
至于资料在故事不同时间点应该是什么状态，通常仍由作者自己判断。
Campfire 把故事拆成可以连结的世界模组
Campfire 采取的是另一条路。
角色不是一份普通文件。
地点、物品、文化、宗教、语言、关系、时间线、地图与故事弧，也不必全部塞进相同格式的资料页。
作者可以按照自己的故事需要，使用不同模组建立世界元素，再透过可自订的栏位与面板保存资料。
角色可以拥有背景、特征与关系。
地点可以保存说明与图片。
物品可以成为独立元素。
Timeline、Calendar 与 Arcs 则可以协助作者观看事件、日期与故事发展。
Manuscript 模组让正文也能留在同一个创作环境里。
Campfire 的优势不只是资料种类很多。
更重要的是，它承认世界观里不同事物需要不同的整理方式。
一个角色和一个地点不应该只是两份换了标题的笔记。
它们在世界里扮演不同角色，也需要不同资料结构。
Campfire 同时提供浏览器、桌面与行动装置上的使用方式，并让创作者依需求选择写作与世界观模组。
它目前也涵盖角色、地点、物品、关系、时间线、故事弧与 Manuscript 等功能。
所以 Campfire 不是单纯替世界观准备一个更漂亮的资料夹。
它试图让故事世界本身成为可以被组织、浏览与连结的专案。
两套工具都能保存正文和设定，但保存不等于同步
如果只比较功能清单，Scrivener 和 Campfire 的重叠其实不少。
两者都能保存正文。
都能拆分章节。
都能建立角色与地点资料。
都能整理研究、笔记与故事结构。
也都有方法让作者找到需要的内容。
真正的差异，不只在于资料能不能被放进去。
而在于资料改变时，其他地方会不会知道。
假设角色洛恩在第六章进入王城。
第九章从守卫身上取得一把铜钥匙。
第十四章把钥匙交给米拉。
第十八章王城遭到封锁。
第二十二章，米拉带着钥匙再次回到城门。
这些内容完全可以被写进 Scrivener。
作者也可以在 Campfire 建立洛恩、米拉、王城与铜钥匙，并把相关事件放进时间线。
问题出现在作者回到第十二章。
那一刻，铜钥匙在谁手上？
洛恩是否仍在王城？
米拉是否已经取得钥匙？
王城是否已经封锁？
作者需要的不是角色和物品的最终资料。
也不是整条时间线上所有事件的总览。
作者需要的是故事走到第十二章时，由前面事件共同形成的世界状态。
Scrivener 可以把相关章节、笔记与角色页并排，让作者查找。
Campfire 可以透过角色、物品、地点与时间线模组，把需要交叉比对的资料整理得更清楚。
但在这两种工作方式里，作者仍然需要理解事件顺序，然后自己推导第十二章的答案。
资料都在。
答案也可能都找得到。
可是世界的「当时」仍然需要由作者重新拼出来。
一把钥匙可以同时存在于三种不同的真相里
长篇写作最容易发生的问题，不是作者完全没有记录。
而是同一件事在不同地方留下了不同版本。
正文写着洛恩已经把钥匙交给米拉。
洛恩的角色页仍然把铜钥匙列在随身物品里。
铜钥匙的资料页写着持有人未知。
时间线则只写了「两人在王城分别」。
每一份资料都不是完全错误。
它们只是没有一起更新。
更麻烦的是，作者脑中可能还保存着另一个版本。
在最初的大纲里，洛恩本来没有交出钥匙。
作者后来修改正文，却仍然记得原本安排。
等到第二十二章需要使用钥匙时，他很自然地让洛恩把它拿出来。
这时候，问题不在作者找不到设定。
也不在世界观资料不够完整。
问题是正文、设定、时间线与记忆同时保留了不同版本的世界。
Scrivener 能帮作者管理这些文件。
Campfire 能帮作者管理这些世界元素。
但只要正文中的事件与资料页之间仍然需要人工同步，作者就必须自己担任两套真相之间的对帐者。
故事越往前，这项工作越不只是整理。
它开始变成持续维护世界历史。
世界观资料不只有内容，还有时间
角色资料通常回答：
这个人是谁？
物品资料回答：
这件东西有什么用途？
地点资料回答：
这个地方原本是什么样子？
这些问题都很重要。
但故事还会产生另一组问题：
这个角色在此刻在哪里？
这件物品在这一章由谁持有？
这个地点在这场事件发生以前是否仍能进入？
这个阵营在领袖死亡后还剩下什么结构？
同一个角色、物品与地点，可以在不同章节拥有不同答案。
因此，世界观不能只有一份永远显示最新结果的资料。
它还需要保存每一次改变发生的位置。
洛恩取得钥匙，是一次事件。
洛恩把钥匙交给米拉，是另一次事件。
王城遭到封锁，也是一次事件。
第十二章的世界，只承认发生在它以前的改变。
第十八章以后的世界，才需要承担王城封锁带来的限制。
这不是多写几份角色卡就能彻底解决的问题。
因为作者真正需要的不是更多资料页。
而是一个能沿着故事时间回答「此刻世界是什么状态」的方法。
InkWeave 让正文事件与世界资料属于同一条时间线
InkWeave 同样具有正文编辑、卷册与章节管理。
角色、物品、地点、阵营与属性，也都是可以建立、查看与管理的世界实体。
不同之处在于，这些实体不是只放在正文旁边供作者查阅。
它们可以被正文里已确认的事件改变。
角色移动到王城，会留下移动事件。
角色取得、放置或转交物品，会改变物品的归属与位置。
地点被封锁、禁入或毁灭，会改变后续行动条件。
角色死亡、失踪、转职或改变属性，也会留在实际发生的故事位置上。
所以当作者把游标放在第十二章，InkWeave 不需要只显示铜钥匙最后由谁持有。
因果律引擎可以沿着第十二章以前已经确认的事件，推导那一刻的答案。
洛恩已经取得钥匙。
但他还没有把它交给米拉。
王城也尚未遭到封锁。
当游标移动到第二十二章，世界才会带着后面更多事件的结果出现。
这里的关键不是 InkWeave 也有一张时间线。
而是正文顺序本身就是世界时间。
事件不是作者另外写在摘要里的说明。
它们是改变角色、物品、地点与阵营状态的因果来源。
写作现场不必再和世界观分开
当作者在 Scrivener 或 Campfire 里写到角色名，他可以搜寻角色资料、打开相关页面，或者把设定放在正文旁边参考。
这些方式都比在大量散落笔记里寻找资料有效。
InkWeave 再往前一步。
当已建立的角色、物品或地点出现在正文中，它们不只是一段可以搜寻的名字。
AVG Stage 与 Inspector 可以依照游标所在的故事位置，带回这些实体此刻的状态。
角色现在在哪里。
物品目前由谁持有。
地点里有哪些角色与物品。
相关状态是否已经改变。
当角色和地点在正文里靠近，世界可以询问这里是否发生移动。
角色和物品靠近时，可以先呈现物品目前的归属，再让作者确认这里是取得、放置、转交，还是只有提到。
两名角色靠近时，也可以检查他们是否位于同一个地方，以及是否已经存在关系。
系统不会因为看到两个名字，就自行决定故事发生了什么。
最后仍然由作者确认。
但作者不必先离开正在写的句子，到另一套资料里重新拼凑世界。
设定不再只是写作以前准备、写作途中查阅、写作以后补充的资料。
它会带着前文造成的改变，回到正文旁边。
回修前文时，差异会变得更明显
长篇很少从第一章一路写到最后一章，中途完全不修改。
作者可能回到第九章，决定洛恩根本没有取得那把钥匙。
这个修改看起来只动到一个场景。
但第十四章的转交事件立刻失去前提。
洛恩不能把自己没有取得的物品交给米拉。
第二十二章依赖米拉持有钥匙的场景，也跟着失去来源。
在一般文件与世界观管理流程里，作者可以使用搜寻、时间线、标签、笔记与版本比较，逐一找出需要修改的地方。
Scrivener 的 Snapshots 很适合保存修改前的文字。
Campfire 的角色、物品与 Timeline 模组也能帮助作者整理相关资料。
但它们的主要工作，是让作者看见并管理内容。
InkWeave 的因果律引擎处理的是内容之间是否仍然成立。
当较早的取得事件被移除，后面的转交不再只是「可能需要留意」。
它失去了因果来源。
验证系统可以指出：这里要求角色交出一件他在目前世界线里并未持有的物品。
它不会替作者决定如何修复。
作者可以让洛恩改用其他方式取得钥匙。
可以把转交改成另一件物品。
也可以接受后面的城门场景必须改写。
InkWeave 不保证故事永远不会改变。
它保证改变不必悄悄发生。
真正的选择，是世界观与正文要不要一起运作
Scrivener 和 Campfire 都不是只能用一句话概括的工具。
Scrivener 不只有正文。
Campfire 也不只有设定。
两者都能承担相当完整的小说创作流程，只是它们整理故事的中心不同。
如果比较停在章节、角色卡、时间线、图片与输出格式，最后很容易变成一张谁勾选了更多功能的表格。
但长篇故事真正困难的地方，通常不是功能表里少了一个栏位。
而是角色、物品、地点与阵营在正文里改变以后，所有后续内容是否仍然承认那些改变。
InkWeave 并不是在写作工具和世界观工具之间再增加第三套需要维护的资料。
它本身就是正文与世界观共同运作的地方。
作者可以从第一章开始建立角色与物品。
也可以从第一个事件开始，让世界记住它们如何移动、转手、改变与失去。
故事现在有多长，不是重点。
重要的是，作者不必等到世界变得复杂以后，才开始补救已经分裂的资料。
当正文里的事件能够改变世界，世界又能把当时的状态带回正文，写作与世界观管理就不再是两份需要反覆对帐的工作。
Scrivener 把长篇变成可以控制的写作专案。
Campfire 把故事世界变成可以整理的知识结构。
InkWeave 则让写作专案与世界结构沿着同一条因果一起改变。
真正要比较的，不只是你能把多少资料放进工具里。
而是当故事开始发生以后，那个世界会不会记得自己已经变成了什么。