# Digest Optimization Summary

## 背景

reader → OpenClaw 日报链路原先的问题主要有两类：

1. **OpenClaw public digest 输入过重**
   - public digest 直接读取完整 `openclaw-delivery-payload.json`
   - 其中混有大量不直接服务公开日报的字段
   - public digest 这一步在 OpenClaw 侧消耗了较多 token

2. **public / internal 生成逻辑没有充分拆分**
   - public digest 与 internal review digest 都基于完整 payload 推导
   - 容易造成重复消耗
   - public digest 还可能被 review / 内部流程语义污染

本轮优化的目标不是重写 reader 主流程，而是在不破坏现有 delivery payload 的前提下，先把 public digest 的输入和生成方式收敛下来，并验证整体 token 与内容质量的变化。

---

## 本轮改动

### 1. reader 新增 `digest-brief.json`

在 FreshRSS pipeline 写出：

- `outputs/freshrss/rerun/<run-id>/candidates/openclaw-delivery-payload.json`

之后，额外生成：

- `outputs/freshrss/rerun/<run-id>/candidates/digest-brief.json`

用途：

- 供 OpenClaw 生成 **public digest** 时优先读取
- 作为 public-only 的轻量输入视图

当前约束：

- 仅保留 `selection_decision == "keep"` 的候选
- 默认最多保留前 5 条
- 高亮 `highlights` 最多保留 3 条
- schema 标识为 `digest-brief.v1`

保留字段：

- `title`
- `source_name`
- `summary`
- `highlights`
- `category`
- `digest_rank`
- `selection_decision`
- `url`

附带计数：

- `source_candidate_count`
- `candidate_count`

---

### 2. public / internal 输入边界拆分

当前推荐口径：

- **public digest**
  - 优先读取 `digest-brief.json`
  - 仅使用 public-only 输入视图

- **internal review digest**
  - 继续读取完整 `openclaw-delivery-payload.json`
  - 保留 keep / review 的决策上下文

这样做的原因：

- public digest 需要更轻、更干净的公开输入
- internal review digest 仍然需要完整上下文来支撑判断、待确认与建议沉淀

---

### 3. digest 成稿的正式落盘位置

正式 run 生成出的 digest 成稿，不应停留在 OpenClaw 的临时目录，而应回写到同一次 reader run 目录下。

推荐正式产物位置：

- `outputs/freshrss/rerun/<run-id>/digest/public_digest.md`
- `outputs/freshrss/rerun/<run-id>/digest/internal_review_digest.md`
- `outputs/freshrss/rerun/<run-id>/digest/combined.json`

这样可以保证：

- 一次 run 的所有输入、输出、摘要结果和日报成稿都收在同一目录下
- 后续 Hugo 发布与 chat 回传基于同一组正式产物，而不是临时文件
- 便于回溯、复盘和后续自动化收口

### 4. 一次生成两份 digest 的生成模式

推荐把：

- `public digest`
- `internal review digest`

改为在 OpenClaw 侧 **一次调用同时生成两份**。

推荐输入：

- `PUBLIC_DIGEST_INPUT` → `digest-brief.json`
- `INTERNAL_REVIEW_INPUT` → `openclaw-delivery-payload.json`

推荐输出：

```json
{
  "public_digest_markdown": "...",
  "internal_review_digest_markdown": "..."
}
```

这样可以减少重复 prompt / 调用开销，同时保留 public / internal 两种视图的边界。

---

### 5. internal review digest 风格收敛

internal review digest 经过一轮人工验证后，收敛成以下规则：

固定结构：

1. `今日候选概况`
2. `已入选重点`
3. `待你确认`
4. `建议沉淀到 IMA`
5. `原始候选清单`

表达规则：

- 不显示 `rank`
- 不显示英文 machine state
- 使用中文状态：
  - `keep` → `已入选`
  - `review` → `待确认`
  - `drop` → `暂不纳入`

内容规则：

- `已入选重点`
  - 标题 + 来源
  - 状态
  - 较完整的一段摘要
  - 一段判断（解释为什么值得入选，以及它在今天 digest 中承担什么角色）

- `待你确认`
  - 标题 + 来源
  - 状态
  - 较完整的一段摘要
  - 原因
  - 建议

- `原始候选清单`
  - 也用中文状态，而不是 `decision=keep/review`

目标：

- 保留 internal review digest 作为“给人看的审阅稿”的属性
- 避免它沦为 payload 的原样转写或机器中间态展示

---

### 6. public digest 风格收敛

public digest 当前推荐结构：

1. `今日概览`
2. `今日重点`
3. `趋势观察`
4. `延伸阅读`
5. `信息来源`

表达规则：

- 不暴露 internal workflow 词汇
- 不写 `待确认` / `建议沉淀到 IMA` / `keep/review/drop` / `selection_decision`
- 保持适合 Hugo 公开浏览的表达方式

内容规则：

- 每个 `今日重点` 条目除了摘要和 highlights 外，增加一句编辑性总结
- 推荐形式：
  - `这篇内容更值得关注的原因在于……`

目标：

- 保证 public digest 不只是“摘要列表”
- 而是一份带有编辑性提炼的公开日报

---

## 实测结果

基于真实 run：

- run 目录：`outputs/freshrss/rerun/20260401-074614`

### 1. public 输入压缩效果

- 完整 payload：`8701` 字符
- `digest-brief.json`：`3080` 字符

压缩比例：

- **减少约 64.6%**

按中位 token 粗估：

- 完整 payload：约 `3955 tokens`
- public brief：约 `1400 tokens`

public 输入侧单次大约减少：

- **约 2500 tokens**

---

### 2. 一次生成两份的总成本估算

基于真实输入输出的中位估算：

- 旧方案（两次生成）：约 `10328 tokens`
- 新方案（一次生成两份）：约 `7734 tokens`

节省：

- **约 2594 tokens**
- **约 25%**

说明：

- 第一步 public 输入瘦身带来的是“输入量级下降”
- 第二步一次生成两份带来的是“调用层重复开销下降”
- 两者叠加后，已经形成比较明显的成本优化效果

---

## 当前默认口径

### public digest

- 输入：`digest-brief.json`
- 风格：公开浏览稿
- 每个重点项包含：
  - 摘要
  - 关键信号
  - 一句编辑性总结

### internal review digest

- 输入：完整 payload
- 风格：内部审阅稿
- 每个重点项包含：
  - 更完整摘要
  - 判断
- 每个待确认项包含：
  - 更完整摘要
  - 原因
  - 建议

### 生成方式

- 优先采用 **一次调用同时生成两份**

---

## 当前阶段结论

本轮优化已经形成一个可用版本：

- reader 新增 public-only 轻量输入视图
- public / internal 边界清楚
- internal 风格和 public 风格都收敛到了可接受版本
- token 成本下降有明确实测支撑
- skill 文档与流程规范已经同步更新

当前更适合的策略不是继续抽象设计，而是：

- 按这套新流程再跑几次真实日报
- 观察稳定性、质量波动和实际使用感受

---

## 后续可选方向

### 1. internal 输入进一步轻量化

潜在方向：

- 新增一个 internal 专用的轻量视图
- 但需要谨慎，避免削弱 internal review 的判断价值

### 2. digest 阶段模型分层

潜在方向：

- reader 上游继续用便宜模型做抽取和结构化
- OpenClaw digest 阶段单独切到更便宜或更合适的模型

### 3. 自动化执行收口

潜在方向：

- 把“一次生成两份”的逻辑进一步标准化
- 更顺滑地接 Hugo 发布与聊天回传
- 让 reader → OpenClaw → Hugo / chat 的路径更接近真正的稳定生产流程