第3章　從輸入到 Vault——四階段流程

為什麼不能一次處理所有資料？攤開 IP 文件後，不能直接製作最終成果嗎？在 Obsidian 裡，這個最終成果稱為 Vault。這是本章第一次出現這個名稱，它的確切樣貌會在稍後的「輸出的景觀」介紹。Librarying 之所以有四個階段，正是對這個問題的回答。

Librarying 從輸入開始，經過第一次擷取、第二次整合、第三次骨架建置與第四次敘事撰寫，最後形成 Vault。我們將依序查看各階段接收什麼、產出什麼，其中介入哪些決策，以及人與 AI 工作夥伴在哪裡、如何分工。

輸入的景觀

想像開始工作的桌面：第一版到第三版的規則書堆在一起；有一個收集五年短篇的資料夾；有某人建好後便停止更新的外部 Wiki；還有一個只在協作聊天中出現過一次便消失的命名候選。Librarying 接收的輸入，就是這些分散資料的全部。一個 IP 的所有文件都原樣進入輸入端。

本章不會一路追隨某個特定 IP，而是在每個階段短引最合適的案例。案例中的人物、裝置、事件都以匿名的「某個 IP」處理，避免與任何讀者的 IP 直接重合。若閱讀時那幅桌面景象與自己的桌面重疊，這份重疊就是將此程序移入自己 IP 的通道。

若有規則書，第一、二、三版全都是輸入，連廢棄的第零版也包括在內。因為源自廢棄資料的名詞或視角，可能流入仍在使用的短篇；要抓住這些痕跡，就必須讓廢棄版本至少通過一次。短篇、小說與劇本等 IP 運作過的所有作品都是輸入，外語作品也連原文一同放入。企劃書與設計書同樣是輸入：企劃書整理作品的大圖與意圖，設計書則收錄角色創傷、事件因果鏈、裝置運作原理等未直接呈現於作品的決定。

外部 Wiki 也要通過。有人五年前開始建立後便放手的頁面，無論持續更新或已遭放置，都包含在輸入中。放置頁面保留了五年前的名詞與視點；要確認它們是否與現行作品錯位，就必須至少檢視一次。

若作品是影像或遊戲，按場景整理的對白資料、過場動畫腳本、遊戲內文字皆為輸入。桌旁夾著的紙本筆記、暫存資料夾的文字、協作聊天紀錄裡僅出現一次的命名候選也都先通過，即使不是正式資料也一樣，因為第一次擷取的合格線相當寬鬆。

輸入量依 IP 而異。若是運作五年的中型 IP，本文文字總量約在一百萬到五百萬韓文字元之間。以一本韓語單行本平均三十萬字元計算，相當於三到十七本書的文字；一個人光是完整通讀一次，就需要一個月。Librarying 從這些輸入抽取關鍵字，卻不讓人去通讀；若由人以通讀方式擷取，工作又會膨脹成六個月。

整理輸入時最先做的是建立位置目錄。在一張表中整理哪個目錄有哪些文件、文件屬於 IP 的哪個時期、屬於哪個領域（規則、短篇、企劃、外部）。此目錄是第一次擷取的起點，由人做決定。可以把目錄樹交給 AI 工作夥伴並取回目錄，但哪份文件屬於哪個領域仍由人判斷。此判斷一旦模糊，下一階段的擷取也會模糊。

輸出的景觀

Librarying 的輸出是 Obsidian Vault。Vault 在 Obsidian 中指一組 .md 檔案：同一工作資料夾裡存放 .md 檔，檔案之間以 wikilink 連結。初次使用 Obsidian 的讀者，可以把 Vault 想成一座 IP 的圖書館——館內放著 1,500 本書，書與書之間透過引文互相連接。

