Day 180 用 OKF 重整 Obsidian 筆記庫

我的 Obsidian 筆記庫裡有一包 Claude Secretary——151 則技術筆記，從 Claude Code 架構到 Threads 演算法都有。原本是平放在一個資料夾裡，用 MOC（Map of Content）檔案做導覽。人讀沒問題，AI agent 靠搜尋和 backlink 也找得到東西——但效率不好，關鍵字搜尋常常撲空、噪音又多，每次都在猜該用什麼關鍵字。

四月 Karpathy（前 Tesla AI 負責人）提了 LLM Wiki 的概念——讓 AI 幫你建知識庫、自動維護。很多人跟著做了，但每個人的 wiki 結構都不一樣，換一個 AI 工具就讀不懂。六月中 Google Cloud 發了一套開放規格叫 OKF（Open Knowledge Format），v0.1，把這個 pattern 變成一個可以帶著走的標準。

今天用了一個 session 把筆記庫搬過去。這篇分享 LLM Wiki 是什麼、OKF 解了什麼問題、我怎麼搬的、搬完之後差在哪。

OKF 長什麼樣

一句話：用資料夾 + Markdown + YAML frontmatter（每個檔案開頭那段標籤資料）組成的知識格式，人跟 AI 都能直接讀。

規則極少——每個 .md 檔的 frontmatter 裡有 type 欄位，就算合規。不用另外裝套件、cat 就能讀、git clone 就能散佈。

結構長這樣：

knowledge-bundle/
├── index.md          # 目錄頁，progressive disclosure（先看目錄再往下讀）的入口
├── log.md            # 變更紀錄
├── topic-a/
│   ├── index.md      # 這個主題的導覽
│   └── concept-1.md  # 一則知識筆記
└── topic-b/
    ├── index.md
    └── concept-2.md

兩個保留檔名：index.md（目錄頁）跟 log.md（更新紀錄）。其他 .md 都是一則一則的 concept（知識筆記）。

每則 concept 的 frontmatter 長這樣：

---
type: zettel
title: MCP 跟 sub-agent 的 context 隔離差異
description: MCP tool call 結果進 main context；sub-agent 隔離中間步驟，只回摘要。
tags: [claude-code, architecture, context]
---

type 必填，其他隨你加。Consumer 遇到不認識的欄位不能拒絕——這是刻意的，讓格式能繼續擴充。

Karpathy 的 LLM Wiki 跟 OKF 的關係

四月 Karpathy 在 X 上提了一個想法：別只拿 AI 寫程式，拿它來建知識庫。他把這個 pattern 叫 LLM Wiki，發了一份 gist，破萬個星。

LLM Wiki 的架構分三層：

Raw Sources——原始資料（文章、論文、資料檔），不可改動，AI 只讀不寫
Wiki——AI 產出的 Markdown 頁面。摘要、概念頁、比較表，全部由 AI 寫、AI 維護交叉引用
Schema——一份 CLAUDE.md 或 AGENTS.md，告訴 AI 怎麼組織這個 wiki

跟 RAG（Retrieval-Augmented Generation，每次提問都重新翻原始資料）的差別：RAG 每次查詢都重新查原始文件；LLM Wiki 是先「編譯」一次——把來源讀完、整理成結構化的 wiki——之後每次查詢都在已經整理好的知識上面跑。Karpathy 的類比是：wiki 就像 compiled binary，你不會每次都重新編譯 source code。

這個 pattern 紅了，很多人跟著做。但做出來的每個 wiki 都是獨立的——Karpathy 的 wiki 有 Karpathy 的結構，你的 wiki 有你的結構，某間公司的 metadata catalog 有自己的欄位。表面上都是 Markdown + frontmatter + 交叉連結，但沒有人約定過「哪些欄位每份文件都該有」「目錄頁該叫什麼名字」。

Google Cloud Blog 講得直接：

The pattern is compelling and powerful, but each instance is bespoke. There is no agreed-upon answer to what fields every document should carry, or what filenames mean what.

OKF 就是來補這個洞的。 它不是另一個筆記工具或 wiki 平台，是一套格式標準——定義最小的共同規則，讓不同人、不同 agent、不同組織建出來的知識庫可以互通。你用 Claude Code 建的 wiki，Codex 能讀；你團隊的知識庫，合作方 git clone 下來就能用，不需要裝任何 SDK。

一句話：LLM Wiki 是 pattern，OKF 是讓這個 pattern 可以跨工具、跨組織沿用的標準。

跟原本的 Obsidian vault 差在哪

Obsidian 本身對 AI 只能算「部分可讀」——筆記是 Markdown，但結構靠 plugin（Dataview、Graph View）、靠人的整理習慣。AI 要理解你的組織方式得猜。

