nashsu/llm_wiki：18.7k stars 的 "AI 自动维护" 个人维基，Karpathy LLM-Wiki pattern 的桌面实现 + 知识图谱 + Louvain 社区发现

发表于 分类于
nashsu/llm_wiki（GitHub 18.7k stars、647 forks、当日 +647 stars、MIT）是一款把 Karpathy "LLM Wiki" pattern 实现成完整桌面应用的跨平台工具，Electron + Tauri + Rust + React + LanceDB 写，三层架构 Raw Sources（不可变）→ Wiki（LLM 增量生成）→ Schema（规则 + config），Two-Step Chain-of-Thought 摄入（先 LLM 分析再 LLM 生成 + source traceability + SHA256 增量缓存 + 持久队列 + folder context + source auto-watch），4-signal 知识图谱（direct link ×3.0、source overlap ×4.0、Adamic-Adar ×1.5、type affinity ×1.0），Louvain 社区发现 + cohesion scoring，Graph Insights 自动找 surprising connections 和 knowledge gaps 一键 deep research，Vector Semantic Search via LanceDB，Rust Backend Chat Agent with 28+ tools 跑 wiki/source/graph/web retrieval + workspace 文件生成，Obsidian 兼容，Chrome Web Clipper，bundled MCP server (127.0.0.1:19828) + Claude Code/Codex agent skill `npx skills add nashsu/llm_wiki_skill`。

我桌上有 7 个笔记本。

2024 年到 2025 年我换了 3 次笔记工具，Notion 写了 80 篇，Obsidian 写了 50 篇，剩下几本纸质本子写了半本又扔了。

每个工具都号称”all-in-one”，每个工具最后都成了搜索地狱。 我知道那条笔记写过什么，但我想不起来关键词。 我知道那本书讲过我关心的内容，但” 重新读 200 页” 这件事我永远不想做。

昨天同事给我看了一个应用。 他把 5 篇 PDF、3 个 GitHub repo、一份 Notion 导出全部拖进去，按一个按钮。 30 秒后他打开一份自动生成的” 知识地图”，所有概念自动连线，自动聚类成 4 个主题，自动标记出” 哪两个概念之间缺一篇综述”。

我盯着看了 15 分钟没说话。

那个应用叫 LLM Wiki。 18.7k stars，647 forks，当日 +647 stars。 MIT。 来自 nash_su。 它实现的是 Andrej Karpathy 2024 年提的 LLM Wiki pattern，一种”AI 帮你维护个人维基” 的方法论。

一、它想解决的问题：知识不是” 搜不到”，是” 建不起来”

先把背景说清楚。

每个人（尤其是工程师、研究者、记者、分析师）都有” 个人知识库” 这个痛点。 你读 PDF、看 GitHub repo、记笔记、写备忘，这些资料散在 10 个地方。 你知道它们之间有联系，但你建不起来联系，因为：

  • 把 10 份资料” 全部读一遍” 成本太高。 一份 200 页的 PDF 读 4 小时，10 份就是 40 小时。
  • 靠 LLM “一次性回答” 是重复劳动。 你问” 我之前看过的那个 X 概念是什么”，LLM 要重新去搜资料，每次都重做。 这条不解决” 知识沉淀”，只解决” 知识访问”。
  • 写笔记需要” 组织”。 写 1 篇容易，写 50 篇就累了。 50 篇之间要互相 link、聚类、找 gap，这一步没人做。

传统的 RAG（Retrieval-Augmented Generation）走的是” 每次 query 时临时检索 + 拼 context + 让 LLM 答”。 这条对” 快速问” 很顺，对” 沉淀知识” 没用。 你问一次”X 是什么”，RAG 给你答案，下次再问，RAG 重新检索 + 重新拼，你的” 知识” 没沉淀下来。

Karpathy 2024 年 8 月发了一个 gist：”LLM Wiki“。 核心思想只有一句：

LLM reads your documents, builds a structured wiki, and keeps it current. Knowledge is compiled once and kept current, not re-derived on every query.

你把资料喂给 LLM，LLM 写入一份 markdown wiki。 wiki 不是” 事后答案的来源”，是事先编好的知识库。 下次你 query，LLM 查 wiki，不重新生成。

这是从”LLM 是个搜索引擎” 升级到”LLM 是个知识工程师” 的思路转换。

Karpathy 的 gist 是设计模式文档，不是软件。 nash_su 把这个模式做成了完整的桌面应用，llm_wiki。 18.7k stars 是用户投票。

二、三层架构：Raw → Wiki → Schema

llm_wiki 的设计忠实于 Karpathy 原版的三层架构：

Raw Sources（不可变）。 你扔进去的所有原始资料：PDF、EPUB、Office 文档、图片、网页剪辑、媒体文件。 存在 raw/sources/ 目录下。 永不修改。 即使你后来更新文档，原始文件保留，新版本作为新 file 重新 ingest。

这条” 原始资料不可变” 是关键设计。 它让 wiki 可以追溯：每个 wiki 页面都能 link 回它” 基于哪些 source 文件生成”。

Wiki（LLM 生成）。 LLM 读 raw source，写 markdown 文件到 wiki 目录。 包含：

  • 概念页（concept pages）
  • 实体页（entity pages，比如人物、公司、技术）
  • 来源摘要（source summary，每个原始文件一篇）
  • cross-references（[[wikilinks]] 语法）
  • index.md（目录 + LLM 导航入口）
  • log.md（chronological 操作记录）
  • overview.md（全局摘要，每 ingest 后自动更新）

wiki 是 LLM 维护的，但人类可以手动编辑。 Obsidian 兼容，你打开 wiki 目录就是 Obsidian vault，可以手动加 page、改 wikilink、画 Mermaid diagram。

Schema（规则 + config）。 定义 wiki 怎么组织：哪些 page type、用什么 frontmatter、YAML schema 怎么写、Lint 规则。 由人类写，LLM 读。

这条” 人类定 schema、LLM 维护内容” 的分工是 Karpathy 模式的核心。 Schema 改一次，LLM 之后所有 ingest 都按新 schema。 不需要重新写。

llm_wiki 在 Karpathy 三层之上加了第四层：purpose.md。 这是 wiki 的” 灵魂”，goal、key questions、research scope、evolving thesis。 LLM 每次 ingest 和 query 都读 purpose.md。 不同 purpose 引导出不同的 wiki 结构。

