基于大模型、SKills 的知識管理

今天不聊新工具，聊點更高級的東西——三個巨佬的知識管理哲學

還有我自己的知識管理及內容生成工作流

Karpathy

昨天 Andrej Karpathy（斯坦福 PhD、OpenAI 創始成員、前特斯拉 AI 總監、CS231n（全球最火深度學習課程）締造者）發了條長推，炸了整個 AI 圈子。

這條推文的核心觀點是：他現在把大部分 token 預算花在了"操作知識"上，而不是"操作代碼"。

什么意思？

他搭了一套 LLM 驅動的個人知識庫系統，用 Obsidian 做前端，Markdown 做底層格式，LLM 負責一切臟活累活。

整個系統的架構可以拆成五個模塊：

Karpathy 知識庫系統：五大模塊 1. 數據導入（Data Import）

把各種原始素材——論文、文章、代碼庫、數據集、圖片——統統丟進 raw/ 目錄。

用 Obsidian Web Clipper 瀏覽器插件一鍵裁剪網頁文章為 .md 文件，配合快捷鍵把相關圖片下載到本地。

核心思路：先不管三七二十一，把所有原始材料攢在一起。

2. 知識編譯（Wiki Compilation）

這是整個系統最核心的一步——讓 LLM 把 raw/ 目錄里的散碎材料"編譯"成一個結構化的維基。

具體做什么？

• 為每份原始數據生成摘要

• 建立反向鏈接（backlinks）

• 將數據分類到不同的概念

• 為每個概念撰寫專題文章

• 將所有文章互相鏈接

注意這個詞：編譯（compile）

Karpathy 用的是編程的隱喻——原始數據是"源碼"，維基是"編譯產物"，LLM 就是那個"編譯器"

3. 問答驅動（Q&A）

當維基長到足夠大（他舉例說他某個研究方向的維基有約 100 篇文章、40 萬字），就可以開始向 LLM Agent 提各種復雜問題了。

一個關鍵的發現：他本以為需要搞復雜的 RAG，但實際上 LLM 自己維護的索引文件和摘要就夠用了。

在這個規模下，Agent 可以比較輕松地讀取所有重要的相關數據。

這點我必須插一嘴——40 萬字對現在的長上下文模型來說真不算什么。

Gemini 的百萬 token 窗口，Claude 的 200K 上下文，處理這個量級的知識庫綁綁有余。

Karpathy 說不需要 RAG，在這個規模下我同意

4. 輸出呈現（Output）

Karpathy 不喜歡在終端里看答案

他更傾向于讓 LLM 生成 Markdown 文件、Marp 格式的幻燈片、matplotlib 圖表，然后在 Obsidian 里直接查看

更聰明的是：他會把輸出"歸檔"回維基，這樣每次探索和查詢都會"累積"在知識庫里，讓它越用越富

5. 健康檢查（Health Check）

定期讓 LLM 對維基做"體檢"：

• 查找數據不一致的地方

• 用網絡搜索填充缺失信息

• 發現有趣的關聯，建議新的文章候選

• 提出下一步要調查的問題

他說 LLM 在"建議進一步的問題"這件事上做得相當好。這不就是我們說的 Agent 自主探索 嗎？

用一張流程圖來理解 Karpathy 的系統：

Lex Fridman：把知識庫變成跑步伙伴

Karpathy 發完推，Lex Fridman 秒回——他也有類似的系統。

Lex 的身份不用多介紹了吧？全球最火的 AI 播客主持人，他的 Lex Fridman Podcast 采訪過 Elon Musk、Sam Altman、Mark Zuckerberg、Karpathy 本人，以及一堆你叫得出名字的科技大佬

Lex 的設置和 Karpathy 類似，但有幾個獨特的點：

前端混合體：Obsidian + Cursor（用來編輯 .md 文件）+ 自己 vibe-coded 的網頁終端

Lex 不滿足于 Markdown 的靜態渲染——他經常讓 LLM 生成動態 HTML 頁面（帶 JavaScript），這樣他可以對數據排序、篩選，交互式地調整可視化

做播客的知識管理需求：因為播客嘉賓覆蓋的領域極廣，Lex 的研究興趣數量和多樣性遠超普通人。

這種場景下知識庫方法的優勢更明顯——你不可能把所有領域的知識都記在腦子里。

最炸裂的用法——跑步語音播客：Lex 會讓系統為特定主題生成一個臨時的迷你知識庫，加載進 LLM，然后在 7-10 英里的長跑中開啟語音模式。

跑步的時候，它就變成了一個交互式播客——他可以隨時提問、聽答案、深入探討。

