LLM Wiki+Research Skill Graph+Obsidian 構建個人知識研究引擎

2026年4月3日，安德烈·卡帕西（OpenAI聯合創始人、特斯拉前人工智能主管，也是“氛圍編程”一詞的創造者）發佈了一條標題爲“大語言模型知識庫”的推文，講述了他如今如何利用大語言模型構建個人知識維基，而非僅用於生成代碼。

這條推文迅速爆紅。次日，他又發佈了新內容：一份“創意文件”，完整闡述了該理念背後的架構、理念與工具。

所謂創意文件，也是他這次提出來的新概念。他的原話是：

The idea of the idea file is that in this era of LLM agents, there is less of a point/need of sharing the specific code/app, you just share the idea, then the other person's agent customizes & builds it for your specific needs.” “創意文件的理念是，在這個大語言模型智能體的時代，分享具體的代碼或應用的意義/必要性已經不大了，你只需分享創意，對方的智能體就會根據你的具體需求進行定製並構建出來。”

這是一個微妙卻意義深遠的轉變。傳統上，開發者做出實用的東西后，會分享實現方案：一個 GitHub 代碼倉庫、npm 上的一個包、一個 Docker 鏡像。

接收者會克隆它、配置它並運行它。

但在人人都能使用大模型智能體（Claude Code、OpenAI Codex、OpenCode、Cursor 等）的時代，分享創意可能比分享代碼更有價值。

因爲思路是可移植的，而代碼是特定的。

卡帕西在 macOS 上使用 Obsidian 搭配 Claude Code。

你可能在 windows 上使用 VS Code 搭配 OpenAI Codex。

一個共享的 GitHub 代碼倉庫需要被複刻、修改和調試。

而一個共享的思路文件只需複製粘貼到你的智能體中，你的智能體就會構建出一個完全適配你具體環境的版本。

話說回來，LLM Wiki 解決了知識怎麼存。

但是存進去了怎麼用呢？

如果你只是基於這個知識庫，給大模型一個提示詞去問問題，那得到的答案可能也不是很好。

因爲模型的上下文是有限的，注意力是會漂移的。

爲了解決這個問題，我找到了一個和LLM Wiki完美互補的方案，Research Skill Graph。

Research Skill Graph 搭建了一套基於知識庫做深度研究的方法論，它通過定義一套深度研究的方法論來規範LLM的研究行爲，提升最終的效果。

這篇文章會完整系統的介紹LLM Wiki和Research Skill Graph的原理、使用方式以及如何將二者結合做出一個個人的知識庫研究引擎。

1: RAG和傳統筆記工具的共同的死因：維護成本太高

RAG系統和傳統筆記工具都有一個共同的死因，那就是維護成本太高。

沒有人願意在週末花三個小時更新30個過時的Wiki頁面。

人類對知識整理的熱情曲線是這樣的：前三天高漲，然後指數級衰減。

除了維護成本，RAG還有一個重要的問題，那就是知識無法沉澱。

RAG的工作流程大概是這樣子的。

輸入一個prompt。
程序對你的prompt進行分詞
分詞後到向量數據庫檢索，每個檢索的內容都有一個得分。
程序根據得分進行rerank，篩選有效的信息。
那個prompt+rerank出來的信息，再次調用LLM 進行內容生成。

這就是所謂的檢索增強生成。

你有沒有發現一個問題？

那就是RAG的流程，每次都是從1-5。跑完之後沒有任何的反饋和沉澱。

Karpathy 在創意文件裏面指出：

"The LLM is rediscovering knowledge from scratch on every question. There's no accumulation."

"LLM 每次都在從零重新發現知識。沒有積累。"

這個問題的本質是認知浪費。

假設你有一個包含 50 份研究報告的知識庫，想問一個需要綜合其中 5 份報告的複雜問題。

在 RAG 模式下，LLM 必須找到這 5 份報告的相關片段，拼出答案。

下次你問一個相關但不同的問題，它又得重來一遍推理鏈。

RAG把知識當成一個可以隨時搜索的數據庫，卻忽略了知識需要編譯、鏈接、維護。

下面是傳統RAG和LLM Wiki的對比。