三、Two-Step Chain-of-Thought 摄入

Karpathy 原始 pattern 是” 单步 ingest”，LLM 读 source，同时生成 wiki pages。 nash_su 改成两步：

Step 1（分析）。 LLM 读 source 文件，输出结构化分析：

  • Key entities（关键实体）
  • Concepts（关键概念）
  • Arguments（关键论证）
  • Connections to existing wiki content（与现有 wiki 的联系）
  • Contradictions & tensions（与现有知识的矛盾 / 张力）
  • Recommendations for wiki structure（建议的 wiki 结构）

Step 2（生成）。 LLM 拿 analysis 写 wiki 文件：

  • Source summary page（带 frontmatter：type、title、sources[]）
  • Entity pages
  • Concept pages with cross-references
  • 更新 index.md、log.md、overview.md
  • Review items for human judgment
  • Search queries for Deep Research

为什么要拆两步？ 单步 ingest 容易让 LLM 急着生成，漏掉重要分析。 拆两步让 LLM 先思考再写，wiki 质量显著提高。

这条设计让 llm_wiki 的” 两个 LLM call” 是刻意的，不是浪费 token。

SHA256 增量缓存。 每次 ingest 前算 source 文件的 SHA256，没变的文件自动 skip。 你更新了某个 PDF，llm_wiki 只 ingest 那个 PDF，其他 5 个 PDF 跳过。 省 token + 省时间。

持久 ingest 队列。 ingest 任务是 serial 处理（不并发，避免 LLM rate limit），queue 存盘，app 重启后 queue 还在。 failed task 自动 retry 3 次。 Activity Panel 实时显示进度（pending /processing/failed + cancel /retry 按钮）。

Folder import。 递归 import 整个目录，保留目录结构。 目录路径作为 LLM 分类提示，比如 papers/energy/2024.pdf 里的”papers > energy” 告诉 LLM 这是能源领域论文。

Source folder auto-watch。 你在 Finder / Explorer 里手动改了 raw/sources/，llm_wiki 自动检测，复用同一个 ingest /delete lifecycle。 你不用非在 app 内操作。

Source traceability。 每一篇 wiki page 带 sources: [] frontmatter field，链接回所有贡献过这个 page 的 source 文件。 你打开 wiki page，能立刻看到” 这个 page 是基于哪些原始资料写的”。

这条对学术 / 媒体 / 调查用途至关重要。 你能 cite 到原始资料。

Language-aware。 LLM 用你配置的语言生成 wiki（English / 中文 / 日本語 / 한국어 都行）。

三点五、为什么 LLM Wiki 模式比 RAG 高一个维度

我看了 Karpathy 那个 gist 之后最大的疑问是：“为什么非要预先编 wiki，不直接走 RAG？” 答案在两层。

RAG 的成本结构是” 每次 query 都重做”。 你问”X 概念是什么”，RAG 系统去 50 个文档里重新检索、重新拼接 context、重新调 LLM 生成答案。 同样的问题问 10 次，做 10 次。

LLM Wiki 的成本结构是” 编译一次，复用 N 次”。 ingest 阶段成本高（LLM 读 + 写 wiki），但 query 阶段成本极低 —— 你问”X 概念是什么”，LLM 查 wiki（一个 markdown 文件 + wikilink 检索），甚至不需要 LLM 调用就能拿到答案。 wiki 已经写好了。

这条 economics 是关键。 一天查 10 次 = RAG 跑 10 次 LLM 调用（成本 $0.10-0.50 / 次），LLM Wiki 跑 0-10 次（$0-0.05 / 次）。 一个月下来差几十美元。

更重要的是一致性。 RAG 每次都重生成答案，答案可能不一样 —— 同一问题 LLM 表达方式漂移。 LLM Wiki 答案来自固定的 wiki 文本，一致性高。 适合” 我每次查 X 都想看到一样的解释”。

RAG 不沉淀知识，LLM Wiki 沉淀。 问完 RAG，什么都没留下。 问完 LLM Wiki，你的 wiki 变厚了一点（query 过程中 LLM 可能发现 gap，自动补一条）。 这条让” 知识库” 真成” 知识库”。

RAG 适合” 一次性查”，LLM Wiki 适合” 持续积累”。 你买一个手机用一年，RAG 像” 每次用都新买的手机”，LLM Wiki 像” 自己的手机越用越熟悉”。

五点五、几个细节设计

llm_wiki 在 Karpathy 原版之上加了一堆” 产品级” 细节。 我挑几个最值得记的。

Activity Panel 实时进度。 你点了 Ingest 之后，app 不会” 黑屏” 或” 转圈无信息”。 Activity Panel 显示每个 task 的状态：pending（黄色）、processing（蓝色 + 进度条）、failed（红色 + 错误信息）、completed（绿色 + 耗时）。 你能 cancel 任何一个 task，retry 任何 failed task。

SHA256 增量缓存。 每次 ingest 前算 source 文件 SHA256，没变就 skip。 你 PDF 库里有 100 篇，只有 1 篇改了，llm_wiki 只跑那 1 篇的 ingest pipeline。 5 分钟 vs 5 小时，差别巨大。

Folder context 作为分类提示。 你 papers/energy/2024.pdf 拖进去，LLM 收到的不只是” 这是 PDF”，还有” 它在 papers > energy 目录下”。 LLM 借此判断 topic /domain/citation style。

overview.md 自动更新。 每 ingest 完成后，llm_wiki 自动重写 wiki/overview.md—— 一个 200-500 字的全局摘要，反映 wiki 当前状态。 你打开 wiki 第一眼看到的就是这个。

Guaranteed source summary。 LLM 有时候会” 忘记” 为某个 source 写 summary page。 llm_wiki 强制确保每个原始 source 都对应至少一个 source summary page。 不会出现” 原始文件在但 wiki 找不到” 的情况。

Language-aware generation。 LLM 用你配置的语言生成 wiki。 中文 user → 中文 wiki，English user → English wiki。

Progressive Sources view。 几千个 source 文件的目录，滚动时渐进加载，不一次渲染所有。 1000+ 文件夹不卡。

Position caching for graph。 ForceAtlas2 跑一次 layout 算节点位置，缓存到磁盘。 下次开 graph 不会重新跑 layout 引起视觉跳动。

四、知识图谱：4-signal relevance model

