Seven's blog

起因：一个很小的烦恼

我平时看技术文档、英文博客、Wikipedia，经常会卡在一些不认识的单词上。频率不高，但足够烦人——每次遇到，都得中断阅读，切到词典查一下，再想想「这词要不要记下来」。

真要记的话，路径更长：打开背单词 App，手动搜索，手动加进生词本。一个词点五六下，读一篇文档遇到十个生词，光录入就十几分钟过去了。

也试过现成的单词本，但它们和「我当下正在读的这篇网页」是脱节的。词书按主题或考试划分，而我读的是 Github Readme、某个库的 RFC、英文论文——这些页面里的词汇分布，任何一本预制词书都覆盖不好。

我真正想要的其实很简单：看到一篇英文文章，把它里面的生词一次性收集出来，直接进我正在用的背单词 App 的生词本。 这样背的词就是我这周真实读到的词，针对性拉满。

背单词 App 我用的是「不背单词」（bbdc.cn），所以就围绕它做。工具的名字叫「单词雷达 WordRadar」——雷达扫一遍页面，生词就现形了。

功能介绍：极致简约

• 一键添加网页单词到「不背单词」
  最近高频接触各种各样的开源项目和 SKILLs，每天都要直面开源项目文档和 SKILL 介绍等各种英文单词。屡屡查词不如一次背词，索性直接全部添加到生词本，背完便能无障碍阅读原文。
  点一下扩展图标、再点一下「采集当前页」，扩展就把正文里的英文单词全部提取出来，和本地词库对比，弹窗告诉你：本次采集了 N 个单词，其中 M 个是新词。如果不想添加整页单词到生词本，也可以只处理选中文本。

• 词形还原与去重
  采集不是把页面上所有英文词都抓下来完事：先做归一化（所有格剥离，dog's 算 dog；大小写折叠，全大写的 THE 归到 the），再做词形还原（cameras 归到 camera，went 归到 go），按词元去重，过滤缩略词和缩合形式。所以 lived、living、lives 不会以三个词条的面目重复出现在你面前。

• 本地上传
  硬盘里的英文笔记、字幕文件，直接在扩展里上传 .txt / .md 采集，走同一个推送流程。

• 安装便捷
  Chrome / Edge 商店直接装，随版本发布自动更新，不用自己下载源码编译。装好之后打开 bbdc.cn 登录一次，就能开始用。

什么是 LLM-WIKI

LLM-WIKI 是 Andrej Karpathy 大神 2026 年 4 月提出来的一个理念，核心是让大语言模型把阅读、理解、综合、交叉引用、矛盾发现和问答，持续沉淀为一个持久、结构化、互链、带引用的 Markdown 知识库。

Agent owns the wiki; human owns the judgment.

它可以：

• 把离散的信息沉淀成结构化的知识库：通过理解、提炼、总结，把生财有术海量优质内容转换成清洗、糅合过的知识库。从文档中提取 概念/实体/总结 等多层结构，帮助我们更好地理解信息。
• 把文档集合转化为概念图谱：通过 wikilink 在文档和文档之间建立关联，关系脉络一目了然。
• 把问答的过程转换成知识维护过程：有价值的问答沉淀进知识库，问答本身也可以是知识。
• 把 LLM 的阅读工作从一次性消耗变成复利资产：LLM-WIKI 的每次摄入都会沉淀知识，告别传统一次性消耗。
• 维护知识：知识库不是死物，通过定期的 lint 检查和维护知识库，检查断链、修正引用关系、处理冲突、更新陈旧事实，防止知识库腐化。

一张图看懂 LLM-WIKI：

1
2
3
4
5
6
7
8
9
10
11

flowchart TD
    A[Raw Sources<br>网页 / PDF / 代码 / issue / transcript] --> B[Ingest<br>读取、理解、拆解]
    B --> C[Wiki Knowledge Layer<br>Markdown 页面 + wikilinks + citations]
    C --> D[Query<br>基于 wiki 回答问题]
    D --> E{答案有长期价值吗?}
    E -- 是 --> C
    E -- 否 --> F[只返回答案]
    C --> G[Lint / Maintain<br>查断链、无引用、冲突、陈旧事实]
    G --> C
    C --> H[Derived Indexes<br>全文搜索 / 向量 / 图索引 / backlinks]
    H --> D

通过 “资料进入 → 知识编译 → 问答复用 → 好答案回写 → 定期维护 → 知识继续变好” 的核心循环打造知识复利。

Manjaro Linux 用 WiFi（wlp7s0）上网，把网线口（enp8s0）共享给一台下游设备。共享用的不是独立 dnsmasq，而是 NetworkManager 自带的 shared 模式。下游设备能正常上网，但 IP 是 DHCP 动态分的，今天 .108，下次可能 .109。想把那台设备固定成 10.42.0.2，方便后面做端口转发和固定访问。

现场

笔记本同时连着两张网卡：

1
2
3
4
5
6
7
8
9
10
11
12
13

              上游 WiFi（出口）
 wlp7s0  192.168.1.x/24   gw 192.168.1.1     （示例网段）
     │
┌────┴─────┐
│  笔记本   │  Manjaro 26.1 / Kernel 7.1.4
│          │  NetworkManager 1.58（nmcli）/ dnsmasq 2.93
│          │  ipv4.method=shared（共享连接）
└────┬─────┘
     │ enp8s0  10.42.0.1/24
     │  └─ NM 内置 dnsmasq：DHCP 池 10.42.0.10–254，租约 3600s
     ▼
下游设备（share client）
MAC aa:bb:cc:dd:ee:01   （示例）   当前拿到 10.42.0.108

容器重建后 nginx 仍连旧 IP，把请求打到了 Docker 重新分配的别的服务上。根因是 proxy_pass 写主机名只在启动时解析一次并永久缓存，用 resolver + 变量版 proxy_pass 按 TTL 动态解析修复。

自从 Karpathy 提出 llm-wiki 这套理念，我就一直想自己动手搭一个 AI 知识库——用它记录笔记、学习知识，也试着让它指引生活。

几经拖延，最后先让 AI 帮我把 llm-wiki 的生态通盘调研了一遍。结果出乎意料地详实：llm-wiki 为什么出现、解决了什么问题，理念和社区如何发展，有哪些开源实现，又该怎么亲手创建一个——都讲清楚了。

整理成文，分享至此，供君参考。

本文涉及版本、星标数、项目状态等信息，截至 2026-07 月的公开仓库/文档，后续可能变化，请以官方最新信息为准。

先用一个比喻理解 llm-wiki

传统 RAG 像一个“临时资料员”：

1

你问问题 → 它去仓库里翻几箱资料 → 抽出几页 → 临时拼一个答案

llm-wiki 更像一个“长期图书管理员 + 研究助理”：

1
2
3

新资料进来 → 它读懂、归档、做索引、写摘要、加交叉引用、标注冲突
你问问题 → 它先查已经整理好的知识图谱 → 必要时再回原始资料核验
好答案 → 继续沉淀回知识库

一句话：

RAG 每次临时找资料；llm-wiki 平时就把资料整理成会复利的知识资产。