OKF 補上三件事：

Frontmatter metadata——AI 讀 type 跟 description 就知道這則筆記是什麼，不用讀全文
index.md progressive disclosure——AI 先讀目錄頁，看哪些主題跟問題有關，再往下鑽。不用掃 151 個檔案
跨系統可攜——同一包知識可以丟給不同 AI agent、不同工具讀。不綁任何 Obsidian plugin

重點：OKF 不取代 Obsidian，是加一層結構讓 Obsidian 裡的內容對 AI 也友善。 Wikilink 照用、Dataview 照跑、Graph View 照看。

我怎麼把 151 則筆記搬過去

原本的結構：

Claude Secretary/
├── moc-claude-code.md       # MOC 導覽
├── moc-ai-agents.md
├── moc-threads.md
├── ...（共 8 個 MOC）
├── note-001.md              # 平放的 zettel 筆記 × 151
├── note-002.md
└── sources/                 # 60 份參考資料

搬完：

Claude Secretary/
├── index.md                 # OKF 根目錄（frontmatter 有 okf_version: "0.1"）
├── log.md                   # 變更紀錄
├── claude-code/（19 則）
│   └── index.md
├── ai-agents/（19 則）
├── threads/（12 則）
├── web-frontend/（21 則）
├── devops/（17 則）
├── macos/（15 則）
├── data-ai/（14 則）
├── networking/（11 則）
├── information-strategy/（11 則）
├── bdd-testing/（10 則）
├── openclaw/（2 則）
├── sources/（60 份，不動）
└── Review Dashboard.md

11 個主題目錄，每個有自己的 index.md。

最關鍵的一步是把 8 個 moc-*.md 轉成 OKF 的 index.md，另外 3 個原本沒有 MOC 的主題也補上了新的 index.md——不只是改檔名，而是加上 frontmatter、重寫導覽結構。每個 index.md 會有一段 "Connecting thread"，說明這包筆記之間的脈絡，讓 AI 讀完目錄就知道整個主題的知識是怎麼串起來的。

Obsidian 的 wikilink 搬了之後不會壞，因為它是靠檔名解析、不靠路徑。Dataview 的 FROM "3. Resources/Claude Secretary" 也自動遞迴子目錄。搬的成本其實很低——主要時間花在寫 index.md 的導覽跟 connecting thread。

AI 讀起來差多少

搬完之後我拿同一個問題實測：「background sub-agent 為什麼不能用 MCP tool？怎麼繞過去？」

**只靠關鍵字搜尋（搬之前的做法）：**花了 10 次工具呼叫（8 次搜尋 + 2 次讀檔）。中間 4 次搜尋撲空——因為筆記裡寫的是 "sub-agent"，搜 "subagent" 就找不到。搜 "MCP" 回來 234 筆，大部分無關。最後是在一篇 daily content（Day 55）裡翻到答案的。

**用 OKF 的 index.md 導覽：**3 次讀檔。根目錄 index.md → claude-code 的 index.md → 直接讀到 foreground-vs-background-sub-agents.md。零撲空、零噪音，每一步都知道下一步該去哪。

同一個問題，10 次 vs 3 次，差 3 倍多。 關鍵差異不是「AI 讀不讀得到」——都讀得到——而是 OKF 的 index.md 給了 AI 一張地圖：從哪裡開始、每個主題下有什麼、它們之間的脈絡是什麼。沒有這張地圖，AI 只能靠關鍵字碰運氣。

值不值得搬

看你的筆記庫多大、你有沒有在用 AI agent 讀它。

如果你的 Obsidian vault 主要是自己翻，不接 AI，搬不搬差別不大——你已經有自己的組織方式。

如果你像我一樣，讓 Claude Code 的 MCP server 直接查筆記庫，或者未來想讓不同 AI 工具讀同一包知識——OKF 的結構會省掉很多 AI 在那邊瞎猜你筆記邏輯的時間。

規則就兩條：每個 .md 有 frontmatter 裡的 type，目錄頁叫 index.md。門檻低到可以一個下午搬完 150 則筆記。

OKF 不是要你換筆記軟體，是讓你現有的 Markdown 筆記多一層 AI 也讀得懂的結構。

最近開始做免費的一對一諮詢，幫你把 AI 接進自己的工作流——有需要的話可以約：https://www.dawsonwang.com/

Karpathy LLM Wiki gist：https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f OKF v0.1 Spec：https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md OKF 官方介紹：https://okf.md/spec/ Google Cloud Blog：https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing

用 OKF 重整 Obsidian 筆記庫