基于OpenClaw构建Wiki模式知识库的全链路自动化实践

知识管理这事儿，很多人一开始热情高涨，但最后往往陷入同一个死循环：看到好文章→收藏→需要时搜索→从头到尾重读一遍。每次都要从原始材料里重新挖信息，什么积累都留不下。

坦白说，这种模式实在太累人了。收藏夹攒了几百条"稍后看"，笔记软件堆了几千条笔记，真要用的时候搜半天也找不到能用得上的内容。更别提那些日常杂事的干扰，剪藏了两个礼拜，知识库就乱成一锅粥，有时候连打开整理的勇气都没有。

好在AI技术给了我们解放的机会。Andrej Karpathy在2026年4月提出的

，提供了一个更聪明的解法。他的核心洞察一针见血：AI知识库应该是，而不是每次查问题时才临时拼凑的碎片。

通俗点说就是，你看过的内容AI会提前帮你整理出重点、理清关联，永久地存在知识库里，下次要用直接拿就行，不需要每次都重新翻原文从头梳理。

这篇文章就来详细拆解一下：如何用大模型构建一个真正用得上、不用自己天天整理的个人知识库，让AI替你把脏乱差的资料理得明明白白。

从收藏不看到搜索不到：为什么知识管理总是死循环？

先说说被这个老问题困扰了很久的那些典型场景：

• 读了很多文章，但跟人聊起来还是说不清楚，感觉啥都没记住
• 收藏夹从几十条攒到几百条"稍后看"，归档速度永远跟不上收藏速度
• 笔记软件里堆了上千条笔记，真到用的时候翻遍也找不到一条能直接用上的

背后原因其实很直接——每天事情太多了，分给定期整理知识库的时间少得可怜。往往剪藏了两个星期的内容，库里的结构就已经崩得亲妈都认不出来。

还好AI革命来了，终于有了不用自己当苦力的知识管理模式。

以前大家搞知识管理，本质上就是一条死循环：读一篇文章 → 点收藏 → 需要时搜索 → 重新从头到尾读一遍。每次都要从原始材料里重新挖掘信息，什么积累都沉淀不下来。

Andrej Karpathy 提出的

则完全不同。他的核心洞察特别戳人：

AI知识库应该是

结构化的、可迭代的、持久的

，而不是每次查问题时才临时拼凑的零散碎片。

翻译成大白话就是：你看过的内容AI会提前帮你整理好重点、串清楚关联，永久存在知识库里。下次要用直接拿就行，不用每次都得从头翻一遍原始材料重新捋一遍。

这就是本文要分享的核心内容：如何用大模型构建一个真正能用起来的个人知识库，不用自己天天整理，AI把你那个脏乱差的知识库理得明明白白。

：

技术栈:

OpenClaw + SearXNG + crawl4ai + Obsidian + Gitea (NAS Self-hosted)

方法论：LLM Wiki Pattern

核心思想

传统RAG（检索增强生成）模式是这样的：

用户提问 → 检索原始文档 → LLM拼凑答案 → 答案用完就丢

每次问答都是

，没有任何积累。LLM每次都要找并拼凑相关片段，但什么都留不下来。

Wiki模式完全不同：

用户提问 → LLM基于已有Wiki回答 → Wiki持续更新扩充 → 越积累越丰富

。跨引用已经存在，矛盾已被标记，综合内容已经反映了你读过的所有内容。每添加一个源，Wiki就更丰富一分。

三层架构

Karpathy提出了经典的三层架构：

：

层级	内容	维护者
Raw Sources	原始采集文件（文章、论文、图片）	人类，只添加不修改
Wiki	LLM生成的结构化概念页、双链图谱	LLM主要维护，人类可参与
Schema	CLAUDE.md / AgentS.md，约定和工作流	人类编写，LLM遵循

：

• Obsidian = IDE

• LLM = 程序员

• Wiki = 代码库

两种知识库的对比

	RAG模式	Wiki模式
知识形态	每次查询临时拼凑	持久编译，跨引用已建立
累积性	无，每次从头	递增，越积累越丰富
矛盾处理	无法发现	LLM自动标记
维护成本	查询时才想起	LLM自动维护
适合场景	简单问答	深度研究、知识体系构建

Wiki模式的操作流程

：把新源丢到raw集合，告诉LLM处理它

1. LLM读取源
2. 与你讨论关键要点
3. 在wiki写摘要页
4. 更新索引
5. 更新相关实体和概念页
6. 添加日志条目

单一个源可能涉及

。

：针对wiki提问

• LLM搜索相关页面、读取、合成答案并引用
• 答案可以是markdown、比较表、幻灯片、图表