知識處理時機 · 查詢時（每次提問重新處理） — 攝入時（每條素材只處理一次）
交叉引用 · 每次查詢臨時發現 — 預構建並持續維護
矛盾檢測 · 可能被忽略 — 攝入時標記
知識積累 · 無——每次從零開始 — 隨素材和查詢持續複利增長
輸出格式 · 聊天記錄（臨時性） — 持久化 Markdown 文件（可複用）

2: LLM Wiki 是什麼

2026 年 4 月 4 日，Karpathy 發佈了那個 GitHub Gist。開頭是這麼寫的：

"A pattern for building personal knowledge bases using LLMs."

"一個用 LLM 構建個人知識庫的模式。"

Karpathy是這麼描述LLM Wiki的，注意他用的詞是 "pattern"（模式）。

LLM Wiki 的核心思想是：不要在查詢時檢索原始文檔，而是讓 LLM 持續地、增量地構建和維護一個持久的結構化的、相互鏈接的 Markdown 文件集合，也就是Wiki。

當你添加一條新素材時，LLM 不是簡單地把它索引用於後續檢索，而是閱讀素材，提取關鍵信息，再整合到已有的 Wiki 中。

這個整合包括：更新實體頁面、修改主題摘要、標註新舊數據之間的矛盾、加強或挑戰正在演化的綜合分析。

Wiki 是一個持久的、複利增長的產物。交叉引用已經存在。矛盾已經被標記。綜合分析已經反映了你讀過的所有內容。

3：LLM Wiki的三層架構

LLM Wiki 的架構由三層組成：

1. Raw 層 — 你的原始素材庫

文章、論文、圖片、數據文件——所有你搜集的原始素材。這一層是不可變的（immutable）。

LLM 永遠不會動raw目錄下的任何文件。

實際操作中，Karpathy 用 Obsidian Web Clipper 把網頁剪藏爲 Markdown，圖片下載到 raw/assets/ 目錄。

社區裏還有一個值得注意的實踐：vault 分離——保持個人主 vault 的高信噪比，另建一個獨立 vault 承載 Agent 生成的內容（後文會詳細討論這個策略）。

2. Wiki 層 — LLM 編譯後的結構化知識

Wiki 層是整個架構的核心，也是LLM的核心工作層。

每條新素材進來時，LLM 執行的是一次系統性的更新：閱讀素材、寫摘要頁面、更新索引、更新相關的實體和概念頁面、追加時間記錄、檢查矛盾。

一條素材可能會影響 10-15 個 Wiki 頁面。

一個LLM Wiki典型的目錄結構如下：

wiki/ 根目錄下包含：

index.md（主目錄，所有頁面的索引）
log.md（時間線，所有操作記錄）
overview.md（高層綜合）
concepts/（概念頁面）
entities/（實體頁面）
sources/（素材摘要）
comparisons/（比較分析）

index.md 是內容導向的總目錄。每一頁都被列出，附帶鏈接、一句話摘要和可選的元數據（日期、來源數量等）。LLM 回答查詢時，會先讀 index.md 定位相關頁面，再深入閱讀。Karpathy 說這個機制在中等規模（約 100 條素材、數百個頁面）下工作得驚人地好，完全不需要 embedding-based RAG 基礎設施。

log.md 是時間線。只追加，不修改。每條記錄以一致的格式開頭（如 ## [2026-04-02] ingest | Article Title），這樣你可以用簡單的 Unix 工具解析它——grep "^## \[" log.md | tail -5 就能獲取最近 5 條記錄。

3. Schema 層 — 規則和配置

schema層通過一個文檔（比如 Claude Code 的 CLAUDE.md 或 Codex 的 AGENTS.md），告訴 LLM Wiki 怎麼組織的、有哪些約定、攝入素材、回答問題和維護 Wiki 時該遵循什麼工作流。

這個配置文件讓 LLM 成爲一個有紀律的 Wiki 維護者，而不是一個通用聊天機器人。

Schema 固化了三樣東西：目錄結構、頁面約定、操作工作流。

頁面約定裏有一個關鍵的設計：每條筆記頂部的一行摘要。MindStudio 的搭建指南專門強調了這一點：