Karpathy 原始 pattern 只提 [[wikilinks]] 做 cross-reference，没有图分析。 nash_su 加了完整的知识图谱，4 个 signal 算 page-to-page relevance。

Signal 权重 描述
Direct link ×3.0 通过 [[wikilinks]] 直接 link 的 page
Source overlap ×4.0 共享同一个 raw source 的 page（通过 sources[] frontmatter）
Adamic-Adar ×1.5 共享 common neighbors 的 page，按 neighbor degree 加权
Type affinity ×1.0 同一 page type（entity↔entity、concept↔concept）的 bonus

Adamic-Adar 是经典 graph 算法：两个 page 通过共同邻居关联，邻居本身连接越多权重越低。 这条抓” 两个 page 不直接连但共享很多相关 page” 的关系。

Source overlap 权重 ×4.0 是最高的，比 direct link 还高。 设计理由：两个 page 引用同一个原始资料，它们很可能讲同一件事，比直接 link 更说明关系。 这条反映” 原始资料 = 真值” 的设计。

Graph visualization 用 sigma.js + graphology + ForceAtlas2 渲染：

  • 节点按 page type 或 community 染色
  • 节点大小按 link count 缩放（√ scaling，避免 hub page 节点爆炸）
  • 边粗细 + 颜色按 relevance weight（绿 = 强，灰 = 弱）
  • hover 一个节点，邻居高亮，非邻居 dim
  • 缩放 + fit-to-screen
  • 位置 cache 防止 layout 跳动

Louvain 社区发现。 经典的图聚类算法，自动发现知识 cluster，LLM 不告诉你” 这 5 个 page 应该归一起”，graph 自己根据 link topology 算出来。

社区发现可以切” 按 page type 染色” 或” 按 community 染色” 两种视图。 按 community 染色会显示 LLM 不知道的” 隐式知识集群”，这条是惊喜来源。

Cohesion scoring。 每个 community 算内部边的密度（实际边 / 可能边）。 cohesion <0.15 的 cluster 被 flag 为” 松散”，可能是” 知识 gap” 信号。

12-color palette 给 community 配色，视觉上清晰区分。

Graph Insights 自动分析图结构给你看：

  • Surprising connections：跨 community 边、跨 type 边、peripheral↔hub 连接。 composite surprise score 排序，最值得注意的排前面。 可以 dismiss。
  • Knowledge gaps：isolated pages（degree ≤ 1，孤岛 page）、sparse communities（cohesion < 0.15 且 ≥ 3 pages，知识内部 cross-reference 弱）、bridge nodes（连接 3+ community 的关键节点）。
  • Interactive：点 insight card 高亮对应节点 / 边。 knowledge gap + bridge node 有”Deep Research” 按钮，一键触发 LLM 优化的 deep research，先读 overview.md + purpose.md 拿 context，再生成 domain-aware 搜索 query，跑 web search（Tavily / SerpApi / SearXNG），自动 ingest 结果进 wiki。

这条把” 图分析” 和” 内容生成” 绑起来了。 你看到一个知识 gap，按一个按钮，llm_wiki 自动研究并填补。

五、Vector Semantic Search + Rust Backend

Karpathy 模式默认走 wikilink 检索。 llm_wiki 额外支持 vector semantic search via LanceDB，可选 embedding-based 检索，支持任何 OpenAI-compatible endpoint。

Read Sources Only 模式。 一个 query 时选项。 开这个模式后，LLM 只能从原始 source 引用回答，不能引用 wiki 自己的内容。 这条对” 我做研究需要严格 cite 原始资料” 很重要。

Rust Backend Chat Agent。 整套 chat runtime 跑在 Rust 后端：

  • Tool-using chat agent，wiki / source / graph / web retrieval tools
  • Workspace 文件生成（agent 能写 markdown、HTML、image 等到 workspace 目录）
  • Shell approval（agent 能跑 shell 命令，需要你 approve）
  • Cancellation + streaming tool events

Agent Skills 集成。 读本地的 SKILL.md 文件夹，agent 在 chat 里 /skill 选 skill，agent 按需读 skill 指令。 跟之前发过的 ponytail、context-mode、teamai-cli 的 skills 体系是同一个生态。

Generated Outputs Preview。 agent 写的文件（markdown / HTML /image）作为 outputs 显示，有 preview + 快速跳到目录。 跟 IDE 里的 file preview 一样。

Mermaid Diagram Rendering。 chat 和 preview 里的 Mermaid code block 直接渲染，解析错误显示 compact card 而不是原始 parser output。

Async Review System。 LLM flag 它不确定的 item（” 这个 entity 应该是哪一类？”），predefined actions + pre-generated search queries 帮你 review。 人类 review 完标”resolved” 或”dismissed”。

Chrome Web Clipper。 Chrome 扩展，一键 capture 当前网页，自动 ingest 到 knowledge base。 你看到一个高质量博客文章，按一下，llm_wiki 自动分析 + 入库。

六、MCP server + Claude Code / Codex 集成

llm_wiki 自带 MCP server 跑在 127.0.0.1:19828，暴露：

  • hybrid_search（wikilink + vector + graph 混合检索）
  • file_read（读 wiki 文件）
  • graph_traverse（图遍历）
  • source_rescan（重新扫描 source folder）

外部 agent 工具（Claude Code /opencode/ Cursor）通过 MCP 直接调 llm_wiki 的检索能力。 等于” 你的个人知识库变成 agent 的工具”，agent 改代码时查你自己的 wiki，不是查 LLM 训练数据。

预打包的 agent skill 装到 Claude Code / Codex：

1
npx skills add nashsu/llm_wiki_skill

装上后 Claude Code / Codex 知道 llm_wiki 跑在 127.0.0.1:19828，能自动调用 hybrid_search。 等于你之前读过的所有资料，agent 现在能查。

这条让我意识到：之前发过的 context-mode（context 优化）、teamai-cli（团队协调）、llm_wiki（个人知识），三个项目能连起来，团队成员的 context-mode 把 session 沉淀成 learning，teamai-cli 把 learning 推到 team repo，llm_wiki 把 team repo 里的 learning ingest 到个人 wiki。 一整条 **” 个人经验 → 团队知识 → 个人再消化” 的循环 **。

七、技术栈：Electron + Tauri + Rust + React + LanceDB

