第1章．從詞彙表到雲端：我們處理的資料如何改變

不可能用一個詞解釋《星際大戰》。

當我們說「以宇宙為背景的善惡對決」時，真正重要的東西便漏掉了：首先是原力。沒有原力的《星際大戰》很難稱為《星際大戰》。但放進原力，絕地武士團自然隨之而來；放進絕地，光劍隨之而來；放進光劍，達斯・維達隨之而來；放進達斯・維達，「我是你父親」那句台詞也會一串串跟來。

有反抗軍與銀河帝國，有死星與千年鷹號。這些事物不是各自分離存在，而是彼此扣合：絕地與達斯・維達相連，原力與光劍相連，反抗軍與銀河帝國相連。

星際大戰就是這整張連結網。 它不是一個詞，而是這些詞編織而成的關係網。

讀者的 IP 也是同樣道理。無論小說、遊戲、網路漫畫或規則書，把一個 IP 用一個詞說明就會變成謊言。構成那個 IP 的所有詞如何互相連結，這本身就是那個 IP。

我們稱為「圖書館化（librarying）」的工作，是有意識地建造這張關係網。它將只活在創作者腦中的關係網取出來，變成看得見、摸得著的資料；本書將用十四章引導這項工作。

資料沒有連結這件事

經營一個 IP 約五年的人，桌面通常是這種樣子。

若有規則書，大概堆了七本：本篇分成第一版、第二版、第三版，中間夾著兩本左右輔助資料集，還留著一本曾想全面重做卻半途而廢的第零版。如果短篇累積起來，資料夾輕易超過一百篇；外部維基也會開在一邊螢幕。五年前有人開始卻停手的頁面接近一千頁，但活著的頁面不到兩百；打開企劃書資料夾，同名檔案以不同版本放了約三十份：v1.0、v1.1、v1.1_修正、v1.2_最終、v1.2_最終_再最終。

想在這種桌前寫一篇新短篇，馬上會被瑣碎問題絆住：三年前規則書出現的那個人物叫什麼？那個人物所屬勢力寫在企劃書哪裡？與那勢力敵對的集團在哪篇短篇初次登場？要回答這些問題，只能逐一翻找七本規則書與一百篇短篇。因為不能搜尋，沒有連結，同一個詞也沒有在任何資料中被一致整理。

最後作者會創造名字相近的新人物，或稍微改設定把既有人物拿來用，或乾脆跳過。於是 IP 裡開始堆積小矛盾：一個人物有兩個名字，一件事件的日期在兩本書中不一致，一個地點的描述在前篇與後篇不同。IP 越大，矛盾也一起膨脹。

這就是資料散落問題的實體。不是因為沒有術語，而是因為沒有關係。

古老的問題

這個問題並不新。托爾金數十年間留下大量手寫筆記，但資料未被系統化管理，死後兒子克里斯多福又花了數十年才整理完。法蘭克・赫伯特的《沙丘》世界觀，也在兒子延續系列時遇到不少重新建構的困難。

到了網路小說與網路漫畫時代，問題以大得多的規模浮現。連載數百話期間，必須一致管理數十名人物與數百個專有術語。粉絲可能先站出來建立維基，但那終究是讀者的資料，不會成為作者的內部資料。它必然混入讀者的詮釋與誤讀，更重要的是，它無法作為作者寫下一話時放在身邊參照的工具。

一個 IP 的資料沒有整理在同一處。 這個問題至今仍未解決。

詞彙表這個第一個答案

對此問題的第一個答案，是詞彙表（glossary）。把一部作品出現的專有名詞、專業術語、世界觀關鍵字依序列出，並在每個項目旁附上短定義的一張表，就是詞彙表。

製作詞彙表的工作方式本身對每個人都很熟悉。開始一部作品時，在作者筆記的一角另留一張詞彙表頁面，每出現一個新詞便多加一行。只看一部作品的邊界內，這種方式已足夠有效率；打開詞彙表就能一眼確認哪些人物漏了、哪些機制還沒定義。

但作品變成兩部的瞬間，景色開始改變。第二部的新項目必須加進第一部的詞彙表，而其中可能有人物已在第一部被一行提及，因此得先決定是否同一人。若判斷為同一人，就要用第二部資訊補強第一部的一行；作品變成五部、十部時，這類決定量會爆炸性增加。

詞彙表失敗的原因，不只是量太多。列表這種形式本身，在結構上不適合 IP 知識的性質。

列表形式有兩項缺陷。

第一，無法容納項目與項目之間的關係。 一個人物生於哪個地點、在某事件扮演什麼角色等關係，可以寫成「相關：A、B、C」，但要再次確認 A、B、C 分別是什麼項目，仍得從頭翻列表。關係即使被儲存，要沿著關係移動卻不方便。

