在OpenClaw里，用大模型构建一个真正能用起来的个人Wiki模式知识库 时间: 2026-06-12 22:05 分类: 猿码 热度: 0°C 评论  以前大家搞知识管理基本都是死循环：读一篇文章 → 点收藏 → 需要时搜索 → 重新从头到尾读一遍。等于每次都要从原始材料里重新挖信息，啥沉淀都留不下。 Andrej Karpathy 在 2026 年 4 月提出了一个更聪明的模式——**LLM Wiki Pattern**。他的核心洞察特别戳人： > AI知识库应该是结构化、可迭代、持久化，不是每次查问题的时候才临时凑出来的零散碎片。 说人话就是：你看过的内容AI会提前帮你整理好重点、串清楚关联，永久存到知识库里，下次要用直接拿，不用每次问问题都得把之前的原文翻出来重新读一遍重头捋。 这就是本文要分享的内容：如何用大模型构建一个真正能用起来的个人知识库，不用自己天天整理，AI帮你把脏乱差的知识库理得明明白白。 > 技术栈: OpenClaw + SearXNG + crawl4ai + Obsidian + Gitea (NAS Self-hosted)  这套方法，我用了一周后的样子  ##前题 已经配置好可用的 OpenClaw（这个部分可以参考之前的教程：[【教程】手把手教你在云服务器上安装openclaw](https://blog.gaomeluo.com/archives/openclaw/ "【教程】手把手教你在云服务器上安装openclaw")） 我有NAS，本教程基于NAS，云服务器同理，成本会更低一些，建议上云。 ##一、方法论：LLM Wiki Pattern ###1、核心思想 传统的 RAG（检索增强生成）模式是这样的： > 用户提问 → 检索原始文档 → LLM 拼凑答案 → 答案用完就丢 每次问答都是**从零开始**，没有任何积累。LLM 每次都要找并拼凑相关片段，但什么都留不下。 Wiki 模式完全不同： > 用户提问 → LLM 基于已有 Wiki 回答 → Wiki 持续更新扩充 → 越积累越丰富 **知识编译一次，然后保持最新**。跨引用已经存在，矛盾已被标记，综合内容已反映你读过的所有内容。每添加一个源，Wiki 就变得更丰富。 ###2、三层架构 Karpathy 提出了经典的三层架构：  三层职责：  类比： - Obsidian = IDE - LLM = 程序员 - Wiki = 代码库 ###3、两种知识库的对比  ###4、Wiki 模式的操作流程 Ingest（摄取）：把新源丢到 raw 集合，告诉 LLM 处理它 LLM 读取源 与你讨论关键要点 在 wiki 写摘要页 更新索引 更新相关实体和概念页 添加日志条目 单个源可能涉及 10-15 个 wiki 页面。 Query（查询）：针对 wiki 提问 LLM 搜索相关页面、读取、合成答案并引用 答案可以是 markdown、比较表、幻灯片、图表 好答案可以归档回 wiki 作为新页面 Lint（检查）：定期让 LLM 做健康检查 页面间的矛盾 被新源取代的陈旧主张 没有入站链接的孤立页面 缺失的交叉引用 ###5、应用场景 这个模式可以应用到很多场景：  ###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 理解最近做了什么 ###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 可以生成动态表格和列表。 ###8、可选 CLI 工具 当 wiki 增长时，你可能需要一些小工具帮助 LLM 更高效地操作 wiki： **qmd：**本地 markdown 搜索引擎，混合 BM25/向量搜索 + LLM 重排，全部本地运行。有 CLI（LLM 可以调用）和 MCP 服务器（作为原生工具）。 **自己 vibe-code 一个简单搜索脚本**也是可以的——LLM 可以帮你快速搭建。 ###9、为什么 LLM 维护 Wiki 是革命性的 维护知识库繁琐的部分不是阅读或思考——是记账（bookkeeping）： - 更新交叉引用 - 保持摘要最新 - 注意新数据何时与旧主张矛盾 - 维护数十个页面间的一致性 **人类放弃 wiki 是因为维护负担增长快于价值。** LLM 不会无聊、不会忘记更新交叉引用、一次可以触及 15 个文件。维护成本接近零。 - **人类的工作：**管理源、指导分析、提出好问题、思考一切意味着什么 - **LLM 的工作：**其他一切 ###10、与 Vannevar Bush Memex 的关系 这个想法在精神上与 Vannevar Bush 的 Memex（1945） 相关——一种个人策划的知识存储，文档间有关联 Trails。Bush 的愿景更接近这个而非 Web 变成的样子：私人、积极策划，文档间的连接与文档本身一样有价值。 **他无法解决的部分是谁来维护，LLM 解决了。** ##二、采集工具实践 ###1、采集链路全景 采集是知识库的"源头活水"。没有持续的高质量输入，再好的知识库也会枯竭。 我的采集链路分为三层，各司其职：  ###2、为什么不用 Firecrawl？ 最初考虑过 Firecrawl，但它太重了：  Firecrail 的问题： - 需要部署 5 个独立服务 - NAS 资源有限，跑不动 - 维护成本高 最终选择：crawl4ai，单容器，无外部依赖。 ###3、SearXNG：搜索聚合引擎 **SearXNG** 是一个开源的元搜索引擎，聚合 99 个搜索引擎： - Wikipedia、arXiv、Google Scholar - GitHub、GitLab - 各种新闻站、技术博客 **为什么用 SearXNG？** - **不依赖单一搜索 API**：分布式搜索，避免被封 - **支持指定引擎**：可以只搜学术资料或只搜 GitHub - **开源可控**：部署在自己 NAS上 - **MCP 协议支持**：可以接入 OpenClaw 作为工具 工作流程：  ###4、crawl4ai：轻量级网页采集 **crawl4ai **是一个开源的网页采集工具，特点： - 单容器部署：只需要一个 Docker 镜像 - 内置 Playwright：自动渲染 JS 页面 - LLM Markdown 优化：自动提取正文，生成高质量 Markdown - 异步设计：支持大规模并发采集 **适用场景：** - 技术博客（结构清晰） - 文档站点 - GitHub 项目页 - 没有强反爬的网站 ###5、CloakBrowser：复杂站点采集 **CloakBrowser** 是一款反检测浏览器，适合采集"难缠"的站点： **核心能力：** - 多 Profile 管理：每个站点独立 Cookie 环境 - 登录态保持：一次登录，后续自动携带 Cookie - Web UI 可视化：能看见浏览器在做什么，方便调试 - CDP 协议：支持远程控制 **适用场景：** - 微信公众号：需要微信 UA + 登录态 - Cloudflare 拦截站：需要绕过浏览器指纹检测 - 需要验证码的站点：手动过验证码后自动采集 ###6、三层采集对比  ###7、采集后的处理 采集只是第一步，更重要的是结构化：  raw/ → wiki/ 的转换由 OpenClaw 自动完成： - 读取 raw/ 中的 Markdown - LLM 提取关键概念 - 生成结构化 wiki 页面 - 建立双向链接 - 更新索引和日志 ##三、实践：我的双库架构 ###1、Obsidian 双库设计 我的方案是用 Obsidian 分两个库，职责分离： **Personal 库（个人笔记主库）** - 使用 PARA 组织法（Projects, Areas, Resources, Archives） - 存放自己的创作、项目笔记、随手记录 - 以人类写作为主 **AI 库（AI 采集知识库）** - 存放 AI 采集和编译的内容 - 内部再分 raw/ 和 wiki/ 两个目录 - LLM 主要维护，人类可参与 **为什么分开？** - 关注点分离：个人创作 vs 信息摄入 - 避免 AI 生成内容污染个人思考空间 - 两个库可以有完全不同的同步策略 ###2、数据同步架构 这是一个多端协同的架构，涉及 **PC、NAS、Gitea、OpenClaw** 四个角色：  **同步流程详解：** - 用户本地创作 - 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 的最新采集结果 ###3、为什么这样设计？ **优点：** - 零手动同步：一切都是自动的，Git 就是同步中枢 - 版本可控：所有改动都有 commit history，可回滚 - 多端一致：PC、NAS、Gitea 三端永远同步 - 隔离安全：Personal 库和 AI 库独立，不互相干扰 **适合人群：** - 有NAS或者云服务器的群体 - 愿意用 Obsidian + Git 管理笔记 - 希望 AI 能自动采集和整理信息 ##四、工具部署：Ansible 自动化 为了方便管理和迁移，我用 Ansible Playbook 管理所有工具： # 核心 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 负责采集和构建。 搞通这个数据流程，就玩转起来了。 天光云影共徘徊,唯有源头活水来。 **技术栈总结**：  参考 - Karpathy LLM Wiki Pattern - crawl4ai GitHub - SearXNG - CloakBrowser #####更多OpenClaw的玩法 #####关注教程：[玩转OpenClaw丨OpenClaw手把手的教程合辑](https://blog.gaomeluo.com/archives/wan-OpenClaw/ "玩转OpenClaw丨OpenClaw手把手的教程合辑") 标签: AI智能 openclaw
评论已关闭