第一次開啟一個 IP 的 Vault 時，左側欄會按字母或韓文字母順序列出 1,000 到 2,000 個 .md 檔案；上方有搜尋欄，旁邊有開啟圖譜檢視的按鈕。點選一份檔案後，本文由五部分構成：開頭的 frontmatter（YAML 中繼資料）、一兩行定義、兩三段詳細說明、多語言翻譯候選，以及 AI 工作夥伴寫成的二百至一千字元敘述。

frontmatter 是以冒號配對鍵與值的一組行。代表關鍵字、分類、世界觀軸、英文名、羅馬字、版本狀態、出處、相關關鍵字等資訊分行放入。其中的世界觀軸是本書第二個分類基準的名稱，第六章會用一整章討論。人幾乎不會直接讀 frontmatter，而是讓搜尋與自動化讀取它來處理工作。定義是一兩行；詳細說明短則一段、長則兩三段；翻譯候選是英文與羅馬字等多語言標記；敘述區塊則依條目的重要性放入二百至一千字元的敘述。這就是一個 .md 檔案的樣貌，1,500 個檔案全以相同格式整理。

按下 Obsidian 的圖譜檢視按鈕，畫面會展開 1,500 個點與其間的連線。點對應一個表題語，線對應一個 wikilink。連線大量匯集的點是 hub，連線較少的是 leaf。這幅如星座般展開的圖，就是 Librarying 的最終成果。

成果一旦完成，Vault 就成為 IP 的真實來源。外語作品的深度閱讀工作會引用 Vault 裡的人物與裝置表題語；從零塑造角色的工作會參照 Vault 的世界觀關鍵字；出版 LOREBOOK 的製作則把 1,500 個表題語轉為百科條目。第十二章會詳細說明此出口的景觀。

流程不是線性的。出口工作中新生成的詞彙、新確定的寫法、新增加的設定，都會回流到 Vault；這稱為逆流。每有逆流，第一次擷取與第二次整合的小循環便重複，第三次骨架建置也增量更新。因此 Vault 並非做完即止，而是在 IP 存活期間持續成長。第十一章會詳談逆流與營運循環。

為什麼必須是這個順序

在介紹四個階段之前，先回答一個問題：為什麼一定要四個階段？不能縮成兩個或三個嗎？

理解每個階段為何置於此一順序，就能看見把 Librarying 套用到自己 IP 時，可以如何調整各階段。

各階段解決的是不同層次的問題。第一次問「有什麼」，從輸入文件拉出關鍵字本身；第二次走向「同類事物是否被歸在一起」，把同義寫法合併為一個表題語並選定代表寫法；到第三次，問題變為「是否是工具可處理的格式」，把 CSV 的列轉成 Obsidian .md 檔；最後第四次問「這是不是活的資訊」，填入解開表題語在 IP 內所處位置的敘述。

層次不同，所以順序不能調換。從第二次整合開始，沒有可整合的材料，工作無法出發；跳過第二次，把第一次的五千列直接交給第三次，同一對象會散落為三個 .md 檔，彼此不會相互引用；跳過第三次，兩千個表題語只會排在 CSV 裡，沒有 .md 檔提供第四次敘述的空間；跳過第四次，雖有 frontmatter、定義與詳細說明，卻沒有解釋其在 IP 內位置的敘述，出口工作得到的便是有資訊卻沒有脈絡的辭典。

資料工程有一副稱為 ETL 的骨架：Extract、Transform、Load，意即擷取、轉換、載入資料的三個階段，是資料工程數十年來打磨的資產。Librarying 的第一次擷取對應 Extract，第二次整合對應 Transform，第三次骨架建置則精確對應 Load。

這裡常讓人想說：「所以 Librarying 前三個階段不過是 ETL 的應用。」我反而認為相反。資料工程把這副骨架用於交易紀錄、日誌、感測數值等結構化與半結構化資料；然而 IP 敘事資料是從未有人放入此骨架的材料。規則書、短篇、廢棄版本、外部 Wiki 等資料，混雜著人的手感、矛盾與時期變化；第一次、第二次、第三次正是把這些材料首次鍛入擷取—轉換—載入之框架的工作。它不是相似之物，而是借用已驗證的骨架，為新材料專門化的結果。

