日报工具写到后面，很容易把问题归到“来源不够多”。
于是继续加 GitHub 查询，继续加 RSS，继续加网页列表。短期看，日报确实变丰富了；再过几天，它也可能变成另一种噪音。每天都有东西，但每天都不一定值得看。真正缺的不是更多入口，而是读完以后能留下反馈。
所以我这次没有继续给 daily-open-source-brief 加采集器，而是先补了一个本地反馈 CLI。
搜索、收藏、忽略、来源健康，这几个动作看起来很小，也不像“模型功能”。但它们能把我读完以后的选择记下来，下一轮排序才有东西可用。
日报不是一次性摘要
如果日报只是每天生成一段中文摘要，那它更像一次性邮件。
今天读完，明天忘掉；这周收藏过什么，下周也不记得；某个来源连续失败，只有日志里知道；我不想再看某类内容，也只能在脑子里烦。
这样用久了会很别扭：摘要越写越顺，用户动作却没有地方落。模型可以把当天内容改得更好读，但它不知道哪些东西被我保存过，哪些被我忽略过，哪些来源已经连续坏了。
日报要变成长期工具，就不能光关心“今天发什么”。它还要关心“我看完以后做了什么”。
先做本地动作，不急着做复杂前端
反馈入口可以做成网页控制台，也可以接飞书机器人。不过第一步不一定要这么重。
本地 CLI 已经够用了：
python -m app.brief_cli todaypython -m app.brief_cli recent --days 7python -m app.brief_cli search "EDA"python -m app.brief_cli save --url "https://example.com/item" --note "later"python -m app.brief_cli ignore --keyword "娱乐"python -m app.brief_cli health这些命令不漂亮，但够稳。它们不需要常驻服务，不需要登录态，也不需要把一个半成品 Web 控制台挂到服务器上。对一个个人日报工具来说，这个顺序更实际：先让动作能被记录，再考虑入口怎么变顺手。
我更喜欢这种小台阶。它看起来不是大功能，却能把工具从“每天吐一份摘要”推到“能记住我的选择”。
收藏不是书签，是排序信号
save 表面上只是收藏一条内容。
它当然可以当书签用，但我更在意另一件事：它能告诉系统，这类东西对我有用。收藏记录可以进入 saved_items，也可以同步写入 item_feedback，后面排序时就有了依据。
这和浏览器书签不一样。浏览器书签只是存起来；日报里的收藏应该反过来影响下一轮日报。比如我反复保存开源 EDA、Verilog、半导体工具链相关内容，那么后面的排序就不该继续把泛泛的 AI 新闻顶到前面。
这样点星标就不是一个孤立动作，它会影响下一轮日报。
忽略规则要硬一点
收藏告诉系统“多来点这个”，忽略告诉系统“少来点这个”。
ignore --keyword 这类命令很粗糙，但它有一个优点：范围明确。它不用靠模型猜我是不是不喜欢某个主题，而是直接写下一条规则。
信息流里最烦人的内容，往往不是完全不相关，而是看起来沾点边、但我就是不想天天见到。比如泛娱乐、泛营销、重复搬运、标题党。靠模型每次临场判断，会有漂移；用忽略规则压一下，至少有一个稳定的边界。
这里也要克制。忽略规则不该直接删除原始记录，更适合降低有效分或标记 filtered_by_feedback。原始数据还在，排序结果更贴近我，这样后面排查也容易。
搜索让日报有记忆
日报如果只能看今天，就会很短命。
SQLite 和 FTS 在这里就很合适。search "EDA"、recent --days 7 这类命令让日报不只是一封当天邮件，也能变成一个小型资料库。
我不需要每次都去翻 HTML 归档，也不需要把所有内容重新发给模型总结。很多问题只要本地搜索就够了：上周看到的那个项目叫什么，最近有没有类似主题，某个来源是不是持续产出低质量内容。
能用确定性检索解决的问题，就别急着交给模型。这也是我做这种工具时反复出现的判断。
来源健康别只藏在日志里
采集来源一多，失败就会变成常态。
GitHub 可能限流，RSS 可能超时，网页结构可能改，邮件或 Lark 投递也可能临时失败。麻烦的不是失败本身，而是失败一直藏在日志里；等某天日报突然变薄，才发现某个来源已经坏了好几天。
health 命令就是把这种状态拿出来。
它不需要复杂，只要能看到来源名、类型、最近状态、条目数、耗时和错误，就足够做第一轮判断。日报工具不是大型监控系统，但它至少应该知道自己今天看哪里成功了，哪里没有看成。
反馈入口可以晚点变漂亮
这类功能最后当然可以接到网页、飞书或邮件按钮上。
比如每条日报下面有“保存”“不感兴趣”“稍后读”，或者在飞书里发一句 /日报 搜索 EDA。不过这些入口都应该建立在已经稳定的本地动作上。
先有 CLI，再有机器人；先有表结构，再有按钮；先有本地可验证动作，再有漂亮界面。这个顺序能避开一个常见坑：前端看起来很完整，后端其实没有记住任何东西。
对个人工具来说，先丑一点没关系。动作能落库、下一轮能用，就已经比只靠感觉调顺序强很多。
先让下一轮用上反馈
日报工具继续加来源之前，应该先学会听反馈。
收藏会影响下一轮排序，忽略规则会压掉反复出现的噪音，搜索能把旧内容找回来，health 至少让我知道今天哪些来源没抓成。
这一步不算大功能，但会改变我后面怎么调排序。
所以我现在不急着继续堆来源，先让已有来源能被这些反馈慢慢校正。
继续读