第12章　Vault 的出口：下一步工作会带走什么

完成验证的 Vault 现在进入下游工作。1,500 个词条已经汇集，连接它们的 wikilink 已经铺设，九种分类与世界观轴这两套坐标体系已经建立，每个词条也都填入了叙述。

从这里离开的出口有四个：短篇写作、角色构建、多语出版、百科全书与 lorebook 制作。四项工作各自把 Vault 作为输入，再制作新的成果。后面会一起讨论的 B2B 不是出口；它是多个团队共享同一 Vault、分配更新权限的运营环境，应当与四个出口区分开来。

没有 Vault 会发生什么

长期运营 IP 的团队往往有类似经验。

“这个人物在一处叫姜敏智，在另一处又叫姜敏书，到底哪一个才对？”

“这个装置的限制条件是什么？好像在规则书第三版的某个地方……”

“我们去年改过这个设定，通知翻译团队了吗？翻译稿里还在用旧版本的名字。”

“新编辑刚加入，理解世界观大概要一个月。”

这些问题都有同一个原因：信息分散在许多地方，没有一个可以确认何者为当前官方信息的单一来源。

信息分散的成本比想象中大。如果五位成员每人每周花一小时确认“这个设定对不对”，一年就会积累 260 小时的确认成本；即使经过这些确认，原稿仍出现错误信息时，返工修改的成本还会随之而来。

Vault 把全部信息的正式版本集中在一处，因此解决了这个问题。需要确认时，只要打开 Vault。

单一真实来源：借来之后变得更难的概念

单一真实来源（Single Source of Truth，SSOT）这一概念来自软件工程。不过我不会说 IP 原样照搬了它；IP 借用了这个概念，却把它放到了更困难的问题中。

软件的 SSOT 相对容易处理。代码只有一套，那一套就是事实；同一函数不能同时拥有两种真实，若争论哪个值正确，实际运行的代码会给出答案。因为真实只有一个，SSOT 自然成立。

IP 的 SSOT 并非如此。像《The Witcher》这样，小说、游戏和电视剧分别分支成不同脉络的 IP，正史并不只有一个。必须把多条分歧正史同时管理在一处，还不能遗漏哪一条脉络对哪项工作才是真实依据。代码只有一套，无须面对这种事；IP 的 Vault 却要并列容纳多种连续性，同时担任 SSOT。换言之，IP 的 SSOT 承担了软件不必解决的问题。

这项原则比 IP 更古老。律师事务所处理案件时，会把所有成员共享的一份案件文件作为官方记录；如果有人放下这份文件，只根据私人笔记工作，就会产生错误，因此大家都查看同一文件本身就是原则。

学术研究团队把数据保存在一个共享仓库也是同样道理。每个成员若复制同一数据并分别保存，副本之间便会出现不一致，“版本2”“最终版”“最终最终版”都会成为不同的文件。这时约定只承认一个共享仓库为真正版本，就是 SSOT。

Wikipedia 的目标本来也是公共知识的 SSOT。正如想确认“姜敏智”是否为官方名称时会看 Wikipedia 怎样写，Librarying 的运营方式是，在确认 IP 设定时先看 Vault 怎样写。

整理良好的 IP 字典成为多种媒体共同输入，也能在实际内容中看见。《我独自升级》从 2016 年的网络小说开始，延续为网络漫画，2024 年又扩展到动画、Netmarble 的手机游戏和衍生网络漫画，始终共享同一个世界。我把它理解为：一个整理良好的世界观，成为网络小说、网络漫画、动画和游戏等不同工作的共同输入值。

但媒体增多不表示所有作品共享同一脉络。前面提到的《The Witcher》就是这样：它从波兰小说出发，延伸至 CD Projekt 的游戏和 Netflix 的剧集，游戏与剧集各自从原作分出了支线。在这种 IP 中，SSOT 不是强制只有一个真相的装置；若存在分支脉络，Vault 必须明示它们之间的关系与各自的正史范围，才会真正发挥 SSOT 的作用。

Vault 成为 SSOT 的具体机制

Vault 要成为单一真实来源，需要两个条件：全部官方词汇都在 Vault 中，且变更必须从 Vault 发生。

首先，只要 IP 使用的词汇有一个不在 Vault 中，Vault 对该词就不能担任 SSOT。这正是第一阶段抽取要足够广泛、并通过回流不断补强的原因；Vault 的覆盖率越高，SSOT 的作用就越强。

所谓变更要在 Vault 发生，是指团队成员想改原稿中的人物名字时，应先修改 Vault 的代表关键词，再修改原稿。先修正 Vault，变更就会通过 wikilink 传播到整个 Vault。“姜敏智”变为“姜敏书”的瞬间，所有以 [[姜敏智]] 连接的文件链接都会更新为 [[姜敏书]]。反之，先改原稿、之后再改 Vault 或干脆不改，Vault 与原稿便会不一致，这就是 SSOT 崩塌的开始。

