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

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

我自己被这个问题困扰好久了：

• 读了很多文章，但跟人聊起相关内容还是说不清楚，感觉啥都没记住
• 收藏夹攒了几百条"稍后看"，归档速度跟不上收藏速度
• 笔记软件堆了几千条笔记，真要用的时候搜半天也找不到能用的内容

每天要忙的事实在太多了，分给定期整理乱知识库的时间太少了？通常剪藏俩礼拜，整个库就乱成垃圾堆，有时候连打开整理的勇气都没有。

还好赶上AI这波技术革命，终于有不用自己当苦力的知识管理模式了。

以前大家搞知识管理基本都是死循环：读一篇文章 → 点收藏 → 需要时搜索 → 重新从头到尾读一遍。等于每次都要从原始材料里重新挖信息，啥沉淀都留不下。

Andrej Karpathy 在 2026 年 4 月提出了一个更聪明的模式——LLM Wiki Pattern。他的核心洞察特别戳人：

AI知识库应该是结构化、可迭代、持久化，不是每次查问题的时候才临时凑出来的零散碎片。

说人话就是：你看过的内容AI会提前帮你整理好重点、串清楚关联，永久存到知识库里，下次要用直接拿，不用每次问问题都得把之前的原文翻出来重新读一遍重头捋。

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

TL;DR：

技术栈: OpenClaw + SearXNG + crawl4ai + Obsidian + Gitea (NAS Self-hosted)

这套方法，我用了一周后的样子

1. 方法论：LLM Wiki Pattern

1.1 核心思想

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

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

每次问答都是从零开始，没有任何积累。LLM 每次都要找并拼凑相关片段，但什么都留不下。

Wiki 模式完全不同：

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

知识编译一次，然后保持最新。跨引用已经存在，矛盾已被标记，综合内容已反映你读过的所有内容。每添加一个源，Wiki 就变得更丰富。

1.2 三层架构

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

三层职责：

类比：

• Obsidian = IDE
• LLM = 程序员
• Wiki = 代码库

1.3 两种知识库的对比

1.4 Wiki 模式的操作流程

Ingest（摄取）：把新源丢到 raw 集合，告诉 LLM 处理它

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

单个源可能涉及 10-15 个 wiki 页面。

Query（查询）：针对 wiki 提问

• LLM 搜索相关页面、读取、合成答案并引用
• 答案可以是 markdown、比较表、幻灯片、图表
• 好答案可以归档回 wiki 作为新页面

Lint（检查）：定期让 LLM 做健康检查

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

1.5 应用场景

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

1.6 两种导航文件

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

index.md（内容导向）

• wiki 的目录——每个页面列出链接、一行摘要、可选元数据（日期、来源数）
• 按类别组织（实体、概念、来源等）
• LLM 每次摄取时更新
• 回答查询时，LLM 先读索引找相关页面，再深入阅读
• 在中等规模（~100 来源、~数百页面）下效果出奇好，不需要 RAG 基础设施

log.md（时间顺序）

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

1.7 Obsidian 技巧

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

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

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

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

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

1.8 可选 CLI 工具

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

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

自己 vibe-code 一个简单搜索脚本也是可以的——LLM 可以帮你快速搭建。

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

维护知识库繁琐的部分不是阅读或思考——是记账（bookkeeping）：

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

人类放弃 wiki 是因为维护负担增长快于价值。

LLM 不会无聊、不会忘记更新交叉引用、一次可以触及 15 个文件。维护成本接近零。

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

1.10 与 Vannevar Bush Memex 的关系

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

他无法解决的部分是谁来维护。LLM 解决了。

2. 采集工具实践

2.1 采集链路全景

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

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

2.2 为什么不用 Firecrawl？

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

Firecrail 的问题：

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

最终选择：crawl4ai，单容器，无外部依赖。

2.3 SearXNG：搜索聚合引擎

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

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

为什么用 SearXNG？

• 不依赖单一搜索 API：分布式搜索，避免被封
• 支持指定引擎：可以只搜学术资料或只搜 GitHub
• 开源可控：部署在自己 NAS上
• MCP 协议支持：可以接入 OpenClaw 作为工具

工作流程：

2.4 crawl4ai：轻量级网页采集

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

• 单容器部署：只需要一个 Docker 镜像
• 内置 Playwright：自动渲染 JS 页面
• LLM Markdown 优化：自动提取正文，生成高质量 Markdown
• 异步设计：支持大规模并发采集

适用场景：

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

2.5 CloakBrowser：复杂站点采集

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

核心能力：

• 多 Profile 管理：每个站点独立 Cookie 环境
• 登录态保持：一次登录，后续自动携带 Cookie
• Web UI 可视化：能看见浏览器在做什么，方便调试
• CDP 协议：支持远程控制

适用场景：

• 微信公众号：需要微信 UA + 登录态
• Cloudflare 拦截站：需要绕过浏览器指纹检测
• 需要验证码的站点：手动过验证码后自动采集

2.6 三层采集对比

2.7 采集后的处理

采集只是第一步，更重要的是结构化：

raw/ → wiki/ 的转换由 OpenClaw 自动完成：

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

3. 实践：我的双库架构

3.1 Obsidian 双库设计

我的方案是用 Obsidian 分两个库，职责分离：

Personal 库（个人笔记主库）

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

AI 库（AI 采集知识库）

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

为什么分开？

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

3.2 数据同步架构

这是一个多端协同的架构，涉及 PC、NAS、Gitea、OpenClaw 四个角色：

同步流程详解：

1. 用户本地创作

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

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

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

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

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

3.3 为什么这样设计？

优点：

• 零手动同步：一切都是自动的，Git 就是同步中枢
• 版本可控：所有改动都有 commit history，可回滚
• 多端一致：PC、NAS、Gitea 三端永远同步
• 隔离安全：Personal 库和 AI 库独立，不互相干扰

适合人群：

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

4. 工具部署：Ansible 自动化

为了方便管理和迁移，我用 Ansible Playbook 管理所有工具：

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

优势：

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

5. 实验计划

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

核心指标：

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

当前进展：

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

6. 总结

核心理念：

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

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

技术栈总结：

参考

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