"The one-line summary at the top of each note is surprisingly important. Claude reads it to decide whether the full note is relevant."

"每條筆記頂部的一行摘要出乎意料地重要。Claude 靠它判斷整條筆記是否相關。"

傳統筆記是給人看的，我們自己記住什麼東西在哪，然後導航過去。

LLM Wiki 的筆記是給模型看的，模型用摘要做初篩，只深入閱讀相關頁面。

每個 Wiki 頁面都應有結構化的頭部：標題、一行摘要、標籤、創建日期、關聯頁面。

Schema並不是完全不可變的，如果用了一段時間後發現某些約定不好用，就改Schema。

爲了更好的理解這三層架構，我們可以用軟件編譯的流程來類比一下：

raw是源代碼，LLM是編譯器，wiki是可執行文件，健康檢查是測試套件，查詢是運行時。

源代碼（raw/）：原始的、人類編寫的素材，不可變
編譯器（LLM）：讀取源代碼，生成結構化輸出
可執行文件（wiki/）：編譯後的產物，可以直接使用
測試套件（health check / lint）：定期檢查一致性、發現矛盾
運行時（query）：用戶在編譯後的知識上提問和探索

還可以用Git的內部對象模型來映射知識結構：

Blob · 原子知識單元 — 單個事實、模式、被否定的方案
Tree · 目錄/索引 — 分類和導航結構
Commit · 來源事件 — 誰、什麼時候、爲什麼加入這條知識
Branch · 競爭假設 — 平行的研究線索
Merge · 綜合/收斂 — 假設的合成或解決
Tag · 穩定快照 — 經過驗證/審計的知識版本

這個映射的核心優勢是內容去重——相同的知識產生相同的哈希值，相同的結論不會在 Wiki 裏出現兩次。

它同時解決了溯源問題：每條知識的來源、時間和理由都被記錄在案。

4: LLM Wiki的維護

Wiki的維護主要靠操作：Ingest、Query、Lint

Ingest（攝入） 是 Wiki 增長的引擎。Karpathy 偏好一條一條攝入，保持參與感：

Query（查詢） 不只是問問題。好的回答本身也應該被存回 Wiki，查詢是雙向建設——你消費知識，同時 Wiki 在增長。

Lint（檢查） 是健康保障。健康檢查主要做以下事情：

查找矛盾數據：掃描多篇文章中互相矛盾的事實和數字。這種事情眼睛掃不過來，但 LLM 可以在一次檢查中找出“論文 A 說 X，論文 B 說非 X”這樣的衝突。
補全數據空白：找到某篇文章引用了一個概念頁面遺失的情況，自動去網上查找補全。相當於是讓 Wiki 自我修復。
發現隱含關聯：在表面看上去沒有聯繫的頁面之間找到隱含聯繫——這種事人類很容易忽略，LLM 卻能擅長。
建議新頁面：根據現有頁面的覆蓋範圍 / 密度，推薦還應該新增哪些主題頁面。

從手工編輯到工具化自動化：MCP Server

以上三個操作定義了 Wiki 的完整生命週期。開源項目 llmwiki 將 Wiki 的核心能力抽象爲 7 個工具：

wiki_query：做關鍵詞搜索並返回頁面內容
wiki_search：對整個 wiki/ 文件夾做原始 grep
wiki_list_sources：列出原始素材文件
wiki_read_page：讀取單個頁面內容
wiki_lint：檢查孤兒頁面和斷裂鏈接
wiki_sync：觸發素材到 Wiki 的更新與轉換
wiki_export：導出爲 AI 可理解的格式（llms.txt、JSON-LD 等）

這 7 個工具本質上就是把 Ingest、Query、Lint 三個手工操作變成了程序化接口。這樣任何 Agent 都能直接操作你的 Wiki，llmwiki 目前已經適配了 Claude Code、Codex CLI、Cursor、Gemini CLI、Copilot覆蓋了當前主流的 AI 編程助手。

LLM Wiki 可以用來做什麼：