不过，对已经出版 lorebook 或官方百科全书的 IP，还会多出一层优先关系。出版物是向读者公开的官方文本，因此其正文优先于 Vault 的工作叙述。此时 Vault 并不是压过出版物的上位真实来源，而是与出版物同步、为后续工作做准备的工作资料中心。如果 Vault 与已出版 lorebook 正文冲突，应按出版正文更新 Vault。Librarying 的 SSOT 不意味着“任何时候 Vault 永远胜过一切”，而是明确当前工作阶段哪份资料为基准，将这一基准反映在 Vault 中，让所有人看到同一份资料。

在短篇写作工具中使用 Vault 的方法

用于短篇、小说、剧本写作的工作工具，以三种方式使用 Vault：参照世界观词汇、检查一致性、分析覆盖率。

世界观词汇参照，是在写作中需要再次确认某项设定时打开 Vault。例如出现“这个装置的限制条件是什么？”的疑问，答案就在 Vault。第9章要求认真建立结构化区段（限制条件与确定事实），理由就在这里。写作工具可以程序化读取这些区段，写作者也可以直接阅读。

假设要在织物世界观“努比之地”写一个出现“重新编织”的场景。重新编织努比以改变历史与法律时，需要什么、谁有权力、谁能揭穿重织的谎言，都已整理在 Vault 中。写作者能在写场景的途中立刻打开 Vault 确认信息；没有 Vault，就只能逐一翻找旧稿或依靠记忆。

一致性检查，是在完成稿中查找与 Vault 词汇不同的写法。若代表关键词与别名都已登记，检查工具就能找到原稿里的这些标记。例如“姜敏智”与“姜敏书”同时出现时，工具会指出哪一个是 Vault 的官方写法。发现 Vault 中没有的新写法会进入回流队列，因此这也是自动追踪写作者新创词汇的机制。

覆盖率分析则查看 Vault 的哪些词条在已写短篇中被使用到什么程度。若某个 hub 词条尚未出现在原稿，就能发现围绕该词条规划新短篇的空间；从这个意义上说，Vault 也是“尚未写出的故事地图”。

在角色构建工作中使用 Vault 的方法

角色表制作工具从 Vault 获取两类信息：世界观关键词参照和人物关系图参照。建立新角色时，会提取该角色所属世界观轴的词条。例如织造记录世界观轴的角色，其轴上的装置、概念与价值词条构成角色背景，并自动填入角色表的“世界观关键词”栏。新角色能否自然融入世界，可由其是否能用 Vault 的词汇充分说明来衡量；无法用 Vault 词汇说明的角色，在这个 IP 世界里也相应显得陌生。

假设在处理氏族、织造和阶级的 IP 中建立名为“无纹者”的角色：他不能读写或编织纹样，却只凭赤裸记忆掌握氏族的一切。从 Vault 取出其背景词条，织造轴会给出 [[努比]]、[[纹样]]、[[重新编织]]，记忆轴会给出 [[赤裸记忆]]、[[焚书]]、[[无纹者]]，人物关系则带出读写并编织纹样的 [[织女（人物）]]。

这些词条进入角色表的“世界观关键词”栏。即使创建者不手动查找 Vault，织造轴与记忆轴的交集词条也会自动呈现为候选。没有 Vault，创建者就要重新阅读 IP 原始资料，亲手收集世界观词汇。

人物关系图参照也一样。既有人物词条的 related 字段和结构化区段“相关人物”会清楚展示人物网络；新角色加入网络的什么位置、设为师徒、对手、家人还是同事，都可沿着关系网络决定。没有 Vault，创建者只能在脑中逐一描绘已有关系。

在多语出版工作中使用 Vault 的方法

IP 用其他语言出版时需要翻译，Vault 中与翻译相关的列便成为核心资料。每个词条的英文名、罗马字和翻译注释列，是译者最先打开的材料；第5章所说“写给未来译者的信”正是这种翻译注释。

例如译者遇到“无纹者”而要决定英文译法。Vault 的词条会写明：英文名为 “Munmunja (the unwoven)”；翻译注释说明它是一个世界中所有知识都织入布料、因而不能读或织纹样之人的复合概念，不能直译为 “illiterate”，否则会失去无法读懂织在布上的文字这一世界特有含义。第一次定义为 “Munmunja (the unwoven)” 后，之后只写 “Munmunja”，只在原稿首次出现时加括号说明。

遵循这项决定，所有译者都会同样翻译“无纹者”。没有 Vault，译者会各自选择 “Munmunja”、“the unwoven” 或 “illiterate”，以致同一 IP 英文版第一卷与第二卷对同一术语使用不同译法。

