Refine OpenClaw payloads and reorganize docs

fellback.md

@@ -0,0 +1,129 @@
+我看了，这版 可以，方向是对的。
+如果这是“上游项目 → 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
+下游确认状态单独建模
+那这套就很稳了。