而第四次不在 ETL 裡。資料工程止於載入，Librarying 卻在整理好的資料上再疊一層活的敘述。不止於整理、而在其上書寫的第四次，正是 Librarying 的獨特之處；任何資料管線都沒有與之對應的階段。

四個階段產生什麼

先簡要查看各階段接收何種輸入、製作何種產出。第四章至第九章會逐一展開。

第一次擷取從輸入文件拉出所有關鍵字，整理為五欄 CSV。CSV 是以逗號分隔欄位的表格式文字檔，試算表與自動化工具都能處理，適合作為中間產物。此處使用 IDX、分類、關鍵字、說明、出處五欄，一個 IP 的結果可達五千至一萬五千列。合格線寬鬆，允許重複、錯字與未整理的狀態。若一開始就要求精確，每拉出一個關鍵字都得同時判斷「是否與既有表題語重複」「屬於哪個分類」「應歸在哪種代表寫法」；一個決定等待下一個決定的瓶頸，會讓第一次擷取慢上數十倍。它像數位攝影的 RAW 工作：先全部拍下，再在下一階段篩選與校正。AI 工作夥伴承擔核心工作，多位夥伴並行自動擷取九分類表；人則負責修訂九分類指南、決定新分類、宏觀檢收，以及確認代名詞、視點、廢棄名詞的痕跡。第四章會詳細討論。

第二次整合把第一次的五千至一萬五千列，歸併為一千至兩千個表題語並組成十三欄 CSV。錯誤決定會讓整部 Wiki 偏移，因此合格線嚴格要求 95%。最常見的是同義詞組：把第一次的「黑色空洞」「黑色煙霧」「黑暗霧氣」歸為一個表題語並確定代表寫法。同音異義詞、隨時期改變意思的關鍵字、同名的不同人物等判斷，只有讀完五年作品的人腦才能精確做出。AI 工作夥伴快速製作同義詞候選、定義初稿、相關連結、世界觀軸候選；人做最後決定。十三欄 CSV 約在兩至四小時內整理完成。第五章與第六章詳述此階段。

第三次骨架建置把第二次 CSV 轉換為 1,500 個 Obsidian .md 檔。它幾乎完全自動化，是確定性的轉換，人的手幾乎不介入。

一列的一個表題語成為一個 .md 檔；列的欄位放入 frontmatter 欄位；定義與詳細欄變成本文段落；相關關鍵字自動注入為 wikilink；本文最後保留一個供敘述填入的空位。此時開啟 Obsidian 圖譜檢視，1,500 個節點與 wikilink 連成的網絡便鋪滿一個畫面。不過，寫作空間仍是空的。

建置本身約五分鐘，人為檢收約三十分鐘。檢收的對象是稱為 manifest 的建置結果摘要檔，其中包含檔案數、分類別統計與進度狀態（第七章詳談）。若轉換規則有缺陷，1,500 個檔案都會帶著同一缺陷，因此建置後的人為檢收是強制的。第七章與第八章詳述此點。

第四次敘事撰寫是 Librarying 的創作階段。若前三次在建立骨架，第四次便是在骨架上寫下讓 IP 世界活起來的敘述。每個表題語寫二百至一千字元，hub 為五百至一千字元，leaf 為二百至三百字元。AI 工作夥伴可在約五至十小時內寫出 1,500 則敘述（人手撰寫則超過一千小時），人再檢收格式、連結、篇幅、語調與專案脈絡，拉到合格線。leaf 可以短，卻不表示可以空白；營運用 Vault 的目標是整體 LLM 完成率 95% 以上。第九章詳談。

第一、二、三次的本質；第四次的本質

把四個階段展成一條流程後，有一點需要指出：第一次、第二次、第三次與第四次的本質不同。

