从公众号到全网收藏:OpenClaw 如何把碎片信息统一进知识库

承接上一篇「公众号一键进知识库」：这次把链路拉长——任意网页入库、小红书收藏整理、RSS 日报与 AI 摘要。借助 OpenClaw，日常在飞书或微信里丢链接、对齐收藏；真正整理、入库、让 AI 读本地知识库，在 OpenClaw 会话里完成。

三月份写过一篇，《把喜欢的公众号文章，OpenClaw 一键变成自己的知识库》，发出去后陆续有不少阅读和转发，说明这套东西对一部分朋友有用、也感兴趣。于是接着把工具往下升级，又走了三步：

工具从「只认公众号」升级到「任意链接」
把小红书收藏从「吃灰」变成可整理、可选入库
用 RSS + 定时任务解决「订阅太多看不完」

下面按顺序说清楚它们各自解决什么问题、入口怎么接、在 OpenClaw 里怎么和 AI 配合。

先说明：知识库存在哪、怎么统一管理

所有知识库都是落在你自己电脑上的本地目录（默认在 ~/knowledge_base/ 下）。网页、笔记、RSS 摘出来的内容，最终都进同一套「文件夹 + 索引」体系，相当于统一数据源——不是散落在各个 App 收藏夹里，而是可检索、可追溯的一套资料池。

需要备份或跨机器协作时，也可以把整个目录推到 GitHub 等仓库（注意别提交登录态、密钥类文件）。换环境照样能拉下来，OpenClaw 里的 AI 仍然可以按路径读文件、做问答和调用工具，逻辑不变。

具体有哪些库、每类文章归到哪一类，在脚本的 kb_config.py 里配置。目前分了四套知识库，各自一套分类目录和关键词（给自动归类 / 路由用）：

知识库	侧重	分类大致覆盖（节选）
AI_KnowBase	AI 与组织变革	战略与框架、实践与案例、工具与方法、人才与文化、AI Coding、未分类
Engineering_KnowBase	技术与工程	系统架构、后端与中间件、前端与移动端、数据与存储、DevOps 与工程效能、未分类
Management_KnowBase	管理与团队	战略与组织、团队与人才、机制与流程、目标与绩效、职场与个人成长、未分类
PM_KnowBase	产品与运营	产品战略、用户研究、产品设计、数据分析、运营增长、未分类

以上分类完全可按需调整。打开 kb_config.py 即可增删分类、修改关键词、调整优先级。比如：

做后端为主，可以把「系统架构」拆成「微服务」「云原生」「高可用设计」
关注 AI 应用落地，可以给「AI Coding」下面再加「Agent 框架」「Prompt 工程」「模型选型」
暂时用不到的分类直接删掉，新领域随时新建

分类关键词决定了自动归类时的匹配规则，改完配置立即生效，已入库的文章不会受影响。

能力边界：目前以图文、偏文字内容为主

整条链路现阶段最顺的是图文和偏文字：公众号、技术博客、RSS 正文、小红书里的图文/文字笔记等，抓正文、落盘、给 AI 读 .txt，路径相对清晰。

小红书、B 站等收藏里，纯视频资源很多——若要和「文章」一样进个人知识库，往往要另做音视频获取、转写/字幕、摘要、存储空间与带宽、合规等，和「抓网页 HTML 正文」不是一类问题。我这边暂时还没做视频向的转化与整段保存，后面再单独研究（例如是否先转文稿或字幕再入库）。若你收藏里视频占比高，可以把本文先当作文字资料沉淀这一条线；视频化是下一阶段的题目。

一、kb_collector：从公众号，到「任意链接」都能进知识库

上一版的抓手是 mp.weixin.qq.com：Playwright 打开文章，按#js_content 抽正文，再分类、建索引。日常还会遇到技术博客、专栏、新闻站——链接不是微信域名，但我也想并进同一套知识库，让 OpenClaw 里的 AI 能读 README、读 .txt，做检索和综述。

现在的做法是把它升级成 kb_collector：同一套入库与分类逻辑，网页抓取侧改成统一页面抓取模块——微信仍优先用#js_content，其它站点则按常见语义结构 fallback（如 article、main、.content 等），尽量抽出正文再入库。

使用方式可以很朴素：