個人成長：跟蹤目標、健康、心理狀態——把日記、文章、播客筆記歸檔，構建一個關於自己的結構化畫像
深度研究：在幾周或幾個月內深入研究一個主題——讀論文、文章、報告，增量構建一個有演化論點的綜合 Wiki
讀書伴侶：逐章歸檔，構建人物頁面、主題頁面、情節線索頁面。Karpathy 提到了 Tolkien Gateway——一個由志願者花幾年時間構建的、包含數千個相互鏈接頁面的粉絲 Wiki。你可以獨自做到類似的事情

商業團隊場景同樣適用。由 LLM 維護的內部 Wiki，素材來源可以是 Slack 線程、會議轉錄、項目文檔、客戶通話記錄。競爭分析、盡職調查、旅行規劃、課程筆記——任何你在一段時間內積累知識並希望它有組織而非散亂的場景，LLM Wiki 都能幫忙。

LLM Wiki 不是銀彈，社區也有不同的聲音

評論區裏，nishchay7pixels 寫道：

"The knowledge stored could easily be corrupted and it will become impossible for user to figure that out. The more you rely on Agent the more you will start doubting your own memory."

"存儲的知識很容易被污染，而用戶將無法辨別。你越依賴 Agent，就越會開始懷疑自己的記憶。"

這個擔憂是合理的。gnusupport則認爲 LLM Wiki 本質上是"一個自我延續的 LLM 上下文生成器"——沒有 LLM，它只是一堆無組織的文件。

他主張回到 Doug Engelbart 的 Dynamic Knowledge Repository 理念，用 PostgreSQL 做確定性存儲。他花了 23 年構建的 Hyperscope 系統積累了 245,377 名用戶和 95,211 份超文檔。

兩個觀點都有道理，但它們指向的是同一個問題：信任邊界。

Karpathy 的 raw/ 不可變原則和 Obsidian CEO Steph Ango 的 vault 分離方案，都在做同一件事——給"什麼是可信的"劃一條清晰的邊界。

保持個人主 vault 的高信噪比，另建一個獨立的"Agent vault"承載 LLM 生成的全部內容。兩套 vault 互不污染，你始終能在主 vault 裏保持對知識來源的掌控。

devsarangi2 提出了另一個實際問題：團隊擴展性。一個 PM 不需要 80% 的技術文檔——同一份 Wiki 對不同角色的價值差異巨大。

也就是說，LLM Wiki 在個人場景下最有價值，團隊場景需要額外的角色過濾層。

LLM Wiki 是一個強大的個人工具，但它有自己的適用邊界。信任邊界需要設計，角色差異需要處理，數據質量需要持續審計。

Part 5: 從零搭建實戰指南

理論講夠了，現在動手。以下是搭建一個 LLM Wiki 的完整步驟。

第 1 步：安裝 Obsidian 和 Claude Code

Obsidian 是 LLM Wiki 的最佳前端：本地優先、圖譜視圖、插件生態齊全。

下載 Obsidian，創建一個新的 Vault——就是一個文件夾，裏面所有東西都是純 Markdown。

Claude Code 是目前非常適合 LLM Wiki 的 Agent。它可以直接訪問本地文件系統**。不需要複製粘貼，告訴它筆記在哪，直接問問題。

Claude Code能讀取指定文件或整個目錄、跨文件搜索、創建和更新筆記、執行 shell 命令來過濾和組織。

安裝只需一行命令：

npm install -g @anthropic-ai/claude-code

第 2 步：創建目錄結構

在 Vault 根目錄下執行：

mkdir -p raw/sources raw/assets
mkdir -p wiki/index wiki/concepts wiki/entities wiki/sources wiki/comparisons
git init

這是最基礎的骨架。raw/ 放原始素材，不可變；wiki/ 放 LLM 編譯後的產物。

第 3 步：寫 Schema 文件

Schema 文件是你的 CLAUDE.md（如果你用 Claude Code）或 AGENTS.md（如果你用 Codex）。它告訴 LLM 怎麼維護這個 Wiki。以下是一個最小可用版本：

