10 萬人收藏了@karpathy的這篇文章：
然後他釋出了一個完整的 GitHub Gist。5,000+ 顆星星。1,400+ 次複製。兩天之內。
大多數人也會收藏那篇文章，然後什麼都不做。
不是因為它很難，而是因為沒人給他們確切的提示詞。
我來解決這個問題。
我會帶你走過整個系統，給你每一步可直接複製貼上的提示詞，並告訴你這個方法在什麼情況下會失效——這樣你就不會浪費一個週末在一個規模擴大時就會崩潰的東西上。
「人類的工作是策劃來源、引導分析、提出好問題、思考一切背後的意義。LLM 的工作則是其他所有事。」—— Andrej Karpathy
概念（60 秒版）
你的知識散落在各處。在 4 個不同的 App 裡儲存了文章。2023 年的書籤你永遠不會再打開。會議筆記存在一個你早就忘記的資料夾裡。
現在，當你向 AI 詢問關於你資料的問題時，它每次都從零開始。上傳文件、問問題、獲得答案。下一次對話？它已經忘記了一切。這就是 ChatGPT 檔案上傳、NotebookLM 和大多數 RAG 系統的運作方式。零累積。
Karpathy 的想法翻轉了這個模式。
與其讓 AI 每次都搜尋你的原始檔案，不如讓 AI 讀取你的來源一次，然後編纂一個結構化的 Wiki。包含摘要、交叉引用、想法之間的連結、標記出的矛盾。
全部由 AI 維護。全部是簡單的 Markdown 檔案。
下次你問問題時，AI 不需要挖掘原始文件。它直接讀取它已經建立好的 Wiki。
連結已經存在。
綜合分析已經反映了你讀過的一切。
你新增的每個來源都讓 Wiki 更豐富。你問的每個問題都可以再存回 Wiki。知識會複合成長，而非每次都重設。
他的成果：大約 100 篇文章，約 40 萬字，集中在一個研究主題上。他一個字都沒寫。AI 編寫、連結、分類並維護了這一切。
沒有資料庫。沒有 Embedding。沒有向量儲存。只有資料夾和文字檔案。
為什麼你應該在乎？
三個現在就對你有用的使用情境：
如果你是創作者或行銷人員，這是一個內容研究引擎。將競爭對手分析、熱門文章、受眾洞察丟進 raw/ 資料夾。Wiki 會浮現你手動找不出來的模式和觀點。
如果你是創業者或顧問，這是你在客戶工作、市場研究或競爭分析上的第二個大腦。你產出的每份報告都會回饋到系統中。三個月後，你的 AI 對你領域的了解會勝過大多數新進員工。
如果你是學生或研究人員，這正是 Karpathy 實際打造它的目的。深入研究數十篇論文，讓 AI 追蹤想法如何連結、作者們在哪裡分歧、以及哪些缺口仍然存在。
*這也可以用於許多商業研發工作流程。
在開始建構之前：你需要什麼
→ 任何能讀取本地檔案的 AI 程式碼工具（Claude Code、Cursor、Codex 或類似工具）
→ 一個文字編輯器（建議使用 Obsidian，但 VS Code、記事本等任何工具都可以）
→ 10 份以上你有興趣的主題的來源文件
→ 初始設定 30 分鐘，之後每新增一個來源 10 分鐘
就這樣。不需要特殊軟體。不需要建立帳號。不需要安裝外掛程式。
本文的其餘部分是建構過程。7 個步驟。每個步驟都有你將貼進 AI 的確切提示詞。請依序執行。
步驟 1：建立資料夾結構（2 分鐘）
在你的電腦上任何地方建立這個結構：
1my-knowledge-base/2├── raw/ # 你的原始素材。AI 會讀取但絕不修改。3│ └── assets/ # 圖片、螢幕截圖、圖表4├── wiki/ # AI 維護的 Wiki。你閱讀。AI 撰寫。5├── outputs/ # 查詢產生的報告、分析、答案6└── CLAUDE.md # 讓整個系統運作的設定檔
三個資料夾，一個檔案。如果你在這裡花超過 2 分鐘，那就是想太多了。
步驟 2：撰寫你的設定檔（每個人都會跳過的步驟。別這麼做。）
設定檔是區分一個通用聊天機器人和一個有紀律的 Wiki 維護者的關鍵。
它告訴你的 AI 知識庫的主題是什麼、如何組織內容、以及當你新增來源、提出問題或執行維護時該做什麼。
其他指南只會給你一個 10 行模板。這裡是完整的正式版設定檔，基於 Karpathy 的 Gist 修改，專為實際使用而設計：
1# 知識庫設定檔23## 身份4這是一個關於 [你的主題] 的個人知識庫。5由 LLM Agent 維護。人類負責策劃來源和提出問題。LLM 負責所有其他事項。67## 架構8- raw/ 包含不可變的原始文件。絕不修改 raw/ 中的檔案。9- wiki/ 包含編纂好的 Wiki。LLM 完全擁有這個目錄。10- outputs/ 包含產生的報告、分析和查詢答案。1112## Wiki 慣例13- 每個主題在 wiki/ 中有一個獨立的 .md 檔案14- 每個 Wiki 檔案以 YAML 前置資料開頭：15 ---16 title: [主題名稱]17 created: [日期]18 last_updated: [日期]19 source_count: [為此頁面提供資訊的原始來源數量]20 status: [draft | reviewed | needs_update]21 ---22- 前置資料之後，是一個段落的摘要23- 使用 [[主題名稱]] 進行 Wiki 頁面之間的內部連結24- 每個事實性主張都要引用其來源：[來源: 檔案名稱.md]25- 當新資訊與既有內容矛盾時，明確標記：26 > 矛盾：[舊主張] vs [新主張] 來自 [來源]2728## 索引與日誌29- wiki/index.md 列出每個頁面，附上一行描述，並依分類排列30- wiki/log.md 是僅可附加的按時間順序記錄31- 日誌條目格式：## [YYYY-MM-DD] 動作 | 描述32 （動作：ingest、query、lint、update）3334## 引入工作流程35處理新來源時：361. 讀取完整的原始文件372. 與使用者討論關鍵要點383. 在 wiki/ 中建立或更新摘要頁面394. 更新 wiki/index.md405. 更新 Wiki 中所有相關的實體與概念頁面416. 從既有頁面新增反向連結到新內容427. 標記任何與既有 Wiki 內容的矛盾438. 在 wiki/log.md 中附加條目449. 一個來源應觸及 10-15 個 Wiki 頁面4546## 查詢工作流程47回答問題時：481. 先讀取 wiki/index.md 以找出相關頁面492. 讀取所有相關的 Wiki 頁面503. 合成答案，附上 [來源: 頁面名稱] 的引用514. 如果答案揭示了新的見解，提議將其存回 wiki/525. 將有價值的答案儲存到 outputs/5354## 維護工作流程（每月）55檢查：56- 頁面之間的矛盾57- 被較新來源取代的過時主張58- 沒有入站連結的孤立頁面59- 被提及但從未解釋的概念60- 遺漏的交叉引用61- 沒有來源歸屬的主張62輸出：wiki/lint-report-[日期].md，附嚴重程度等級6364## 重點領域65[列出這個知識庫涵蓋的 3-5 個主題]
複製這段內容。自訂重點領域。將它放在你的專案根目錄，命名為 CLAUDE.md。
步驟 3：填滿你的 Raw 資料夾（10 分鐘的傾倒，零整理）
打開 raw/ 資料夾，把所有東西扔進去：
→ 將文章複製貼上成 .md 或 .txt 檔案
→ 從你目前使用的任何應用程式匯出筆記
→ 將螢幕截圖和圖表儲存到 raw/assets/
→ 貼入研究論文、PDF、競爭對手分析
→ 丟進你囤積了好幾個月的書籤
不要整理。不要重新命名。不要清理。那是 AI 的工作。
Karpathy 的小提示：Obsidian Web Clipper 瀏覽器擴充功能可以一鍵將任何網頁文章轉換為 Markdown。
設定一個快捷鍵（設定 → 快速鍵 →「下載附件」）來將所有圖片拉到本地端，讓 AI 可以參考它們。
如果你不使用 Obsidian，從瀏覽器直接複製貼上也完全沒問題。
目標是數量，不是完美。
步驟 4：執行你的第一次引入
打開你的 AI Agent。指向你的專案資料夾。貼上這個：
引入提示詞：
1「讀取 CLAUDE.md 中的設定檔。然後處理 raw/ 中的 [檔案名稱]。完整閱讀它，與我討論關鍵要點，然後：在 wiki/ 中建立摘要頁面、更新 wiki/index.md、更新所有相關的概念和實體頁面、新增反向連結、標記任何矛盾、並在 wiki/log.md 中附加條目。」
一次處理一個來源。Karpathy 也是這樣做的。閱讀摘要。檢查更新。引導 AI 應該強調什麼。這會產生比一次批次處理所有內容好得多的結果。
在 5-10 個來源之後，你的 wiki/ 資料夾就會有一個索引、一個日誌，以及 15-30 個相互連結的頁面。
那時事情就會開始運轉。
步驟 5：開始查詢你的知識庫
一旦你有 10 個以上的 Wiki 頁面，這個系統就變得真正有用了。貼上這個：
查詢提示詞：
1「讀取 wiki/index.md。根據知識庫中的內容，回答：[你的問題]。引用哪些 Wiki 頁面為你的答案提供了資訊。如果這揭示了值得保存的新連結，在 wiki/ 中建立一個新頁面並更新索引。」
最能提取價值的問題：
→「這個知識庫中最大的三個缺口是什麼？」
→「哪些來源彼此矛盾？矛盾點是什麼？」
→「根據現有內容，我接下來應該研究什麼？」
→「僅使用 Wiki 內容撰寫一篇關於 [主題] 的 500 字簡報」
→「[概念 A] 和 [概念 B] 之間存在什麼連結？」
關鍵迴圈：好的答案應該被存回 Wiki 中。
一個比較、一個分析、一個你發現的連結。
它們會像引入的來源一樣在知識庫中複合成長。
每個問題都會讓下一個答案變得更好。
步驟 6：執行每月健康檢查
這是沒有人會做的步驟。但正是這個步驟防止整個系統慢慢腐爛。貼上這個：
維護提示詞：
1「根據 CLAUDE.md 中的維護工作流程，對 wiki/ 執行一次完整的健康檢查。將結果輸出到 wiki/lint-report-[日期].md，附上嚴重程度等級（🔴 錯誤、🟡 警告、🔵 資訊）。建議 3 篇文章來填補最大的知識缺口。」
為什麼這很重要：當 AI 寫了某些稍微錯誤的內容，而你把它存回去後，下一個答案就會建立在錯誤的基礎上。
兩個月後，你會有五個頁面加強同一個錯誤。健康檢查可以在它滾雪球之前就抓住它。
每個月一次檢查。花費你十分鐘。如果你想讓系統保持可靠，這是不可妥協的。
步驟 7：讓它複合成長
這就是這個系統發揮真正價值的地方。
在持續使用 4-6 週後，你不只是在搜尋筆記。
你在查詢一個結構化的知識系統，它對你來源之間連結的理解比你還要深入。
加速複合成長的三種方法：
將探索輸出存回去：當 AI 產出你覺得有價值的比較或分析時，將它儲存到 wiki/ 或 outputs/。
Karpathy 說他自己的探索和查詢「總是在知識庫中累積」。
加入視覺化輸出：讓 AI 將答案呈現為 Markdown 表格、圖表或幻燈片簡報（Marp 格式）。
這些會變成可重複使用的資產，而不是一次性的聊天訊息。
版本控制一切：你的 Wiki 只是 Markdown 檔案。
初始化一個 Git 儲存庫。你就會擁有完整的歷史記錄、分支能力，以及復原任何 AI 搞砸的事情的能力。
好的。這就是建構過程。現在，這裡是其他人都不會告訴你的部分。
這個系統會在哪裡失效（誠實版）
這是一個新興的模式，不是一個成熟的產品。Karpathy 自己也稱之為「一堆 hacky 的腳本」，並說還有做成真正產品的空間。
在信任你的知識給這個系統之前，你需要知道這些：
上下文視窗上限。
Karpathy 的 Wiki 可以處理約 100 篇文章和 40 萬字。但即使是 128K token 的上下文視窗也僅能容納約 9.6 萬字。AI 會透過索引選擇性地讀取，這意味著它可能會遺漏某些東西。研究顯示 LLM 存在「迷失在中間」的效應，長輸入中間部分的資訊會被降低優先級。你的查詢結果會存在盲點。接受這一點。
錯誤複合。
AI 寫了一個帶有細微錯誤的 Wiki 頁面。你根據它進行查詢。錯誤進入了你的答案。你把那個答案存回去。現在兩個頁面都加強了同一個錯誤。每月的維護檢查有幫助，但執行檢查的 AI 和製造錯誤的 AI 有一樣的盲點。這是最大的風險。Karpathy 的 Gist 下一位評論者一針見血：「當輸出被存回去時，錯誤也會複合成長。」
幻覺並不會消失。
Wiki 方法因為 AI 將答案根植於你的來源，所以減少了幻覺。但它並沒有消除幻覺。AI 仍然可能綜合出在來源素材中不存在的連結。而且因為 Wiki 看起來很權威（乾淨的 Markdown、交叉引用、引用），你更容易信任錯誤的資訊。別這麼做。
成本不是零。
每次引入、每次查詢、每次維護檢查都會消耗 Token。一個觸及 10-15 個頁面的來源，使用前沿模型可能花費 2-5 美元的 API 費用。50 個來源光是引入就要 100-250 美元。比一個研究助理便宜。但絕非免費。
它無法擴展到企業級。
Karpathy 說這種索引檔案方法在約 100 篇文章時可以不用 RAG。當來源超過 10,000 個時，這個模式就會失效。索引會變得太大。數千頁之間的一致性變得不可能。你將需要這個系統試圖避免的基礎設施。要知道它的天花板。
單一模型的盲點。
你整個 Wiki 只是一個模型對你來源的詮釋。那個模型有它的偏見和傾向。對於高風險的決策，一位 Gist 的評論者建議獨立地透過 4 個以上的模型執行查詢，然後比較一致性。這樣更穩健。成本也是 4 倍。
該怎麼應對
→ 錯誤複合：每月執行維護檢查。手動交叉檢查關鍵主張。在高風險決策上絕不盲目信任 Wiki。
→ 上下文限制：每個 Wiki 專注於一個領域。多個領域？就用多個知識庫。
→ 成本：使用前沿模型進行引入和複雜查詢。使用較便宜的模型進行簡單更新。
→ 幻覺：上述設定檔要求每個主張都要有來源引用。如果一個頁面做出了沒有 [來源: 檔案名稱] 的主張，維護檢查會標記它。
→ 擴展性：接受這是一個個人工具，不是企業基礎設施。如果你超出了它的能力範圍，那是個好問題。
為什麼它仍然重要
儘管有上述所有問題，這仍然是目前最實用的個人知識系統。
原因非常簡單：人類會放棄 Wiki，因為維護的負擔成長速度比價值快。
你開始整理，前兩週感覺很棒，然後維持動力讓你疲憊，你再也沒碰過它。
LLM 不會感到無聊。它們不會忘記更新一個交叉引用。它們可以在一次處理中觸及 15 個檔案而不抱怨。
Lex Fridman 確認他也在運行類似的設定。
他會產生互動式 HTML 視覺化，並建立「迷你知識庫」載入語音模式，在 7-10 英里的跑步中使用。
來自 DAIR.AI 的 Elvis Saravia 一直在為 AI 研究策劃建立 LLM 知識庫。
在 Karpathy 的 Gist 發布後的 48 小時內，多個開源實作已經上傳到 GitHub。
這不再只是一個實驗。
對於任何進行嚴肅研究的人來說，這正成為標準做法。
你的完整提示詞庫（全部複製）
本文中每一個提示詞，集中放在這裡：
設定檔：從步驟 2 複製完整的 CLAUDE.md 模板。
引入（單一來源）：
1「讀取 CLAUDE.md 中的設定檔。處理 raw/ 中的 [檔案名稱]。完整閱讀它，與我討論關鍵要點，然後：建立摘要頁面、更新索引、更新所有相關頁面、新增反向連結、標記矛盾、記錄引入。」
引入（批次，較少監督）：
1「讀取 CLAUDE.md。依序處理 raw/ 中所有未處理的檔案。針對每個檔案：建立摘要、更新索引、更新相關頁面、記錄引入。自動執行。」
查詢：
1「讀取 wiki/index.md。回答：[問題]。引用 Wiki 頁面。如果這個答案值得保存，提議將它建立為一個新的 Wiki 頁面。」
維護：
1「根據 CLAUDE.md 中的維護工作流程，對 wiki/ 執行一次完整的健康檢查。將結果輸出到 wiki/lint-report-[日期].md，附上 🔴/🟡/🔵 的嚴重程度。建議 3 篇文章來填補缺口。」
探索：
1「讀取 wiki/index.md，找出既有主題之間 5 個最有趣但尚未探索的連結。針對每個連結，解釋它可能揭示什麼見解，以及什麼來源可以幫助確認它。」
簡報：
1「根據 wiki/ 中的所有內容，撰寫一篇關於 [主題] 的 500 字執行摘要簡報。引用來源。結構如下：當前狀態、關鍵張力、開放問題、建議的下一步。」
去建構吧
收藏 Karpathy 的 Gist 和從中受益之間的差別，只是一個下午的時間。
選擇你的主題。建立資料夾。複製設定檔。
丟進你已經有的東西。執行你的第一次引入。
然後明天再用另一個來源做一次。
下週再用五個。
Wiki 每一次都變得更聰明。這就是全部的重點。
三個資料夾。一個設定檔。
一個 AI 來做你永遠不會自己做的苦工。
停止收集書籤。開始編纂知識。
把 Claude 變成 20 多種不同的行銷與商業專家。
安裝真正的專業知識，而不只是提示詞。
獲取我的 Claude 技能組合包 👇