在对话里丢任意 HTTP(S) 链接，让助手调用采集脚本；
或维护一个 urls.txt 批量跑。

需要心里有数的是：并不是每一个站点都能 100% 完美——登录墙、强反爬、单页应用加载慢，都可能影响抓取；公开可读、结构正常的页面成功率最高。这和「所有 URL 都魔法般成功」是两回事，但对我日常读文章、做主题调研已经够用。

抓取成功后，会按前文说的 kb_config 路由写入对应知识库：README 索引 + 原文可追溯；AI 在 TOOLS.md 里声明工具即可读取——从「只能存微信」到「能抓下来的网页都能进统一知识库」，渠道不再割裂。

二、xhs_collector：小红书收藏，一次拉齐、整理完再决定是否入库

另一个痛点是小红书：很多短笔记、图文混排，收藏了很多，却很少二次整理。（收藏里若以视频笔记为主，当前仍偏「能抽到的文案与元信息」；整段视频的转化、落库见上一节「能力边界」，后续再研究。）

单独做了一个 xhs_collector 脚本流，大致能力：

用浏览器会话拉取自己账号下的收藏笔记（首次需要按提示完成登录，会话会落在本地状态文件里，注意别泄露）；

把笔记整理成可阅读的文本 / 轻量 HTML，带上标题、正文、标签、原文链接；

与 kb_collector 共用同一套路由与知识库配置——也就是说，你可以先「批量导出整理」，再在流程里手动选择要写入哪一个知识库、归哪一类，避免一股脑全塞进库。

这样，「收藏 ≠ 入库」：先提高效率把笔记从 App 里「拉出来、结构化」，再决定哪些值得长期进知识库；和 RSS 那条「先读后存」的思路也是一致的。

三、rss_daily：订阅几十个源，用「日报 + AI」读得完

第三个场景是信息过载：

我订阅了几十个技术博客、公众号 RSS、独立站更新，根本看不过来；

传统 RSS 阅读器擅长聚合，但不会帮你做摘要、去重、按主题合并；

纯 AI 对话又没有稳定的「每日新文章入口」，全靠你手动贴链接。

我这边实现的是 rss_daily 这一套脚本，核心思路：

定时抓取：按 config.yaml 里配置的 RSS/Atom 源（以及需要的公众号直链策略）拉取条目，拉正文，增量入库（避免重复处理）；

结构化输出：生成「今日新文章列表」、日报 Markdown 骨架，方便接下一环；

AI 摘要与精选：在 OpenClaw 对话里用你自己配置的模型去读这批输出，做摘要、去重、热点归纳，产出「今日精选 N 篇」——脚本层不绑死某一家大模型 API，保持和你现有 OpenClaw 环境一致；

推送到飞书 / 微信等：RSS 日报这条线我暂时还没接自动推送；需要时在 OpenClaw 配定时任务（到点跑 rss_daily、再把产出交给会话或 Webhook）即可接上 IM，实现成本不高，看需要再上。

一句话：RSS 负责「不漏更新」，AI 负责「读得完、抓重点」；需要的话，定时任务 + 推送再把内容「送到眼前」。

四、串起来看：三条线都指向同一件事

能力	解决什么	和 AI 的关系
kb_collector	把零散网页变成本地、可检索的资产	助手可读库内文件，做问答与综述
xhs_collector	把「收藏夹吃灰」变成可整理、可选入库	先结构化，再由你决定要不要进 kb
rss_daily	订阅多、看不完 → 日报 + 摘要；推送可接定时任务 + 飞书/微信（按需）	在 OpenClaw 里用模型做「今日精选」与追问

它们不是三个孤立小工具，而是一条输入（链接 / 收藏 / 订阅）→ 结构化沉淀 → 再被 AI 利用的流水线。上一篇写的是其中第一站；这一篇算是把后面几站也补上了。

五、写在最后

如果你也在用 OpenClaw（或类似的 Agent + 工作区框架），最值得投资的可能不是更长的系统提示词，而是把「能稳定落盘」的链路和工具先搭好。工具会迭代，但「能存、能找、能喂给 AI」这一层逻辑不会过时。

本笔记为个人阶段性实践记录，仅供交流参考。若你关心 AI 在研发协作、工程落地中的真实用法，欢迎关注「智码探路」，后续会陆续分享案例与实践心得。