从 358 条到 22 条：每日资讯摘要的四层漏斗

我在 RedEarth 里订阅了几十个安全资讯来源，每天能抓到三四百条内容。最早的做法是把它们全部丢给大模型，让它“挑出重要的写成摘要”。效果很差：上下文太长，模型容易漏掉后面的内容；单个高产来源会占满篇幅；同一件事被五六个来源报道，摘要里就重复五六次。

后来我把流程拆成了四层，每层只做一件事。

第一层：按发布时间取数，每个来源设配额

一开始我用的是“抓取时间”，结果某个来源一次补抓了一周的旧文章，全部被当成“今天的新闻”。改成按文章自身的发布时间过滤后，这个问题就没了。

另一个问题是全局截断：如果只设置“最多取 300 条”，一个每天发上百条的来源就会把其他来源挤掉。所以改成每个来源单独设配额，再合并。

这一层结束：358 条。

第二层：聚类分桶，去掉噪声

用关键词规则把文章分到不同的“桶”里，比如“漏洞”“威胁组织”“数据泄露”“行业动态”。桶的定义不写死在代码里，而是作为工作流节点的配置，可以在页面上增删。

分桶的同时做两件事：

• 标题高度相似的文章合并成一条，保留信息最全的那一篇；
• 不属于任何桶的内容直接丢弃，比如招聘、活动预告、产品广告。

这一层是纯规则，不调用大模型，速度快、结果可解释。结束时剩下 54 条。

第三层：大模型筛选和改写

到这一步数据量已经足够小，可以一次交给大模型。提示词只要求它做两件事：判断每条内容是否值得读，以及把值得读的内容改写成一两句中文。

我试过在提示词里写十几条详细规则，结果反而更差，模型会顾此失彼。最后保留的提示词很短，真正的约束放在代码里，比如输出必须是固定格式的 JSON，解析失败就重试。

这一层结束：22 条。

第四层：排版

最后一层再调用一次大模型，只负责把 22 条内容按桶组织成一份可读的摘要，然后由工作流的推送节点发到我的聊天窗口。把“筛选”和“排版”分开，是因为两件事放在一起时，模型经常为了排版好看而改掉筛选结果。

整条链路在 RedEarth 里是一条工作流：trigger.schedule → rss.fetch → rss.cluster → ai.llm → ai.llm → channel.send，每个节点的配置都可以在编辑器里改。

小结

经验是：能用规则做的事不要交给大模型。前两层把数据量压下来以后，大模型的表现稳定了很多，调用成本也降了一个数量级。