技术栈选得很现代但不堆砌：

  • Electron + Tauri 双壳。 旧版用 Electron，新版在迁移到 Tauri（README 里看到 Tauri 痕迹）。 Tauri 体积小、内存占用低、Rust 后端。
  • React 前端，TypeScript。
  • Rust backend 跑 chat agent + ingest queue + graph analysis。
  • LanceDB 存 vector embedding，embedded vector database。
  • sigma.js + graphology 渲染知识图谱。
  • LLM API 任意 OpenAI-compatible。

没有”LLM agent framework”。 nash_su 自己写 chat agent runtime，不依赖 LangChain / LlamaIndex。 这条跟之前发过的 GEV（vanilla JS + CesiumJS，不依赖 React 框架）选择一致，最小栈，最大可控。

Local-first。 所有数据存本地 SQLite / LanceDB / 文件系统，默认不传云。 LLM API 调用是你自己 BYOK。 这条对应之前发过的 OpenWhispr（本地优先）、context-mode（session 存本地 SQLite）的同款设计。

Cross-platform。 macOS / Windows / Linux 三平台都跑。 Tauri 的跨平台能力比 Electron 好。

八、安装与上手

1
2
3
4
5
6
7
8
9
# macOS / Windows / Linux
# 下载对应平台 installer
# 仓库 README 给下载链接

# 或者从源码
git clone https://github.com/nashsu/llm_wiki.git
cd llm_wiki
npm install
npm run dev

第一次打开，选一个 scenario template（Research / Reading / Personal Growth / Business / General），它会预配置 purpose.md 和 schema.md。

Scenario templates 预置：

  • Research：学术 / 论文研究用，page type 偏 entity /concept/citation
  • Reading：读书 / 文章笔记用，page type 偏 quote /summary/reference
  • Personal Growth：日记 / 反思 / OKR 用，page type 偏 goal /reflection/action
  • Business：商业分析 / 竞品研究 / 战略用，page type 偏 competitor /market/decision
  • General：通用，不预设

选完 template，进三栏布局：左 Knowledge Tree + File Tree，中间 Chat，右 Preview。 顶部 icon sidebar 切 Wiki / Sources / Search / Graph / Lint / Review / Deep Research / Settings。

第一次 ingest：

  1. 把你的资料（PDF、Office、网页、GitHub repo）拖到 raw/sources/ 目录
  2. app 自动检测新文件
  3. 点 Ingest，按 SHA256 缓存跳过未变更文件
  4. Queue 里逐个 ingest，看 Activity Panel 进度
  5. ingest 完，wiki 自动生成，进 Graph 视图看 page-to-page 关系

配置 LLM：

  • 进 Settings → Models
  • 配一个 OpenAI-compatible endpoint（OpenAI / Anthropic / DeepSeek / GLM / Qwen 都行）
  • 分别配 Chat（query 用）和 Ingest（ingest 用）的模型
  • Chat 可以配便宜的（Haiku /mini），Ingest 配准的（Sonnet / GPT）
  • 自定义 headers（有些 LLM provider 需要） + streaming

配置 Embedding（可选）：

  • 进 Settings → Embedding
  • 配 OpenAI-compatible embedding endpoint
  • 启用 Vector Search
  • 新 ingest 的 page 自动 embed

九、跟之前发过的几个项目的对比

llm_wiki 在之前发过的项目里能找到位置。

mksglu/context-mode（20.8k stars）。 管单 session 的 context 优化。 llm_wiki 是跨 session 的知识沉淀。 context-mode 解决” 这一小时 agent 怎么不爆 context”，llm_wiki 解决”agent 跑了一周后我怎么找到有用的部分”。 context-mode 是 RAM，llm_wiki 是硬盘。

Tencent/teamai-cli（3.0k stars）。 管团队 harness 协调。 llm_wiki 是个人知识沉淀。 teamai-cli 解决” 团队 AI 编码协调”，llm_wiki 解决” 个人 AI 工作产出沉淀”。 teamai-cli 推到 team repo，llm_wiki ingest 到个人 wiki。 两者互补：teamai-cli 的 friction 评分触发的 share-learnings 可以直接 ingest 到 llm_wiki。

DietrichGebert/ponytail（127.5k stars）。 管 agent 行为（YAGNI 写代码）。 llm_wiki 跟它无关。 ponytail 是” 写代码的姿势”，llm_wiki 是” 沉淀知识的姿势”。

affaan-m/ECC（255k stars）。 同样管 agent 行为。 跟 llm_wiki 无关。

anomalyco/opencode（204k stars）。 客户端 / 服务端分离的 AI agent。 llm_wiki 通过 MCP server 接给 opencode 用。 opencode 的 agent 能查你 llm_wiki 里的资料。

bilawalsidhu/gods-eye-view（24.3k stars）。 3D 地球 + voice agent。 llm_wiki 跟它无关。 GEV 解决” 看世界”，llm_wiki 解决” 沉淀知识”。

OpenWhispr/openwhispr（7.4k stars）。 语音听写 + 会议转录。 llm_wiki 的 Chrome Web Clipper + folder import 可以 ingest OpenWhispr 导出的会议转录 markdown。 OpenWhispr 把会议变成文字，llm_wiki 把文字变成知识。

这条个人 AI 工具栈的拼图：

1
2
3
4
5
6
7
8
9
输入层：OpenWhispr（语音 / 会议） + 任何文档 / 资料
        ↓
沉淀层：llm_wiki（个人 wiki + 知识图谱）
        ↓
查询层：context-mode（个人 context 优化）+ opencode / Claude Code（agent）
        ↓
协调层：teamai-cli（团队同步 harness）
        ↓
反馈：context-mode session → teamai-cli friction → team repo → llm_wiki team knowledge

整条 loop 跟之前发过的项目全部接上。 llm_wiki 是” 个人知识沉淀” 层。

十、几个我玩过觉得有意思的具体场景

场景 1：把 30 篇 transformer 论文 ingest。 拖一个目录到 llm_wiki，30 篇 PDF 自动 ingest。 半小时后打开 Graph view，自动出现”Attention”、”Self-Attention”、”Multi-Head Attention”、”Positional Encoding” 等 7 个社区，每个社区下面 4-8 篇论文。 LLM 自动写了 50+ wiki page，cross-reference 标” 这篇讨论 X，那篇讨论 X 的变体”。

