MEJE BOOKS Knowledge Library

MEJE PROCESS · MEJE 知識庫化工作流程白皮書 (21 章)

第6章 兩個分類基準——九分類與世界觀軸

MEJE Works · 章 6

第6章 兩個分類基準——九分類與世界觀軸

若一個 IP 只有一個分類基準,會發生什麼事?打開「共同」的人物分類,協會幹部、攻略地下城的覺醒者、一般市民聚在一起。三者都是人物。然而,光靠人物分類,無法知道三者屬於協會領域、地下城領域還是日常領域。同樣限制出現在任何 IP。

本書常用的示範 IP 是「菌絲海」。覆蓋行星的菌絲網是魔法、記憶、溝通的媒質,種族依與何種菌共生而分開,是一個 SF 生態世界。以這個 IP 一路追到最後,便能清楚看見何謂正交,以及兩個分類基準如何咬合。

Librarying 使用九分類與世界觀軸兩個分類基準。兩者彼此正交。九分類問「此關鍵字在敘事中有何功能」,世界觀軸問「此關鍵字屬於我們世界觀的哪個結構」。每個表題語對兩個問題各有一個答案,這兩個答案就是座標。

若分類基準只有一個

以武功繫於星座的江湖世界「星羅江湖」來看只有九分類時會發生什麼事。打開人物分類,正派掌門人、邪派殺手、讀天文的觀相家、遊走江湖的浪人都在同一類。四人都在故事裡作為行動者運作,確實都是人物。

但光靠人物分類,很難知道四人彼此有何關係,或在這個 IP 世界觀中屬於哪個領域。正派掌門人跨在正邪派領域與率領一個門派的門派領域;觀相家接觸武功繫於星的天文領域;浪人則屬於不隸屬任何門派的江湖領域。同樣是「人物」,在 IP 中卻分布於完全不同的世界觀領域。

若此區別未在 Vault 裡表達,有人搜尋「顯示所有天文領域的人物」便得不到答案,只能打開整個人物分類逐一用眼挑選。表題語若有 1,500 個,這極其麻煩;世界觀軸作為第二分類基準加入,正好解決這個問題。

分面分類:兩個獨立基準的歷史

同時使用兩個獨立分類基準不是 Librarying 的發明。資訊科學與圖書館學有一種稱為分面分類(Faceted Classification)的方法論。

動物→脊椎動物→哺乳類→食肉類→貓科,這樣按一個基準往下分層的是傳統階層分類。它直觀,但只能使用一個基準,無法完成「住在非洲的哺乳類」這樣同時套用地域與分類群兩個基準的搜尋。

分面分類不同之處在於,將一個對象分成多個獨立分面。以一本書為例,主題是歷史、地域是韓國、時代是朝鮮、形式是小說;各面獨立附著,既可按任一分面搜尋,也可如「朝鮮時代韓國歷史小說」般同時套用四個分面。

Obsidian 的 tags 系統實作此分面分類,Librarying 的九分類與世界觀軸便是把此系統用作兩個獨立分面。

正交是什麼

在數學中,兩個軸正交是指兩者獨立運作,一軸上的值不決定另一軸的值。若 X 軸決定「朝哪個方向」,Y 軸決定「有多高」,兩軸即為正交:朝東也可以低或高;高也可以朝東或朝西。

以「菌絲海」看九分類與世界觀軸的正交。假設此 IP 的世界觀軸定為「菌絲網」「種族」「共生」「身分」「地形」「一般」六軸。「光菌族」在九分類是人物、在世界觀軸是種族;「空孢子囊」是物件且屬種族;「共生」是概念且屬共生;「菌絲接續」與「共享記憶」是裝置且屬菌絲網;「掌握大節點的支配者」是人物且屬身分;「不毛地」是場所且屬地形;「發光菌絲」是場面調度且屬地形。同一世界觀軸「種族」有人物、物件、概念;同一九分類人物有種族軸的光菌族與身分軸的支配者。一個表題語以一個九分類乘上一個世界觀軸來座標化,兩座標不決定彼此即為正交。

事件將人物、場所與物件束在一起時

