OpenClaw 信息获取主入口
先接住,再看懂,再行动。最新同步:2026-04-20 09:00,当前共 203 条内容对象。
这套系统已经能把群里的链接接住,并归一成 content_current.json。
它也已经能直接翻出 priority 队列,不再需要你每次自己解释先做什么。
最大的堵点不在“有没有表”,而在补抓、标题修复、分组理解这三层还没完全压平。
所以现在它更像“收录器 + 排队器”,还不是完整的“理解器 + 复用器”。
先继续压低 39 条待补抓和 0 条标题缺口。
再把 136 条可用内容稳定压进“分组与理解”。
你现在先去哪一层
先给任务入口,不先讲系统术语。
我刚发了链接
先确认有没有接住。
- 看 message_id
- 看原始链接和采集时间
- 不要先去 priority
我想知道这条是什么
先看标题、证据、状态。
- current 是数据库主视图
- 适合看标题、状态、去重
我现在要处理任务
先看今天该做什么。
- 可直接转化:136
- 立即补抓:39
我在排查问题
先看异常、责任和线索。
- scoreboard 看图表和分布
- bitable 跟问题和外部线索
现在卡在哪
先看堵点,而不是先看系统术语。
卡在补抓:39
原因:正文或证据还没拿到,所以 current 和 priority 里仍有大量内容停在 pending。
下一步:先跑 XHS / 公众号抓取,把 pending 继续压低。
卡在标题不可读:0
原因:微信链接仍有一批只有 URL,没有标题,导致你很难一眼判断内容主题。
下一步:先补标题,再进入理解层和行动层。
卡在恢复:28
原因:原链接已经失效,普通抓取不够,必须明确切换到恢复队列。
下一步:把它们转入跨渠道补搜 / 重试。
卡在分组理解:136
原因:这些内容已经能用了,但还没进入稳定的主题分组和复用入口。
下一步:进入“分组与理解”,先做稳定工作簇。
分组与理解
不是所有内容都该直接进 priority。先把同类内容放在一起,再决定怎么复用。
高热待转化
已经 captured,而且重复出现较多。它们最适合先进入聚类/转化,不该继续埋在总表里。
XHS 待抓取簇
当前 backlog 主要集中在小红书侧。这里不是单条异常,而是一个系统性待抓取簇。
三省六部幻觉:为什么"虚拟公司"式多Agent "三省六部"... http://xhslink.com/o/AZGK9J5GgWO 复制后直接打开【小红书】,笔记即刻可见。
最近出现:2026-04-20 09:00
打开链接让cc写了个linkedin抓取器,找工作效率翻10 我开发了... http://xhslink.com/o/AqzaeDj5Tjn 复制内容,然后进入【小红书】查看相关笔记。
最近出现:2026-04-20 08:56
打开链接Skill 越多,死的越快 关于AI与人机协作: 你不是在向... http://xhslink.com/o/4Ihx3U5WF7T 把文本复制下来,打开【小红书】即可查看。
最近出现:2026-04-20 08:35
打开链接致敬,科学家30年收集的数据向所有人开放了 全球每 4 ... http://xhslink.com/o/37txaFrM6kQ 直达【小红书】探索笔记全文~
最近出现:2026-04-20 08:33
打开链接微信标题修复簇
这些内容未必没抓到,但标题仍然不可读,导致你在 current 和 priority 里仍然很难识别内容主题。
恢复队列簇
这不是普通 pending,而是需要明确改走跨渠道补搜/重试的恢复队列。
四层地图
多个表不是让你背名字,而是让你知道“这一层回答什么问题”。
raw:有没有接住
保留 message_id、原始链接、采集时间。
不要拿来:判断价值和主题。
current:这到底是什么
把链接变成一行一个内容对象。
本地真底座:content_current.json
priority:现在先做什么
直接翻成今日处理队列。
不要拿来:证明收没收到。
bitable / scoreboard:哪里出问题了
这里是治理和责任层,不是内容主库。
适合:跟进异常、责任、线索。
| 你现在的任务 | 最该打开 | 原因 | 先别打开 |
|---|---|---|---|
| 证明刚发的链接有没有被接住 | raw | 它才保留最小事实和 message_id。 | priority |
| 知道这条内容到底是什么 | current | 它已经做了归一、挂证据、标状态。 | raw |
| 决定今天先处理什么 | priority | 它直接给队列和动作。 | current |
| 跟进问题和线索 | bitable / scoreboard | 这层是运营治理,不是内容主视图。 | current |
从信息源到行动链路
真正重要的是事实层、理解层、行动层不要混在一起。
1. 信息源入场
群消息 / 链接 / 转发内容。这里只定义“有东西进来了”。
2. raw 接住
保留原始事实、时间、message_id,不解释内容。
3. current 归一
合并为 content object,挂状态、证据、next action。
4. priority 行动
把对象翻成今日可执行队列。
当前数据库状态和三条队列
这部分必须反映当前事实,而不是沿用旧报告里的旧数字。
状态分布
平台分布
行动队列
可直接转化
立即补抓
三省六部幻觉:为什么"虚拟公司"式多Agent "三省六部"... http://xhslink.com/o/AZGK9J5GgWO 复制后直接打开【小红书】,笔记即刻可见。
建议动作:运行 XHS 抓取
打开链接让cc写了个linkedin抓取器,找工作效率翻10 我开发了... http://xhslink.com/o/AqzaeDj5Tjn 复制内容,然后进入【小红书】查看相关笔记。
建议动作:运行 XHS 抓取
打开链接Skill 越多,死的越快 关于AI与人机协作: 你不是在向... http://xhslink.com/o/4Ihx3U5WF7T 把文本复制下来,打开【小红书】即可查看。
建议动作:运行 XHS 抓取
打开链接致敬,科学家30年收集的数据向所有人开放了 全球每 4 ... http://xhslink.com/o/37txaFrM6kQ 直达【小红书】探索笔记全文~
建议动作:运行 XHS 抓取
打开链接跨渠道补搜 / 重试
目标是什么,做到了多少
这块放在后面,作为复盘层,不抢首页第一屏。
把 OpenClaw 信息获取系统做成一个真正可用的数据库主入口:多个表职责清晰、路径清晰、当前待办清晰、打开就知道去哪一层。
离线本地单页已经存在,不再依赖 board shell 才能看。
raw / current / priority / scoreboard / bitable 的职责边界已经明确。
从信息源获取到行动的主链路已经可视化。
cluster / clarify 仍缺一层真正可操作的前台视图。
页面数据之前是写死的,容易过时。
backlog 和标题修复还没被做成持续更新的首页信号。
数据在持续变化,静态页面一旦写死就会快速过时。
系统已经有 raw 和 action 两端,但中间解释层仍需要更稳定前台化。
还差什么,为什么
cluster / clarify 还是工作簇,不是正式产品层
这次已经前台化,但仍是基于可靠字段的操作簇,不是真正语义主题簇。
首页仍然是静态产物,需要脚本重生成
我已经把它变成可生成,但它不是运行时自动刷新。原因是你要的主入口必须在 file:// 下可打开,不能依赖本地 fetch。
还有 10 条微信 URL 标题、52 条待补抓
页面能把问题暴露清楚,但不能替代抓取和标题修复本身。
常用入口与刷新
raw 台账
确认有没有接住。
打开 rawcurrent
看标题、证据、状态。
打开 currentpriority
看今天先做什么。
打开 priorityscoreboard / bitable
看问题、责任、线索。
打开问题层下一轮继续实现的三件事
1. 把这个生成器纳入日常刷新链路
每次 current 同步后,顺手重生成离线首页和 operating-model snapshot。
2. 给 cluster lane 加可控归类规则
先从可靠规则开始,不要一上来假装有稳定语义聚类。
3. 补标题与补抓,让首页信号继续下降
页面已经把问题暴露出来,下一步是让异常数量真的降下去。