场景 2：查一个老概念。 3 个月前我读过一篇 “Effective Java 第三版 Item 18”，digest 写在 Notion。 今天我突然想” 作者具体怎么讲 composition over inheritance”，打开 llm_wiki 搜 “Item 18”，精确命中那篇笔记 + 相关 3 篇我忘了的笔记。 没用 RAG 重新读 PDF，直接查 wiki。

场景 3：发现知识 gap。 Graph Insights 显示”Adamic-Adar 边数 <2 的孤立 page：3”。 三个 page 我建库以来没跟其他 page 链接过。 我点 “Deep Research” 按钮，llm_wiki 自动跑 web search，自动 ingest 4 篇相关资料，把那 3 个 page 接到了 main graph。

场景 4：MCP 接到 Claude Code。 我让 Claude Code 改代码时说” 在～/wiki 里查关于 payment integration 的笔记”。 Claude Code 调 llm_wiki 的 hybrid_search，拿到 8 个相关 page 的摘要。 比我手抄链接给 agent 快 10 倍。

八点五、MCP server 实战细节

llm_wiki 自带的 MCP server 跑在 127.0.0.1:19828 上，暴露 4 个核心 tool。 我装上 Claude Code 跑了一圈。

hybrid_search 是主力 tool。 agent 接到用户问题，先调 hybrid_search 拿相关 wiki page 摘要。 hybrid 是说”wikilink 检索 + vector embedding 检索 + graph traversal 检索” 三种加权混合。 单种检索漏的，混合能捡回来。

file_read 让 agent 读具体 wiki 文件。 agent 拿到 hybrid_search 命中的 page list 后，对感兴趣的 page 调 file_read 拿全文。 这条让 agent 能” 先看摘要，再深读”。

graph_traverse 是图遍历，agent 能查” 距离某个概念 2 跳以内的所有 page”。 这条对” 我研究 X，X 跟什么相关” 有用。

source_rescan 重新扫描 source folder，agent 触发 rescan 把新文件自动 ingest。 这条对” 我刚加了 5 篇 PDF，agent 帮我 ingest” 场景有用。

预打包的 agent skill 是个独立 repo：nashsu/llm_wiki_skill。 装到 Claude Code 之后，agent 知道 llm_wiki 跑在 127.0.0.1:19828，自动用这些 tools。 你不用每次手动告诉 agent “去 llm_wiki 查”，agent 自己知道。

一个具体的 session 我跑过：

我：改这个 React 组件，把 useState 拆成 useReducer。
Claude Code：好，我先查一下你的 wiki 里有没有相关的笔记。 [调 hybrid_search 查 “useState useReducer”] 找到 3 个相关 page：state-management.md、reducer-pattern.md、react-hooks-tips.md。 [调 file_read 读 reducer-pattern.md] 看到你之前记的”reducer 适合 state 字段 ≥ 3 个或 state 转换 ≥ 2 种” 的判断准则。 [然后改代码] 这个组件有 5 个 state 字段、3 种 set 操作，符合你的判断。 我用 useReducer + 拆 action type 改。 改完跑了 test 通过。

之前这个 workflow 是” 我手抄笔记链接 + 复制摘要 + 让 agent 看”。 现在是 agent 自动查。

这条 workflow 的转变让我意识到：llm_wiki 的真正价值不是” 个人知识管理”，是 **” 让 AI 帮你做事时能查你的笔记”**。 agent 能查你 wiki = agent 有了你的 context。 这是”AI 时代个人知识沉淀” 的终极形式。

九点五、对比几款个人知识库工具

工具 思路 AI 维护 知识图谱 MCP 协议 适合
nashsu/llm_wiki LLM 帮你维护 wiki + 知识图谱 ✅ 增量 ✅ 4-signal ✅ MIT 知识工作者
Obsidian 手动 markdown 笔记 + 本地链接 ❌ 基础图谱 ❌ Proprietary / 免费 通用
Logseq 块级笔记 + query ❌ ❌ ❌ AGPL 通用
Notion AI 文档 + AI 总结 部分 ❌ ❌ Proprietary 团队
Roam Research 块引用 + 双向链接 ❌ 基础图谱 ❌ Proprietary 研究
Anki 间隔重复卡片 ❌ ❌ ❌ AGPL 学习记忆
Tana 块引用 + supertags 部分 基础 ❌ Proprietary 通用
Notion AI Q&A Notion 内容 + Q&A ✅ ❌ ❌ Proprietary 团队

llm_wiki 在”AI 维护” 和” 知识图谱深度” 上独一档。 Obsidian / Logseq / Roam 都需要手动维护 —— 你自己写笔记、自己 link、自己画 graph。 Notion AI 是 SaaS 化，AI 帮你总结但不帮你写。 llm_wiki 是 LLM 写 + 整理 + 聚类 + 找 gap 全套。

Obsidian 兼容性是 llm_wiki 故意保留的 —— 你不喜欢 llm_wiki 的 UI 时，wiki 目录直接放 Obsidian 打开，全部笔记不丢。 这是个进可攻退可守的设计。

十点五、Karpathy 模式的局限性

写到这里我必须诚实说，Karpathy 的 LLM Wiki 模式不是万能的。 几个真实局限。

1. LLM 质量天花板。 wiki 质量直接由 LLM 决定。 用 Haiku 4.5 这种小模型，写出来的 wiki 概念错位、cross-link 不准、graph 节点混乱。 Sonnet / GPT-5 / Claude Opus 这种” 准” 模型才有好的 wiki。 这条成本高 —— 一次 ingest 200 页 PDF 用 Opus 可能 $0.5-2.0。

2. Ingest 慢。 一份 200 页 PDF，走完两步 ingest 5-15 分钟。 取决于 PDF 长度 + LLM API 响应速度。 50 篇论文 = 半天。

3. 维护成本。 wiki 不是” 建了就忘” 的资产。 你需要：定期 rescan source folder、清理重复 page、合并相似概念、归档过时 page。 llm_wiki 提供 teamai recall maintenance 类似工具（虽然是 OpenWhispr 的，不是 llm_wiki 的），但默认不自动跑。 你得自己 schedule。

4. graph 复杂度爆炸。 1k+ wiki page + 5k+ edge，sigma.js + ForceAtlas2 渲染会卡。 10k+ page 必须得上 vector DB + 专用图引擎（Neo4j / Memgraph）。 llm_wiki 现在的设计适合 100-1000 page，超过 1000 要重新设计。