設計世界觀軸時常漏掉一個觀點:光把人物、場所、物件、事件分開,關係不會充分顯現。CIDOC CRM 等整合文化遺產資訊的本體論,不把人、場所、物件、時間只看作獨立清單,而試圖透過事件與行為連結它們,理由正在此處。博物館文物的意義,來自它曾在哪個時代、哪個場所、經誰的手、置於何種事件中被一併記錄。

IP 也一樣。一把劍是物件,劍客是人物,比武場是場所;但將劍從誰交給誰、在哪個比武場折斷、事件後門派權威如何改變綁在一起的是事件。沒有事件,人、場所、物件只是各自清單;事件進入後,三張清單才連成一段世界觀記憶。

因此世界觀軸不是單純建立「人物軸」「場所軸」「物件軸」。九分類已把人物、場所、物件分開;世界觀軸要顯示它們在何種世界觀領域與事件流程中相遇。一個 IP 以「王位繼承」為軸,另一個以「菌絲網」,又一個以「安置」為軸。好的軸不是將清單切得更細的名稱,而是能說明人物、場所、物件、事件同時被束起的場景名稱。

為何需要世界觀軸

只用九分類時,打開人物分類會混合主角、配角以及來自不同世界觀領域的人物。敘事功能都同為人物,在 IP 裡卻屬於完全不同的世界觀領域。

在 Vault 圖譜檢視中,人物分類的點聚成一種顏色。要區分「這些人物屬於世界觀的哪個領域」,需要另一種顏色區分,第二基準便是世界觀軸。在 Obsidian 開啟 Vault 與圖譜檢視,可以兩種方式為點著色:按九分類,人物藍色、場所綠色、裝置橘色,按敘事功能分開;按世界觀軸,各領域有不同顏色,按世界觀領域分開。同一個 Vault 如同用兩副透鏡觀看。有了兩副透鏡,便可搜尋「只顯示某世界觀軸中某九分類的所有關鍵字」,同時使用兩個座標。

世界觀軸因 IP 而異

九分類是本書規定的分類,因此對每個 IP 相同;世界觀軸不同,必須依 IP 設計。

觀察五個 IP 的軸組如何不同。每個 IP 有五個核心領域,加上「一般」與「未定」共七軸。現代獵人題材的「共同」使用地下城、覺醒、協會、濃度、日常;香氣媒介身分與魔法的戀愛奇幻「香宮」使用香、身分、社交界、家門、神聖;武功繫於星座的武俠「星羅江湖」使用武功、天文、正邪派、江湖、門派;雨是正統性印記的東方王朝物「雨司府」使用天命、水、官署、權門、民心;死者引導航路的宇宙 SF「喪輿號」使用冥路、航行、家門、安置、次元。五個 IP 的核心領域全然不同,一眼可見。

同為九分類物件的一物,如「杖」,在 IP 中所屬軸也不同。「星羅江湖」刻星座的本命星牌決定武人的星,屬「武功」;「香宮」裝當日佩戴香氣的香水瓶代替身分證,屬「身分」;「共同」區分覺醒者身分的等級卡是協會授予標識,屬「協會」;「喪輿號」固定亡者的牌位是航法師寄居的航行核心,屬「航行」。敘事功能同為物件,依世界觀結構卻落在不同軸。

人物分類也同樣依 IP 進入不同軸。「香宮」的大貴族調香師因製香而屬「社交界」軸;「雨司府」的雨司府大提學是談天官署的首長,屬「官署」軸;「喪輿號」的安置院祭司掌管死亡,屬「安置」軸。同為九分類人物,所屬軸仍依 IP 以何種領域組成而不同,世界觀軸沒有正確模式。即便同是奇幻,魔法為核心的 IP 與政治為核心的 IP 軸也不同,故須先確認本 IP 置何者於中心再設計軸。

打開 D&D《Forgotten Realms Campaign Setting》目錄,這種軸的想法直接表現為書的章構成。Magic、Deities、History、Organizations、Life in Faerûn 等世界觀領域按章分開,各章中人物、場所、物件、事件一起包含。一個人物同時出現在 Deities 與 Organizations 章很常見。因此此章構成對應世界觀軸而非九分類。《Eberron Campaign Setting》也是同樣方式,只是領域名稱與數量不同。

