第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 詞彙來衡量；無法用 Vault 詞彙說明的角色，在這個 IP 世界裡也相應顯得陌生。

假設要在處理氏族、織造與階級的 IP 中建立名為「無紋者」的新角色：他無法讀取或編織紋樣，卻只憑赤裸的記憶掌握氏族的一切。

從 Vault 取出構成此角色背景的詞條，織造軸會得到 [[努比]]、[[紋樣]]、[[重新編織]]，記憶軸會得到 [[赤裸記憶]]、[[焚書]]、[[無紋者]]，人物關係則會一併帶出讀取並編織紋樣的 [[織女（人物）]]。

這些詞條進入角色表的「世界觀關鍵字」欄位。即使作者不親自翻找 Vault，織造軸與記憶軸交集的詞條也會自動呈現為候選。沒有 Vault，要建立同一角色，作者就得重讀 IP 原始資料，手動收集世界觀詞彙。

人物關係圖參照也是如此。查看既有人物詞條的 related 欄位與結構化區段「相關人物」，人物間的關係網便一目了然。將新角色加入關係網的哪個位置、設定為師徒、競爭者、家人或同僚，都能沿著網絡決定。沒有 Vault，便只能在腦中逐一描繪既有人物關係再工作。

在多語出版工作中運用 Vault 的方法

將 IP 以其他語言出版需要翻譯，這時 Vault 裡和翻譯相關的欄位就是核心資料。

每個詞條的英文名、羅馬字與翻譯註解欄，是譯者最先打開的資料。第5章所說的「寫給未來譯者的信」，正是翻譯註解。

設想譯者在原稿中遇到「無紋者」，必須決定如何譯成英文。打開 Vault 的「無紋者」詞條後，可看到：

英文名：Munmunja (the unwoven) 翻譯註解：「無紋者（無紋者）」是指在所有知識都被織入布料的世界中，無法讀取或編織紋樣之人的複合概念，不能直譯。若簡單譯成 “illiterate”，會失去此世界中「不能讀取織在布上的文字」的特有含意。第一次定義為 “Munmunja (the unwoven)” 後，之後不併列原語，只使用 “Munmunja”。僅在原稿初次出現時加入括號解說。

遵循這個決定，這個 IP 的所有譯者都能以同一方式處理「無紋者」。沒有 Vault，各譯者會各自決定：有人用 “Munmunja”，有人用 “the unwoven”，有人用 “illiterate”，於是同一 IP 的英文版第一卷與第二卷會對同一詞彙產生不同譯法。

異稱／別名欄在翻譯中也同樣重要。當原文同時出現「重新編織」、「努比偽造」和「再次編織」，Vault 會告訴譯者三者其實指向同一事物；譯者便可決定要統一成一種譯法，還是保留不同譯法。沒有別名資訊，譯者初次遇到「再次編織」時，不會知道它是已經出現過的概念。

翻譯完成後，過程中做出的翻譯決定會回流到 Vault。「這個詞固定使用某一譯語」的決定記入翻譯註解，供下一次翻譯直接再用。

在翻譯產業裡，這類資料近似 termbase，也就是術語資料庫。ITS 等國際化、在地化體系會分別標示哪些字串該翻、哪些術語帶有特定含義、該向譯者顯示何種註解，理由也相同：譯者收到的不只是單字，還必須知道該單字在何種條件下該如何處理。

Librarying 的 Vault 能給翻譯團隊的資訊正是這些：某些專名不應翻譯而要保留原語；某些術語只在初次出現時附括號說明；某些別名雖指向同一詞條，卻應依場景刻意使用不同譯法。這些資訊進入翻譯註解後，譯者不必每次重新決定，而是承接 IP 已作出的決定。

因此，多語出版中的 Vault 不只是參考資料，更是保存已核准術語決定的營運資料。原文標記、官方譯名、禁用寫法、是否併列原語、初次出現解說與文化注意事項都在一個詞條裡管理時，翻譯的一致性便不依賴個人記憶，而依賴資料結構。

在百科全書與 lorebook 製作中運用 Vault 的方法

製作 IP 的官方百科全書或 lorebook 時，Vault 本身就是原始資料。