前三次的本質是機械性的整理：從輸入拉出關鍵字，聚合相同意義，轉換成 Obsidian 格式。有清楚的規則，依規則處理結果便可確定。人也會做決定，但範圍狹窄而明確。

第四次的本質是敘事式寫作：把一個表題語解開為一段流動的敘述。它無法化約為清楚規則；一個表題語的合格線也不等於下一個。語調、脈絡與 IP 特有的細微處都會介入。

這兩種本質的差異決定協作的質地。前三次把輸入交給 AI 工作夥伴、收回結果後幾乎原樣送往下一階段；第四次則收下第一次初稿後往返兩三輪。

時間預算

把第一次、第二次、第三次、第四次的時間相加，一個 IP 的 Librarying 約在九至十六小時內完成。這個數字正是本文要向讀者展示的縮時本質。

分配如下：設定檔（世界觀軸、分類指南、參照目錄）三十分至六十分；第一次擷取三十分至兩小時（AI 並行）；第二次整合兩至四小時（人的決定加 AI 輔助）；第三次骨架建置五至十分（確定性自動化）；故事摘要準備三十分至六十分。此摘要不是為避免每次閱讀全稿的簡單概述，而是從製作人的觀點詮釋原稿、劇本、規則書，壓縮為第四次散文脈絡的檔案。第四次敘事撰寫需五至十小時（AI 工作夥伴為核心），驗證需一至三小時（人的檢收加自動檢查）。合計九至十六小時，這是以第一次循環為基準的數字。

第一次循環是初次為一個 IP 進行 Librarying 的時間。其後新短篇進入、做增量更新時，時間會短得多。一篇短篇通常有三十至五十個新表題語，前三次的小循環約三十分鐘，加上第四次敘述約一小時，一篇短篇的更新在總計 1.5 至 2 小時即可收尾。第十一章會詳談此營運循環。

兩雙手的分工圖

把這張圖整理成一條流程，便能一眼看見第四至第九章各自細看哪個位置。

設定檔是人的工作：決定世界觀軸、修訂分類指南、建立參照檔案目錄。第一次擷取由 AI 工作夥伴自動擷取九分類表，人負責宏觀檢收與新分類決定，合格線為 60%。第二次整合由人負責同義詞組、表題語命名、世界觀軸確定，AI 產出同義詞候選、定義初稿、世界觀軸候選，合格線為 95%。第三次骨架建置在執行腳本後，由人確認 manifest 與自動驗證結果，合格線為 100%。第四次敘事撰寫由 AI 為每個表題語製作第一次初稿，人負責語調指南、五階段檢收與合格判斷；hub 寫得長而深，leaf 寫得短而準。驗證由自動檢查產出違規報告，人進行人工抽樣與整合建置判斷，合格線為 100%。

這張圖是十四章的指南。第四至第九章逐章細看上述各行；第十章是驗證，第十一章是營運循環，第十二章是出口，第十三章回顧五年營運，第十四章收束全文。

簡要說明圖中的 hub 與 leaf。1,500 個表題語的重要性並不相同。置於 IP 核心的表題語會被其他表題語頻繁引用；這種常被引用的表題語稱為 hub，引用較少的稱為 leaf。1,500 個之中，hub 通常有一百至一百五十個。兩者適用不同的敘述篇幅與檢收合格線：hub 長而深，leaf 短而簡潔。第八章將詳談 hub 的自動判定與人的決定。

手持這張圖

第一次收集材料，第二次整理材料，第三次把整理好的材料轉為工具可處理的格式，第四次在這個格式上填入 IP 的敘述。倒轉順序，工作就會崩解；遵循順序，便能得到九至十六小時的結果。

從下一章第四章起，我們進入第一個階段——第一次擷取。整整一章將細看九分類分開什麼、不歸併什麼，五欄 CSV 的一列如何構成，以及 AI 工作夥伴對正規化輸入文件進行全量擷取時會發生什麼。

第3章 從輸入到 Vault——四階段流程