閱讀心得：LLM Wiki

為什麼這是對的

長期以來，個人知識管理的最大痛點不是「讀不夠多」，而是「整理太麻煩」。做過知識管理的人都有經驗：一開始充滿熱情地建目錄、寫筆記、做連結，但隨著資料量增長，維護的邊際成本越來越高，最終放棄。

Karpathy 點出了一個殘酷的事實——人類不是不願意維護知識庫，而是維護的負擔增長速度超過了價值增長速度。

LLM 的出現從根本上改變了這個等式。LLM 不會厭倦更新交叉引用、不會忘記修改某個過時的段落、可以在一次操作中觸及 15 個檔案。維護成本趨近於零時，知識庫自然能持續成長。

最有共鳴的部分

「Obsidian 是 IDE，LLM 是程式設計師，維基是程式碼庫。」

這個類比非常精準。就像程式設計師（LLM）根據需求文件（Schema）撰寫程式碼（維基頁面），而產品經理（人類）決定要做什麼功能（加入什麼來源）、程式碼要有什麼品質（lint）。

值得思考的面向

1. LLM 的幻覺問題：LLM 在撰寫維基時可能產生不準確的內容，尤其當原始資料有模糊之處。Karpathy 的對策是讓維基成為 Git 倉庫——但有版本控制不代表內容正確。人類在 loop 中做 review 是必要的。

2. 規模化挑戰：文中提到數百個來源、數百個頁面仍可運作，但當 wiki 達到數千頁時，index.md 的線性掃描可能不敷使用。qmd 這樣的搜尋引擎最終會成為必需品。

3. 共同演化的 Schema：這是整份文件中可能最被低估的部分。好的 schema 文件是 LLM Wiki 成敗的關鍵——它需要隨著使用經驗不斷調整，找到最適合特定領域的知識組織方式。

對 Vannevar Bush Memex 的引用

1945 年 Bush 提出的 Memex——個人化、有策展的知識儲存裝置——確實比後來的全球資訊網更接近這份文件的願景。Bush 無法解決的是由誰來做維護。2025 年的今天，LLM 給出了答案。