Karpathy LLM Wiki 知識庫管理筆記
一、我與 CC 的核心工作教條
這兩天看到很多人轉那篇 Karpathy 講的，關於用 AI agent 來管理個人知識庫的文章。這其實是我第一天用 AI agent 就想做的事，而那篇文章我看完後，讓我對於一些邊界的東西又想得更清楚了。
於是，經過與 Claude Code（CC）的一番討論後，我們現在的運作核心教條如下。這次是在原本的四條之外，又加了第五條。
- 語言：台灣繁中。
- 語調：要理性，不要客套話。
- 在回答之前，先用精確的領域術語重述問題。
- 推理過程：先提出反對論點，再加以反駁，最後得出結論。
- Wiki vault 就是 CC 的私人維基百科。當 CC 進行工作時，會自動儲存成 wiki 的 md 檔案。Copper 提出問題時，CC 就會從中檢索並回答。Note 是 Copper 學習用的，而 wiki 則是 CC 所知道的知識。整個過程會自動迭代，不需要額外批准。
我編輯的是位在 ~/.claude 資料夾下的 CLAUDE.md 檔案。這是所有對話開啟或重新整理時，都會被自動注入的文件。我把檔案最開頭的部分，設定為最高規格的法條。
第五條目前定義 md 檔案為知識庫內的一等公民，只有它的存在是要被正視且可搜索的。然後 md 檔案分成兩類，一類是 wiki，另一類是 note。前者由機器讀取、機器維護，是機器對機器的模式。後者則是給人類閱讀，以及人機共同維護，機器幫忙做結構化和正規化。
所有參考檔案都會留在知識庫裡面可以查得到。PDF 檔入庫後，會自動進行光學字元辨識，再批次轉成 md 檔案。所有的筆記都伴隨側邊檔案，在側邊檔案裡面就可以查到對應的原始 PDF。
這個架構的重點就是 LLM 以及本地端的文檔，Obsidian 只是一個好用的資料管理工具，但不是必備，也可隨時被替換。AI Agent 也是隨時可被替換的。
二、Karpathy 的 LLM 知識庫做法，以及我的類似實踐
Andrej Karpathy 最近分享了一個他認為非常實用的做法：用 LLM 來建立和維護個人知識庫。
他把各種研究資料收集到一個目錄中，讓 LLM 自動「編譯」成一個 markdown wiki，包含摘要、分類、概念文章和交叉連結——然後在這個 wiki 上進行問答、產出簡報、圖表，甚至反過來用 LLM 做「健康檢查」來持續提升資料品質。
這篇貼文一出，不少科技圈的人紛紛表示自己也有類似的做法。「讓 LLM 幫你管理知識」正在從少數人的 hack 變成一種新的工作典範。
我自己也有類似的做法。我現在會在一個文件夾下，把公司相關的所有資料——市場研究、專案規劃、競品分析、客戶紀錄、工作日誌——全部用 markdown 文件有序地儲存在不同的子目錄裡，並且維護 index 文件來說明「去哪裡找什麼」。
這整個目錄結構就是我的 Knowledge Base。然後透過 Claude Code，直接在這個 Knowledge Base 上面工作：問任何問題、做市場分析、產出簡報、進行新的研究、產生合約文件，完成後再把產出存回知識庫。
Knowledge Base 就這樣不斷地累積和成長，每一次的使用都讓它變得更完整、更有價值。
重點是：你不需要複雜的 RAG 架構就能做得很好。 只要目錄結構清楚、有好的索引，LLM 就能在這個規模下輕鬆找到需要的資訊。效率非常高，門檻也很低。
三、Karpathy LLM Wiki 深度解析 + PR 變成 Prompt Request
Andrej Karpathy 用 LLM 做知識庫管理的議題非常火熱。今天 Karpathy 把上次的 LLM 知識庫想法寫成了 idea file，不寫程式碼、不寫實作文件：Karpathy 認為分享想法的方式也該變了，從 Pull Request 到 Prompt Request，整串內容看他聊 AI 怎麼改變知識管理和軟體開發的可能方向。
第一個是他寫了一份叫 LLM Wiki 的「idea file」，講怎麼用 LLM 建個人知識庫。第二個是他在這篇 X 下面回覆轉述龍蝦爸 Peter Steinberger 的觀點，說現在的 PR（Pull Request）應該變成 Prompt Request，LLM 時代的很多做事方式正在改變。
LLM Wiki：讓 AI 幫你「養」一座知識庫
大多數人用 LLM 處理文件的方式是 RAG：丟一堆文件進去，問問題的時候 LLM 去撈相關片段，組出答案。NotebookLM、ChatGPT 的檔案上傳，基本上都是這個模式。這模式能用，但有個根本問題：每次問問題，LLM 都在從零開始拼湊。問一個需要綜合五份文件的問題，它每次都得重新找、重新接。沒有東西被累積下來。
Karpathy 的想法不一樣。他說與其讓 LLM 每次都從原始文件裡撈，不如讓 LLM 持續地建立和維護一座 wiki。你丟一份新資料進去，LLM 讀完之後，把重點整合進現有的 wiki 頁面裡，更新實體頁、修改摘要、標記新舊資料的矛盾、補上交叉引用。知識被編譯一次，然後持續更新，而不是每次查詢都重新推導。
他自己的做法是一邊開 LLM agent，一邊開 Obsidian。LLM 根據對話內容編輯 wiki，他在 Obsidian 裡即時瀏覽結果、看 graph view、追連結。用他的比喻：Obsidian 是 IDE，LLM 是工程師，wiki 是 codebase。
三層架構
他把整個系統分成三層：
- Raw Sources：你收集的原始資料（文章、論文、數據），LLM 只讀不改。
- Wiki：LLM 產生和維護的 Markdown 檔案，摘要、實體頁、概念頁、比較表、綜合分析，全部由 LLM 負責寫和更新。
- Schema：一份設定檔（像 Claude Code 的 CLAUDE.md），告訴 LLM 這座 wiki 的結構慣例、命名規則、工作流程。
搭配三個主要操作：
Ingest（資料匯入）：不只是丟檔案進去而已，過程中會讀取內容、清理格式、轉換成系統能用的結構，然後存好。在 LLM Wiki 的脈絡裡，Ingest 就是你丟一份新資料給 LLM，它讀完之後擷取重點，可能一次更新十幾個 wiki 頁面。
Query（查詢）：對 wiki 提問，LLM 找到相關頁面後綜合出答案。好的回答本身也有保存價值，可以直接存成新的 wiki 頁面，讓你的提問也變成知識庫的一部分。
Lint（健康檢查）：Lint 原本是程式開發的術語，指用工具自動掃描程式碼，找出語法錯誤、風格不一致、潛在 bug 這類問題。Karpathy 把這個概念借來用在 wiki 上：定期讓 LLM 掃一遍整座知識庫，找出頁面之間的矛盾、被新資料取代的舊結論、沒有任何連結指向的孤兒頁面、提到了但還沒建立獨立頁面的重要概念。
最有價值的 Insight
這個想法最有價值的 insight 是：維護知識庫最煩的事從來就是 bookkeeping。更新交叉引用、保持摘要跟最新資料同步、標記新舊資訊的衝突、維護頁面之間的一致性。人類會放棄 wiki，是因為維護成本的增長速度超過它帶來的價值。LLM 不會煩，不會忘記更新某個引用，一次可以動十幾個檔案。人的工作是挑選資料來源、問對問題、思考這些東西加在一起代表什麼意思。LLM 負責剩下的苦工。
他也提到這個概念跟 1945 年 Vannevar Bush 提出的 Memex 很像，一個有關聯路徑的個人知識庫。Bush 這概念無法解決的部分是由誰來維護，而 LLM 解決了這個問題。
這份文件本身就是示範
Karpathy 在最後特別說了一段話，他說這份文件故意保持抽象，只負責傳達概念，不給具體實作。目錄結構、命名規則、頁面格式、要用什麼工具，全部取決於你的領域和偏好。所有提到的東西都是可選、模組化的，挑有用的拿，不需要的跳過。
正確的用法是：把這份文件丟給你的 LLM Agent，然後跟它一起合作，實作出一個符合你需求的版本。這份文件唯一的工作就是把 pattern 講清楚，剩下的讓 LLM 去搞定。
他沒有寫一個完整的 GitHub repo 附帶安裝教學和範例專案，而是寫了一份 idea file，設計成可以直接貼給任何 LLM Agent 的格式。因為在 Agent 的時代，分享一個想法不再需要附上完整的程式碼和設定，你只需要把概念講清楚，Agent 會幫你把剩下的部分建出來。文件的形式本身就在實踐它描述的那個世界。
PR 變成 Prompt Request
第二個想法來自 Karpathy 在 X 上的討論。他轉述了 Peter Steinberger 的觀點：以後開發者提交的應該是 Prompt Request，不是 Pull Request。
PR（Pull Request）是工程師寫完一段程式碼之後，先發一個「請求」給團隊，說「我寫了這段，請幫我看看能不能合併進去」。其他工程師會審查這段程式碼，給意見、抓 bug，確認沒問題之後才正式合併。可以把它想成交作業之前先讓同事幫你檢查一遍。
背景是這樣的：現在越來越多人用 AI 寫程式碼，然後直接發 PR。問題是這些 AI 生成的程式碼品質參差不齊，審查的人要花大量時間去讀 Claude 或 ChatGPT 拼出來的東西。
Steinberger 的想法是：既然 AI Agent 已經有能力實作大部分想法，開發者根本不需要自己先把想法硬寫成程式碼再交出去。直接提交你的 prompt 就好。描述你要什麼、怎麼做、需要注意什麼，讓負責審查的人（或他們的 Agent）根據這個 prompt 重新生成、review、再合併。
這個討論串底下的回應也蠻有意思的：
- 有人說一個好的 prompt request 需要寫得夠精確，精確到審查者能清楚理解它會怎麼影響 codebase。但到了那個精確程度，prompt 本身跟程式碼也差不多了。
- 也有人指出，prompt request 的說法其實是把 PR 的本質從「審查程式碼」轉移成「審查規格」。大多數 PR comment 本來就是在討論不夠清楚的需求，而不是在討論程式碼本身。
- 也有人觀察：在大企業裡，以後衡量生產力的方式可能會從「這週你發了幾個 PR」變成「這週你發了幾個 prompt request」。與其計算 token 用量，不如算你產出了多少有品質的 prompt。
總結
這兩個想法放在一起，指向一個共同的趨勢：人在工作流裡的角色正在從「執行者」移向「策展者」和「提問者」。
- LLM Wiki 裡，人不寫 wiki，人選資料、問問題、決定方向。LLM 做所有的整理和維護。
- Prompt Request 裡，開發者不寫程式碼，開發者描述意圖和規格，Agent 負責實作。
把人從重複性的苦工裡抽出來，讓人專注在判斷和方向上。聽起來很理想，實際上能不能走通，取決於 LLM 的執行品質什麼時候穩定到可以被信任。目前看來，這個距離正在快速縮短。