我在 Notion 裡存了 4,217 篇剪藏文章，Obsidian 有 1,800 條雙向連結，Readwise 累積了 12,000 條高光。全部複習一遍要 83 小時。結果 4 月 3 日 Karpathy 在 X 發的那條 1,600 萬觀看的推文告訴我：這三個工具可能一個都不需要。
他的原話：最簡單、也最強的 LLM 知識庫，就是一個裝滿 markdown 檔案的 wiki 目錄。沒有 RAG，沒有向量資料庫，沒有花俏的 plugin。把整個目錄直接塞進 LLM 的 context window，讓模型一次讀完全部內容再回答問題。
我用一週時間真的把三個工具的內容搬出來，整理成一個 markdown wiki 丟給 Claude Sonnet 4.6。這篇文章就是那個實驗的完整過程——目錄結構、三條可以複製的 prompt、一週後的真實觀察、和三個工具的成本對比表。
Karpathy 的 LLM 知識庫方法，到底在講什麼？
Andrej Karpathy 是前 OpenAI 創始成員、前 Tesla AI 總監、nanoGPT 作者。他在 4 月 3 日的推文裡提出一個主張：個人知識庫不該存在 Notion 或資料庫裡，而該是一個乾淨的 markdown 目錄結構，例如：
wiki/
people/
karpathy.md
sama.md
concepts/
transformers.md
rlhf.md
attention.md
projects/
nanoGPT.md
llm-c.md
reading-notes/
2026-04-books.md
Karpathy 自己的 wiki 大約 100 篇檔案、40 萬字。他的做法是把整個目錄當成 context 一次餵給 LLM，不切 chunk、不做 embedding、不用 RAG。Claude Sonnet 4.6 的 200K token 上下文可以一口氣吃下大約 60 萬中文字，GPT-5 的 Long Context 更寬。40 萬字塞進去還有餘裕。
這個做法的威力在於「跨筆記推理」。你問：「我讀過的書裡，哪幾位作者對注意力機制的觀點是互相矛盾的？」RAG 只會撈相似段落，Notion AI 只看當前頁，但把整個目錄作為 context，LLM 可以同時比對 Dennett、Hofstadter、Karpathy 的筆記，給你一個真正的對照分析。
為什麼 Notion、Obsidian、Readwise 都沒解決這個問題？
三個工具我都付費用了超過五年。客觀講每一個在單點功能上都做得很好，但沒有一個能回答「跨筆記的問題」。差異點在下面這張表：
| 維度 | Notion | Obsidian | Readwise | LLM 知識庫 |
|---|---|---|---|---|
| 儲存模型 | 資料庫 | Markdown | 高光片段 | Markdown 目錄 |
| 跨筆記推理 | 弱（AI 看單頁） | 無（要裝 plugin） | 無 | 強（原生支援） |
| 語意查詢 | 全文 match | 插件實作 | 半年前才加 | 自然語言直接問 |
| 匯出方便性 | 難（格式混亂） | 原生 markdown | 有 export | 本身就是檔案 |
| 月費 | 10 美元 | 免費 | 11.99 美元 | 20 美元（Claude Pro） |
關鍵是「儲存模型」那一列。Notion 把所有內容鎖在自己的資料庫格式裡，匯出時連連結都會斷掉。Obsidian 的 markdown 雖然乾淨，但雙向連結依賴人工維護，一兩年後就成了亂七八糟的 graph。Readwise 的問題更根本——它只存「句子」，沒有存「觀點」，高光之間沒有結構關係。
我的遷移實驗：7 天從三個工具搬到一個目錄
下面是完整的時間表和三條可以直接複製的 prompt。整個遷移過程一個人做完，不需要寫程式，只要會複製貼上。
Day 1：把三個工具的內容全部匯出
Notion 用「Export as Markdown & CSV」匯出整個 workspace，得到一個 zip 檔。Obsidian 本來就是 markdown 可以直接複製。Readwise 後台的「Export to Markdown」可以一鍵把所有 highlights 導出成一個大檔案。三者合起來我拿到 6,200 個 .md 檔，總共 41 萬字。原始結構亂到不能看——Notion 導出會把每篇文章包進一層深的資料夾路徑，檔名還帶亂碼。
Day 2-3：用 LLM 產生目錄結構
把前 200 個檔案的檔名和每檔前 500 字塞給 Claude，讓它幫忙設計目錄結構。這一步是整個實驗最關鍵的，目錄設計決定了後面的查詢效率。Prompt 如下：
你是個人知識管理顧問。下面是我 200 篇筆記的檔名和前 500 字摘要。 請幫我設計一個 markdown wiki 目錄結構，要求： 1. 最多三層（top/mid/leaf） 2. top 層不超過 8 個資料夾 3. 每個資料夾要有明確的邊界，避免灰色地帶 4. 輸出格式用 tree 指令的縮排形式 5. 每個 top 資料夾後面用一句話解釋收納原則 輸入： 這裡貼檔名和摘要
Claude 給我的結構跟我自己想了五年的分類完全不一樣。它建議用 people / concepts / books / essays / projects / daily-notes / meta 七個 top 資料夾。我原本堅持的「by date」分類被它直接砍掉，理由是時間戳用檔名記就夠了，資料夾不該承擔時間屬性。
Day 4-5：增量歸檔與手動校對
剩下的 6,000 個檔案用這條 prompt 批次分類：
目錄結構：貼上 Day 2 產出的樹狀圖 任務：幫下面這批檔案決定存放位置。每個檔案輸出三個欄位： - filename（原檔名） - target_path（目標路徑） - reason（一句話理由） 如果檔案內容太弱、或是純 highlight 沒上下文，標 "archive/"。 輸入：一批 50 個檔案的內容
每批 50 個檔案跑一次，大約兩天跑完。產生 archive 的有 1,400 個，大部分是 Readwise 的零散高光。我原本以為這些高光是寶藏，結果 Claude 一針見血：「脫離上下文的單句高光對推理沒有幫助」。後來也證明留下的 4,800 篇才是真正有分析價值的內容。
Day 6-7：實戰查詢測試
查詢階段用的 prompt 很直接，不需要任何技巧：
下面是我過去五年的讀書與研究筆記，共 4,800 篇 markdown 檔案， 已整理成 wiki 目錄結構。請基於這些筆記回答我的問題， 引用時標註來源路徑（例如 concepts/attention.md）。 目錄樹 + 全部檔案內容 問題：你的問題
我測試的第一個問題是：「我讀過的書裡，哪幾位作者對『直覺』的定義互相矛盾？列出原文引用。」Claude 用 4 分鐘給了一個四行對照表，引用了 Kahneman、Klein、Dennett、Taleb 的原文——這是我過去五年在 Notion 裡搜尋「intuition」永遠做不到的事，因為 Notion 的搜尋是關鍵字 match，而這四位作者分別用 intuition、expert cognition、heterophenomenology、via negativa 四個不同詞彙在討論同一件事。
一週後的三個真實發現
發現一：資料變多查得更準，這違反我的直覺。在 Notion 時代，筆記越多越難找，因為搜尋命中率被稀釋。但在 LLM 知識庫裡，資料越多反而越能給出細緻的 synthesis——因為模型可以交叉比對的素材更豐富。這顛覆了「定期清理筆記」這個 PKM 界的教條。
發現二：我的舊想法被 LLM 打臉很多次。問 Claude「我的筆記裡有沒有前後矛盾的觀點」，它給出的第一個例子是 2022 年我認為「long-form content 已死」，但 2024 年的筆記裡又引用數據支持 long-form 回潮。這種時間線上的自我矛盾，自己讀一萬遍筆記也看不出來，LLM 一次查詢就揪出來。
發現三：Markdown 的約束力比想像中強。Notion 的 block 可以無限嵌套，結果我寫筆記越寫越花俏，到後來連自己都不想翻。改用純 markdown 之後，格式被限制住，思考反而更聚焦。Karpathy 在推文裡講的「constraint breeds clarity」完全不是雞湯。
三個必須知道的 caveat
這套方法不是沒有代價。實測一週後，我列出三個要提前知道的問題：
第一是 token 成本。以 Claude Sonnet 4.6 輸入 3 美元/百萬 token 為例，41 萬字的知識庫單次查詢輸入約 32 萬 token，單次成本約 0.96 美元。一個月 50 次深度查詢等於 48 美元。如果訂閱 Claude Pro（20 美元/月）可以覆蓋大部分用量，但會被速率限制卡住。重度使用者要有心理準備。
第二是隱私問題。把五年份的個人筆記整個上傳到雲端 LLM，不是每個人都能接受。Anthropic 和 OpenAI 的 API 條款都聲明不用 API 資料訓練，但心理門檻還是在。如果筆記裡有客戶資訊、醫療紀錄、或跟家人朋友有關的敏感內容，建議先用本地模型（例如 Llama 4 Scout 在 M3 Max 上可以跑）過濾一輪再上傳。
第三是長期累積後需要重建目錄。知識庫成長到某個規模（大約 200 萬字之後）會超出主流 LLM 的 context 長度，這時候要把目錄拆成幾個子集分開查詢，或是等下一代 1M token 模型普及。這是方法論的物理上限，目前還沒有完美解法。
三個 PKM 工具 vs LLM 知識庫：兩年總成本
| 方案 | 兩年訂閱費 | 查詢能力 | 離線可用 |
|---|---|---|---|
| Notion + Obsidian + Readwise | 約 528 美元 | 關鍵字 match | 部分 |
| Notion AI 全家桶 | 約 768 美元 | 單頁語意 | 不支援 |
| Claude Pro + markdown 目錄 | 480 美元 | 跨筆記推理 | 不支援 |
| Claude API 按量付費 | 約 1,150 美元 | 跨筆記推理 | 不支援 |
意外的是 Claude Pro + markdown 目錄反而是最便宜的組合。代價是 Claude Pro 有訊息次數上限，如果查詢很頻繁會被卡，這時候升到 API 付費會跳到最貴——但跨筆記推理的能力是真正無可取代的。
這套方法適合誰、不適合誰？
適合：讀過 100 本以上非小說書的重度讀者、長期寫專業文章的創作者、做跨領域研究的學者、需要從海量個人資料裡找 pattern 的顧問或分析師。共同特徵是「知識資產會被反覆查詢使用」。
不適合：把筆記當成打卡工具的人（每天記但從不翻回來看）、隱私極度敏感不願把內容上雲的使用者、筆記量還不到 500 篇的初學者（這個規模用 Notion 就綽綽有餘）。小筆記量用大模型是殺雞用牛刀。
結論：PKM 的範式正在轉移
過去十年的 PKM 工具全部建立在一個假設上：人類用軟體組織知識，軟體負責存。Notion 的雙向連結、Obsidian 的 graph view、Readwise 的 spaced repetition，本質上都是幫人類建立「人工索引」的輔助工具。
Karpathy 這條推文的意義在於把這個假設反過來：LLM 負責組織，markdown 只負責存，人類只負責問問題。軟體從「倉庫 + 索引工具」變成「會思考的圖書館員」。當你的知識庫到達某個規模後，這個新架構的效率會把舊架構甩開好幾個量級。
我不是說大家明天就該把 Notion 刪掉。但如果你也累積了五年以上的筆記，又感覺「知道得越多反而越難用」，建議找一個週末試試這套流程。最多 7 天，你會知道自己過去花在人工組織上的時間，有多少是 LLM 可以直接替你承擔的。
常見問題 FAQ
Karpathy 的 LLM 知識庫方法跟 RAG 有什麼不同？
RAG 把資料切成小 chunk 存進向量資料庫，每次查詢只撈回最相似的幾段丟給 LLM，跨 chunk 推理會斷鏈。Karpathy 的方法是把所有資料塞進一個大的 markdown 目錄，直接當成 LLM 的上下文全部載入，模型一次看見所有內容，適合做多跳推理（例如「哪兩位作者的觀點互相矛盾」）。代價是 token 費用和上下文長度限制。
筆記量要到多少才值得用這套方法？
經驗門檻大約是 500 篇以上或總字數 10 萬字以上。低於這個量用 Notion 的全文搜尋就夠，大模型的跨筆記推理能力發揮不出來。500 篇以上的時候，Notion 搜尋開始失效，LLM 方法的優勢才顯現。超過 3,000 篇之後，差距會拉開到「不可逆」的程度。
不會寫 markdown 也能用這套方法嗎？
可以。Markdown 只是用 # 表示標題、用 – 表示列表的純文字格式，5 分鐘就會。更重要的是現有 Notion、Obsidian、Evernote 筆記都支援匯出成 markdown，你不需要從頭手寫。匯出後直接丟給 Claude 或 GPT-5 整理成目錄結構就好。
本地端模型可以跑這套方法嗎？
可以，但 context 長度是瓶頸。Llama 4 Scout 支援 10M token context 可以跑大型知識庫，但硬體要求高（M3 Max 128GB 或雙 RTX 4090）。比較務實的本地方案是 Gemma 3 27B 搭配 128K context，適合 10-20 萬字規模的知識庫。隱私敏感用戶可以用這條路線。
延伸閱讀
免責聲明：本文為 AI 工具實作教學與個人經驗分享。文中引用的 Karpathy 推文發表於 2026 年 4 月 3 日，觀看數與轉推數截至發稿日。所有 prompt 範例為實測後的簡化版，讀者使用時請依自身需求調整。AI 工具的輸出品質受模型版本、上下文長度、prompt 設計影響，結果不保證一致。
發表迴響