D&D 四十年前按領域劃分世界觀,終究只是一種分類。按領域分,該領域的人物、場所、物件雖會聚在一起,卻無法只憑領域分類知道人物是否為敘事行動者、物件是否為敘事裝置。Librarying 借用領域分類作世界觀軸,再在其上正交疊加九分類。唯有兩軸交叉,才可作「只要信仰領域的人物表題語」這樣同時指兩座標的搜尋。既有地誌或個人 Wiki 多只按一個基準分資料,Librarying 則以兩個重疊基準閱讀 IP 資料。

世界觀軸的設計原則

世界觀軸設計有四個原則。

數量是 5 至 7 個。 太少(2 至 3 個)分類過粗而失去意義,太多(10 個以上)則難以管理。將一個 IP 的核心世界觀領域壓縮為 5 至 7 個是建議範圍。

必須有「一般」軸與「未定」軸。 「一般」為不屬特定世界觀領域的通用詞彙分類,如「你好」「昨天」「大」等與 IP 無關也能使用的詞彙;「未定」是尚未確定所屬軸的表題語暫時分類。沒有這兩軸,無法分類的表題語會無所屬而留下,到檢收階段才被發現。

歸納決定。 與其先在腦中編軸再塞入表題語,不如先掃一百個表題語、發現何種組合自然形成;這種姿態會做出適合本 IP 的世界觀軸,是設定檔階段的核心工作。

不固定,但不隨意改變。 世界觀軸在第二次整合中可能需要調整。若放入「一般」的表題語大量累積,可能從中發現新軸。但每次新設或變更軸都要記錄在設定檔,並重新檢查已附上的表題語軸。世界觀軸在第二次 CSV 與 frontmatter 中像允許值一樣使用,因此清單外軸名混入時,驗證階段會抓為錯誤。

為何必須在設定檔先決定

第三章時間預算將「設定檔」置於最初,是因為未先決定世界觀軸,第二次整合便困難。

第一次擷取後,將五欄 CSV 裡的五千至一萬五千列交給 AI 工作夥伴整合為十三欄時,要填世界觀軸欄便需要允許值清單。沒有允許值,AI 會按各表題語即興加軸,跨一千個表題語軸名便參差不齊。「菌絲海」可能同一軸分裂成「菌絲網」「菌絲」「菌絲網世界觀」「菌絲界」四種寫法。設定檔階段確定世界觀軸允許值,委派第二次整合時一併交付,AI 工作夥伴便只在允許值內附軸,寫法會統一。

設定檔產物為{專案}_profile.md。除世界觀軸允許值外,也包含九分類的 IP 別特記事項、輔助參照文件清單、第四次敘事撰寫的語調指南。此檔是 Librarying 第一次循環的起點。

歸納決定:讓表題語說出自己的軸

以「菌絲海」看設定檔中決定世界觀軸的具體姿態。第一次擷取尚未開始,或只是預先掃過部分結果時,閱讀 IP 文件會看見一頁裡常一起出現的詞彙組。無論打開哪份文件,菌絲網、節點、接續、共享記憶總一起出現;別處有光菌族、腐敗菌族、石菌族、孢子遊浪族一起出現;又別處有光菌森林、腐敗菌沼澤、石菌山脈、不毛地一起出現。

這些組各自是世界觀軸候選:「菌絲網」「種族」「地形」。與何種菌結合決定能力的組成為「共生」;握住大節點者集聚權力的組成為「身分」;不進任何組的通用詞彙分類為「一般」。將發現的六軸加上供尚未歸屬表題語使用的「未定」軸,在設定檔確定。第一次擷取後的第二次整合,便把每個表題語放在這些軸之一。

這種歸納姿態讓表題語自行顯露所屬軸。人不先訂軸名,而先察看本 IP 分成哪些領域。把名稱放在前面會強迫表題語塞入名稱;先發現 IP 的模式,表題語則自然坐進自己的分類。

兩座標同時存在時

