把標籤變成卡片，知識庫才活起來：標籤連結法 Tag Wiki

很多人的知識庫有一個共同的命運：資料一直存進來，分類卻一直跟不上，最後變成存了等於沒存。我自己也走過這條路。後來我把整套整理方式收斂成一個動作，知識庫才真的活起來。這個方法我叫它標籤連結法，英文是 Tag Wiki。

一、它要解決的問題

一般 hashtag 有兩個先天侷限。第一，意思是別人決定的。你打一個「基礎」的標籤，那個基礎是軟體預設的基礎，不是你心裡那個基礎。標籤本身沒有地方讓你寫下「我說的基礎是什麼意思」。第二，改名成本高。標籤一旦用開，要改名得逐篇去換，於是同義詞越長越多，系統慢慢失準。

純資料夾分類也有侷限：一份資料只能放進一個資料夾，跨主題的內容總有一個歸屬被犧牲。

Tag Wiki 用一個動作回應這些侷限：把標籤做成一張卡片。

二、一個動作：把標籤變成卡片

標籤不再只是貼在文末的 hashtag。它本身就是一張頁面，也是整個知識庫的連結樞紐。升級之後，一張標籤卡片有兩個能力。

定義：因為標籤本身是卡片，你可以在卡片裡寫下「我所謂的這個詞是什麼意思」，從此這個詞在你的知識庫裡有你自己的意思。

定位：標籤卡片之間可以互相連結。哪些近、哪些遠、哪些有關聯，透過連結關係浮現出來。一篇文章只要連到一張標籤卡，之後點那張卡就能找到所有相關內容。

一個務實的好處：改名成本低。用 wiki 連結的軟體裡，改一張卡片的檔名，所有指向它的連結會自動跟著更新，不需要逐篇去換。

三、為什麼我幾乎不用 YAML

很多筆記軟體教學會教你用 YAML 後設資料搭配資料庫式查詢做結構化整理，那是一條成熟的路，適合需要大量報表的人。

我選擇另一條，把分類交給標籤卡片，幾乎不用 YAML。理由有三：一是可讀性，結構化區塊夾在筆記最上方，讀內文時是干擾；二是對 AI 來說，標籤標得準就足以表達脈絡，多一層結構化欄位不會讓模型更懂；三是穩定性，結構化語法對格式敏感，寫不好容易在某些軟體出錯。

兩種思路各有適用場景，我的取捨是用最少的語法換最低的維護成本與最高的可讀性。

四、什麼時候適合用，什麼時候該換工具

這是我最想講清楚的一段，因為很多人會搞混。知識組織沒有單一最佳解，依資料量與使用情境不同，適合的做法也不同。

文章篇數只是粗略的參考，真正決定該用哪一種的，是查詢的複雜度、內容關係的密度、更新頻率與團隊規模。歷史上有人手寫卡片盒累積到數萬張仍運作良好，可見數量不是真正的牆。

五、顧問跨客戶要先處理隔離

如果你跟我一樣要管很多客戶的資料，真正的關鍵不是數量，是保密。客戶的原始資料不能互相混在一起被檢索到。我的做法是把每個客戶的內容物理隔開，跨客戶層只抽取方法論層級的共通模式來統整，不把客戶原文混進共用層。這樣既能跨客戶累積自己的洞察，又守住每個客戶的機密邊界。

六、受控詞彙怎麼版本控管

標籤卡片用久了，一定會遇到要加新詞、改定義、讓舊詞退場的時刻。這時最怕的狀況是詞改了，半年後沒人記得為什麼改。我的做法是把整份受控詞彙表當成一份有版本的規則文件來管理，方法不需要任何程式背景，照做就行。

字典檔是唯一真相。所有標籤必須從字典檔選用，不可自行發明。我的字典目前累積約 220 個受控詞，分成四個維度：對象（誰）、內容（講什麼）、情境（用在哪）、性質（什麼屬性）。每個詞有一張標準定義卡，寫清楚定義、定位、邊界、統一用詞跟不使用的詞。

每一版改動都留下紀錄。字典檔開頭有一份變更紀錄，我的字典從 v1.8 走到 v2.19，累積了 20 個版本。每一版記三件事：動了哪些詞、為什麼、誰拍板。去個人化之後，一筆紀錄長這樣：

機器可讀版只當衍生檔。字典檔另外會轉出一份機器可讀的對照檔（JSON 格式），讓 AI 在存檔前自動比對標籤合不合規。鐵則是這份衍生檔禁止手改：改了字典就重新產生一次，再跑驗證腳本確認兩邊一致。唯一真相永遠是那份人看得懂的字典檔。

七、怎麼開始

1. 先想清楚輸出：你以後最常要把什麼東西叫出來用。整理是為了將來拿得出來用，不是為了收藏。
2. 從眼前一個正在進行的專案開始，為它建幾張最必要的標籤卡片，分到幾個固定維度。
3. 之後每存一份新資料，就掃一遍維度，從受控表選標籤。