Chris 筆記｜第二大腦不是儲存系統，是編譯器

我的想法

我很久之前就做了 RAG，的確讓我的 RAW materials 看起來更加方便整理了，然後之前聽了 Karpathy 的分享，也開始建構多個 LLM Wiki，的確這給我的知識圖譜又上了一個臺階。但是隨着 LLM wiki 的數量越來越多，要逐一管理進行更新，總是有遺漏或忙忘的時候，LLM wiki 就有可能變成倉庫的可能。

這一篇文章提到"編譯"這點，想法很好也值得學習，可以通過在 Claude Code 中安排 cron 排程的方式，讓它每隔一段時間就重新編譯一次，這樣會讓新的資料與舊的詞條，再次發生關聯，這點今天就立刻去作。

摘要 / Summary

大多數人打造第二大腦時把它當成檔案櫃：筆記丟進去，需要時再搜尋，祈禱對的東西會浮現。這篇文章指出那只是「檢索」，而檢索有天花板。Karpathy 在 2026 年 4 月描述的 LLM Wiki 想法幾天內傳遍 GitHub，核心區別是：圖書館會隨時間變大，編譯器則會變得更聰明。RAG 系統在每一次查詢時都重新付出理解的代價，編譯過的 wiki 只在攝入時付一次代價，之後每次查詢取用的都是模型建構並維護好的、結構化、互相連結的知識。

架構很簡單：三個資料夾（raw 是輸入緩衝區、wiki 是編譯發生的地方、output 從已編譯的知識建構），一個檔案（CLAUDE.md，模型持續維護並在每個工作階段開頭讀取的活文件），一個迴圈——每份新來源被攝入、連結、整合進既有結構，系統再寫一份簡報說明改了什麼、為什麼改。文章也誠實點出限制：品質完全取決於來源品質，一份壞來源在圖書館裡容易移除，但在編譯器裡可能已經觸及十五個頁面才被發現；密度不夠時（大約要 50 到 100 份編譯良好的來源之後）連結才會開始浮現非顯而易見的關聯，之前一個好搜尋引擎大概就做得到同樣的事；而且這套流程需要 Claude Desktop 與付費方案才跑得動排程與檔案系統存取。

文章最後給了四段可以直接拿去用的提示詞：攝入新來源、建構 CLAUDE.md、建立專案資料夾、設定每日編譯迴圈，訴求是把「維護負擔」從人類轉移給模型——人類保留的是選擇來源、決定研究方向、監督綜整結果這些不可簡化的部分。

重點 / Keypoint

「RAG 在每一次查詢時都重新推導知識。編譯過的 wiki 只推導一次，然後保持它是最新的。」

Karpathy 直接點名這個問題：「收集資訊這個動作毫不費力。但要把五十則互相連結的筆記維持在最新、一致、交叉引用的狀態，是沒有人能持續下去的工作。」

檢索回答問題，編譯建構理解。