這點重要，是因為 IP 知識的核心不在事實而在關係。「某人物有某個名字」的事實，遠不如「那個人物為何在這個事件與那個人物衝突」重要。無法舒服追隨關係的資料形式，正會在表達此核心時暴露限制。

第二，列表是單向的。 即使人物 A 的項目寫著「相關：地點 B、事件 C」，走到地點 B 的項目時，「與此地點相關的人物：A、D、E」的反向資訊也不會自動出現。要維持反向資訊，就得在人物 A 與地點 B 兩邊親手寫上相同內容；項目越多，這種手動管理越不現實。

看看這兩項缺陷如何在實務中顯現。假設某 IP 要修正名為「亨斯福教區牧師宅」的地點，於是在詞彙表找到該項目並改正。然而要找出在亨斯福教區牧師宅發生的事件、以它為背景的場景、出現它的人物故事，並使它們全都一致，最後仍只能從頭重讀整份詞彙表，因為項目之間沒有連結。

沒有連結時，改動一邊後很難確認變化對另一邊有何影響。這就是 IP 越大，作者越感到窒礙的結構性原因。

容納關係的格式

從詞彙表的失敗出發的替代方案，是直接連接項目與項目的想法。

翻開百科全書時會看到「→參見：項目名」之類的標示，像這樣直接連結項目的想法其實很早就存在。讀者讀 A 時轉到 B，再從 B 轉到 C 的連鎖，紙本百科全書也曾以自己的方式嘗試實現。

把這個想法完全實現的是網際網路。全球資訊網的核心想法是用連結把文件與文件接起來，維基百科則是把這個想法套用到百科全書格式的結果。讀「拿破崙戰爭」時可點到「特拉法加海戰」，再轉到「納爾遜上將」；任一項目也會顯示「參照這份文件的文件」，連反向連結都能確認。

有趣的是，熱門 IP 越成長，最後越接近這種連結的辭典形狀。我常以《全知讀者視角》為例：原作網路小說、網路漫畫、電影各自分成大項目，並以連結相接；從一個人物可立刻跳到他所屬的事件與世界觀設定。熱門韓國網路小說終究會長成表題詞彼此連結的辭典。遊戲方面，《英雄聯盟》的製作公司直接經營名為 Universe 的官方劇情網站，備有從一位英雄立刻跳到其所屬地區與事件的連結式正典資料庫。

將這個想法套用到 IP 資料管理，畫面會是如此：在一個人物頁面內，他相關的事件、常出現的地點、所使用的機制都用連結相連；事件頁面列出牽涉該事件的其他人物，地點頁面再以連結列出以該地為背景的事件。

這就是把 IP 資料不當作列表而當作網絡管理的想法；這張相連的網絡稱為關鍵字雲。若詞彙表是沒有連結的列表，關鍵字雲便是那些關鍵字互相連接的關係網。

在這裡，連結本身就是資訊。兩個項目之間有連結，包含編輯者判斷二者在 IP 中以某種方式相關。因此連結密度高的項目位於 IP 核心，幾乎沒有連結的項目位於周邊。沿著連結走，IP 的地形會自然顯露。

第一次打開圖譜檢視的那天

有一種實現這個想法的工具，叫做 Obsidian 的筆記工具。

Obsidian 將使用者建立的所有筆記以 .md 檔案保存在同一個工作資料夾。.md 是 Markdown 格式的副檔名，這種格式只在純文字加上幾個輕量符號，便能標示標題、強調與連結。它不像 Word 檔那樣沉重，而是連記事本都能開啟的輕量文字。

Obsidian 可以用 [[項目名稱]] 的表示法自由連接這些 .md 檔案，這種表示通常稱為 wikilink。Obsidian 會在稱為圖譜檢視的畫面中一次展開 wikilink 所連的關係網，讓你看見點浮在畫面上、點與點之間有線相連的圖。

曾有一天，我把五年份資料搬進 Obsidian，第一次打開圖譜檢視。

此前，連資料到底有多少都無法估計。我知道詞彙表記載的項目數量，卻無法得知這些項目如何相連、哪個人物是 IP 實際中心、哪個人物意外位於周邊、哪個事件接到最多表題詞、哪個概念最深地支撐世界觀。

打開圖譜檢視後，這些東西才開始可見。IP 哪個區域密集、哪個區域空白；哪個人物比預期連接更多表題詞、哪個人物孤立無援——詞彙表始終看不見的資料風景，一眼就進入視野。

那正是我從詞彙表走向雲端的瞬間。

名為圖書館化的工作