你品品：一個人一邊跑步一邊跟 AI 討論量子力學或者神經科學。

知識的攝入方式從"坐著讀"變成了"邊跑邊聊"

kepano：Obsidian 創始人的"冷水"

然后 Obsidian 的創始人 kepano（Steph Ango）出來說話了

他沒有否定 Karpathy 的方法，而是提出了一個很微妙的警告：

"我更喜歡我的個人 Obsidian 倉庫具有高信號噪聲比，并且所有內容都有已知的來源。"

kepano 的核心觀點：你的個人筆記庫應該是"你"的思想的體現，而不是 AI 的。

他的建議是：

1. 保持個人倉庫干凈 ——這是你的思維主場

2. **給 Agent 一個單獨的"雜亂倉庫"**——讓 AI 在那里隨便折騰

3. 只在 Agent 產出有用工件時 ，才手動搬到主倉庫

他擔心什么？如果人類寫的和 AI 寫的混在一起太多：

• 搜索 會被 AI 生成內容淹沒

• 反向鏈接 不再局限于你真正思考過的內容

• 圖譜視圖 變成 AI 的知識圖譜，不再是你的

• 你無法 追溯 哪些想法是自己的、哪些是機器生成的

這段話的背后是 kepano 一貫的哲學

他寫過一篇很有名的文章叫 **"File over app"**（文件優先于應用），核心主張是：

如果你希望你的寫作在 2060 年甚至 2160 年的電腦上仍然可讀，那它最好在 1960 年代的電腦上也能被讀取。

他還寫過 **"Don't delegate understanding"**（不要把理解力外包）——你可以讓 AI 幫你干活，但不能讓 AI 替你思考

理解力本身就是你最大的資產

在他的個人 Obsidian 實踐中，他甚至直接說：

"有人問我能不能用 LLM 自動化筆記整理，但我不想這么做。我享受這個過程。做這種維護工作幫助我理解自己的模式。"

Karpathy 的方法論是天才級別的，Lex 的應用場景讓人拍案叫絕，kepano 的警告確實發人深省

他們三個人講的是知識管理鏈路上不同的環節

我在做的事：補上"最后一公里"

Karpathy 搭的是一個知識積累與檢索系統——把數據灌進去，編譯成知識，然后查詢和輸出。

但作為一個每周要輸出 3-5 篇技術文章、配套口播視頻、社交媒體內容的人，我需要的不只是"積累"和"查詢"，我需要把知識變成內容產品推出去。

這就是我做的事——知識管理的下游：內容生產流水線。

zhangAI/                          # Karpathy 說的"知識庫"
├── 1-Wechat/                     # 公眾號文章（成品庫）
│   ├── Archive/                  # 已發布文章
│   └── ing/                      # 正在寫的稿子
├── .agent/skills/                # 58 個 AI Skill（執行層）
│   ├── 1-write_tech_article_pro/ # 技術文章撰寫
│   ├── 1-title_generator/        # 標題生成（3種風格）
│   ├── 1-video-script-converter/ # 文章→口播稿
│   ├── 1-doubao-tts-voice-clone/ # 口播稿→克隆語音
│   ├── audio-to-video/           # 語音→豎版短視頻
│   ├── 1-upload-images-to-picgo/ # 圖片→個人圖床
│   ├── design_svg_card/          # 知識卡片設計
│   └── ...還有 50 多個
├── Video/                        # 視頻產物
│   ├── 口播稿/
│   ├── 口播音頻/
│   └── 成品視頻/
├── Clippings/                    # Karpathy 說的 raw/ 目錄
├── CLAUDE.md                     # AI Agent 的"操作手冊"
├── AGENTS.md                     # Codex 的上下文配置
└── GEMINI.md                     # Gemini 的指令文件

看出區別了嗎？

Karpathy 的系統是 raw/ → wiki/ → query——知識的上游。

我的系統是 素材 → skills/ → 文章 → 視頻 → 社交媒體——知識的下游。

它們不是競爭關系，是上下游互補關系

Karpathy 解決的問題是：大量散碎信息怎么變成可查詢、可增長的結構化知識？ 我解決的問題是：有了知識和選題，怎么高效地變成文章、視頻、社交內容？

一篇文章從素材到成品視頻，我的 Skill 流水線是這樣的：

一條命令"幫我寫篇技術文章"觸發 write_tech_article_pro Skill，輸出 Markdown 成品。然后"轉成口播稿"觸發 video-script-converter，接著"用豆包轉成音頻"觸發 doubao-tts-voice-clone，最后"音頻轉視頻"觸發 audio-to-video

