資料越存越多，怎麼讓 AI 找得到？

這篇在講什麼

資料存得越多，AI 越容易找錯或找不到。我的知識庫有七千多份 Markdown 檔案、131 個技能包，AI 每次工作只讀其中幾份，靠的是三件事：檢索頁（先看目錄再翻內容）、雙向連結（我連到你，你也找得到我）、漸進式載入（先讀簡介，用到才讀全文）。這篇用三個實際的應用來講：Karpathy 提出的 LLM Wiki、技能包、我自己用的 Tag Wiki（標籤連結法），再講我為什麼選 Tag Wiki，以及怎麼從一張檢索頁開始。

資料給 AI 太多，等於沒給

我在 AI 系列課第一堂舉過一個例子。AI 像剛到公司的新人，公關系畢業。叫他寫企劃書時，給他去年和前年的兩份企劃書，他很快就知道怎麼寫。如果跟他說「公司庫有一千份，看完你就會寫了」，這句話有講跟沒講一樣，因為太多了。

AI 也一樣。它每次能讀進去的量有上限，讀進去的東西越雜，越抓不到重點。所以問題從「資料有沒有存」變成「AI 這次該讀哪幾份」。下面三件事，都是在回答這個問題。

檢索頁：AI 找資料先看目錄，再翻內容

檢索頁就是一份目錄。它不重寫內容，只列出「什麼東西在哪裡」，每一行一個連結加一句說明。

我的知識庫有幾張常用的檢索頁：

我的知識庫也有一份寫給 AI 的規則：問「專案在哪」，先讀專案位置總表，再讀專案檢索頁，再讀那個專案的入口檔，以上都找不到才全庫搜尋。全庫搜尋排在最後一順位。

檢索頁本身很省：AI 讀一張目錄，花的字數遠少於把每份檔案打開來看。它的代價是要維護，目錄跟實際檔案對不上時，AI 會照著錯的目錄去找。所以我讓程式從資料夾現況自動生成一部分目錄，例如每個技能包檔尾的檔案清單，後面會講到。

雙向連結：我連到你，你也找得到我

連結有兩個方向。A 檔寫了一個連到 B 的連結，這是正向連結；站在 B 的角度，「有哪些檔案連到我」就是反向連結（backlinks）。

雙向連結的好處是不管從哪一端進來，都找得到另一端。我在 Obsidian（我用的筆記軟體）裡寫 [[標籤連結法]]，這篇筆記就連到「標籤連結法」那張卡；反過來，從那張卡出發，可以列出所有提到它的筆記。2026 年 10 月 15 日查了一次，目前有 89 份檔案連到這張卡。

查反向連結，我用的是最陽春的搜尋指令

2026 年 8 月的一次實測：同一題「哪些筆記掛了圖譜工程這個標籤」，用文字搜尋指令（grep）不到一秒撈到 8 筆，用 Obsidian 的反向連結功能花了將近三秒、只撈到 1 筆。原因是 Obsidian 的反向連結要那張標籤卡已經建好才算得到，而那張卡當時還沒建。之後我把 AI 查資料的主要方式改成文字搜尋，也不再要求一定要開著 Obsidian。

雙向連結會壞，要有程式檢查

我的知識官網也有雙向連結：每篇文章在設定檔列出「相關文章」，A 列了 B，B 也應該列回 A。官網有一支小程式檢查這件事，連到不存在的文章就擋下上線，只有單向的就提醒。2026 年 10 月 15 日跑了一次：189 篇文章，斷掉的連結 0 個，單向沒回連 125 個。單向不擋上線，因為有時候是故意的，也可能正在分批補。

LLM Wiki：讓 AI 自己寫、自己維護一份互相連結的筆記

LLM Wiki 是 Andrej Karpathy 在 GitHub 上公開的一份做法說明（llm-wiki.md ↗）。照他的原意，這是一種用大型語言模型建立個人知識庫的模式，不是現成產品：

• 原始資料放一層，不改動。
• 由 AI 讀原始資料，寫成一組持續更新、互相連結的 Markdown 頁面，這一層就是 wiki。
• 再用一份規則文件告訴 AI 這個 wiki 的結構和操作方式。
• 平常的操作分成三種：把新資料收進來、查詢、檢查整份 wiki 有沒有矛盾或過時的地方。

它跟「問問題時才去原始資料裡撈片段」的做法不同，重點是讓 AI 平常就把知識整理好、把連結建好。

我怎麼看 LLM Wiki

我在 2026 年 6 月的觀點日記裡寫過，它跟 Obsidian 裡文件互相連結是同一類概念，都是讓文件跟文件之間可以互相找到，知識庫不會變成一堆孤立的文件。但我自己實際操作時發現，讓文件直接互連，準確性最高，管理成本也最高。每寫一篇文章，都要去找所有跟它有關的文章、一一建立連結，對我來說不切實際，除非是非常高價值的議題才值得這樣做。這是我對直接互連的取捨；Karpathy 的原案把交叉連結和維護交給 AI 來做。所以我用了別的方式，後面會講。

技能包：簡介是門牌，檔案清單是目錄

技能包是一個資料夾，裡面放一份主說明（SKILL.md）和需要時才讀的參考檔。我現在有 131 個技能包，全部加起來約 586 萬字，AI 不可能每次都讀完。

每個技能包開頭的簡介，就是門牌