异称和别名列也同样重要。原文中“重新编织”“努比伪造”“再次编织”同时出现时，Vault 会指出三者其实指向同一事物，译者便能决定统一一种译法还是保留不同译法。没有别名资料，译者首次看到“再次编织”时，不会知道这是已经出现过的概念。

翻译完成后，过程中形成的翻译决定会回流到 Vault。“此术语固定采用某译法”的决定记入翻译注释，供下一次翻译直接复用。这种资料近似术语数据库（termbase）。ITS 等国际化和本地化体系会分别标记哪些字符串需要翻译、哪些术语有特定意义、该向译者显示哪些注释，原因也在于译者需要的不只是词语，更需要知道它在何种条件下该怎样处理。

Vault 因而能告诉翻译团队：哪些专名不应翻译而要保留原语，哪些术语只在首次出现时加括号解释，哪些别名虽指向同一词条却应按场景有意译为不同表达。原文写法、官方译名、禁用写法、是否保留原语、首次说明和文化注意事项都在词条内管理时，翻译一致性就依赖资料结构而非个人记忆。Vault 不只是参考资料，更是保存已批准术语决定的运营资料。

在百科全书与 lorebook 制作中使用 Vault 的方法

制作 IP 的官方百科全书或 lorebook 时，Vault 本身就是原始资料。Vault 的 1,500 个词条成为百科全书的 1,500 个条目，第四阶段的 LLM 叙述成为条目正文。若 hub 词条从一开始就按百科全书条目水准写作，几乎无需修改即可使用。

从 Vault 移到百科全书所需的额外工作只是编辑与编排：考虑读者阅读顺序的安排，添加图像和图表，以及出版格式编辑。与没有 Vault 时从头制作百科全书相比，这些工作所需时间少得多，因为“写什么条目、怎样写”早已决定。经历过这种变化的创作者会说：“以前做一本百科全书要几个月；有了 Vault，就能只专注于编辑和设计。”

Vault 在 B2B 环境中的角色

B2B 不是 Vault 产出成果的出口，而是多个团队共用同一 Vault、分配更新权限的环境。IP 开发、翻译、游戏开发和出版团队共同处理一个 IP 时，开发团队更新设定，其他团队必须立即知道。没有 Vault，信息经过邮件、文件和会议传递，有些团队收到，有些团队错过；有了 Vault，更新瞬间所有团队就得到相同的最新信息。

关键是预先确定更新权限：由哪个团队更新 Vault，其他团队何时接收更新。通常 IP 开发团队兼任 Librarying 团队，负责把官方设定变更反映进 Vault；其他团队可以读但不直接修改，若需修改则向 Librarying 团队提出请求。没有这一结构，多团队各自改 Vault，Vault 会按团队分裂，最终 SSOT 的数量和团队数量一样多。

还需要一层维护工作：构建索引，检查哪些词条已得到充分使用的覆盖率，定期观察哪些 hub 对其他词条影响最大。这些不是短篇写作或翻译等出口工作，而是为长期使用 Vault 的运营工作。有自动化时应定期生成索引、覆盖率和影响力快照；没有自动化时，负责人也应手动记录状态。

长期来看，Vault 也可能迁入更结构化的知识库。Wikibase 等工具擅长让多人协作修改结构化信息，并让人和机器共同复用。Obsidian Vault 若是适合人读写的工作坊，Wikibase 式知识库则更接近查询、复用与公开连接的运营场。没有必要一开始就走到那一步；创作团队现在需要的不是完成的数据库，而是今天能用的 Vault。但若持续保持 frontmatter、manifest 与词条关系的一致性，日后便会打开把部分资料迁入知识图谱或数据库的道路。

有 Vault 与没有 Vault 时

没有 Vault 时，确认一个设定也要翻找原始文档，连文件在哪儿都记不清；同一概念在不同原稿有不同写法，新成员掌握世界观要一到三个月。译者各自翻译同一术语，制作百科全书必须从头重读原始资料并新写条目。五年后如果不是原作者的人接手 IP，世界观的大量内容可能只存在于写作者脑中，交接本身都会被阻塞。

有 Vault 时，确认设定只要打开 Obsidian 搜索；每个词条都有唯一官方写法，所有别名已登记。新成员阅读一百个 hub 即可掌握 IP 核心，译者通过翻译注释延续统一决定，百科全书制作可集中于编辑和设计。五年后新接手 IP 的团队也能打开 Vault，从头理解世界观。

Vault 是起点

Vault 不是终点，而是起点。Librarying 建立的 Vault 让短篇写作开始、角色表得以制作、翻译得以推进；这些工作产生的新词汇和决定又会经由回流返回 Vault。单一真实来源最终意味着所有团队、所有工作和所有工具都看向同一个 Vault。

第13章将进行实战回顾：亲手打造 1,500 个词条时学到什么，哪些地方与预期不同，以及如果重来一次会怎么做，将在其中坦率记录。

第12章 Vault 的出口：下一步工作会带走什么