已经可以直接进入转化 / 复用
Home
OpenClaw 信息获取主入口
先接住，再看懂，再行动。最新同步：2026-04-15 12:48，当前共 182 条内容对象。
正文或证据还没抓到
微信链接仍有标题不可读
原链接失效，需要转恢复队列
当前结论
这套系统已经能把群里的链接接住，并归一成 content_current.json。
它也已经能直接翻出 priority 队列，不再需要你每次自己解释先做什么。
当前卡点
最大的堵点不在“有没有表”，而在补抓、标题修复、分组理解这三层还没完全压平。
所以现在它更像“收录器 + 排队器”，还不是完整的“理解器 + 复用器”。
今天最重要
先继续压低 21 条待补抓和 1 条标题缺口。
再把 133 条可用内容稳定压进“分组与理解”。
Task First
你现在先去哪一层
先给任务入口，不先讲系统术语。
01 · Intake
我刚发了链接
先确认有没有接住。
- 看 message_id
- 看原始链接和采集时间
- 不要先去 priority
02 · Understand
我想知道这条是什么
先看标题、证据、状态。
- current 是数据库主视图
- 适合看标题、状态、去重
03 · Action
我现在要处理任务
先看今天该做什么。
- 可直接转化：133
- 立即补抓：21
04 · Ops
我在排查问题
先看异常、责任和线索。
- scoreboard 看图表和分布
- bitable 跟问题和外部线索
Bottlenecks
现在卡在哪
先看堵点，而不是先看系统术语。
P0
卡在补抓：21
原因：正文或证据还没拿到，所以 current 和 priority 里仍有大量内容停在 pending。
下一步：先跑 XHS / 公众号抓取，把 pending 继续压低。
P0
卡在标题不可读：1
原因：微信链接仍有一批只有 URL，没有标题，导致你很难一眼判断内容主题。
下一步：先补标题，再进入理解层和行动层。
P1
卡在恢复：28
原因：原链接已经失效，普通抓取不够，必须明确切换到恢复队列。
下一步：把它们转入跨渠道补搜 / 重试。
P1
卡在分组理解：133
原因：这些内容已经能用了，但还没进入稳定的主题分组和复用入口。
下一步：进入“分组与理解”，先做稳定工作簇。
Group & Clarify
分组与理解
不是所有内容都该直接进 priority。先把同类内容放在一起，再决定怎么复用。
Cluster Lane A
高热待转化
123
已经 captured，而且重复出现较多。它们最适合先进入聚类/转化，不该继续埋在总表里。
Cluster Lane B
XHS 待抓取簇
17
当前 backlog 主要集中在小红书侧。这里不是单条异常，而是一个系统性待抓取簇。
一个还没做出来的产品，已经有人付费了(2) 昨天发了那... http://xhslink.com/o/6U2ZnCCh7kZ 复制后打开【小红书】查看笔记！
最近出现：2026-04-15 12:48
打开链接冲浪学到一个新人名，我的提示词在此刻升华 Michael P... http://xhslink.com/o/2gHFn5XprHz 复制后打开【小红书】查看笔记！
最近出现：2026-04-15 11:46
打开链接Hermes 🆚 openclaw 我选Hermes 最近ai圈突然冒出个He... http://xhslink.com/o/AsdWIGVQfGT 复制后打开【小红书】查看笔记！
最近出现：2026-04-13 16:48
打开链接用招聘网站作为情报🔎网站 这周末用2小时做了一个想做... http://xhslink.com/o/APhuL4I56MS 复制后打开【小红书】查看笔记！
最近出现：2026-04-13 16:45
打开链接Cluster Lane C
微信标题修复簇
5
这些内容未必没抓到，但标题仍然不可读，导致你在 current 和 priority 里仍然很难识别内容主题。
Cluster Lane D
恢复队列簇
28
这不是普通 pending，而是需要明确改走跨渠道补搜/重试的恢复队列。
Four Layers
四层地图
多个表不是让你背名字，而是让你知道“这一层回答什么问题”。
L0 · Event Log
raw：有没有接住
保留 message_id、原始链接、采集时间。
不要拿来：判断价值和主题。
L1 · Canonical Layer
current：这到底是什么
把链接变成一行一个内容对象。
本地真底座：content_current.json
L2 · Action View
priority：现在先做什么
直接翻成今日处理队列。
不要拿来：证明收没收到。
L3 · Ops Workspace
bitable / scoreboard：哪里出问题了
这里是治理和责任层，不是内容主库。
适合：跟进异常、责任、线索。
| 你现在的任务 | 最该打开 | 原因 | 先别打开 |
|---|---|---|---|
| 证明刚发的链接有没有被接住 | raw | 它才保留最小事实和 message_id。 | priority |
| 知道这条内容到底是什么 | current | 它已经做了归一、挂证据、标状态。 | raw |
| 决定今天先处理什么 | priority | 它直接给队列和动作。 | current |
| 跟进问题和线索 | bitable / scoreboard | 这层是运营治理，不是内容主视图。 | current |
Source → Action
从信息源到行动链路
真正重要的是事实层、理解层、行动层不要混在一起。
1. 信息源入场
群消息 / 链接 / 转发内容。这里只定义“有东西进来了”。
2. raw 接住
保留原始事实、时间、message_id，不解释内容。
3. current 归一
合并为 content object，挂状态、证据、next action。
4. priority 行动
把对象翻成今日可执行队列。
Current State
当前数据库状态和三条队列
这部分必须反映当前事实，而不是沿用旧报告里的旧数字。
状态分布
平台分布
行动队列
可直接转化
立即补抓
跨渠道补搜 / 重试
Goal Review
目标是什么，做到了多少
这块放在后面，作为复盘层，不抢首页第一屏。
目标
把 OpenClaw 信息获取系统做成一个真正可用的数据库主入口：多个表职责清晰、路径清晰、当前待办清晰、打开就知道去哪一层。
已实现
离线本地单页已经存在，不再依赖 board shell 才能看。
raw / current / priority / scoreboard / bitable 的职责边界已经明确。
从信息源获取到行动的主链路已经可视化。
还差什么
cluster / clarify 仍缺一层真正可操作的前台视图。
页面数据之前是写死的，容易过时。
backlog 和标题修复还没被做成持续更新的首页信号。
为什么
数据在持续变化，静态页面一旦写死就会快速过时。
系统已经有 raw 和 action 两端，但中间解释层仍需要更稳定前台化。
Gap Review
还差什么，为什么
P0
cluster / clarify 还是工作簇，不是正式产品层
这次已经前台化，但仍是基于可靠字段的操作簇，不是真正语义主题簇。
P1
首页仍然是静态产物，需要脚本重生成
我已经把它变成可生成，但它不是运行时自动刷新。原因是你要的主入口必须在 file:// 下可打开，不能依赖本地 fetch。
P1
还有 10 条微信 URL 标题、52 条待补抓
页面能把问题暴露清楚，但不能替代抓取和标题修复本身。
Links & Refresh
常用入口与刷新
raw 台账
确认有没有接住。
打开 rawcurrent
看标题、证据、状态。
打开 currentpriority
看今天先做什么。
打开 priorityscoreboard / bitable
看问题、责任、线索。
打开问题层Three Hard Actions
下一轮继续实现的三件事
1. 把这个生成器纳入日常刷新链路
每次 current 同步后，顺手重生成离线首页和 operating-model snapshot。
2. 给 cluster lane 加可控归类规则
先从可靠规则开始，不要一上来假装有稳定语义聚类。
3. 补标题与补抓，让首页信号继续下降
页面已经把问题暴露出来，下一步是让异常数量真的降下去。