给 RSS 装了个摘要机器

Miniflux 已经用了挺久了。

订阅了虎嗅、晚点、爱范儿、Hacker News，加上几个英文 newsletter，每天进来三四百条，积压着，像一个永远清不完的待办列表。

读不完是正常的。问题是你根本不知道哪些值得点进去——光靠标题判断，经常要么被骗进去，要么真正有意思的漏掉了。

于是就想：能不能先让 AI 读一遍，告诉我这篇讲了什么？

最初的弯路

最开始想着本地跑个 LLM，省事省钱。sl3 那台机器有 16GB 内存，试了几个量化版本，gemma2-2b 跑得动，但生成速度慢到让人抓狂——处理一篇文章要十几秒，有时候直接超时，摘要还缺斤少两。换 mistral-7b-Q4，吃内存，系统直接开始 swap，基本废了。

本地 LLM 这条路，至少在我这个配置上，做不到每篇文章都处理得过去。

然后想到了 GitHub Copilot。已经在用，API 可以调，后端挂的是 gpt-4o-mini，速度快，token 限制也够用，关键是不用另外付费。就这么定了。

服务不复杂，一个 Python 脚本，跑在 sl3 上，用 systemd 守护：

HN 的处理单独写了逻辑：除了原文，还会把评论区一并抓下来，分两个部分总结——“文章说了什么"和"HN 在聊什么”。两件事有时候差很远。比如某篇介绍新数据库的文章，评论区全在骂作者没提到某个竞品，这种信息只看原文是感知不到的。

有个细节处理起来有点麻烦：Miniflux 有时候拉回来的是全文，有时候只有摘要，得先判断正文长度，太短就去原 URL 再抓一次。网站防爬虫的程度参差不齐，爱范儿直接给全文，虎嗅要带 Cookie，偶尔还是会失败，这种情况就只用摘要凑合。

每天早上打开 Miniflux，文章顶部已经有一段蓝色的摘要在等着你。

读起来快了很多。很多文章看完摘要就够了，知道发生了什么，不需要点进去；真正有意思的，摘要会让你更容易判断值不值得细读。

有几次摘要比原文写得好——可能模型把废话过滤掉了，核心反而更清楚。这让我有一丝复杂的感受。

HN 的双摘要比较有意思。有时候文章本身很普通，但评论区冒出来一个真在这个领域干了十年的人，随手写了几段干货，比文章值钱多了。现在这些也被收进摘要里了，不容易错过。

用了几天，感觉挺好。然后有一天早上打开，摘要全没了。

Miniflux 每次刷新 feed 会重新拉取内容，覆盖掉 content 字段。我辛辛苦苦生成的摘要，就这么被刷掉了。

这是个设计问题，不是 bug。Miniflux 本来就不是为了让你改文章内容的，它只是个阅读器。我硬把摘要写进去，迟早会被覆盖。

折腾了一会儿，意识到这条路走不通——除非每次刷新之后立刻重新跑一遍摘要，但那样太浪费，也不优雅。

得换个思路。

与其把摘要塞进 Miniflux，不如在 Miniflux 之前就把活干完。

新版的逻辑是这样的：脚本直接去订阅原始 RSS，把每篇文章喂给 AI，摘要存进 SQLite。然后用这些数据重新生成一份代理 feed XML，推到 alice 服务器上，用 Caddy 做静态服务。Miniflux 订阅的不再是原始 feed，而是这份代理 feed。

这样 Miniflux 每次刷新，拉到的就是已经带了摘要的版本，它爱怎么覆盖就怎么覆盖——覆盖的也是有摘要的内容。

订阅源的名字也改了一下，叫「爱范儿·摘要」「博海拾贝·摘要」，在 Miniflux 侧栏里一眼就知道这是处理过的 feed。

原来用的是 gpt-4o-mini，重新设计的时候顺手换成了 gpt-4.1。

摘要质量明显好了一些——不只是把原文缩短，能更准确地抓住文章的核心。字数从之前的 300~500 字压到 300 字以内，反而更好读。

存储也从一个 JSON 文件换成了 SQLite。JSON 那个其实一直凑合用着，但一旦写入中断就容易损坏，SQLite 稳一点，查起来也方便。

多语言混排有点乱——英文原文的人名、产品名被翻译成了奇怪的中文，我在 prompt 里加了"专有名词保留英文"，好了很多，但还是偶尔翻错。

图片里的信息完全抓不到，模型不处理图片。有几篇虎嗅的文章，关键数据在一张截图里，摘要读起来语焉不详，点进去才发现原来是图。这个问题暂时没有好的解法。

每 2 分钟一篇的节奏，在文章堆积多的时候会欠债。周一早上看，可能周五的东西还没处理完。不着急，反正也读不完。

架构稍微复杂了一点，但每个部分的职责更清晰了：原始 RSS 不动，AI 处理在中间层，Miniflux 只管消费。

每天早上打开 Miniflux，「爱范儿·摘要」「虎嗅·摘要」安静地排在侧栏里，文章顶部有段摘要，不会消失，也不会再被刷掉。

有时候一个方案跑通了，不代表它真的对。只是没出问题而已。