今天不聊新工具，聊點(diǎn)更高級(jí)的東西——三個(gè)巨佬的知識(shí)管理哲學(xué)

還有我自己的知識(shí)管理及內(nèi)容生成工作流

Karpathy

昨天 Andrej Karpathy（斯坦福 PhD、OpenAI 創(chuàng)始成員、前特斯拉 AI 總監(jiān)、CS231n（全球最火深度學(xué)習(xí)課程）締造者）發(fā)了條長推，炸了整個(gè) AI 圈子。

這條推文的核心觀點(diǎn)是：他現(xiàn)在把大部分 token 預(yù)算花在了"操作知識(shí)"上，而不是"操作代碼"。

什么意思？

他搭了一套 LLM 驅(qū)動(dòng)的個(gè)人知識(shí)庫系統(tǒng)，用 Obsidian 做前端，Markdown 做底層格式，LLM 負(fù)責(zé)一切臟活累活。

整個(gè)系統(tǒng)的架構(gòu)可以拆成五個(gè)模塊：

Karpathy 知識(shí)庫系統(tǒng)：五大模塊 1. 數(shù)據(jù)導(dǎo)入（Data Import）

把各種原始素材——論文、文章、代碼庫、數(shù)據(jù)集、圖片——統(tǒng)統(tǒng)丟進(jìn) raw/ 目錄。

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

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

2. 知識(shí)編譯（Wiki Compilation）

這是整個(gè)系統(tǒng)最核心的一步——讓 LLM 把 raw/ 目錄里的散碎材料"編譯"成一個(gè)結(jié)構(gòu)化的維基。

具體做什么？

• 為每份原始數(shù)據(jù)生成摘要

• 建立反向鏈接（backlinks）

• 將數(shù)據(jù)分類到不同的概念

• 為每個(gè)概念撰寫專題文章

• 將所有文章互相鏈接

注意這個(gè)詞：編譯（compile）

Karpathy 用的是編程的隱喻——原始數(shù)據(jù)是"源碼"，維基是"編譯產(chǎn)物"，LLM 就是那個(gè)"編譯器"

3. 問答驅(qū)動(dòng)（Q&A）

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

一個(gè)關(guān)鍵的發(fā)現(xiàn)：他本以為需要搞復(fù)雜的 RAG，但實(shí)際上 LLM 自己維護(hù)的索引文件和摘要就夠用了。

在這個(gè)規(guī)模下，Agent 可以比較輕松地讀取所有重要的相關(guān)數(shù)據(jù)。

這點(diǎn)我必須插一嘴——40 萬字對(duì)現(xiàn)在的長上下文模型來說真不算什么。

Gemini 的百萬 token 窗口，Claude 的 200K 上下文，處理這個(gè)量級(jí)的知識(shí)庫綁綁有余。

Karpathy 說不需要 RAG，在這個(gè)規(guī)模下我同意

4. 輸出呈現(xiàn)（Output）

Karpathy 不喜歡在終端里看答案

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

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

5. 健康檢查（Health Check）

定期讓 LLM 對(duì)維基做"體檢"：

• 查找數(shù)據(jù)不一致的地方

• 用網(wǎng)絡(luò)搜索填充缺失信息

• 發(fā)現(xiàn)有趣的關(guān)聯(lián)，建議新的文章候選

• 提出下一步要調(diào)查的問題

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

用一張流程圖來理解 Karpathy 的系統(tǒng)：

Lex Fridman：把知識(shí)庫變成跑步伙伴

Karpathy 發(fā)完推，Lex Fridman 秒回——他也有類似的系統(tǒng)。

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

Lex 的設(shè)置和 Karpathy 類似，但有幾個(gè)獨(dú)特的點(diǎn)：

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

Lex 不滿足于 Markdown 的靜態(tài)渲染——他經(jīng)常讓 LLM 生成動(dòng)態(tài) HTML 頁面（帶 JavaScript），這樣他可以對(duì)數(shù)據(jù)排序、篩選，交互式地調(diào)整可視化

做播客的知識(shí)管理需求：因?yàn)椴タ图钨e覆蓋的領(lǐng)域極廣，Lex 的研究興趣數(shù)量和多樣性遠(yuǎn)超普通人。

這種場(chǎng)景下知識(shí)庫方法的優(yōu)勢(shì)更明顯——你不可能把所有領(lǐng)域的知識(shí)都記在腦子里。

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

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

你品品：一個(gè)人一邊跑步一邊跟 AI 討論量子力學(xué)或者神經(jīng)科學(xué)。

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

kepano：Obsidian 創(chuàng)始人的"冷水"

然后 Obsidian 的創(chuàng)始人 kepano（Steph Ango）出來說話了

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

"我更喜歡我的個(gè)人 Obsidian 倉庫具有高信號(hào)噪聲比，并且所有內(nèi)容都有已知的來源。"

kepano 的核心觀點(diǎn)：你的個(gè)人筆記庫應(yīng)該是"你"的思想的體現(xiàn)，而不是 AI 的。

他的建議是：

1. 保持個(gè)人倉庫干凈 ——這是你的思維主場(chǎng)

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

3. 只在 Agent 產(chǎn)出有用工件時(shí) ，才手動(dòng)搬到主倉庫

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

• 搜索 會(huì)被 AI 生成內(nèi)容淹沒

• 反向鏈接 不再局限于你真正思考過的內(nèi)容

• 圖譜視圖 變成 AI 的知識(shí)圖譜，不再是你的

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