從一篇文章到一條短視頻，全程約 8 分鐘，傳統方式需要 2-3 小時。

所以理想的完整架構，應該是把上下游接起來：

Karpathy 的知識編譯層（上游：積累、編譯、檢索）
            ↓
    老章的內容生產流水線（下游：寫作、配音、視頻）
            ↓
    發布 & 多形態分發
            ↓
    反饋回知識庫（閉環）← 這一步大家都還沒完全做好

這也是我接下來要補的課——給自己的系統加上 Karpathy 式的"知識編譯層"，讓過去寫的每一篇文章都成為未來創作的養料。

關于 kepano 的"污染論"

kepano 擔心 AI 生成的內容會"污染"個人知識庫

他的解決方案是兩個倉庫——一個干凈的給自己，一個臟的給 AI

這個擔心是合理的

不過在我的實際操作中，我用的是另一條路：溯源標記。

在我的系統里，每個 Skill 生成的文件都有清晰的來源標記——YAML 頭部的 author 字段、文件路徑本身（比如 Video/口播稿/ 一看就知道是 AI 轉的）、以及 Skill 的執行日志。這樣不需要物理隔離，也能知道每一段內容是誰寫的、用什么工具寫的、基于什么素材寫的

兩種方案各有道理

kepano 的物理隔離更干凈純粹，適合把 Obsidian 當"思維延伸"的人；

我的溯源標記更靈活，適合人機協作頻繁、產出量大的場景

不過 kepano 有句話我是完全同意的——**"Don't delegate understanding"**

你可以讓 AI 幫你整理知識，但你不能讓 AI 替你理解知識

如果你連自己知識庫里的內容都沒讀過、沒消化過，那這個知識庫再大也不是你的

Karpathy 最有遠見的一句話

Karpathy 整個推文我認為最有遠見的一句話：

"隨著倉庫的增長，自然地也想考慮合成數據生成 + 微調，讓你的 LLM '知道'數據在其權重中，而不僅僅是上下文窗口。"

這才是真正的終局——從上下文到權重

現在所有的知識管理方案，本質上都是在"上下文工程"的范疇內打轉

把知識塞進上下文窗口讓 LLM 讀取——管你是 RAG 還是直接長上下文

但想象一下：如果你能用自己積累的 40 萬字知識庫微調一個專屬的小模型，讓它從骨子里"理解"你的領域知識和思考方式。那就不是"你問它答"了，那是你訓練了一個數字分身。

三人觀點對比

維度

Karpathy

Lex Fridman

kepano

核心身份

AI 研究者 / 教育者

播客主持人 / 研究者

Obsidian CEO / 產品哲學家

知識庫用途

研究探索

多領域播客準備

個人思維記錄

對 LLM 的態度

全面擁抱，讓 LLM 管理一切

擁抱但重視多模態輸出

審慎，警惕過度依賴

Obsidian 角色

只是"前端渲染器"

混合前端之一

思維的延伸

核心哲學

"編譯知識"

"知識要可交互"

"文件優先于應用"

最大貢獻

完整方法論框架

語音交互式學習

人機邊界思考

One More Thing

三位巨佬給了我們三個視角：

• Karpathy 搭了知識管理的上游基建—— raw/ → compile → wiki → query

• Lex 打開了知識消費的新維度——語音對話、動態可視化、運動中學習

• kepano 守住了最重要的底線—— 知識庫的主人是你，不是 AI

而我在做的事情，是補上下游的最后一公里——把知識變成文章、視頻、社交媒體內容，讓它流動起來：

積累（Karpathy）→ 消費（Lex）→ 守護（kepano）→ 生產（老章）→ 反哺積累

你的知識管理系統，走到了哪一環？

參考資料：

1. Andrej Karpathy — X/Twitter 長推文，2026 年 4 月，關于 LLM 驅動的個人知識庫系統

2. Lex Fridman — 對 Karpathy 推文的回復，關于混合前端和語音模式知識消費

3. kepano (Steph Ango) — 對 Karpathy 推文的回復，關于個人倉庫與 Agent 倉庫分離

4. Steph Ango, "File over app" — stephango.com/file-over-app — 文件優先于應用的產品哲學

5. Steph Ango, "Don't delegate understanding" — stephango.com/understand — 不要將理解力外包的警示

6. Steph Ango, "How I use Obsidian" — stephango.com/vault — Obsidian 創始人的個人筆記實踐

7. Andrej Karpathy 個人頁面 — karpathy.ai — 個人經歷與項目列表