第11章　Vault 的一生：回流与运营循环

完成验证的 Vault 进入后续工作后，短篇会据此写作，角色表也会继续制作。已经建好一次的 Vault，是否就完成任务了？

并不是。答案来自 Librarying 运营中最重要的一项原则。

“完成”这个概念本身的错误

“Vault 完成”这句话暗含一个假设：完成后的 Vault 已成为不再变化的稳定状态。但 IP 会变化。新作品出现，设定被修改，新人物登场，原有人物也显露新的面向；只要 IP 仍在生长，它的词汇就会一起变化。

若把 Vault 当作一次完成便结束的产物，最初费心建立的 1,500 个文件，即使两年间新出了十部作品，也会停留在原样。写作者在 Vault 中找不到新词汇，就会停止使用它；不被使用的 Vault 也失去更新理由，最终被搁置到无法再发挥作用。

想想维基百科就容易理解。它从未“完成”：每天都有大量新条目与修订，昨天发生的事今天便可能成为条目。这就是活的文档（living document）。Vault 也是活的文档；它不是完成后便停止，而是在 IP 存续期间与之共同改变。这种认识转换正是第11章的起点。

回流：写作回到 Vault 的循环

Librarying 的基本方向，是让信息从 IP 文档流向 Vault。第一阶段从原始文档抽取关键词，经过第二至第四阶段，完成为 Vault 词条。

回流（backflow）是相反方向的过程：利用 Vault 写作短篇时，新创造的词汇会回到 Vault。理解其缘由便会明白，回流不是例外事件，而是创作自然带来的副产物。

设想写作者参考既有 Vault，使用神秘世界观“Rosy Hollow”中的“修正”和“校正”词条写一个场景，却发现需要一个既有设定没有的概念，于是新造“逆读（逆读）”。它指原案者反向解读修正抹去瑕疵后遗留的过新痕迹，复原刚刚被擦去之物；这是一种与抹除瑕疵的修正方向相反、重新读出被删除之物的行为。

该概念首次出现在这篇短篇中，尚未进入 Vault，却很可能在同一 IP 的其他作品里再次使用，正因此需要回流。写作者留下简短定义及其在短篇中的出处，备注便积累到回流队列。Librarying 会在下一次增量执行时检查队列里的新词汇。

重要的是，系统不会立即自动登记。人必须先判断：该词是否真是应收录进 Vault 的词条、既有词条的别名，还是只在一篇短篇中出现后便消失的临时表达。只有决定收录的项目才加入第二阶段 CSV，确认世界观轴处于允许值范围后，第三阶段骨架构建会以增量方式生成新的 .md 文件。随后第四阶段补齐叙述，回流队列中也留下登记完成的时间。

写作时发现新词汇，将其登记进 Vault，再在下一次写作中重新参照；只要这个循环不断，Vault 就会成长为一部活的词典。

回流的实务运营

写作者写短篇时经常会使用 Vault 中没有的术语。此时有两种做法：一是立即登记，暂时停止写作，直接把该术语加入 Vault；二是放入回流队列，不打断写作，只记下发现了新术语，等写作结束后统一处理。新术语若是该短篇的核心概念，适合立即登记；若只是周边词汇的首次出现，则可先放入队列。立即登记的好处是，在同一篇短篇中再次使用该术语时，能马上从 Vault 参照。

完全不做回流，Vault 最终会停止运作。若只持续写作，Vault 与写作之间的差距会日益扩大；到了某个时刻，写作中使用的词汇已无法在 Vault 找到，写作者便会认定 Vault 没有用处，不再参考它。

然而，把回流管理得过于严格同样不现实。每写一个词都停下来更新 Vault，会打断写作的节奏；回流不该成为写作负担。每完成一篇短篇便处理一次回流队列，是现实可行的平衡。

增量更新：只重新处理发生变化的部分

IP 运营中出现新增或修改资料时，需要再次运行 Librarying。若每次都从头重跑，首轮耗费的 9 到 16 小时又要重来，显然效率很低。

这与软件开发的版本管理（git）相似。修改代码时，不会重新构建全部代码，而是只重新编译变更文件，未变更的文件继续使用上一次构建结果；这就是远快于全量构建的增量构建（incremental build）。Librarying 的增量更新也遵循同一原理，只处理变化部分。新增一篇短篇时，流程如下。

只对新短篇文件做第一阶段抽取。 向既有第一阶段 CSV 添加新行，不碰原有行。
完整重跑第二阶段整合。 新行会被吸收进既有词条或形成新词条，也可能补强旧词条的异称、别名与相关关键词。
增量运行第三阶段骨架构建。 只为新词条生成 .md 文件；既有文件按幂等规则只更新 frontmatter 和正文，LLM 区块会被保留。
增量运行第四阶段叙述写作。 只填充新建文件的 LLM 区块。

一篇短篇通常新增 30 到 50 个词条。这样的增量更新约需 1.5 到 2 小时，只相当于完整重跑的八分之一到十分之一。

既有 LLM 叙述得以保存的原因：幂等规则的长期价值

第7章所述的幂等更新规则，是指再次运行骨架构建时，虽然会重写 frontmatter、定义和详情，却不触碰由人填写的 LLM 叙述区块。它的长期价值在以下情境中很清楚。