我的系統裡有一支程式，從每段簡介（description）裡把「使用者會怎麼說」抓出來當觸發詞。例如 3X4 資料整理法那個技能包，簡介寫「當使用者說『教我 3X4』『幫我建 3X4』」，程式就抓出「教我 3X4」「幫我建 3X4」「3X4」這幾個詞。現在 131 個技能包共抓出 1,695 個觸發詞。

每次我送出一句話，系統會先拿這句話比對觸發詞，命中的話只告訴 AI「這幾個技能包可能有關，說明在這個路徑」，最多五個，只給路徑，不給內容。AI 判斷真的用得上，才去讀那個技能包。

每個技能包的檔尾，有一份自動生成的檔案清單

主說明開頭掛兩到四個標籤，檔尾列出這個技能包所有參考檔的連結。這樣一來，技能包自己就是一張小檢索頁：從標籤卡可以反向找到技能包，從技能包可以正向找到每一份參考檔。131 個技能包裡，目前 112 個已經有這份清單。

Tag Wiki：每篇只連到幾張標籤卡

Tag Wiki 是我自己的做法，中文叫標籤連結法。它的靈感來自 LLM Wiki，但做了取捨：不需要每篇內容互相比對，只要連到幾個關鍵節點就好。

關鍵節點就是標籤卡。這裡的標籤本身就是一張頁面，可以寫下「我說的這個詞是什麼意思」，標籤卡之間也可以互相連結。每篇文章只掛幾個標籤，等於只連到幾張卡；要找某個主題時，從那張卡的反向連結就能把相關文章都叫回來。

我常用的比喻是經絡與穴道。脈絡太多太細，管不完，抓住幾個關鍵穴位，就能調控整條經絡。標籤卡就是穴位。

為了讓標籤不亂長，我有一份標籤字典，規定只能從字典裡選，字典沒有的詞要先問我。目前整理出的標籤卡有 289 張，分成對象、內容、情境、性質四類。

LLM Wiki、Tag Wiki、RAG 怎麼選：我自己用 Tag Wiki 的理由

這三種做法，我自己的整理是：

我在 2026 年 6 月寫下的初估是：一千篇以內可以用 LLM Wiki 式，一千到一萬篇 Tag Wiki 還不錯，一萬篇以上可能要用 RAG。

而且這三種可以互相應用。我的知識庫用 Tag Wiki 管標籤，同時也建了向量索引（依意思找資料的做法，可以當成 RAG 的檢索那一步），用來找「忘了當時用什麼詞、只記得意思」的資料。技能包則跟標籤卡連在同一張網上。

我選 Tag Wiki，理由是我自己的情況：資料已經七千多份，橫跨很多個客戶和主題，我需要的是低成本、可以大量維護的方式。標籤負責把資料聚起來，技能包負責把資料用起來。

漸進式載入：先讀簡介，用到才讀全文

前面講的檢索頁、雙向連結、三種應用，最後都是為了同一件事：AI 不用一次讀完全部，需要什麼讀什麼。這叫漸進式載入（progressive disclosure，也有人叫按需載入）。

技能包是最清楚的例子，分三層：

我在課堂上用看海報來比喻。走過電影海報，先被大標題吸引，知道這部電影在演什麼；走近一點，看到劇情簡介、卡司；想知道更多，就掃海報上的 QR code 去官網。需要什麼，再載入什麼。

以我的技能包為例，全部約 586 萬字，主說明約 115 萬字，名稱、簡介這些開頭欄位加起來約 5.6 萬字（2026 年 10 月 15 日盤點）；路由每次只提示最多五個候選技能包的路徑，這裡算的只是技能包的提示，AI 的上下文還有其他內容。

漸進式載入成立的前提，是 AI 知道「下一層在哪裡」。簡介要寫清楚什麼時候該用、主說明要寫清楚什麼時候去讀哪一份參考檔、檢索頁要跟實際檔案對得上。這就是為什麼前面先講檢索頁和雙向連結。

今天就能開始：先做一張檢索頁

不用一次做完三件事，先從一張檢索頁開始。把下面這段貼給你的 AI（它要能讀你的資料夾，例如 Claude Code、Codex；不行的話，把檔名清單貼給它）：

做完之後，往下走的順序：

1. 告訴你的 AI：「以後找資料，先讀檢索頁，找不到再搜全部。」
2. 從第 3 題挑出的詞裡選幾個當標籤，每個標籤寫一句定義，之後只用這幾個。
3. 如果你有技能包，檢查每個技能包的簡介裡有沒有寫「使用者會怎麼說的時候用它」。

檢索頁與技能包路由，哪裡有把握、哪裡還沒有

• 觸發詞比對會漏。它比的是字面，同一個意思換個說法就可能對不上。路由上線測試時就遇過「幫我把這段錄音轉成文字」沒有命中，補了詞才過。所以我把它定位成加速器，沒命中時，AI 還是要回頭查目錄。
• 檢索頁要維護。手寫的目錄會過期，我能自動生成的就自動生成，手寫的靠每月健檢。
• 規模的數字是我的初估。上面那張表是我個人的整理，會隨模型能力改變，請當成判斷方向的參考。

靜態的文件找得到之後，下一步是讓好幾個 AI 互相分工、彼此交接，這是 AI 系列課第四堂第 3 篇要講的事。