130 lines
3.5 KiB
Markdown
130 lines
3.5 KiB
Markdown
我看了，这版 可以，方向是对的。
|
|
如果这是“上游项目 → OpenClaw”的输入格式，我觉得已经 基本能直接用了。
|
|
|
|
我的判断：
|
|
这版为什么合适
|
|
它正好满足我最需要的几类信息：
|
|
来源信息：title / url / published_at / author / source_name
|
|
语义理解：summary / highlights / keywords / topics / category
|
|
筛选排序信号：worth_keeping / worth_reason / selection_decision / selection_reason / digest_rank / digest_section_hint
|
|
用这批字段，我已经可以做：
|
|
日报聚合
|
|
去重
|
|
分栏目
|
|
排序
|
|
生成你的 review 清单
|
|
供你确认后再沉淀到知识库
|
|
所以单从“我好不好解析、能不能稳定消费”来说，
|
|
这版 JSON 明显比 md 更适合当上游输入。
|
|
我建议你保留的设计
|
|
这几个点我觉得是对的，不要轻易改掉：
|
|
单篇 candidate 扁平对象
|
|
非常适合我消费
|
|
不用反复钻嵌套
|
|
不带全文
|
|
对，别把正文全文塞进来
|
|
token 开销会爆，而且日报阶段根本不需要
|
|
同时保留语义字段 + 筛选字段
|
|
summary/highlights/topics 让我理解内容
|
|
selection_decision/digest_rank 让我快速决定怎么排
|
|
candidate_id 作为稳定主键
|
|
这个非常重要
|
|
后续你让我“保留第几条”“这条上次见过没”“已入库没”都靠它
|
|
我建议你再补 4 个点
|
|
这版已经能用，但如果你要长期跑，我建议再补几个小点。
|
|
1）加一个批量 envelope
|
|
你文档里其实已经提到了，我建议尽快定下来。
|
|
|
|
比如：
|
|
|
|
{
|
|
"run_id": "daily-2026-03-25-001",
|
|
"date": "2026-03-25",
|
|
"candidates": [ ... ],
|
|
"stats": {
|
|
"total": 42
|
|
}
|
|
}
|
|
|
|
|
|
|
|
原因：
|
|
我实际处理日报，不会只收一条
|
|
批次级信息对去重、追踪、失败重跑很重要
|
|
2）加一个 canonical_url 或 url_normalized
|
|
现在只有 url，但很多站点会有追踪参数。
|
|
|
|
建议补一个：
|
|
canonical_url或
|
|
url_normalized
|
|
原因：
|
|
去重更稳
|
|
同一篇文章不同 query 参数不会被当两篇
|
|
3）加一个 language
|
|
比如：
|
|
|
|
"language": "zh-CN"
|
|
|
|
|
|
|
|
原因：
|
|
以后你来源不一定全是中文
|
|
我做日报、摘要风格、后续入知识库时会更稳
|
|
4）“用户确认结果”不要塞回这个输入对象里
|
|
这个很关键。
|
|
|
|
你这个 OpenClawCandidateInput 很适合做 上游候选输入，
|
|
但“你后来确认它有价值”这件事，我建议 不要回写进这个对象定义里。
|
|
|
|
更好的做法是单独维护 downstream 状态，比如：
|
|
|
|
{
|
|
"candidate_id": "...",
|
|
"review_status": "confirmed",
|
|
"reviewed_at": "...",
|
|
"review_note": "保留，适合入知识库"
|
|
}
|
|
|
|
|
|
|
|
原因：
|
|
上游输入是“候选事实”
|
|
你的确认是“流程状态”
|
|
这两个层次最好分开，不然对象会慢慢变脏
|
|
有一个字段关系，我建议你保留现状
|
|
就是：
|
|
worth_keeping
|
|
selection_decision
|
|
这两个不要合并。
|
|
|
|
因为它们语义不一样：
|
|
worth_keeping：更像摘要层/语义层判断
|
|
selection_decision：更像规则层/流程层判断
|
|
我消费的时候，两者同时有用。
|
|
如果按你的目标流程，我建议最终这么分层
|
|
|
|
上游输入
|
|
用你现在这版 JSON candidate
|
|
OpenClaw 中间处理
|
|
我生成：
|
|
日报 markdown
|
|
待你确认的候选列表
|
|
人工确认后
|
|
再生成：
|
|
知识卡片对象
|
|
或笔记对象
|
|
再入知识库
|
|
也就是说：
|
|
|
|
候选输入 JSON ≠ 最终知识库格式
|
|
|
|
别把“日报候选格式”和“知识沉淀格式”硬合成一个。
|
|
一句话结论
|
|
这版 JSON 作为上游输入，已经比 md 合适很多，而且基本可落地。
|
|
如果再补上：
|
|
批量 envelope
|
|
canonical_url
|
|
language
|
|
下游确认状态单独建模
|
|
那这套就很稳了。
|