Second Brain 實踐心得：結合 CODE 理論與 Karpathy LLM Wiki 方法論

本文由作者構思、AI 輔助撰寫，發布前已由作者審閱。

多數人的知識管理工具都沉過一次。Notion 精心分好 folder、Obsidian Graph View 截圖很美、Evernote 存了幾百篇文章——但需要的時候還是從 Google 重新搜。問題不是工具不好，而是知識管理的根本問題從來沒有被解決。

這篇文章從 Tiago Forte 的 CODE 理論出發，說明第二大腦的核心架構，再結合 Andrej Karpathy（OpenAI 共同創辦人）在 2026 年提出的 LLM Wiki 方法論，解釋如何在 AI 時代把第二大腦真正用起來。

為什麼你的知識工具最後都沉了

傳統工具把所有維護成本留給人

知識工具沉掉不是因為你懶，而是因為維護成本長期超過使用回報，人就會放棄。傳統工具的設計邏輯是：你負責捕捉、你負責整理、你負責分類、你負責維護連結、你負責在筆記過期時更新。每一步都是摩擦力，摩擦力累積就變成「等我有空再整理」，然後永遠沒有空。

更根本的問題是：大多數人「存東西」是為了讓自己安心，不是為了真的用它。你以為你存了這篇文章，就擁有了它的知識——但其實你只是多了一筆待整理的帳。

第一大腦的職責被弄錯了

Tiago Forte 在《Building a Second Brain》裡說：第一大腦不是用來儲存的，而是用來思考和創造的。當我們把「記住學過的東西」這個任務留在腦子裡，大腦就要分心管理這些待辦記憶，沒有餘裕做更深層的思考。

這是建立第二大腦的根本動機：把記憶外包出去，讓大腦清出空間做真正有價值的事。

為什麼說「第二大腦是流程，不是工具」

Tiago Forte 提出一個精確的定義：第二大腦必須能做到三件事——捕捉資訊（Capture）、連結資訊（Connect）、創造成果（Create）。Google Drive 之所以不算第二大腦，是因為它只做到「儲存」，無法做到「連結」和「創造」。

這個定義有一個重要含意：你換哪個工具並不重要，重要的是你有沒有一套能做到這三件事的流程。Notion 可以是第二大腦，純文字 markdown 也可以——差別在於你怎麼使用，不在於工具本身。

只做到了 Capture，沒有做 Connect 和 Create。存進去就結束了，知識沒有被連結到其他東西、也沒有被用來產出任何成果，它就只是一筆死資料。

第二大腦的理論基礎：CODE 四步驟

為什麼需要一套系統，而不是好習慣

「要勤做筆記」是好建議，但它不夠用。好習慣告訴你「要做」，但不告訴你「怎麼做讓它有效」。Tiago Forte 的貢獻是把第二大腦的操作提煉成一套可重複的系統：

CODE——Capture（獲取）→ Organize（組織）→ Distill（萃取）→ Express（表達）。

這四個步驟解決了不同層次的問題，缺一不可。

CODE 的四個步驟與核心問題

Capture（獲取）——只存有共鳴的東西

Capture 最大的挑戰不是「如何存」，而是「什麼值得存」。Tiago Forte 提供四個篩選標準：

有啟發性：帶來新觀點、刺激思考的東西
未來派得上用場：和你的工作、興趣、專業相關的東西
息息相關：和你正在解決的問題直接相關
令你意想不到：你還不知道、想弄懂的東西——不要存「早就知道的事」

為什麼我存了這麼多，查的時候還是找不到？

因為你存的東西太多了，稀釋了真正重要的資訊。Capture 的關鍵是「不要捕捉什麼」，而不是捕捉越多越好。每存一筆，問自己：「這對我正在解決的問題有什麼具體幫助？」

Organize（組織）——以「可操作性」分類，不是以「資訊類型」

Tiago Forte 設計了 PARA 系統，把所有資訊分成四個類別：

Projects（專案）：正在做、有明確截止日的任務
Areas（領域）：長期負責維護的領域（工作、健康、財務）
Resources（資源）：未來可能有用的素材（感興趣的主題）
Archives（檔案庫）：其餘的東西，先存起來

分類的優先順序是由上而下：這筆資訊對哪個「專案」最有用？沒有的話，對哪個「領域」？沒有就放「資源」，都不是就「封存」。核心概念是：筆記要存到它能發揮功用的地方，而不是它原本「屬於」哪個主題。

Distill（萃取）——讓未來的你能快速抓住重點

Distill 的具體方法是「累進式摘要（Progressive Summarization）」：每次重讀一份筆記，都進一步提煉它：

1000 字原文
→ 複製最重要的 300 字段落
→ 粗體標記最關鍵的幾句話
→ 最後用自己的話寫一句白話結論

