這篇要講Query，首先

Query 有分使用者查和 AI 查，使用者查就是直接用 Obsidian 的搜尋功能，或是說直接根據資料結構判斷檔案位置，這部份沒什麼好說的，所以從這篇開始往後所有跟 Query有關的敘述，都是

「AI 查」。

AI 怎麼查？

還記得我們說過本質上，LLM Wiki 就是一堆 Markdown 檔案 + 一個能操作檔案系統的 Claude 嗎？

先假設檔案夾裡面真的就「只是一堆檔案 + 一個能操作檔案系統的 Claude」。在這種情境下，AI 是怎麼查資料的？

以 Claude 為例，會使用三種主要工具：

1. Glob

Glob 是用檔名／路徑模式找檔案，不看內容、不看時間，適合「我知道檔案長什麼樣子或放在哪個目錄結構，但不確定實際檔名或想批次列出」的情境。

簡單記的話：這個方法「只看檔案名稱」。

舉例：

• 我想找出2026鐵人賽系列下的所有文章，AI 會透過 Glob查：wiki/projects/active/iThome鐵人賽2026/文章/*.md——適合想知道目前有幾篇、檔名怎麼命名
• 找某個主題所有子頁：wiki/evergreen/topics/DragonsHoard建設歷程/**/*.md——遞迴抓整個主題目錄

需要詳細 Glob 行為說明，可以到 Claude 官網查，上方截圖就是去官網截的。

2. Grep

Grep 是找檔案「內容」裡有沒有某個字串或模式（pattern），適合找內容，也是最主要 AI 用來搜尋的工具。

舉例：

1. 用日期前綴掃時間軸：log.md 每筆紀錄固定 ## [YYYY-MM-DD] 開頭，搜尋 ## \[2026-09 就能篩出某個月份所有操作紀錄，不用整份從頭讀到尾。
2. 搜尋知識庫中有關「AI 輔助開發」的所有內容。

3. Read

Read 是在你已經知道「就是這個檔案」之後，把完整內容拿進來看。

舉例：

• 你直接說要看某個檔案：像你問「chaos/白板.md 現在寫了什麼」，不用搜，直接 Read
• 執行 skill 流程時載入規則本體：任何 skill 執行前要先 Read 相關檔案拿到完整內容
• 改檔案前的必要動作：Edit 工具規定改檔案前一定要先 Read 過，確保改動基於實際內容而非猜測

具體流程通常長這樣：

1. 先用 Glob 搜尋檔名／目錄結構：掃一下有哪些資料夾、檔名長怎樣，猜哪裡可能有關。
2. 從查詢裡自己抽關鍵字去 grep 內容，不是把整個問題丟進去比對，而是模型自己判斷「這個問題大概會用到哪些詞」，用那些詞去掃全部檔案的內容。
3. 看 grep 命中的檔名/行數，挑最像的幾個去真的 Read——所以不會每個命中都讀。
4. 讀完之後模型自己決定夠不夠：夠了就直接回答，不夠就換關鍵字再 grep 一輪，或往別的目錄找。這個「夠了就停」是模型當下的主觀判斷。

上面這四個步驟「全部」都是 Agent（有工具、能操作檔案系統的那種 AI）自己的行為；更具體地說，是 Claude 的行為。

換成 LLM Wiki，會有什麼不一樣？

前面講的是「只是一堆檔案」的情況，沒有CLAUDE.md、index.md這些「導引」，Claude 只能用 Glob 猜「大概在哪裡」。

換成 LLM Wiki 的話，CLAUDE.md 跟 index.md 能夠提供足夠上下文，讓 AI 不用猜。

具體是這樣：

• 資料夾結構：切好範圍之後，Claude 看到問題大概就知道該往哪個資料夾找，不用猜。
• index.md：每個主題做「範圍宣告」、每篇文章「在講什麼」都濃縮成一句話寫在那裡，不用展開每個候選頁面全文才知道相不相關。
• CLAUDE.md：定義了 frontmatter 欄位（type／status／tags）跟 wikilink（[[頁面名稱]]），讓 grep 有明確、可預期的目標可以打，不用對內容做語意判斷。

意外闖進 Harness 的範疇

以上就是這篇的全部內容，本來只是弄 LLM Wiki，不知不覺就進入到 Harness 的範疇（Glob／Grep／Read 這三個工具）。

主要是 Query 這個動作越是想要查得澈底，就越需要對 AI 的搜尋有更多了解，因此很自然地，了解 AI 能做什麼成了需要做的事。

在知識庫資料量還沒起來的初期，使用者往往會發現讓 AI 自己搜，不去對查詢做太多的限制與規範，其實會搜的比較快。

但是隨著資料增長，問題肯定會隨之而來，像是：越來越失控的 AI 行為、怎麼問就是查不到的資料、以及 AI 逐漸失智的回答。

細節不顧好，失智的速度就越快，所以持續的學習試錯與調校，這是我一直在做的事。

也鼓勵想建知識庫的夥伴們不要覺得麻煩，如果覺得麻煩，先把我走過的路（文章）看完。