# LLM Wiki Schema ## 項目結構 - raw/sources/ — 原始素材，不可變 - raw/assets/ — 圖片等附件 - wiki/ — LLM 生成的 Wiki，由 LLM 維護 ## 頁面約定每個 Wiki 頁面必須包含 YAML frontmatter： --- title: 頁面標題 type: concept | entity | source | comparison sources: [來源列表] related: [相關頁面] created: YYYY-MM-DD updated: YYYY-MM-DD --- 此外，每條筆記應包含一行摘要和標籤，方便模型快速判斷相關性： Summary: 一句話描述這條筆記的核心內容 Tags: #topic1 #topic2 ## 攝入工作流（Ingest） 1. 閱讀 raw/sources/ 中的新素材 2. 在 wiki/sources/ 寫一條摘要 3. 更新 wiki/index.md 4. 更新相關實體/概念頁面 5. 檢查矛盾並標記 6. 在 wiki/log.md 追加記錄 ## 查詢工作流（Query） 1. 讀取 wiki/index.md 定位相關頁面 2. 閱讀相關頁面的完整內容 3. 綜合回答，附引用 4. 將有價值的回答存回 Wiki

目錄結構不要過度設計。一開始四五個頂層文件夾就夠了，隨着素材積累自然演化出子目錄。過早規劃層級，Schema 反而會變得脆弱。

第 4 步：攝入第一條素材

安裝 Obsidian Web Clipper 瀏覽器擴展，把文章剪藏爲 Markdown 保存到 raw/sources/。然後在 Vault 目錄下啓動 Claude Code：

cd ~/my-llm-wiki
claude

告訴它："請處理 raw/sources/ 中最新的素材。"它會按照 Schema 執行攝入工作流。

第 5 步：檢查結果，迭代 Schema

打開 Obsidian，檢查生成的 Wiki 頁面。發現問題就改 Schema。Karpathy 建議的檢驗標準是10 條素材測試：攝入 10 條素材後，問一個需要綜合多條素材的問題。如果 Wiki 給出了從單條素材中無法獲得的洞察，系統就是有效的。

實戰技巧

幾條在搭建過程中會被反覆驗證的經驗：

保持術語一致。 如果你在一些筆記裏寫"RAG"，在另一些筆記裏寫"Retrieval-Augmented Generation"，Claude 能關聯它們——但選一種寫法堅持用，結果會更乾淨。

筆記要聚焦。 一個一萬字的雜燴文檔，查詢效果遠不如十個一千字的專題筆記。每條筆記只覆蓋一個主題，用 [[wikilinks]] 連接相關筆記。

用 /inbox 模式處理粗糙素材。 把不知道該如何分類的筆記先扔進 wiki/inbox/，堆到一定數量再讓 Claude 幫你歸檔整理。這比每條筆記都精雕細琢效率高太多。

充分利用 Obsidian 插件生態。 Karpathy 在 Gist 裏推薦了幾個插件：Marp 是一個基於 Markdown 的幻燈片格式，Obsidian 也有對應插件——你可以直接從 Wiki 內容導出演示文稿，不需要 PowerPoint。Dataview 能跑查詢頁面 frontmatter——只要你的 LLM 給每個 Wiki 頁面都按俱樂部約定添加了標籤、日期和來源計數等 YAML 格式元數據，Dataview 就能自動生成動態表格和列表。例如只要寫一條 Dataview 查詢語句，就可以列出”過去七天內所有更新過的概念頁面“，比手動維護索引高效太多了。

圖片本地化 。Karpathy 在 Gist 裏分享了個具體實踐，把圖片也下載到本地（而不是僅保留外部 URL 引用）。在 Obsidian 的 Setting → Files and links 設置附件文件夾的路徑是一個固定目錄（比如 raw/assets/），搜索 Hotkeys 裏的”Download“，把”Download attachments for current file“綁定一個快捷鍵（比如 Ctrl+Shift+D）。粘進文章後按下快捷鍵，所有圖片都會自動下載到本地。這樣你的 LLM 不但可以看到圖片，還可以直接引用到本地文件。

進階工具

當 Wiki 足夠大（超過 50 條各類素材）你可能會發現搜索上有些力不從心。有以下三條路可以走：

強化搜索能力 ：除了 Obsidian 自帶的功能，Karpathy 還推薦了一個開源項目：qmd——Shopify CEO Tobi Lutke 構建的原生 Markdown 搜索引擎，結合了 BM25/向量搜索 + LLM 重排序。更大規模（上百條以上），可以用 LlamaIndex 自行在 Markdown 文件構建向量索引，爲 Claude 加強語義搜索能力。