假设 IP 两年间推出了 50 篇短篇，并做了 50 次增量更新。LLM 区块的一部分叙述来自两年前首次第四阶段写作，另一部分来自最近的增量更新；即便经过 50 次重建，LLM 区块也没有损失一行。没有幂等规则，两年来的写作成果可能在某一次重建时消失。

增量更新有一点必须留意。第二阶段 CSV 的定义或详细说明更新后，frontmatter 与正文会换成新信息，LLM 叙述却可能仍引用旧版本。发现这种不一致时，应当对该词条的 LLM 叙述进行增量重写：不是完全删除重写，而是参考既有叙述，只反映改变的部分。

不一致有多严重取决于具体情况。若只是“修正”的官方英文名称改变，只需修改 LLM 叙述中使用英文名的部分；若“修正”的核心概念本身改变，则需重写整段 LLM 叙述。前者是 P2 问题，后者是 P1 问题。

重构：范围更大的更新

回流和增量更新是日常运营，重构则是非定期发生、范围更大的更新，分为两类。

第一类是世界观轴再设计。IP 向新方向扩展后，若积累出既有世界观轴体系无法分类的关键词，就必须重新进行 profiling、设计世界观轴，并更新全部词条的轴分类。第6章说明过，世界观轴起初是暂定的，应在运营过程中依 IP 的需要调整。小幅调整可以用增量更新处理；但 IP 若大幅偏离最初预期，世界观轴可能本身已无法容纳 IP，这就是重构的时机。拖延重构，错误分类的词条及其引用叙述都会增多，日后全部重新分类的成本更高，因此一旦出现信号，应尽早处理。

第二类是命名政策变更。当某一分类的命名规则不统一，需要整理时，例如有的词条代表关键词用韩文，有的用英文，有的混用，便应统一到一个方向。只要在第二阶段 CSV 中批量修改代表关键词，再运行第三阶段骨架构建即可；LLM 区块仍由幂等规则保存。

重构时，我选择不删除旧词条，而是改变版本状态来保存它们。采用新设定的词条保留为现行；不再属于正史、但仍存在于作品中的旧设定标为过去版本；只有完全失效的才作废。这样日后重读旧短篇或参考过去设定时，相关词汇仍留在 Vault。

词条名称本身改变时更需谨慎。若创建新代表关键词文件后立即删掉旧文件，其中的 LLM 叙述与工作备注也可能一起消失。因此应把旧文件单独隔离，确认其中 LLM 区块和备注是否要移植到新词条。名称会改变，长期积累的叙述和判断痕迹却是工作资产。

活的 IP 的确如此运营。2014 年 4 月，Lucasfilm 将小说与漫画累积的既有扩展宇宙统称为“Legends”，移出正史并另行管理新正史，还设置了统筹正史的 Story Group。这并非删除旧设定，而是把它作为过去版本保留，与重构时将旧词条转为过去状态而非废弃的思路相同。DC Comics 2011 年以“New 52”从第1期重新编号，同时保留部分设定而非全面推倒重来，也是一种决定何处延续、何处重新开始的正史版本管理。

运营循环的周期

在实际运营中，Librarying 增量更新的频率取决于 IP 的形态。短篇写作项目建议每完成一篇短篇就更新一次；若积攒十篇后才集中处理，回流队列会大到难以负担，新词汇也会长期不在 Vault 中却已用于写作。长篇原稿或游戏内容则适合在一个章节完成或一个补丁发布时，按章节或补丁运行增量更新。

若 IP 有固定更新周期，Librarying 的更新也应定期执行。例如把每月第一个星期一做增量更新写进运营日历，Vault 就能始终保持接近最新的状态。

无论如何设定周期，有一条原则不会变：Vault 更新一旦成为“这次有时间再做”的事情，Vault 就开始被搁置。 最安全的方式是把更新自动关联到短篇完成、章节完成或补丁发布等特定 IP 事件。

运营十年的 Vault 会是什么模样

如果 Librarying 的运营循环顺畅运作，十年后的 Vault 会是什么样？

最初的 1,500 个词条，会随十年中新作品回流的词汇累积到 3,000 至 5,000 个。枢纽结构也会改变：最初不是枢纽的词条，可能因后来作品频繁引用而晋升为枢纽。

LLM 区块的部分叙述写于十年前，部分则刚刚完成；凭借幂等规则，十年前的叙述在反复重建中也没有被擦去。通读这些叙述，就能清楚看见这个 IP 多年来以何种声音讲述自己的世界。

这就是 Librarying 形成的 IP 记忆存储库：一个 IP 的十年，被收纳在一个文件夹之中。

让 Vault 保持活着

比起首次建立 Vault，维持它的活性也许更困难。开始时有足够的动机和能量，但六个月后仍要处理回流队列、运行增量更新，这项工作必须成为 IP 创作自然的一部分；它不是另行切出的附加工作，而是 IP 运营的一个组成部分。

第12章将讨论 Vault 的出口：Librarying 创建的 Vault 如何被后续工作使用，以及 Vault 在 IP 生态系统中承担什么角色。

第11章 Vault 的一生：回流与运营循环