把一個 IP 的資料建造成雲端的這項工作，我們稱為 〈圖書館化〉。

若 library 意指圖書館或辭典，librarying 就是把建造那部辭典的工作變為動詞形。建造一個 IP 的圖書館，就是我們所稱的圖書館化。

這個稱呼包含小小的意圖。圖書館不是建好一次便結束，圖書館化也不是建造一次便完結的工作。新書進來時，要查看分類系統決定放在哪裡；書架滿了，要添新書架；分類混亂時，要重新整理。就像圖書館營運一樣，一個 IP 的關鍵字雲也是活著、行動的資料。

圖書館這個比喻還有另一層意義。圖書館不只是堆放書，而是分類，依固定標準替每本書編號並指定位置。沒有分類，圖書館只是倉庫；書再多，找不到便等同於沒有。

圖書館化也是同樣。目標不是堆積關鍵字，而是分類、連結、使其可以找到；朝向這個目標的四階段工作，就是圖書館化的本體。

它不是做維基

這裡先切斷一個誤解。用 Obsidian 做維基的方法已很普遍，搜尋便會出現數十種；但圖書館化不是那種做維基。差別不在容器，而在切分方式。

圖書館化不依韓文字母順序或出場順序排列關鍵字，而依敘事功能區分。先問這個詞是人物、裝置還是價值；再交叉 IP 各自設計的世界觀軸，便可做兩座標搜尋，例如在《共同》中只找「與協會糾纏的人物表題詞」，或只找「附屬於地下城的物體表題詞」。只有一種分類標準的辭典做不到這些事。

因此成果的位階不同。粉絲維基是讀者的參照資料，筆記應用的 Vault 是個人的記憶輔助；圖書館化建造的 Vault 則是製作人營運整個 IP 的唯一原本。新短篇、新角色、外語翻譯、百科全書都通過這一本。容器同樣是 Obsidian，收納什麼、如何收納卻不同。

人讀的圖與機器讀的圖

到了這裡，圖書館化會碰到知識圖譜這個更大的潮流。看看 Wikidata 與其基礎工具 Wikibase，許多人共同修正相同知識，結果卻保留為機器也能讀的結構化資料。人讀項目的名稱與說明，機器讀項目的屬性與關係；同一份資料被人與機器以不同方式閱讀。

圖書館化的 Vault 並非要立刻建立這樣的結構化資料庫。Obsidian .md 檔比較接近容易被人閱讀的一側，製作人創作時必須能直接打開查看。不過，一旦把表題詞、別名、九分類、世界觀軸、相關關鍵字、出處分成固定欄位，這個 Vault 也開始逐漸具有機器可讀知識圖譜的性格。

所以把圖書館化稱為「做維基」太小，稱為「完成的知識圖譜系統」又太過。它準確地位在兩者之間：從貼合人手的 Obsidian Vault 開始，卻以長期可走向結構化資料與知識圖譜的形式整理 IP 的關係網。

四階段流程

圖書館化的輸入包含規則書、短篇、企劃書、外部維基、劇本等散落文件，輸出則是 Obsidian 維基。連接兩端的是 一次擷取、二次整合、三次骨架建置、四次敘述執筆四個階段。

一次擷取是從所有輸入拉出關鍵字的階段。依九種分類，逐一記錄規則書出現的所有人物、地點、物品、事件、裝置、概念、價值；不在意重複，即使同一人物以不同寫法出現，也先原樣拉出。一個 IP 的一次擷取結果會成為 5,000 到 15,000 行的巨大表格。

表格進入二次整合後，相同意義的東西會被併入一個表題詞。表題詞指的是關鍵字像辭典項目般正式登錄的形式。例如將「黑霧」、「黑色煙」、「Tenebre」三種寫法併成一個表題詞，該行便會整齊排列英文、韓文、定義、相關關鍵字、翻譯候選。結果是 5,000～15,000 行縮減為 1,000～2,000 個表題詞。

表題詞表完成後，三次骨架建置將其轉換為 1,500 個 Obsidian .md 檔。一個表題詞成為一個 .md 檔，檔案內有定義、詳細說明、相關關鍵字的 wikilink，並保留尚未寫入文字的執筆空間。

最後的四次敘述執筆，將各表題詞的文章寫進這個空間。每個表題詞篇幅介於 200 至 1,000 字。以現代獵人題材世界觀《共同》為例，它不止於「濃度是從閘門滲出的魔力密度」這一句定義，而是用一段流動文字說明該概念在 IP 世界中具有什麼意義。1,500 個執筆空間都填入這類敘述後，一個 IP 的關鍵字雲才完成。