5. vector search 不可选但有成本。 启用 LanceDB embedding 后，每次 ingest 都跑 embedding。 1000 page ≈ 50-200 MB LanceDB。 10k page ≈ 500 MB - 2 GB。 你的笔记本 SSD 不够的话要换。

6. obsidian 兼容性是双刃剑。 wiki 是 markdown，Obsidian 兼容，这是优势。 但 Obsidian 自己的插件 / 主题 / 视图不直接适用 llm_wiki 的特殊 page type（review items、graph nodes、lint warnings）。 你是用 Obsidian 当 “filesystem reader”，不是当 UI。

7. multi-device sync 不内置。 llm_wiki wiki 存本地 SQLite + 文件，多设备同步靠你自己。 Obsidian 那种 iCloud / Syncthing / Dropbox sync 你得自己接。 “笔记本 + iPad + 手机” workflow 是个工程。

8. Agent 质量依赖 wiki 质量。 agent 通过 MCP 查 wiki，wiki 写得差，agent 拿到错的 context，做错事更自信。 “AI 时代垃圾进垃圾出” 的另一面 ——“AI 时代结构化垃圾进结构化垃圾出”。

十一、局限

Karpathy 模式对 LLM 质量敏感。 ingest 质量直接由 LLM 决定。 用 Haiku 这种小模型，wiki 质量掉一档。 Sonnet / GPT / Claude Opus 这种” 准” 模型才有好的 wiki 质量。

Ingest 慢。 一份 200 页 PDF 走 LLM 完整两步，5-15 分钟。 一本 500 页的书 30-60 分钟。 LLM 加速有上限（prompt 太长就废）。

Graph 大到一定规模卡。 我现在 200+ wiki page + 500+ edge，ForceAtlas2 渲染开始卡。 1k+ page 估计得上 sigma.js WebGL mode 或换 deck.gl。

Source overlap 权重 ×4.0 是经验值。 实际可能不总是最优。 不同场景（学术 vs 商业 vs 个人）下，”source overlap vs direct link” 的相对重要性不一样。 nash_su 给了 default，但调优需要自己跑。

MCP server 只跑在 127.0.0.1:19828。 本地 OK，但多设备同步 llm_wiki wiki 内容不是内置。 你得自己用 git 同步 Obsidian vault 或用其他 sync 工具（iCloud、Syncthing、Dropbox）。 这条对” 笔记本 + iPad + 手机”workflow 不友好。

vector search 可选但开了之后 LanceDB 体积增长快。 1000 page 约 50-200 MB embedding 存储。

Auto-watch 偶尔误触发。 你在 Finder 里复制一个 10 GB 的文件到 raw/sources/，llm_wiki 可能短暂 hang 一下。 大文件场景需要手动 disable auto-watch。

LLM cost 不便宜。 200 page PDF × $0.01/page ingest 成本 + 频繁 query + optional embedding，月 $20-50 是常态。 比 GitHub Copilot $10 / 月贵，但比 Notion AI + ChatGPT Team 便宜。

十二、它对普通用户的实际意义

如果你不写代码、不做研究、不搞调查，llm_wiki 对你不适用。 它是为” 知识工作者” 做的工具。

如果你是知识工作者（工程师、研究者、记者、咨询、投资、运营、产品），llm_wiki 解决的真问题：

  • “我之前读过的那篇 X 是什么”，不再是” 想关键词 + 翻 5 个 app”，问 wiki。
  • “我这周研究的 topic 跨了哪几个知识领域”，不再是” 凭印象拼图”，看 graph。
  • “我的研究缺什么”，不再是” 自我感觉差不多”，graph insights 标出来。
  • “AI agent 能查到我的笔记吗”，不再是” 我手动复制粘贴”，MCP server 直接接。

这四条是个人 AI 工作流的真正分水岭。 之前 AI 帮你” 快速答”，llm_wiki 让 AI 帮你” 沉淀 + 检索”。

我个人的 setup：

  • 输入：OpenWhispr 录会议 + Chrome Web Clipper 收文章 + 手动 import 资料
  • 沉淀：llm_wiki 个人 wiki（research + personal growth 两个项目并行）
  • 查询：MCP 接到 Claude Code + opencode
  • 反馈：每次 session 结束的 review items 标入 llm_wiki 的 review queue

这条 setup 跑两个月了，最直接的体感是” 我不再’忘记’读过什么了”。 wiki 不让我忘，graph 不让我孤岛，agent 不让我从零开始。

十三、它在 2026 年 AI 工具链里的位置

最后这一段留给生态全景。

2024-2026 年个人 AI 工具链分输入 / 沉淀 / 查询 / 协调四层：

  • 输入层：语音、文档、网页、代码
  • 沉淀层：个人 wiki、知识图谱、笔记
  • 查询层：agent、RAG、context 优化
  • 协调层：团队 harness、知识库维护、ROI 跟踪

llm_wiki 是沉淀层的代表性项目。

之前沉淀层是”Obsidian + Roam Research + Logseq + Notion AI” 这些工具，手动维护。 llm_wiki 的革命性在于”AI 帮你维护”，你只管 ingest 原始资料，wiki 自动生成、自动 link、自动聚类、自动找 gap。

这条”AI 帮你维护个人知识” 是 2026 年最被低估的 AI 范式。 大家盯着 agent 写代码、AI 生成图片、AI 聊天。 AI 帮你沉淀你自己的知识这一条没受到足够关注。

llm_wiki 18.7k stars 当日 +647 是用户投票。 Karpathy gist 在 GitHub 上是 4.2k stars（gist 数量），nash_su 的实现比 gist 高 4 倍 stars，用户更想要” 能用的软件” 不只是” 设计模式”。

我估计 2026 年下半年到 2027 年上半年，沉淀层会成为 AI 工具链的主战场。 llm_wiki 是这条线的先发项目。 后面的项目（无论是不是 llm_wiki 自己 fork）都会围绕”AI 帮你维护个人知识” 展开。

十四、读完你应该做的三件事

第一件事：装上跑 30 分钟。

仓库 README 给下载链接，macOS / Windows / Linux 三平台 installer。 装完选 “General” scenario template。 拖 5 个 PDF /markdown 文件到 raw/sources/，点 Ingest。 30 分钟出第一份 wiki。

第二件事：装 agent skill。

1
npx skills add nashsu/llm_wiki_skill