端到端工具化： 如果你不想手動設置 Schema 和 Wiki 目錄結構，Pratiyush 推出了一個開箱即用的解決方案 llmwiki 。除了自動化，它的核心價值還在於解決了 LLM Wiki 模式的一個實際痛點：你用不同 Agent（Claude Code/Cursor/Codex）進行的會話記錄，可能分別被分散保存在不同目錄下面。llmwiki 自動收集你的 Agent（目前支持 Claude Code 和 Cursor）產生的所有 .jsonl 轉錄文件，並轉換爲 Karpathy 規範的 Wiki 格式。

此外還自帶靜態站點生成器：全局搜索（Cmd+K），暗色模式，代碼語法高亮，麪包屑導航，相關文章推薦，閱讀時長估算……把本來只是一個文件夾的 Wiki 變成了一個可瀏覽的知識站點。更重要的是它的”雙格式輸出“設計：每個生成的 HTML 頁面對應一個 .txt 的純文本版本和 .json 文件，以及站點級的 llms.txt 和 JSON-LD 圖譜，從而讓其他 AI Agent 能直接消費你的 Wiki 內容。

自動化工作流程： llmwiki 還提供了 SessionStart 的鉤子函數——讓你的 Wiki 在每次啓動 Claude Code 時自動同步新會話，還有文件觀測器後臺輪詢 Agent 的存儲目錄。換句話說，llmwiki 讓 Wiki 的生長過程可以完全被動：你正常使用 Claude Code / Cursor / Codex 處理知識，而 Wiki 在背景自動更新編譯。

它還自帶靜態站點生成器：全局搜索（Cmd+K）、暗色模式、語法高亮、麪包屑導航、相關頁面推薦、閱讀時間估算——把 Wiki 從文件夾變成了一個可瀏覽的知識站點。更值得注意的是它的"雙格式輸出"設計：每個 HTML 頁面都有對應的 .txt 和 .json 文件，以及站點級的 llms.txt 和 JSON-LD 圖譜，讓其他 AI Agent 可以直接消費你的 Wiki 內容。

工作流自動化：llmwiki 還提供了 SessionStart hook——每次啓動 Claude Code 時自動同步新會話，以及 file watcher 後臺輪詢 Agent 存儲目錄。也就是說，Wiki 的增長可以完全被動：你正常使用各種 AI 工具，Wiki 在後臺自動編譯。

6: 從知識存儲到知識使用 — Research Skill Graph

話說回來，LLM Wiki 解決了"知識怎麼存"。

但是存進去了怎麼用呢？

如果你只是基於知識庫，給大模型一個 prompt 去問問題，那跟直接問豆包區別不大。垂直領域的知識還好說，科普類的素材，你的 Wiki 未必拼得過通用模型的知識儲備。

真正的問題出在深度研究上。LLM Wiki 可能有一肚子貨，但不知道怎麼吐出來。

背後是兩個硬傷。

第一個硬傷：上下文窗口塞不下。 每個模型的推理能力都隨輸入長度增加而下降。LLM 對上下文的開頭和結尾表現還行，中間部分的注意力會顯著丟失。簡單點說，你塞進去的領域知識越多，Agent 對這些知識的處理能力就越差。

第二個硬傷：研究方法論缺失。 人類做研究有一套方法論，AI 做研究通常就是一個 prompt 搞定。方法論層面缺了一整層，AI 研究的產出自然淺薄。

這兩個問題引出了另一個創意文件：Research Skill Graph。

6.1 Research Skill Graph 的設計理念

Skill Graph 的核心理念不是某個具體的文件夾結構或視角組合，而是四條設計原則。

原則 1：方法論固化。 研究方法論不應該存在於 prompt 裏，它應該寫進文件。Prompt 是一次性的，文件是持久的。你把"怎麼看問題""怎麼評估來源""怎麼處理矛盾"寫成獨立的 .md 文件，Agent 每次都用同一套方法論，結果是可復現的。

