daily-open-source-brief 里去重、打分、反馈降权这些小步骤，最后决定了日报好不好读。
做每日简报时，我一开始以为难点会在摘要：怎么把 GitHub 仓库、RSS 文章、公开网页通知整理成中文。
后来发现，摘要只是最后一层表达。日报有没有用，更多取决于前面的排序：哪些内容进来，哪些内容合并，哪些内容被降权，哪些内容值得排在前面。
如果排序不稳，摘要再漂亮也只是把噪声包装得更好看。
采集越多，噪声越多
daily-open-source-brief 的采集源不是单一 RSS。它会看 GitHub 仓库、RSS/Atom、公开网页列表，还会把结果存进本地 SQLite，方便后续搜索和归档。
这带来一个问题：来源越多，重复和误报越多。
同一条学校通知可能同时出现在网页列表和 RSS 里；同一个开源项目可能因为 stars 很高、topic 命中、最近 push 过，被多个规则反复推到前面；某些标题看起来热门，但其实和自己的关注方向完全无关。
所以我没有把系统写成“采集之后直接总结”，中间加了一层清洗和排序。
先去重，再谈重要性
跨来源去重的目标不是追求文本相等，而是识别“这两条是不是在说同一件事”。
例如：
关于本科生选课确认的通知本科生选课确认通知这两条在字面上不一样，但对读者来说是同一件事。测试里用标题相似度阈值覆盖了这类情况：命中后只保留一条，另一条标记为跨来源重复。
这个步骤看起来普通，但它会直接影响日报体验。重复信息出现在简报里，会让人误以为今天信息很多，实际上只是同一件事被多个渠道放大。
基础分只处理通用信号
GitHub 项目的基础打分适合处理客观信号：
- stars 数量。
- 是否归档。
- 最近是否还在 push。
- 是否命中 topic。
- 是否使用关注的语言。
- 是否有明确开源许可证。
这些信号能给一个项目“公共意义上的活跃度”。比如一个 Go 写的 self-hosted AI 项目，如果 topic、语言、活跃度都命中，就应该比一个多年不更新的归档仓库更靠前。
但基础分不能代表个人兴趣。一个很火的项目不一定值得我每天看到；一个小众项目如果刚好贴近 EDA、实验自动化或课程工具，反而更有用。
反馈分不能覆盖原始分
我比较在意的一点是：反馈降权不能把最开始算出来的基础分改掉。
例如某条内容基础分是 88，只是因为标题里命中了“娱乐”这样的忽略关键词，所以本次日报里应该被压下去。正确做法是计算一个 effective score，而不是把数据库里的基础分改成负数。
基础分记录的是采集当时的状态，反馈分只是当时的个人偏好。后面规则改了，我希望能重新算一遍，而不是先前的数据已经被改乱。
所以排序里有两层分数：
base score -> 原始信号effective score -> 叠加反馈后的本次排序这让系统既能记住“它为什么被认为重要”，也能表达“我现在不想看它”。
规则比模型更适合做第一道闸
日报当然可以接外部模型做摘要，但我不想把“要不要出现”完全交给模型。
第一道闸更适合用确定性规则：
- 明确忽略的关键词直接降权。
- 已读、已收藏、历史多次出现的内容单独记录。
- 归档仓库天然降权。
- 近期活跃、topic 命中、语言命中的项目加分。
- 跨来源重复只保留代表条目。
这些规则不聪明，但问题出在哪比较容易查，也方便写测试和重新跑一遍。模型更适合在候选集稳定之后做表达，把条目讲清楚，而不是在一堆未经整理的候选里临场判断。
排序最后帮我省了什么
最后形成的流程大概是这样：
collect -> dedupe -> base rank -> feedback weights -> digest它最后处理的是注意力分配：今天可以有很多内容，但日报里不应该把每一条都推到我面前。
这也是我越来越倾向于把个人信息流工具做小、做本地、做可解释的原因。信息过载时，稀缺的不只是摘要能力，还有把不重要内容压下去的能力。
日报系统如果只会收集，就会变成另一个收件箱。
能排序、能降权，还能回头看每条为什么排到这里，才比较像一个能长期用下去的个人工具。
继续读