一次、二次、三次的本質是機械式整理，四次的本質是執筆。兩種本質的差異劃分工作性格，也正是本書最重要主題——與 AI 工作夥伴協作的質地——所由來。

用兩隻手建造的工作

一個人能建好全部 1,500 個 .md 檔嗎？

可以。但若只靠一人雙手推進，要花數個月。只靠手工作業的時代，一個 IP 的圖書館化接近要六個月。要六個月的工作終究不會常做；不常做，資料便不更新；不更新的資料最終會成為死資料。

如今能定期營運圖書館化，背景有兩個變化。第一是程序的整理：建立四階段流程，預先定下各階段的輸入、輸出、合格線。第二是導入 AI 工作夥伴。

沒有 AI，圖書館化也能運作。 方法論本身與 AI 無關，四階段管線、九分類體系、兩座標軸設計、十三欄表題詞結構皆然。陌生詞一次出現很多，但現在不必背；第4章至第9章會逐一拆解。重要的是，這些是 AI 出現前也能手工實作的方法，且實際上長久以來都是這樣做的。

但目前的營運型工作流程，以 AI 工作夥伴與自動化約定為前提。現在的圖書館化，將人手可行的方法放進可重複的時間內，並能再套用到多個 IP。AI 不取代方法論，而是把方法論拉進可持續的營運時間。

AI 承擔的工作很具體：一次擷取的大量處理、同義詞候選擷取、四次敘述執筆的初稿。人手要數月的工作，和 AI 協作可在一兩天內完成。

但決定性判斷始終是人的責任：哪些寫法指同一人物、表題詞要如何命名、世界觀軸怎麼設計、執筆是否跨過合格線，最後決定的不是 AI 而是人。

說 AI 會寫 1,500 個項目，聽起來像量產物，實情正好相反。製作人直接寫的幾篇代表 hub 決定其餘表題詞的聲音。AI 是手，製作人是聲音。手只是快，寫什麼、用什麼調性，是聲音決定。

兩種角色一起前進時，那一兩天實際是 9～16 小時工作。老實說，第一個循環更久；還不熟手時大約是預期的 1.4 倍，從第二、三個循環起才落在這範圍。即便如此，半年已縮成幾天。

本書在每個階段逐行指出交接什麼、為何委任、改善什麼、哪裡必須由人直接決定。它不是「用 AI 很好」這種模糊勸告，而是清楚區分 人在哪裡停下、工具從哪裡開始 的文章。

與姊妹文章的關係

與本書相連的姊妹文章有兩篇：〈西燕閣〉與〈新角色建置〉。

〈西燕閣〉處理深入閱讀外語作品的工作。它拿起珍・奧斯汀《傲慢與偏見》這類作品，在進入翻譯與改編前，精密分析並文檔化人物、事件、世界觀、語言的六階段工作，用十四章展開。〈新角色建置〉則處理從零塑造一個人物的工作。

本書處理的是建立兩篇姊妹文章共同使用的資料基礎。若〈西燕閣〉是深入閱讀作品，〈新角色建置〉是塑造人物，〈圖書館化〉便是建造一本讓深讀與人物塑造都必須通過的辭典。即使尚未讀過姊妹文章，也能獨立跟隨本書。

接下來的流程

先展開十四章的流程。

第1章抓住從詞彙表到雲端、從列表到網絡、從一個人到兩隻手移動的方向。接著第2章更仔細看製作人與 AI 工作夥伴的角色，第3章一次展開四階段流程全貌。

第4章開始正式工作：第4章談一次擷取的方法，第5章談二次整合，第6章談兩個分類標準——九分類與世界觀軸。第7、8、9章談 Vault 的形狀：第7章談三次骨架建置，第8章談 hub 與 leaf 的區分。本書高潮的第9章，用整章詳看四次敘述執筆規格：製作人直接寫的幾篇代表 hub 決定其餘項目的調性，AI 工作夥伴以此調性填入表題詞。

第10、11、12章處理驗證與營運，第13章是實戰回顧，第14章是收尾章。

回到關係網

回到開頭的《星際大戰》。

原力、絕地、光劍、達斯・維達、反抗軍、銀河帝國如何互相連結，就是《星際大戰》。這張關係網先存在喬治・盧卡斯腦中，腦中的關係網成為規則書、電影劇本、角色設定集。資料被充分整理，才使《星際大戰》即使過了一代，仍能在不同製作人手中一致地活著。

若 v1.2_最終_再最終還在資料夾某處，關係網尚未整理於一處，走過十四章後終於會有些東西顯現：哪個人物是此 IP 的實際中心，哪個概念最深地支撐世界觀。

現在開始有意識建造那張關係網的十四章。