# 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 提供四個篩選標準：

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

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

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

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

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

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

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

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

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

```plaintext
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 幫你整合）**。

```python
# 舊模式：你在照顧知識庫
存一筆資料 → 手動整理 → 建立連結 → 更新 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 把這個過程自動化，降低摩擦力到接近零。

### 目錄結構的設計邏輯

```plaintext
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 會：

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

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 一份文章的流程大概是：

```plaintext
你：幫我 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 工具接手最耗人工的整理步驟。這不是完美系統的建立，而是把維護成本降低到讓你願意持續下去的程度。

![](https://cdn.hashnode.com/uploads/covers/69eb406b1e45c4e0dac5fb62/9f8c718c-42b1-425e-9f11-d387e2460bf3.png align="center")