KeyFrame內部研究專用

Every Level of a Claude Second Brain Explained

Nate Herk·6月17日週三·30 min英文

三句話摘要

以五個層次架構,系統性建構屬於自己的 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 只會顯示它真正能驗證的內容。

更多「AI 技術」的內容

Between Two Nerds: Attribution is dead, long live attribution
32 min
AI 技術英文PODCAST8月25日

Between Two Nerds: Attribution is dead, long live attribution

Risky Business

  • 工具成本的破壞性下降 — 傳統上,攻擊者必須重複使用昂貴自製的惡意軟體或工具組,因為開發和維護成本極高。這種成本結構使得安全研究人員可以通過工具特徵和程式碼簽名來追蹤攻擊者。LLM 自動化了代碼生成與維護工作流,使得攻擊者可以輕易為每個目標生成新工具,或改用通用系統工具,導致傳統的工具特徵分析失效。
  • 所有取證證據都在攻擊者掌控之中 — 無論是使用的 IP 位址、惡意軟體類型或戰術流程,這些都是攻擊者的主動選擇。即使看似是隨機巧合,攻擊者仍有能力在事前決定留下什麼痕跡。因此,所有可恢復的取證證據本質上都是攻擊者願意暴露的信息。
  • LLM 削弱工具簽名但保留高階行為特徵 — LLM 經過公開駭客技術訓練,使不同使用者產生相似的攻擊模式。然而,勒索軟體集團、國家級行為者的受害者選擇、贖金要求方式或目標模式等高階特徵仍具有識別價值。例如,鎖定加密交易所的攻擊幾乎只能指向朝鮮。
Everything Goldman Sachs Taught Me About AI (In 10 minutes)
AI 技術英文8月24日

Everything Goldman Sachs Taught Me About AI (In 10 minutes)

Nate Herk

  • 驗證優於相信:看起來完整的AI輸出不等於正確答案,需在提示中要求模型重新檢查數字、引用來源,並對無把握的部分標記。
  • 區分AI與自動化:確定步驟且答案已知的任務用傳統自動化更便宜快速;只在需要判斷力、靈活性或處理複雜資訊時才用AI,兩者結合效果最佳。
  • 以問題驅動選型:先寫清楚「要解決的問題是什麼、成功的樣子是什麼」,再決定用什麼工具,許多失敗項目是從技術而非問題出發。
Mu: a self-hosted personal agent where the interface is an email address you can write to
AI 技術英文8月23日

Mu: a self-hosted personal agent where the interface is an email address you can write to

GitHub Awesome

  • Mu 是自主代理人系統,具有實際網址與獨立伺服器,用戶可透過多種方式與其互動——網頁應用、電子郵件或程式化介面。
  • 架構完整覆蓋日常工作流程的多個層面,整合郵件收發(SMTP/IMAP)、檔案管理、行事曆、新聞聚合、市場數據與搜尋功能於一個 Go 伺服器內。
  • 支援自帶模型與多種通訊協定,用戶可選擇不同的 AI 模型,並透過 MCP、HTTP API 或命令列工具整合到其他系統。