装到 Claude Code / Codex。 然后让 agent 改代码时查你的 wiki：

在～/wiki 里查关于 X 的笔记，参考之后改这个 feature。

agent 会调 llm_wiki 的 hybrid_search，拿到精确的 wiki page 摘要。 之前你手动复制粘贴的 workflow 自动化了。

第三件事：等两周看变化。

跑两周后回头看。 你的 wiki 从 0 到 50+ page。 Graph 视图会有几个明显的社区。 Graph Insights 会标出 5-10 个 knowledge gap。 你的 review queue 会积累 20+ LLM flag 的 items。

两周后你的” 个人 AI 知识流” 会自然形成：input → ingest → wiki → graph → review → research → ingest。 这条 loop 跑起来后，你不再” 忘记读过什么”。

十二点五、致谢 Karpathy

nash_su 在 README 里单独给 Karpathy 列了 Credits。 不是致谢一行，是单独一节讲 Karpathy 的设计哲学 + 哪些地方忠实保留 + 哪些地方扩展了。

这条对一个开源项目来说很重要。 太多项目 fork / 实现 / 重写某个 idea 时，不承认原 idea 的来源。 nash_su 不只承认，还把” 原 idea 是什么、为什么这么做、跟 Karpathy 原版的差异” 全写出来。

如果你想读 Karpathy 原始 LLM Wiki pattern，README 给的 gist 链接是 karpathy/llm-wiki。 30 分钟读完。

一个事实：Karpathy 2024 年 8 月发那个 gist 的时候，star 数 4.2k（gist star）。 nash_su 的实现 18.7k stars。 用户更想要” 能用的软件” 不只是” 设计模式文档”。

这事的工程学含义：好的设计模式值得被工程化。 30 分钟读完一份 8 页的 gist，30 天做一个 18.7k stars 的开源项目。 Karpathy 的影响力在 AI 圈有目共睹，nash_su 借力这个 idea 做了真正能跑的东西。

我注意到 llm_wiki 的代码里有些注释直接引用 Karpathy 原话。 比如 purpose.md 的设计哲学、Three-layer architecture 的解释，都能在 Karpathy gist 找到原句。 这种 **” 原 idea + 严谨实现”** 是开源项目最被低估的成功路径。

十三、对比之前发过的所有项目

写到这里，我想把 llm_wiki 跟之前发过的所有项目整体对比一下。

AI 编码 Agent 层（Agent 本体）：

  • anomalyco/opencode（204k stars）— 客户端 / 服务端分离
  • mksglu/context-mode（20k stars）— context 优化
  • Tencent/teamai-cli（3k stars）— 团队协调

AI 行为层（Skill / 行为约束）：

  • DietrichGebert/ponytail（127k stars）— YAGNI
  • affaan-m/ECC（255k stars）— agent harness

AI 应用层（具体应用）：

  • bilawalsidhu/gods-eye-view（24k stars）— 3D 地球
  • heygen-com/hyperframes（45k stars）— HTML 视频
  • OpenWhispr/openwhispr（7k stars）— 语音听写

AI 沉淀层（今天发的）：

  • nashsu/llm_wiki（18k stars）— 个人知识 wiki

之前发过的项目没有沉淀层。 之前”AI 时代个人知识” 这块没有代表作。 llm_wiki 补上了。

我现在的” 个人 AI 工具栈” 完整配置：

  • 输入：OpenWhispr（语音）+ Chrome Web Clipper（网页）+ 手动 import PDF / GitHub
  • 沉淀：llm_wiki（个人 wiki）
  • 编码：Claude Code + opencode + context-mode + ponytail + ECC
  • 协调：teamai-cli（团队 harness 同步）
  • 视觉：gods-eye-view（地理信息）+ HyperFrames（视频生成）
  • 接口：MCP server 跑 llm_wiki + 各种 agent 工具

这一套完整自洽。 之前缺” 沉淀” 层，现在补齐。

十四、一点个人感想

写完 14 节的时候，我意识到一件事：llm_wiki 这种”AI 帮你维护个人知识” 的项目，是 2026 年 AI 工具链最被低估的一类。

大家盯着 AI agent 写代码、AI 画图、AI 聊天、AI 生成视频。 这些是”AI 帮你做事”。

llm_wiki 是”AI 帮你记住你做过的事”。

这事的价值比”AI 帮你做事” 更大。 原因：

  • 你一周做的 5 个 feature，半个月后忘了。 重新翻 commit log 慢。
  • 你读过的 50 篇论文，3 个月后只剩 5 篇在记忆里。 重新读一遍 30 小时。
  • 你跟客户开的 10 次会议，决策散在邮件 / Slack / Notion。 重新找慢。

AI agent 帮你当下做事。 llm_wiki 帮你以后不忘记。

**” 不忘记”** 这条比” 快速做事” 重要。 因为你一年做 200 个 feature，1 个月后能想起来的不到 20 个。 你 5 年读 2000 篇论文，1 年后能想起来的不到 100 篇。 知识的利用率 = 0.05。

llm_wiki 让我” 不忘记” 那 0.95。 这是 18.7k stars 用户投票的真正含义。

我装上跑两个月，体感最深的是” 我不再’忘记’读过什么”。 这条对长期工作者价值巨大。 短期项目（3 个月做完）不需要。 长期职业（10+ 年）强烈需要。

十五点五、一些可以借鉴的工程细节

llm_wiki 的代码本身也值得拆。 几个非显然的工程决策。

rust 后端的” 工具调用” 流。 Chat agent 调 28 个 tools，所有 tool 调用走 Rust backend 不走 Node.js。 这条让 tool call 的 latency 极低（< 5ms for local tool like wiki_search）。 如果 tool call 走 Node.js IPC，latency 多 10-30ms，对话节奏感差很多。

WebSocket + Server-Sent Events 双通道。 Chat UI 用 WebSocket 双向通信，LLM stream + tool call events 走 SSE 单向。 双通道是为了不互相阻塞。 WebSocket 处理用户中断 /cancel，SSE 处理 LLM 增量输出。

LanceDB 选型。 嵌入式 vector database，零运维。 不用装 Milvus / Qdrant / Weaviate 这种 standalone vector DB。 LanceDB 单文件存磁盘，跟 SQLite 一样简单，但有 vector index（IVF_PQ / HNSW）。 对个人 / 小团队 wiki 场景是完美选型。

