第11章　Vault 的一生：逆流與營運循環

完成驗證的 Vault 進入下游工作後，將以它為基礎撰寫短篇並製作角色表。那麼，建立一次的 Vault 是否已經完成了任務？

並非如此。答案來自 Librarying 營運最重要的原則之一。

「完成」這個概念本身的錯誤

「Vault 完成」暗示它會成為不再變動的穩定狀態。然而 IP 會改變：新作品出現、設定修訂、新人物登場，既有角色也揭露新的面貌。只要 IP 持續存在，它的詞彙也會一起變化。

若把 Vault 視為一次完成即可結束的產物，兩年後即使新增十部作品，最初精心建立的 1,500 個檔案仍停在原狀。寫作者在 Vault 找不到新詞彙，就不再使用它；不被使用的 Vault 也失去更新理由，最後被放置到無法運作。

Wikipedia 從未「完成」：每天都有新條目與大量修訂，昨天的事件今天就能成為條目。這就是活的文件。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 的一生：逆流與營運循環