原則 2：圖譜而非容器。 知識庫是一個容器，你往裏扔東西，需要的時候搜索。Skill Graph 是一張圖譜，每個知識節點通過 [[wikilinks]] 互連，Agent 像研究員查文獻一樣按需導航，而不是把所有內容一次性塞進上下文。

這直接回應了"Lost in the Middle"問題：每個節點足夠短，沒有中間可以迷失。

原則 3：強制多角度，拒絕單一結論。 拿到一個研究問題後，Agent 必須從多個完全不同的角度重新思考，拒絕直接給出答案。常見視角比如：技術、經濟、歷史、地緣、反向、第一性原理。

我們可以根據自己的領域調整。做倫理研究可能需要加一個"利益相關者"視角，做市場分析可能需要加一個"競爭格局"視角。

方法論的核心不變：強制多角度，視角之間的張力纔是洞察的來源。

"Each lens must RETHINK the question, not just add more information. The technical lens and the contrarian lens should feel like they were written by two different researchers who disagree with each other." "每個視角必須重新思考問題，而不是簡單疊加信息。技術視角和反向視角讀起來應該像是兩個互相不同意的研究員寫的。" —— The Smart Ape（AI 研究方法論博客）

原則 4：質量可審計。 研究產出必須可以事後追問。"這個結論基於什麼等級的來源？爲什麼技術視角和反向視角衝突了？"這要求來源分級、合成規則、矛盾處理協議都寫成文件，每個環節有文檔記錄。

下面是一個 Research Skill Graph 的具體實現：

research-skill-graph/ 根目錄下包含：

index.md（方法論固化：Agent 從這裏啓動，讀執行流程）
research-log.md（質量可審計：跨項目日誌，每個環節可追溯）
methodology/（方法論固化：4 個文件定義研究方法論）
research-frameworks.md / source-evaluation.md
synthesis-rules.md / contradiction-protocol.md
lenses/（強制多角度：每個文件定義一個視角的行爲約束）
technical.md / economic.md / historical.md / geopolitical.md
contrarian.md / first-principles.md
projects/（按研究課題歸檔）
sources/（來源記錄模板）
knowledge/（圖譜而非容器：概念和數據點跨項目累積）
concepts.md / data-points.md

6.2 質量保障機制

Research Skill Graph 使用5種層次來評估來源：

Tier 1 · 原始數據 — UN 數據集、同行評審論文
Tier 2 · 權威分析 — 官方技術博客、論文
Tier 3 · 專業評論 — 知名技術博主、行業報告
Tier 4 · 社區討論 — Hacker News、Reddit 技術帖
Tier 5 · 社交軼事 — Twitter 帖子串、未驗證信息

這套來源評估標準也有配套紅旗降級規則。如果某個來源存在利益衝突、混淆因果性或使用情緒化的語言，Agent 會自動給這個來源降級。

當進行跨視角合成時，至少需要 4 個視角同時指向同一方向，才能形成高置信度的結論。單個視角之間的矛盾並不會被解決，而是會被記錄下來。

這套系統最大的價值在於：可復現性。對於同一個來源，LLM 今天可能認爲它是"高可信"，明天又可能會因爲另一些"證據"而跳過。而如果把評估標準寫進文件，Agent 就會用同一個尺子次次都對標。

6.3 Research Skill Graph 的侷限性和適用邊界

說完優勢，Research Skill Graph 還有三個需要你注意的侷限性。

該系統的天花板取決於你寫視角的文件質量。 效果上限 = 視角文件寫得有多嚴謹。你如果在反向視角文件裏面，寫的核心問題跟技術視角文件差不多，那 Agent 產出出來的所謂“反向分析”，除了用來反向的角度之外，跟技術分析沒有區別。

錯誤會越積累越多。 如果 Agent 在某個項目裏寫了一個錯誤的數據點到 data-points.md，下次項目恢復性時會繼承過去項目的 data-points.md。這個問題跟維基百科面臨的"錯誤積累"問題是一樣的：越早期的錯誤會越致命，因爲其後所有內容都是用它建立的。