• 好答案可以归档回wiki作为新页面

：定期让LLM做健康检查

• 页面间的矛盾
• 被新源取代的陈旧主张
• 没有入站链接的孤立页面
• 缺失的交叉引用

应用场景

这个模式可以应用到很多场景：

场景	描述	示例
个人成长	追踪目标、健康、心理、自我提升	记录日记、文章、播客笔记，建立对自己的结构化认知
深度研究	几周或几个月钻研一个主题	读论文、文章、报告，构建不断演进的论文wiki
读书	每章归档，构建人物、主题、情节的关联	像Tolkien Gateway那样，建立个人粉丝百科
团队/商业	LLM维护的内部wiki	输入Slack、会议记录、项目文档、客服通话
竞品分析 / 尽职调查 / 旅行规划 / 课程笔记	任何需要时间积累知识的场景	按需选择

两种导航文件

随着wiki增长，两个特殊文件帮助LLM（和你）导航：

• wiki的目录——每个页面列出链接、一行摘要、可选元数据（日期、来源数）
• 按类别组织（实体、概念、来源等）

• LLM每次摄取时更新
• 回答查询时，LLM先读索引找相关页面，再深入阅读
• 在中等规模（~100来源、~数百页面）下效果出奇好，

  不需要RAG基础设施

• 只追加的操作记录——摄取、查询、lint
• 每条以一致前缀开头（如 ## [2026-04-02] ingest | Article Title）
• 可用简单unix工具解析：grep "^## [" log.md | tail -5
• 日志是wiki演进的时间线，帮助LLM理解最近做了什么

Obsidian技巧

：浏览器扩展，将网页文章转为markdown，快速将来源加入raw集合。

：设置 → 文件和链接 → 附件文件夹路径设为raw/assets/，绑定热键（Ctrl+Shift+D）下载所有图片。这样LLM可以直接查看和引用本地图片，不用依赖可能失效的URL。

：查看wiki的形状——哪些页面互联了、谁是中心页面、谁是孤立页面。

：基于markdown的幻灯片格式，Obsidian有插件，可以直接从wiki内容生成演示文稿。

：对frontmatter运行查询的插件，如果LLM添加了YAML frontmatter（标签、日期、来源数），Data view可以生成动态表格和列表。

可选CLI工具

当wiki增长时，你可能需要一些小工具帮助LLM更高效地操作wiki：

：本地markdown搜索引擎，混合BM25/向量搜索+LLM重排，全部本地运行。有CLI（LLM可以调用）和MCP服务器（作为原生工具）。

也是可以的——LLM可以帮你快速搭建。

为什么LLM维护Wiki是革命性的

维护知识库繁琐的部分不是阅读或思考——是

（bookkeeping）：

• 更新交叉引用
• 保持摘要最新
• 注意新数据何时与旧主张矛盾
• 维护数十个页面间的一致性

。

LLM不会无聊、不会忘记更新交叉引用、一次可以触及15个文件。

。

• 人类的工作
  ：管理源、指导分析、提出好问题、思考一切意味着什么

• LLM的工作
  ：其他一切

与Vannevar Bush Memex的关系

这个想法在精神上与

相关——一种个人策划的知识存储，文档间有关联Trails。Bush的愿景更接近这个而非Web变成的样子：私人、积极策划，文档间的连接与文档本身一样有价值。

采集工具实践

采集链路全景

采集是知识库的"源头活水"。没有持续的高质量输入，再好的知识库也会枯竭。

采集链路分为三层，各司其职：

为什么不用Firecrawl？

最初考虑过Firecrawl，但它太重了：

	Firecrawl	crawl4ai
模块数	5个（RocketMQ + PG + Playwright + API + Redis）	1个镜像
内存需求	10G+	4G
部署复杂度	高	低
适合场景	企业级	个人NAS

：

• 需要部署5个独立服务
• NAS资源有限，跑不动
• 维护成本高

：crawl4ai，单容器，无外部依赖。

SearXNG：搜索聚合引擎

是一个开源的元搜索引擎，聚合99个搜索引擎：

• Wikipedia、arXiv、Google Scholar
• GitHub、GitLab
• 各种新闻站、技术博客

• 不依赖单一搜索API
  ：分布式搜索，避免被封

• 支持指定引擎
  ：可以只搜学术资料或只搜GitHub

• 开源可控
  ：部署在自己NAS上

• MCP协议支持
  ：可以接入OpenClaw作为工具

：

crawl4ai：轻量级网页采集

是一个开源的网页采集工具，特点：

• 单容器部署
  ：只需要一个Docker镜像