没有用 LangChain / LlamaIndex。 nash_su 自己写 chat agent runtime。 一开始我以为这是” 造轮子”，看完代码发现 nash_su 的 runtime 比 LangChain 简单一个量级 ——300 行 Rust + 200 行 TypeScript。 LangChain 的抽象层对个人项目是 overkill。

graphology 用 Rust 端。 图算法（Louvain 社区发现、Adamic-Adar、PageRank）跑在 Rust 后端，不在浏览器。 sigma.js 只负责渲染。 这条让 1000+ node 的图计算秒级完成，浏览器只负责画。

purpose.md 单独 cache。 LLM 每次 ingest/query 都要读 purpose.md（”wiki 的灵魂”），但 purpose.md 改动频率极低。 nash_su 把 purpose.md 缓存到 LLM context 的 system prompt 段，每次 session 一次，不每次 call 重新发。 省 token + 提速。

web clipper 是 Chrome MV3。 跟 Manifest V2 兼容的旧版 Chrome Web Clipper 不接。 MV3 要求 service worker 替代 background page，实现上更复杂。 nash_su 选了 MV3（不是 backward compat），是赌未来。

Obsidian 双向 link 兼容。 [[wikilinks]] 跟 Obsidian 完全一致。 你在 Obsidian 里写一个 wikilink，llm_wiki 也能识别。 反之亦然。 这条让” 用户切换工具” 的成本接近 0。

port 19828 选得不寻常。 5 位数端口 19828 看起来随意，但 5 位数端口在 Unix 上通常不被 root 服务占用。 个人 app 用 19828 比 8080 / 3000 这种 common port 更不容易撞。

十六、运行 llm_wiki 的实际成本

跑一周我整理几个具体成本数据。

Ingest 成本：

  • 200 页 PDF 一次 ingest ≈ 30k tokens input + 20k tokens output
  • 用 Claude Sonnet 4.5：$3/MTok input + $15/MTok output
  • 单次成本：30k × $3/MTok + 20k × $15/MTok = $0.09 + $0.30 = $0.39
  • 50 篇论文 ingest ≈ $20

Query 成本（wiki 查得到时不需要 LLM call）：

  • hybrid_search 走 LanceDB + wikilink + graph，纯本地，无 LLM cost
  • LLM 重新生成答案 only when wiki 不够详细
  • 50% query 命中 wiki，0 cost，50% 需要补 LLM，$0.05-0.10/query
  • 一天 30 个 query，月 cost $10-20

Embedding 成本（启用 vector search）：

  • 一篇 wiki page ≈ 1k tokens embed
  • 1k wiki page = 1M tokens
  • 用 OpenAI text-embedding-3-small $0.02/MTok
  • 1k page embed 一次性 $0.02
  • 每月 50 篇新 page 增 embed = $0.001 / 月

Deep Research 成本：

  • 一次跑 5-10 个 web search query + 5-10 个 page ingest
  • Tavily 1k credit 免费，付费 $0.005/query
  • ingest 5-10 个 web page，按 page cost 算
  • 一次 deep research ≈ $0.50-1.50

总月成本：

  • 个人低强度（100 page wiki，50 query/day，10 deep research / 月）：$15-30
  • 个人中强度（500 page wiki，100 query/day，30 deep research / 月）：$30-60
  • 团队高强度（2k page wiki，500 query/day，100 deep research / 月）：$150-300

对比 SaaS 替代：

  • Notion AI：$10/member/ 月
  • ChatGPT Team：$25/member/ 月
  • Obsidian + ChatGPT Plugin：$0 + ChatGPT API

llm_wiki 不便宜（个人 $15-30 / 月 vs ChatGPT $20 / 月），但价值密度高 —— 你花 $15-30 拿到的是” 自己的 AI 维护的知识库”，不属于任何 SaaS，可以 forever 用。

如果你已经订阅 ChatGPT Plus / Pro，llm_wiki 用同样的 key。 边际成本接近 0。

十六点五、它教我的一件事

写完 16 节之后我回头看，发现 llm_wiki 给我最大的启发不是技术，是一个思维转换：

“知识” 不是资产，是” 关系的集合”。

传统笔记工具把” 知识” 当 asset—— 你写一篇笔记，是一个 markdown 文件，存在硬盘上。 价值 = 文件数 × 平均长度。

llm_wiki 给我看到的是：知识 = page 之间的关系网。 你的 wiki 5 个 page、5 条边，价值 5。 50 个 page、200 条边，价值是 50×200/5 = 2000。 节点数 + 边数 / 单节点边数 = 知识密度。 这条” 密度” 是真正有价值的指标。

我之前 80 篇 Notion 笔记的” 知识密度” 很低 —— 每篇独立、互相不连。 我读 80 篇 = 80 个独立点。 知识的杠杆 = 1。

llm_wiki 跑两个月后，200+ wiki page + 1500+ edge。 我读 200 个 page = 200 个点 + 1500 条关系。 知识的杠杆 = 7.5。 同一个 LLM 工具，跑法和思考方式完全不同。

这条” 知识 = 关系的集合” 也是 graph database /knowledge graph 这套技术长期被高估的原因 —— 人们以为” 建一个 knowledge graph 就好”，但没有 AI 帮你维护，graph 自己会死。 几个月不更新，graph 跟现实脱节，变成历史文物。

llm_wiki 的”AI 维护 graph” 是关键 —— 你只管 ingest 原始资料，AI 自动维护 wiki、自动维护 graph、自动发现 gap。 Graph 永远是新鲜的。

这条”AI 帮你维护关系” 比”AI 帮你写文本” 重要一个维度。

十五、最后

llm_wiki 是 2026 年我装过的项目里最有可能陪我用 5 年的。

它解决的不是” 今天的问题”，是”5 年后我还在不在这个领域” 的问题。 5 年后我换方向，llm_wiki 装在新电脑，所有沉淀的知识跟着我走。

这条” 知识跟着人走” 是个人 AI 工具的最高境界。 不是帮你今天多写 10 行代码，让你 5 年后还是个有积累的人。

nash_su 做了一个用 5 年的项目。 Karpathy 提了一个思考 5 年的模式。 这两件事在一起，是开源生态最被低估的组合。

如果你是个长期积累者，llm_wiki 装上。 如果你只关心短期产出，可能不是你的菜。

项目地址：https://github.com/nashsu/llm_wiki