沒有銀彈。 此方法最適合於：（1）需要深度思考的分析場景；（2）時間較充裕的項目（幾天到幾周的時間量級）；（3）需要可審計性的使用場景，例如儲蓄調查、政策分析或者投資決策支持。不適合一二類問題：對答機器人（“這個 bug 怎麼修”）、百度分答（“vLLM 最新版本是多少”）或創意寫作（寫小說、設計 Logo）。

7: 1+1>2 — LLM Wiki x Research Skill Graph 實戰組合

LLM Wiki 回答的是"我知道什麼"。Research Skill Graph 回答的是"我怎麼研究"。

兩個系統在技術棧上天然兼容。都用純 Markdown 文件，都用 [[wikilinks]] 做節點互連，都在 Obsidian 裏運行，都能被 Claude Code 直接讀寫。

不需要任何適配層。放進同一個 Vault 就能用。

7.1 組合方案實戰：一個研究課題的完整旅程

下面用一個具體的研究課題走一遍完整流程。課題："LLM 推理成本優化"。

第一步：LLM Wiki 編譯知識。 把 30 篇相關素材拖進 raw/。論文（vLLM、TGI 的技術報告）、技術博客（Hugging Face 的推理優化系列）、benchmark 報告（Speculative Decoding 的延遲對比數據）。

每條素材逐一 ingest。LLM 編譯出實體頁面（[[vLLM]]、[[Tensor Parallelism]]、[[Speculative Decoding]]）、概念頁面（[[KV Cache 優化]]、[[量化方法]]）、比較頁面（[[vLLM vs TGI]]）。

矛盾被自動標記。論文 A 說 INT4 量化幾乎無損，論文 B 在長文本場景下測出顯著質量下降，這個衝突會被寫進相關頁面的"contradictions"段。

一條素材更新 10-15 個頁面。30 條素材跑完，你的 Wiki 裏已經有了一張推理優化領域的知識網絡，有實體、有概念、有衝突、有時間線。

第二步：Skill Graph 六視角分析。 在 research-skill-graph/index.md 中填入研究問題。Agent 啓動研究流程，先讀 index.md，再讀方法論文件，然後逐視角分析。

連接點在 knowledge/ 目錄。Agent 做六視角分析時，會直接引用 Wiki 上已經編譯好的頁面，而不需要重新檢索。六個視角每個都有單獨的路線：

Technical 視角：引用 [[KV Cache 優化]] 的 benchmark 結果和 [[vLLM vs TGI]] 的對比實驗結果。這些都是經過驗證、Tier 1/Tier 2 源頭整理編譯的產物。
Economic 視角：整合不同方案的硬件投入和 TCO 數據。節省下來的推理算力去哪了？換來了更多的部署複雜度？這些 Tradeoff 要通過金錢來衡量。
Historical 視角：梳理推理優化技術是如何從貪心解碼 → Speculative Decoding → MoE 演進的。每一步的優化解決了什麼問題，又帶來了什麼新問題。
Contrarian 視角：對剛剛整理到的結論提出質疑。假設“成本優化是無價的”的前提是不對的。在特定場景下，優化帶來的延遲抖動和工程複雜度，可能讓你比裸加 GPU 還要虧錢。
First Principles 視角：歸 Zero。推理就是矩陣乘法運算，由於矩陣不能緩存，所以成本被內存帶寬鎖定。以此爲底線，哪些優化算子是根本，哪些只是在浪費運算資源在邊界“優化”？

第三步：合成閉環。 六視角分析完成後，關鍵發現被寫回 Wiki。比如"Speculative Decoding 在長文本場景下的實際 ROI 低於理論值"，這個發現變成 Wiki 的新頁面或已有頁面的更新段落。下次 ingest 新素材時，這些已編譯的洞察參與更新。

正循環就這樣轉起來了：Wiki 提供持續積累的知識燃料，Skill Graph 用方法論引擎精煉出洞察，洞察寫回 Wiki 成爲新的已編譯知識。每一個循環都讓兩個系統同時變得更厚。

文章說了兩件事：知識如何存儲（LLM Wiki），知識如何運用（Research Skill Graph）。

存和用是同一個飛輪的兩面。只存不用，Wiki 變成數字垃圾場。只用不存，每次研究從零開始。

Karpathy 在推文裏說了一句話：