• 内置Playwright
  ：自动渲染JS页面

• LLM Markdown优化
  ：自动提取正文，生成高质量Markdown

• 异步设计
  ：支持大规模并发采集

：

• 技术博客（结构清晰）
• 文档站点
• GitHub项目页
• 没有强反爬的网站

CloakBrowser：复杂站点采集

是一款反检测浏览器，适合采集"难缠"的站点：

：

• 多Profile管理
  ：每个站点独立Cookie环境

• 登录态保持
  ：一次登录，后续自动携带Cookie

• Web UI可视化
  ：能看见浏览器在做什么，方便调试

• CDP协议
  ：支持远程控制

：

• 微信公众号
  ：需要微信UA+登录态

• Cloudflare拦截站
  ：需要绕过浏览器指纹检测

• 需要验证码的站点
  ：手动过验证码后自动采集

三层采集对比

层级	工具	适用场景	代表站点
搜索层	SearXNG	全网搜索、跨引擎聚合	需要多源对比的调研
简单采集	crawl4ai	结构清晰、无反爬	技术博客、GitHub、文档站
复杂采集	CloakBrowser	JS渲染、登录态、验证码	微信公众号、Cloudflare拦截站

采集后的处理

采集只是第一步，更重要的是

：

的转换由OpenClaw自动完成：

• 读取raw/中的Markdown
• LLM提取关键概念
• 生成结构化wiki页面
• 建立双向链接
• 更新索引和日志

实践：我的双库架构

Obsidian双库设计

方案是用

，职责分离：

• 使用PARA组织法（Projects, Areas, Resources, Archives）
• 存放自己的创作、项目笔记、随手记录
• 以人类写作为主

• 存放AI采集和编译的内容
• 内部再分raw/和wiki/两个目录
• LLM主要维护，人类可参与

• 关注点分离：个人创作 vs 信息摄入
• 避免AI生成内容污染个人思考空间
• 两个库可以有完全不同的同步策略

数据同步架构

这是一个多端协同的架构，涉及

四个角色：

：

1. 用户本地创作

• PC上用Obsidian编辑Personal库和AI库
• Git Plugin自动commit

• Git插件推送

• 定时push到Gitea（Personal.git和AI.git）

• Gitea Action Runner自动部署

• 检测到AI.git提交
• 自动执行脚本pull到NAS服务器

• OpenClaw采集写入

• OpenClaw运行在NAS上
• 执行采集任务后，写入AI库的raw/和wiki/
• 完成后push到Gitea

• 本地Obsidian同步

• Git Plugin定时pull Gitea
• 获取OpenClaw的最新采集结果

为什么这样设计？

：

• 零手动同步
  ：一切都是自动的，Git就是同步中枢

• 版本可控
  ：所有改动都有commit history，可回滚

• 多端一致
  ：PC、NAS、Gitea三端永远同步

• 隔离安全
  ：Personal库和AI库独立，不互相干扰

：

• 有NAS服务器
• 愿意用Obsidian+Git管理笔记
• 希望AI能自动采集和整理信息

工具部署：Ansible自动化

为了方便管理和迁移，用

管理所有工具：

# 核心playbook结构
├── searxng.yml        # SearXNG部署+MCP配置
├── crawl4ai.yml        # crawl4ai Docker部署
├── cloakbrowser.yml    # CloakBrowser+Profile管理
└── update.yml         # 增量更新脚本

：

• 一键部署/升级
• 修改后同步到多台机器
• 版本可控，可回滚
• 基础设施即代码

实验计划

：用2个月验证LLM Notebook的可行性

：

• 知识库条目数
• 交叉链接数
• 实际提问使用率
• Wiki被LLM引用的频率

：

• ✅ 采集链路打通（SearXNG + crawl4ai + CloakBrowser）
• ✅ Git同步流打通（PC ↔ Gitea ↔ NAS）
• ✅ OpenClaw定时任务配置（每天3:00 / 12:00自动调研）
• ❓ 持续采集中

总结

：

我只负责给URL，AI负责采集和构建。
搞通这个数据流程，就玩转起来了。

天光云影共徘徊,唯有源头活水来。

：

环节	工具
知识管理	Obsidian双库（Personal + AI）
版本同步	Git + Gitea + Action Runner
搜索入口	SearXNG MCP
简单采集	crawl4ai MCP
复杂采集	CloakBrowser + Profile Manager
自动化	OpenClaw Agent + Cron
基础设施	Ansible Playbook
NAS	自托管

参考

• Karpathy LLM Wiki Pattern
• crawl4ai GitHub
• SearXNG
• CloakBrowser