這段話的背后是 kepano 一貫的哲學(xué)

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

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

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

理解力本身就是你最大的資產(chǎn)

在他的個(gè)人 Obsidian 實(shí)踐中，他甚至直接說：

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

Karpathy 的方法論是天才級(jí)別的，Lex 的應(yīng)用場(chǎng)景讓人拍案叫絕，kepano 的警告確實(shí)發(fā)人深省

他們?nèi)齻€(gè)人講的是知識(shí)管理鏈路上不同的環(huán)節(jié)

我在做的事：補(bǔ)上"最后一公里"

Karpathy 搭的是一個(gè)知識(shí)積累與檢索系統(tǒng)——把數(shù)據(jù)灌進(jìn)去，編譯成知識(shí)，然后查詢和輸出。

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

這就是我做的事——知識(shí)管理的下游：內(nèi)容生產(chǎn)流水線。

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

看出區(qū)別了嗎？

Karpathy 的系統(tǒng)是 raw/ → wiki/ → query——知識(shí)的上游。

我的系統(tǒng)是 素材 → skills/ → 文章 → 視頻 → 社交媒體——知識(shí)的下游。

它們不是競(jìng)爭(zhēng)關(guān)系，是上下游互補(bǔ)關(guān)系

Karpathy 解決的問題是：大量散碎信息怎么變成可查詢、可增長的結(jié)構(gòu)化知識(shí)？ 我解決的問題是：有了知識(shí)和選題，怎么高效地變成文章、視頻、社交內(nèi)容？

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

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

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

所以理想的完整架構(gòu)，應(yīng)該是把上下游接起來：

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

這也是我接下來要補(bǔ)的課——給自己的系統(tǒng)加上 Karpathy 式的"知識(shí)編譯層"，讓過去寫的每一篇文章都成為未來創(chuàng)作的養(yǎng)料。

關(guān)于 kepano 的"污染論"

kepano 擔(dān)心 AI 生成的內(nèi)容會(huì)"污染"個(gè)人知識(shí)庫

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

這個(gè)擔(dān)心是合理的

不過在我的實(shí)際操作中，我用的是另一條路：溯源標(biāo)記。

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

兩種方案各有道理

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

我的溯源標(biāo)記更靈活，適合人機(jī)協(xié)作頻繁、產(chǎn)出量大的場(chǎng)景

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

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

如果你連自己知識(shí)庫里的內(nèi)容都沒讀過、沒消化過，那這個(gè)知識(shí)庫再大也不是你的

Karpathy 最有遠(yuǎn)見的一句話

Karpathy 整個(gè)推文我認(rèn)為最有遠(yuǎn)見的一句話：

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

這才是真正的終局——從上下文到權(quán)重

現(xiàn)在所有的知識(shí)管理方案，本質(zhì)上都是在"上下文工程"的范疇內(nèi)打轉(zhuǎn)

把知識(shí)塞進(jìn)上下文窗口讓 LLM 讀取——管你是 RAG 還是直接長上下文

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

三人觀點(diǎn)對(duì)比

維度

Karpathy

Lex Fridman

kepano

核心身份

AI 研究者 / 教育者

播客主持人 / 研究者

Obsidian CEO / 產(chǎn)品哲學(xué)家

知識(shí)庫用途

研究探索

多領(lǐng)域播客準(zhǔn)備

個(gè)人思維記錄

對(duì) LLM 的態(tài)度

全面擁抱，讓 LLM 管理一切

擁抱但重視多模態(tài)輸出

審慎，警惕過度依賴

Obsidian 角色

只是"前端渲染器"

混合前端之一

思維的延伸

核心哲學(xué)

"編譯知識(shí)"

"知識(shí)要可交互"

"文件優(yōu)先于應(yīng)用"

最大貢獻(xiàn)

完整方法論框架

語音交互式學(xué)習(xí)

人機(jī)邊界思考

One More Thing

三位巨佬給了我們?nèi)齻€(gè)視角：

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

• Lex 打開了知識(shí)消費(fèi)的新維度——語音對(duì)話、動(dòng)態(tài)可視化、運(yùn)動(dòng)中學(xué)習(xí)

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

而我在做的事情，是補(bǔ)上下游的最后一公里——把知識(shí)變成文章、視頻、社交媒體內(nèi)容，讓它流動(dòng)起來：

積累（Karpathy）→ 消費(fèi)（Lex）→ 守護(hù)（kepano）→ 生產(chǎn)（老章）→ 反哺積累

你的知識(shí)管理系統(tǒng)，走到了哪一環(huán)？

參考資料：

1. Andrej Karpathy — X/Twitter 長推文，2026 年 4 月，關(guān)于 LLM 驅(qū)動(dòng)的個(gè)人知識(shí)庫系統(tǒng)

2. Lex Fridman — 對(duì) Karpathy 推文的回復(fù)，關(guān)于混合前端和語音模式知識(shí)消費(fèi)

3. kepano (Steph Ango) — 對(duì) Karpathy 推文的回復(fù)，關(guān)于個(gè)人倉庫與 Agent 倉庫分離

4. Steph Ango, "File over app" — stephango.com/file-over-app — 文件優(yōu)先于應(yīng)用的產(chǎn)品哲學(xué)

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

6. Steph Ango, "How I use Obsidian" — stephango.com/vault — Obsidian 創(chuàng)始人的個(gè)人筆記實(shí)踐

7. Andrej Karpathy 個(gè)人頁面 — karpathy.ai — 個(gè)人經(jīng)歷與項(xiàng)目列表