Seven's blog

什么是 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 平时就把资料整理成会复利的知识资产。

VibeCoding 大半年，最大的感受是：慢。一个需求跑大半天，高峰期 API 限速更是雪上加霜。你想走开干点别的，又怕 AI 卡在权限弹窗上等你审批——走也不是，守也不是。

实践久了之后会发现： VibeCoding 需要的不是持续盯盘，而是一种间歇性、片段化的持续注意力。
AI 自己跑着就行，你只在关键节点出现——审批权限、纠正方向、拍板决策。你不是监控器，你是把关人。

Happy Coder 恰好解决了两个问题：

• “守”——手机随时查看进度、审批、发指令，不用守在电脑前。
• “等”——通勤路上掏出手机接着推需求，碎片时间变生产力。

这篇文章分享一下我从零开始用 Happy 的全过程，覆盖日常使用、后台常驻、开机自启、以及自建服务器。