---
schemaVersion: 1
slug: mp-243-20260404-pawelhuryn-29000-bookmarks-knowledge-system
ticketId: MP-243
lang: zh-tw
title: 29,000 個收藏背後：Paweł Huryn 談會自己長大的知識系統
summary: Karpathy 分享用 LLM 建 personal knowledge base 的心得，被收藏 29,000 次。Huryn 認為真正的殺手功能不是讀，是寫回去 — 當 LLM 能自動更新知識庫，個人 wiki 就變成了個人研究團隊。
originalDate: 2026-04-03
translatedDate: 2026-04-04
source: "@PawelHuryn on X"
sourceUrl: https://x.com/PawelHuryn/status/2039976101477298582
author: null
authorshipNote: null
canonicalUrl: https://gu-log.vercel.app/posts/mp-243-20260404-pawelhuryn-29000-bookmarks-knowledge-system
status: published
replacementTicketId: null
replacementUrl: null
---

# 29,000 個收藏背後：Paweł Huryn 談會自己長大的知識系統

> **來源:** [@PawelHuryn on X](https://x.com/PawelHuryn/status/2039976101477298582)

[Andrej Karpathy](https://gu-log.vercel.app/glossary#andrej-karpathy) 最近在 X 上的一則貼文，被收藏了 29,000 次。

不是什麼新模型發佈、不是什麼 benchmark 破紀錄。就是一個觀察：最近大量的 token 用量，不是拿去寫 code，而是拿去建 personal knowledge base。

Product Compass 的 Paweł Huryn 看到這則貼文，直接把討論推向了另一個層次：

> You don’t need RAG. You need an INDEX.md, structured directories, and an LLM that reads the right files at the right time.

Huryn 的解讀是，這 29,000 次收藏反映出：Karpathy 說中了不少 CLAUDE.md 使用者早就在做的事。但 Huryn 真正想講的不是「這招大家都會」。他想講的是：Karpathy 還沒做到的那一步，才是分水嶺。

## 從「讀」到「寫回去」— 知識系統的質變

先講 Karpathy 的起手式。

Karpathy 發現自己最近用 LLM 的方式正在改變：以前大部分 token 花在 code manipulation，現在越來越多花在 knowledge manipulation。具體來說，就是針對各種研究主題，用 LLM 幫忙建構、整理、更新一套個人知識庫。

> **Mogu 吐槽時間：**
>
> Karpathy 的原文被 29,000 次收藏，Huryn 認為這代表大家心裡早就有同感。這種集體「對對對就是這個」的共鳴，比任何 benchmark 都能說明一個趨勢正在發生 (￣▽￣)／

Huryn 接過話頭，說他已經用這套方法跑了好幾個月，累積超過 120 個知識檔案。但他強調的重點完全不在檔案數量。

重點在於：**LLM 會寫回去。**

每次分析結束後，LLM 不是吐出答案就收工。按照 Huryn 的說法，每一次分析都會更新系統 — templates、hypotheses、performance data 都會被寫回知識庫。知識庫不是一個被動的倉庫，而是一個會自己長大的有機體。

這就是 Huryn 說的那個 gap：

> That’s the gap between a personal wiki and a personal research team.
>
> 這就是「個人 wiki」和「個人研究團隊」之間的差距。

---

## 不是 RAG — 是結構化目錄

Huryn 的主張很直接：不需要 RAG。需要的是 INDEX.md、結構化目錄、和一個會在對的時間讀對的檔案的 LLM。

這句話的重點不在於全面否定 RAG 的技術價值，而是在指出另一種工作方式的存在：與其依賴 embedding 檢索把「看起來相關」的 chunk 塞進 context window，不如讓 LLM 直接知道知識放在哪裡、怎麼找。

> **Mogu 插嘴：**
>
> 換個比喻：RAG 像是每次要找資料就去圖書館用關鍵字搜尋，找到幾本看起來相關的書，影印幾頁帶走。Huryn 描述的系統像是有一個研究助理，助理不只幫忙找書，還會在讀完之後更新研究筆記。下次再來的時候，筆記已經是最新版的了。圖書館 vs. 研究團隊，定位完全不同 (๑•̀ㅂ•́)و✧

而且更關鍵的差異在於：Huryn 的系統會寫回去。RAG 是被動的 — 被問到才去撈資料，撈完就結束。Huryn 說的是一個每次互動後都會自動更新的系統。

---

## Compound Knowledge — 複利效應

Huryn 把這套方法的核心價值濃縮成一句話：

> The knowledge base compounds on its own.

知識庫會自己複利成長。Templates、hypotheses、performance data — 每一次使用都在替下一次鋪路。就 Huryn 的描述來看，這代表每次分析都會把新內容寫回系統，讓下一次工作能站在前一次的結果上，而不是每次從零開始。

> **Mogu 真心話：**
>
> 120 個以上的知識檔案，跑了好幾個月。真正值得注意的不是數量，是這個系統的時間維度 — 用越久，累積越多經過實戰驗證的 insight，LLM 每次開工前能參考的東西就越豐富。Huryn 說這是 personal research team，從這個角度看確實不誇張 ╰(°▽°)╯

---

## 結語

按照 Huryn 的說法，真正的差別不只是讓 LLM 讀資料，而是讓 LLM 在每次分析後把結果寫回去。Karpathy 的貼文引爆了 29,000 次收藏，而 Huryn 認為下一步才是關鍵 — 從「用 LLM 查知識」到「讓 LLM 維護知識」。

這也是 Huryn 眼中「個人 wiki」和「個人研究團隊」之間的那條線。一邊是一個被動的倉庫，另一邊是一個每次互動後都會自動更新的系統。INDEX.md、結構化目錄、會在對的時間讀對檔案的 LLM — 工具都已經在那裡了。