Vault 的 1,500 個詞條會成為百科全書的 1,500 個條目，第四階段撰寫的 LLM 敘述則成為條目本文。若一開始就把 hub 詞條敘述寫到百科全書條目水準，幾乎不用修改即可移入條目。

從 Vault 移至百科全書所需額外工作只有編輯和編排：考量讀者閱讀順序的安排、加入圖片與圖表、依出版格式編輯。與沒有 Vault 時從頭製作百科全書所需的時間相比，這些工作短得多，因為出版工作開始時，「要寫哪個條目、怎麼寫」早已決定。

實際經驗過 Librarying 後百科全書與 lorebook 製作變化的創作者會說：「以前做一冊百科全書要花幾個月；有了 Vault，就只需專注編輯和設計。」

Vault 在 B2B 環境中的角色

看完四個出口，現在轉向營運環境。B2B 不是 Vault 產出某種成果的出口，而是多個團隊共用同一 Vault、分配更新權限的環境；Vault 在此作為團隊之間的共用資料。

假設 IP 開發、翻譯、遊戲開發、出版團隊共同處理同一 IP。IP 開發團隊更新設定時，其餘團隊必須立刻得知；沒有 Vault，更新會經過電子郵件、文件與會議傳遞，有些團隊收到，有些錯過。有了 Vault，更新的瞬間，所有團隊就取得相同的最新資訊。

這個環境的關鍵是更新權限：哪個團隊更新 Vault、其他團隊何時接收更新，流程必須預先決定。一般結構中，IP 開發團隊兼任 Librarying 團隊，負責把官方設定的變更反映到 Vault；其他團隊可讀取但不可直接修改，需要修改時向 Librarying 團隊提出要求。

沒有這個結構，多個團隊各自修改 Vault，Vault 會依團隊分裂，最後 SSOT 的數量與團隊數量一樣多。

此外還要有獨立維護層。建立索引、確認哪些詞條已被充分使用的覆蓋率、定期檢視哪些 hub 對其他詞條影響較大，與短篇寫作或翻譯等出口工作不同；這些是為了長期使用 Vault 的營運工作。若已有自動化，應定期產生索引、覆蓋率與影響力快照；若尚未自動化，負責人至少也要手動記錄狀態。

長期而言，這個 Vault 可能移入更結構化的知識庫。Wikibase 等工具擅長讓多人協作修訂結構化資訊，並使人與機器共同再利用。若 Obsidian Vault 是適合人類讀寫的工作坊，Wikibase 型知識庫則是更接近查詢、再利用與公開串接的營運場。

一開始不必走到那一步。創作團隊眼前需要的不是完備資料庫，而是今天能使用的 Vault。但只要持續維持 frontmatter、manifest 與詞條關係的一致性，日後就能將部分資料移至知識圖譜或資料庫。Librarying 在保留這種可能性的同時，先從人真正能營運的形式開始。

有 Vault 與沒有 Vault 時

將有 Vault 的 IP 營運和沒有 Vault 的營運並列比較。沒有 Vault 時，確認一個設定也得翻找原始文件，連位置都記不清；同一概念在不同原稿用不同寫法，新成員理解世界觀需一至三個月。譯者各自翻譯相同詞彙，製作百科全書則要從頭重讀原始文件並重寫條目。五年後若非原作者的人接手 IP，世界觀大量內容可能只留在寫作者腦中，連移交都會受阻。

有 Vault 時則不同。確認設定只要開 Obsidian 搜尋；每個詞條有唯一官方寫法，所有別名都已登錄。新成員讀一百個 hub 就能掌握 IP 核心，譯者依翻譯註解承接統一的翻譯決定，百科全書製作可集中於編輯與設計。五年後新接手 IP 的團隊也可打開 Vault，從頭理解世界觀。

Vault 是起點

Vault 不是終點，而是起點。Librarying 建立的 Vault 啟動短篇寫作、角色表製作與翻譯工作；這些工作產生的新詞彙與決定又會透過回流回到 Vault。單一真實來源歸根結柢就是所有團隊、所有工作、所有工具都望向同一個 Vault。

第13章是實戰回顧：直接打造 1,500 個詞條時學到什麼、哪些地方和預期不同，以及若重來一次會如何改變，將坦率地記錄下來。

第12章 Vault 的出口：下一步工作將帶走什麼