兩個分類基準同時存在,Vault 的資訊結構便立體起來。

「菌絲海」新篇章若要詳細處理菌絲網的運作原理,想收集相關裝置表題語時,同時掛上世界觀軸「菌絲網」與九分類「裝置」,呼叫該領域所有裝置表題語,便能一眼看見接續與共享記憶如何咬合。其他 IP 也相同:在「喪輿號」寫處理航行的短篇,要收集該領域裝置,就把「航行」與「裝置」相乘;在「香宮」挑選社交界場景人物,就把「社交界」與「人物」相乘。任何 IP 將世界觀軸與九分類相乘,所需交集便立刻出現。

能進行兩座標搜尋,正是導入世界觀軸的實質理由。若只有一個分類基準,唯一方法是打開所有人物逐一查看;兩基準正交,便能直接取出所需交集。

frontmatter 的實際樣子

第三次骨架建置生成 .md 檔時,檔案頭的 frontmatter 形式如下。

---
title: 菌絲接續
aliases: [接續, 菌絲網接續]
category: 裝置
worldbuilding_axis: 菌絲網
english: Mycelial Linking
romanization: Gyunsa Jeopsok
version: 現行
tags:
  - category/裝置
  - axis/菌絲網
  - version/現行
sources:
  - 規則書第3版 p.24
related:
  - "[[共享記憶]]"
  - "[[無菌者]]"
---

category 欄位是九分類,worldbuilding_axis 欄位是世界觀軸。兩欄以 category/裝置axis/菌絲網 形式進入 tags 陣列,因而能被搜尋。第七章詳談第三次骨架建置時會再處理此 frontmatter 結構。

世界觀軸營運的兩個陷阱

第一個陷阱是世界觀軸膨脹。最初六個軸,但每當遇到放入「一般」曖昧的表題語就新建一軸,很快會膨脹到十二個。超過十個,Vault 圖譜檢視的色彩區分失去意義,搜尋篩選也複雜,管理負擔變大。看似需要新軸時,先看既有軸能否吸收;只有無法吸收才新設,且每次都記錄在設定檔更新。

第二個陷阱是混淆九分類與世界觀軸。例如在「菌絲海」把世界觀軸「菌絲網」與九分類「裝置」混淆,把所有菌絲網關鍵字放入裝置,或反過來把「裝置」定為世界觀軸。九分類問敘事功能,也就是做什麼;世界觀軸問世界觀結構,也就是屬於哪裡。同一菌絲網領域中可同時有裝置、人物、價值、事件,必須時刻記住兩基準彼此正交。

hub 決定的輔助資料

hub 決定在第八章詳談;此處只先指出世界觀軸如何輔助此決定。

一個世界觀軸內相關關鍵字被引用次數最高的表題語,就是該軸的 hub 候選。「菌絲海」中,「菌絲網」軸最常被引用的表題語是該軸 hub 候選,「種族」軸最常被引用的表題語是種族軸的候選。如此尋找各軸 hub,便會顯出本 IP 每個世界觀領域的核心表題語位置。再與整體被引用次數前列的表題語並置,Vault 的結構中心會立體浮現。

只有這兩副透鏡才能看見的問題是:比較「菌絲網軸的 hub 表題語有哪些」與「種族軸的 hub 表題語有哪些」時,哪個軸擁有更多 hub?這比較顯示「此 IP 最深入挖掘哪個世界觀領域」。若五年營運中菌絲網軸有四十個 hub、種族軸只有五個,便是種族世界觀相對未發展的信號,可作為決定下一個創作方向的資料。

手持兩座標系

設定檔確定的允許值清單會在第二次整合委派時一同交付;AI 工作夥伴為各表題語附上候選軸,人再在檢收中確定。一個分類基準看不見的東西,會由兩基準的交集搜尋呈現。

第七章是第三次骨架建置:十三欄 CSV 備妥後,自動轉為 1,500 個 Obsidian .md 檔。這是幾乎沒有人的手介入的自動化階段,但結果首次會在畫面展開 1,500 個點與線。


© 2026 MEJE WORKS Corp. & 김동은WhtDrgon. All rights reserved.