LLM 摘要不要继承聊天上下文#

日报摘要和聊天助手不是一回事。

日报摘要的输入应该是当天候选条目、来源状态和明确的偏好配置。它不该继承上一轮聊天，也不该把用户的私聊上下文带进 provider。

所以这个项目里有一个很明确的默认设置：

1
DAILY_BRIEF_LLM_STORE=0

每次 LLM 调用只发送本次日报候选 JSON，不传会话 ID，不传 previous response ID，默认 store=false。这听起来像配置细节，其实是产品范围。

日报系统需要的是“根据今天这些公开条目，按偏好生成摘要”。它不需要让模型记住我昨天怎么和机器人聊天，也不需要让 provider 替我保存一份长期兴趣史。

如果以后真的要开启存储，也应该是显式选择，而不是默认行为。

画像文件按用户隔离#

个性化日报的第二个范围，是每个用户的画像必须独立。

我更能接受这样的结构：

1
data/profiles/users/<user_id>/profile.yml
2
data/profiles/users/<user_id>/signals/*.jsonl

而不是所有人的偏好都混到一个全局 config/profile.yml 里。

全局配置适合放通用默认设置，比如来源、插件开关、邮件设置。个人画像应该只描述一个用户：想看什么、不想看什么、是否启用日报、投递到哪里。

这个范围带来几个好处：

• 用户 A 的兴趣不会影响用户 B 的日报。
• 清空画像时只清一个目录。
• 出问题时能查到是哪一次明确画像更新导致排序变化。
• 管理员个人日报也能走同一套机制，不需要特殊分支。

个性化最怕“看起来更聪明，实际上不可追踪”。按用户隔离至少能让问题收敛到一个文件夹里。

群聊只作为来源元数据#

日报机器人如果接到飞书或群聊入口，还会遇到一个更麻烦的问题：群聊里的话算谁的偏好？

我的判断是，默认不算。

群聊可以作为消息来源元数据保存，例如这次画像更新来自哪个聊天入口，但不该把“群里有人说喜欢某方向”直接写进某个人的长期画像。个人偏好必须来自明确的用户指令，或者清晰的每日画像总结。

所以类似这些命令才应该进入画像：

1
/日报 画像 想看：半导体产业、开源 EDA、AI 辅助验证
2
/日报 画像 不要：泛泛 AI 聊天应用
3
每日画像总结：偏好开源 EDA、RISC-V、先进封装

而“下午三点提醒我喝水”这类无关私聊，不该创建或修改日报画像。它最多返回支持命令提示。

这不只是功能多少的问题，还要避免系统把普通聊天当成长期偏好。日报工具应该少记，尤其别把闲聊误写进画像。

画像要能看、能清空、能重建#

一个偏好系统如果只能越记越多，后面一定会变脏。

我希望个性化日报至少提供几类操作：

1
profile ingest   # 写入一次明确画像更新
2
profile show     # 查看当前画像
3
profile clear    # 清空偏好
4
run --profile-user-id <id>  # 按某个用户画像生成日报

这些命令看起来朴素，但它们决定了画像是否可审计。

如果一份日报突然开始推很多不想看的内容，我应该能查当前画像；如果画像被污染，我应该能清空重来；如果要测试某个用户的效果，也应该能显式指定用户 ID 生成一份日报。

个性化不是越自动越好。对个人工具来说，可撤销比自动推断更重要。

候选内容和偏好内容别混库#

日报系统里至少有三类数据：

• 公开候选条目：GitHub、RSS、网页公告。
• 个人偏好画像：想看什么、不想看什么、投递开关。
• 运行状态：来源健康、插件运行、发送日志。

它们可以在一次日报生成里汇合，但不该混成同一种记录。

候选条目适合进 SQLite，便于去重、评分、搜索和归档。个人画像适合按用户放在独立目录，便于清空和审计。运行状态适合写健康表和日志，便于判断来源是否失效。

这样做会多几个文件和表，但能换来一个很重要的好处：出了问题知道该查哪里。

如果日报质量变差，先看候选和评分；如果推送对象不对，查画像和投递配置；如果当天没内容，查来源健康；如果 LLM 输出奇怪，查本次候选 JSON 和摘要降级逻辑。

个性化之前先隔离画像#

个性化日报最难的地方，是别让模型把不该记的东西也记进去。

LLM 摘要不要继承聊天上下文，provider 存储默认关闭；用户画像按人隔离，群聊不自动变成个人偏好；画像要能查看、清空和显式指定；候选、画像、运行状态各放各的位置。

这些设计不显眼，但会直接影响这个工具以后好不好维护、敢不敢长期用。

日报是每天会触达人的东西。它越靠近个人偏好，越应该克制。先隔离画像，再做个性化，日报工具才不容易变成一堆清不干净的历史偏好。