Every Level of a Claude Second Brain Explained
三句話摘要
以五個層次架構，系統性建構屬於自己的 AI 第二大腦（Second Brain），並根據實際痛點選擇最適層級。 --- 第二大腦的層次不是越高越好，而是要用最低夠用的架構解決你當下真實的痛點，並始終從「未來會怎麼查詢」反推「現在應該怎麼儲存」。 1. 「向下設計」原則：先想怎麼用，再決定怎麼存
重點整理
重點- 1
1. 「向下設計」原則：先想怎麼用，再決定怎麼存
- 2
你未來會問 AI 什麼樣的問題，決定了現在該用什麼格式儲存資料。就像球不可能通過比它小的框架，資料結構必須符合查詢形狀，否則代理人根本找不到答案。
- 3
2. 每一層解決不同痛點，最低夠用層才是最佳選擇
- 4
作者本人大量使用自己的 Herc2 專案，但仍停留在第二層，因為 Wiki + 路由已滿足需求。升層的動力應來自具體痛點，而不是「看起來更厲害」的衝動。
- 5
3. 向量搜索是語意搜索，不是萬能摘要機
- 6
Vector Retrieval 適合在大量規則文件中精確找到「第 17 條規則」，但若你要 AI 總結上週五整場會議，分塊嵌入後只能搜到片段，完整性仍需依賴原始完整文件，兩者不可混淆。
- 7
4. 第二大腦只儲存「不會刪除的資料」，雜訊比知識更傷害系統
- 8
Slack 訊息、電子郵件、每週變動的客戶數據不應進入第二大腦，因為一個月後就得清除。真正值得存入的是「一年後我還需要記得這件事嗎？」答案為是的那些決策、關係、與專案記錄。
- 9
--
實用技巧與重點
乾貨- 五層架構總覽：
- 第一層：CLAUDE.md / agents.md 純文字路由，關鍵字精確查詢
- 第二層：Wiki + memory.md，主題式組織，CLAUDE.md 自動更新記憶
- 第三層：Vector / 語意搜索（Pinecone、Supabase、Obsidian Smart Search）
- 第四層：知識圖 / 關係圖（LightRAG、Graphify、Obsidian 關係視圖）
- 第五層：G-Brain 模式（Gary Tan / Y Combinator CEO 開發），常駐自動清理更新記憶
- 具體工具與名稱：
- Claude Code、Codex、Hermes（自建代理專案）
- Obsidian（視覺化知識圖，作者本人幾乎不開啟）
- Pinecone、Supabase（向量資料庫）
- LightRAG、Graphify（知識圖解決方案）
- G-Brain（第五層代表性工具）
- 技術細節：
- 向量搜索流程：Chunking → Embedding → Search → Hybrid Reranking
- CLAUDE.md 可設定 `auto memory on/off`，讓 AI 自動更新 memory.md
- Codex 使用 agents.md，Claude Code 使用 CLAUDE.md，內容幾乎相同
- 「grillme」提示技巧（來源：Matt Pocock，作者改良版）：AI 對某主題連續提問直到掌握所有資訊，用於快速建立訓練資料與知識圖輸入
- 決策判斷標準：
- 用關鍵字能找到 → 第一層
- 有 30+ 個文件常忘記位置 → 第二層
- 路由靠關鍵字但查詢是語意 → 第三層
- 需要追蹤「A 導致 B」類型關係 → 第四層
- 需要多業務 / 多客戶常駐更新記憶 → 第五層
- 資料分類框架（4C 中的兩個核心）：
- 語言（Language）：決策、季度 OTA、鎖定的計劃 → 適合放入第二大腦
- 連接（Connection）：Slack、Email、客戶即時資料 → 不放入，避免雜訊
- --
結論
結論“第二大腦的層次不是越高越好，而是要用最低夠用的架構解決你當下真實的痛點，並始終從「未來會怎麼查詢」反推「現在應該怎麼儲存」。”
完整解析
詳細這支影片的核心命題是：每個人的 AI 第二大腦不需要一樣，應該根據自己的痛點選擇最合適的層次。作者以自己的 Herc2 專案為例，帶出一個反直覺但務實的設計哲學——不要因為第五層看起來最炫就直接跳到那裡，而是要從「我會如何問問題」出發，向下設計資料結構。就像你知道球要穿過圓孔，就不應該把球設計成方形；同理，你預計問 AI「摘要上週五會議」，就必須確保會議記錄以可被完整讀取的格式存放，而非分塊嵌入向量資料庫後只能搜到片段。
第一層與第二層是大多數人的起點，也是作者自認目前主要使用的層級。第一層只需要 CLAUDE.md 作為路由核心，搭配幾個固定的 context 檔案，AI 便能根據關鍵字找到正確文件。第二層在此基礎上加入 Wiki 結構與 memory.md，讓 CLAUDE.md 可以自動更新記憶，並透過索引讓代理人沿著「功能 → 工具 → 概念」的路線逐步導航。作者強調，Wiki 裡的連結雖然看起來像知識圖，但本質上只是「背景連結」，缺乏真正的關係語義，例如「A 是 B 的前提」或「C 依賴 D」，這才是第四層要解決的問題。
第三層引入向量搜索，解決的是「關鍵字對不上，但意思相近」的查詢場景。作者以圖片搜索為例，說明當你搜索「對話」，語意搜索能找到「直播測試結果、驗證技巧」等概念相關的內容，而關鍵字搜索只能找到完全命中的字串。然而，向量搜索有一個常見誤解：它非常適合從大量規則庫中精確撈出「第 17 條規則」，但若要對整場會議做全面摘要，嵌入後的分塊會讓代理人只能看到部分片段，反而不如讓代理人直接讀完整文件準確。這代表不同資料類型可以在同一個專案中混用不同的儲存策略。
第四層進入知識圖領域，核心價值在於追蹤資料間的有向關係——哪個專案催生了哪個課程、哪個客戶連接了哪條業務線。作者示範了在 Obsidian 中看到「七日 AI 挑戰」同時連接 YouTube 頻道與 AIS Plus 網路課程的畫面，說明這種關係在 Wiki 中是看不見的。作者也誠實地說，自己日常並不使用知識圖，因為 Wiki 已足夠，但建議若感受到「需要追蹤關係脈絡」的痛點，才考慮引入 LightRAG 或 Graphify 等工具。第五層的 G-Brain 則在第四層基礎上加入常駐自動更新機制，但作者同樣提醒，過多自動化輸入可能帶入雜訊，反而降低系統品質。文章最後也點出，把第二大腦推廣到整個團隊時，技術選型反而是小問題，最大的挑戰是「改變習慣、讓每個人都持續輸入有效資料」的流程管理問題。
---
關鍵時刻
Pipeline v2帶時間戳的重點，會在逐字稿層級分析上線後產生。目前請先透過原始影片觀看。
事實查核
Pipeline v2說法查證是下一次管線升級的一部分。KeyFrame 只會顯示它真正能驗證的內容。