Tiago Forte 的提醒很實用：把未來的自己想成一個極度忙碌的顧客，不會有時間翻細節。摘要不是給別人看的，是推銷給未來自己用的。

Express（表達）——把知識用出來，成果再回存

Express 是整個循環的出口：從第二大腦提取相關素材 → 連結筆記之間的關係 → 創造小規模、可迭代的成果（一篇文章、一份簡報、一段分享）。

重點是：成果不需要是驚天巨作。Tiago Forte 說成果要像積木一樣，規模小但可以持續堆疊。而且成果完成後，要再存回第二大腦——這樣每一次表達都在讓知識庫變得更豐富。

Karpathy 如何用 AI 升級 CODE

CODE 最耗人工的兩個步驟

CODE 框架邏輯完整，但有一個實踐上的瓶頸：Organize 和 Distill 兩個步驟非常耗人工。判斷一份資料和哪些主題相關、找到已有的筆記建立連結、把舊筆記和新資料整合成一篇更完整的東西——每個動作都要花 10-20 分鐘，而且需要對整個知識庫有全局了解。

這就是大多數人卡住的地方：「我知道應該整理，但每次整理都要花很多時間，而且做完了也不確定有沒有整理對。」

Karpathy 的解法：把整理成本轉給 AI

Andrej Karpathy 在 2026 年初公開的 LLM Wiki 方法論，核心概念是：人負責 Capture 和 Express，AI 接手 Organize 和 Distill。

對應 CODE 框架：

CODE 步驟	LLM Wiki 對應	AI 接手後的改變
Capture	raw/ 輸入 + Web Clipper	不變：人仍然負責篩選
Organize	Compile（AI 整合到 concept pages）	AI 判斷觸及哪些主題，自動更新相關頁面
Distill	Compile 中的摘要 + 矛盾偵測	AI 比人更一致地執行累進式摘要，並標記矛盾
Express	Derive（投影片）+ Query 回存	AI 從知識庫直接生成可用的成果

AI 接管 Organize 和 Distill 之後，你只需要說「幫我 compile 這篇文章」，系統就會自動找到相關 concept pages、整合進去、更新連結、記錄日誌。一份資料的整理時間從 20 分鐘壓縮到一句話。

LLM Wiki 的核心設計原則

Karpathy 的系統有一句關鍵設計原則："every exploration adds up"（每次探索都要累積）。每次跟知識庫的互動——不管是新增資料、查詢問題，還是清理維護——都應該讓知識庫變得更完整，而不是用完就消失。

這個原則解決了傳統工具的根本問題：以前每次互動都在消耗知識庫（花時間維護）；現在每次互動都在建設知識庫（AI 幫你整合）。

# 舊模式：你在照顧知識庫
存一筆資料 → 手動整理 → 建立連結 → 更新 index → 花 20 分鐘

# 新模式：知識庫在幫你積累
說一句話 → AI 整合進相關 concept → 自動建立連結 → 知識複利增長

這樣的系統，AI 會不會決定了什麼東西重要、什麼不重要？

AI 是整合者，不是判斷者。Capture 仍然是人做的——你決定什麼值得放進來。AI 的工作是把你放進來的東西，有效地整合到已有的知識網絡裡。觀點和結論仍然是你的，AI 提供的是整合的效率。

三工具組合：容器、方法論、執行引擎

三個層次各自解決不同的問題

實踐 Karpathy LLM Wiki 不需要特定的工具，但有一個效果最好的組合：

Obsidian（容器層）：第二大腦的物理儲存空間。本地 markdown 檔案沒有 vendor lock-in，git 版本控，CLI 可以直接讀寫——AI 工具需要能夠直接操作你的知識庫，不能被關在 web UI 後面。Obsidian 的 [[雙向連結]] 讓頁面之間形成有機網絡，Graph View 讓你看見知識的形狀。

LLM Wiki 方法論（組織層）：不是軟體，是工作流哲學。每份新資料進來，核心問題不是「這篇文章說了什麼」，而是「這份資料讓我對哪個主題的理解改變了什麼、改變了哪裡」。這比直接存原文多了一個關鍵步驟：整合。

AI CLI / Copilot CLI / Claude Code（執行層）：讓 LLM Wiki 方法論真正運作的工具。沒有執行工具，方法論的門檻很高——每次 Compile 都要手動找相關頁面、手動更新、手動維護連結。AI CLI 把這個過程自動化，降低摩擦力到接近零。

目錄結構的設計邏輯

SecondBrain/
├── raw/               ← 唯讀原始資料（Capture 的成果）
│   ├── articles/      ← 文章、筆記
│   ├── clippings/     ← Web Clipper 剪報
│   └── books/         ← 書籍筆記
└── wiki/              ← AI 維護的知識庫（Organize + Distill 的結果）
    ├── index.md       ← 所有頁面的目錄
    ├── log.md         ← 操作日誌（append-only）
    ├── sources/       ← 每份 raw 資料的輕量摘要
    ├── concepts/      ← 核心概念文章（可獨立閱讀）
    └── derived/       ← 衍生產出（slides / QA 回答）

對應 PARA 系統：raw/ 是 Archive（原始素材，不處理），wiki/sources/ 是 Resources（每份資料的索引），wiki/concepts/ 是 Areas（你長期在建設的知識領域），wiki/derived/ 是 Projects 的輸出（可以用的東西）。

三工具的化學反應：Obsidian 是好土壤，LLM Wiki 是耕作方法，AI CLI 是農機。土壤讓根扎穩，方法讓種的東西能長，農機讓你不用每次都自己鋤地。

四個操作讓知識庫越用越強

設計邏輯：每次互動都留下痕跡

LLM Wiki 的四個操作不是隨機的功能清單，而是實現「every exploration adds up」的完整閉環：

Compile（編譯新知識）：原始資料進入 raw/ 後，說「幫我 compile 這篇文章」，AI 會：

讀取 raw 資料
搜尋相關 concept pages
整合進去（不只寫摘要，而是真正合成知識）
偵測矛盾（新資料和舊知識衝突時，顯性標記，不覆蓋）
建立雙向連結

Compile 一份資料會觸及 5-15 個 concept pages，這是正常的——一份好的來源應該和多個主題相關。

Query（查詢）：從 concepts 找答案，回答有整合價值時存回 derived/qa/。關鍵是「查詢的答案也要回存」——讓每次提問都變成知識庫的一筆資產，而不是用完就消失。

Lint（健康檢查）：定期找問題：孤立頁面（無任何 inbound 連結）、斷鏈（source 指向 concept 但 concept 沒有回指）、矛盾內容、過時敘述、被多個頁面提到但還沒有獨立文章的概念。Lint 不只是清理，是找到「知識庫的下一步成長機會」。

Derive（產生衍生成果）：從 concept articles 直接生成 Marp 投影片，或根據 QA 回答產出技術文章。這對應 CODE 的 Express 步驟——知識庫不只是儲存知識，而是直接產出可用的成果。

一個真實的使用體驗

把 Karpathy 的 GitHub Gist 貼給 Claude Code 或 Copilot CLI，讓它幫你建好目錄結構和 AGENTS.md 之後，第一次 Compile 一份文章的流程大概是：

你：幫我 compile 這篇文章（貼上文章連結或內容）

AI：
  Step 1 — 讀取文章
  Step 2 — 搜尋相關 concepts...找到 3 個相關頁面
  Step 3 — 讀取 concepts/知識管理工具選型、concepts/Second-Brain-實踐心得...
  Step 4 — 建立 wiki/sources/XXX.md（摘要頁）
  Step 5 — 更新 concepts/知識管理工具選型（新增 2 個要點）
  Step 6 — 更新 concepts/Second-Brain-實踐心得（整合新觀點，標記矛盾）
  Step 7 — 雙向連結審查完成
  Step 8 — index.md 更新
  Step 9 — log.md 記錄
  Step 10 — Git commit & push

完成。觸及 2 個 concept pages，建議新建 [[concepts/XXX]]（被 3 個頁面提到但無獨立文章）。

一份資料 5 分鐘以內整理完，而且每次整理都在讓知識庫更完整。

如果我懶得 compile 一段時間，知識庫會壞掉嗎？

不會。懶得 compile 只是知識庫停止成長，不是壞掉。這是和傳統工具最重要的差別：以前懶得整理，知識庫會亂掉、難找、最後沒用；現在懶得 compile，知識庫只是停在上次的狀態。這個摩擦力的差異，讓這套系統比以前的工具更可能長期活下去。

結論

第二大腦的理論（CODE）給了你一套「應該做什麼」的框架：Capture 好的素材、Organize 到可操作的位置、Distill 提煉本質、Express 用出來。Karpathy 的 LLM Wiki 方法論回答了「AI 時代怎麼做才可持續」的問題：把整理成本轉給 AI，人只需要做最有價值的兩件事——輸入好素材和提出好問題。

真正的第二大腦不是漂亮的 Notion workspace，也不是龐大的 Obsidian graph，而是一個每次互動都在累積、而不是在消耗你的系統。工具只是手段，讓每次閱讀和思考的成果能被編譯成可調用的資產，才是核心。

如果你也有「存了一堆東西但從來沒再看過」的困擾，這個方向值得試試：找到你現有的知識工具，把 CODE 框架作為流程設計的指引，再用 AI 工具接手最耗人工的整理步驟。這不是完美系統的建立，而是把維護成本降低到讓你願意持續下去的程度。