用大模型+RSS搭建半自动AI日报：信息聚合与过滤实战

1. 做这份AI日报的初衷信息太多时间太少每天早晚刷一遍技术社区、公众号和几个固定信源大概是我过去几年的固定动作。但2026年这个时间点AI领域的更新速度已经到了让人有点焦虑的程度这边大模型刚开源那边Agent框架就迭代了一版上午还挂在热搜上的AI编程工具下午已经有人跑出了新的基准测试成绩。我自己感受最明显的是光靠“刷”已经不行了——刷到什么看什么很容易被情绪化的标题带着走刷完一小时真正有价值的信息没留下几条。所以从今年年初开始我给自己定了一个小目标不追热点但每天必须有一条属于自己的“AI日报”。这份日报不是把热搜榜复制一遍而是围绕我自己关心的几条主线——模型进展、Agent工程实践、AI应用开发、AI编程工具、以及行业里真正落地的东西——做一次信息收敛和判断。做了一段时间之后越来越多朋友问我是怎么维护的用的什么工具、什么流程、怎么保证信息质量。这篇文章就把我目前的完整做法摊开来讲包括信息源怎么选、内容怎么过滤、摘要怎么做、推送怎么发以及中间踩过的一些坑。如果你也想搭一套属于自己的AI信息聚合流程哪怕只是每天花二十分钟维护这篇文章应该能给你一个可以直接上手的参考。我目前用的这套方案本质上是一个“半自动人工”的流水线用爬虫和RSS做信息采集用大模型做初筛和摘要用脚本做格式化和推送但最终的人工审阅和判断环节始终保留。这正好也对应了2026年被反复讨论的一个核心议题——AI Agent到底能在多大程度上替代人的工作我的结论是在信息处理这类高重复、高噪音的任务上AI能替代百分之八十的体力活但剩下的百分之二十判断力才是这份日报真正的价值所在。2. 整体设计思路先定义“你的AI日报”到底是什么2.1 别急着找工具先想清楚你要监控什么很多人一听说要做AI日报第一反应是“哪个工具最好用”。但以我做下来的经验工具永远是最后一步。最先要想清楚的是你到底关心什么。我给自己定的监控主线有四条。第一条是模型与算力层包括主流大模型的版本更新、开源模型发布、评测基准变化这一块决定了我对技术趋势的基本判断。第二条是Agent与工程实践包括Agent框架的迭代、记忆与规划机制的改进、多智能体协作方案这是我个人最关注的方向因为2026年AI应用开发的核心早就从“单次对话”转向了“多步骤任务执行”。第三条是AI应用与场景落地比如AI编程、AI短剧、AI旅游规划这类具体产品形态它们能直观反映技术到底在哪些场景里真的产生了价值。第四条是行业信号与风险包括AI幻觉引发的争议案例、数据合规问题、热门AI网站的流量变化这些信息能帮助我避开一些明显的泡沫。想清楚这四条主线之后我对“热搜词”的态度就变得很明确了。热搜词本身不是信息源它只是一个信号触发器。比如“AI Agent”上了热搜我不会直接去看热搜里的帖子而是会去找这个热词对应的原始信息源头——是谁发布了什么框架、跑出了什么效果、社区讨论的焦点是什么。这就像做菜热搜是饭馆门口的排队人群原始信源才是后厨里真正在炒的菜。2.2 技术选型为什么我选了“RSS 爬虫 大模型API”的轻量组合确定了监控什么接下来才是技术选型。我目前用的是“RSS 定向爬虫 大模型API 定时脚本”的组合没有用任何现成的全天候自动监控平台。这么选的原因有几个。第一这套组合的成本最低。我只需要一台低配云服务器2核4G就完全够用加上一个大模型API的调用额度一个月在基础设施上的开销可以控制在很低的水平。第二它足够灵活。我今天想加一个监控源只需要在配置里加一行想调整摘要长度改一段提示词就能生效。第三也是最重要的一点它让我保持了对整个流程的完全掌控。用第三方平台当然省事但信息源选择、过滤逻辑、输出格式全都被平台的规则限制住了这对于一份“我的日报”来说反而是最大的问题。具体的组件选型我是这样搭配的。采集层用开源的RSSHub加自写Python爬虫负责抓取各个信源的更新。处理层调用大模型API做内容清洗、摘要生成、分类打标这里就涉及到大模型本地部署和云端API的选择问题后面我会专门讲。存储层用一个简单的SQLite数据库记录每天抓到的条目、生成的摘要和最终的发布状态。分发层用脚本生成Markdown文档同时推送到我自己的邮箱和团队群。整套流程跑起来之后我每天的工作量被压缩得很小早上起来花十分钟扫一眼生成的初稿调整几条摘要的措辞删掉一两条我觉得不重要的内容然后点一下推送按钮。两分钟之后这份日报就出现在我所有需要它出现的地方了。3. 信息采集层决定日报质量下限的关键环节3.1 信息源清单我每天盯着的这些地方日报的质量百分之七十取决于信息源。哪怕摘要写得再漂亮如果源本身就漏了或者偏了整份日报的价值都会大打折扣。我目前的信息源大致分成四类。第一类是官方发布渠道包括各大AI实验室的官方博客、知名开源模型的GitHub仓库Release页面、以及学术预印本网站的最新论文列表。这类源的特点是权威性高、时效性强但问题是噪音也不少——官方博客发一篇宣传性质的文章未必说明技术真的有突破。第二类是高质量社区包括海外技术论坛的热门讨论、国内几个头部AI社区的精选文章。这些地方能看到一线开发者的真实使用反馈很多模型的问题评测、框架的坑在官方文档里是看不到的。第三类是行业媒体与聚合站我自己维护了一个“热门AI网站汇总”列表里面包括几个公认信息质量较高的资讯站和分析平台这类源适合用来补充宏观视角。第四类是社交平台的热搜榜与话题流但这类源我处理得比较谨慎它们更多是作为信号触发器而不是直接的内容来源。我把自己常用的信息源整理成了一张表方便你参考信息源类型具体示例监控频率采集方式官方发布头部AI实验室博客、大模型GitHub仓库每2小时RSS GitHub API高质量社区技术社区精选帖、开发者论坛每4小时RSS 定向爬虫行业媒体知名AI资讯站、深度分析平台每6小时RSS学术论文预印本网站最新论文每12小时arXiv API热搜信号平台热搜榜每30分钟爬虫仅作触发信号3.2 抓取细节用RSSHub加自写爬虫解决“采集难”信息源确定之后下一步是解决“怎么抓”的问题。这里我要多说一句不要小看采集层它是我整个流程中踩坑最多的地方。RSSHub是我整个采集体系的底座。它是一个开源的RSS生成工具可以把很多没有提供RSS的网站转换成标准RSS输出。我用它统一接了大部分社区和媒体类源好处是接口统一、部署简单、社区维护的路由非常丰富。但RSSHub也有自身的局限性部分路由年久失修抓取频率过高容易被目标网站限制而且有些动态加载的页面很难靠它处理。所以对于RSSHub覆盖不好的站点我会写定向爬虫做补充。我的经验是写爬虫时有三个细节需要特别注意。第一是请求频率控制我一般对同一域名设置的请求间隔不低于10秒低于这个阈值很容易被识别第二是User-Agent和Cookie处理很多站点会对非浏览器请求做拦截伪造一个正常的浏览器请求头能省很多麻烦第三是页面结构变化的容错所有解析逻辑必须包在异常处理里一旦目标网站改版宁可这条数据暂时抓不到也不能让整个采集流程崩掉。抓下来的原始内容我会统一存进SQLite一个条目包含标题、原文链接、来源、发布时间、正文内容等字段。之所以在“预处理”阶段就做清洗是为了避免把大量HTML噪声数据直接灌给大模型那样既浪费token还容易干扰模型的判断。4. 核心处理逻辑大模型如何帮我把噪音变成信息4.1 内容初筛用规则加模型做两级过滤采集到的原始内容质量是参差不齐的。有的确实是重要进展有的只是营销软文还有大量的是重复报道——同一个模型发布了几十个媒体各写一篇内容大同小异。如果直接把所有内容丢给大模型生成摘要不仅成本高而且日报的阅读体验会非常差。所以我做了两级过滤。第一级是规则过滤先把明显不符合要求的内容踢掉。规则包括标题或正文命中“广告”“推广”“抽奖”等关键词的内容长度过短的比如少于100字基本可以判断是凑数的来源属于我明确拉黑的营销号的以及同一事件的多篇重复报道我会用标题归一化加相似度计算做初判。这一级过滤能砍掉大概百分之三十到四十的噪音。第二级是模型过滤。规则处理不了的内容我会用大模型API做一个“相关性打分”让模型基于我事先定义好的四条监控主线模型进展、Agent工程实践、应用落地、行业信号对每条内容判断它跟哪些主线相关、相关程度有多高、以及是否值得出现在今天的日报里。这一步的关键是提示词设计我后面会展开讲。做完整套过滤之后一天下来真正能进入日报候选池的内容一般也就是十条到二十条左右。这时候日报的骨架就基本出来了。4.2 摘要生成与事实核查让每条内容都“可读”过滤之后是摘要生成。这一步看起来简单——把长文缩短嘛——但实际做起来里面的门道不少。我给大模型的摘要要求是“三段式”第一段说清楚发生了什么事包括主体、动作、时间第二段说明这件事为什么重要也就是它对行业、对开发者、对某个应用场景意味着什么第三段是我个人比较看重的一点——给出可能的质疑点或值得关注的方向。比如某个模型声称跑分超过了GPT系列摘要里就应该点明“该成绩为官方自测数据尚未有第三方独立复现”这是帮读者建立判断力的关键。这里必须强调一个我在实际使用中遇到过很多次的问题AI幻觉。大模型生成的摘要偶尔会编造原文里没有的细节比如把发布时间搞错、把模型参数量张冠李戴、甚至“创作”一条根本不存在的引用。我的应对方案是摘要生成之后会增加一个“事实核查”步骤让模型对照原文检查摘要里的关键事实是否都有出处如果模型判断某条关键信息在原文中找不到依据这条摘要会被标记为存疑交给人工确认。这个方法不能百分之百消除幻觉但确实能把幻觉出现的概率降低不少。关于AI幻觉这个话题后面我在常见问题部分还会专门展开这是一个做AI信息流产品时绕不开的坑。4.3 分类打标与关联推荐日报的附加价值有了经过清洗和摘要的内容之后我还会让模型做一件事分类打标和关联推荐。分类打标比较好理解就是把每条摘要归入我前面定义的主线分类再打上一些具体标签比如“#多模态”“#AI编程”“#Agent框架”“#开源”。这样日报在展示的时候读者可以按分类快速定位自己感兴趣的部分——关心技术的人直接看模型进展关心落地的人直接看应用案例不用从头到尾刷一遍。关联推荐是我后来加上的功能。我会在每天的日报末尾列出几个“延伸阅读”主题比如今天日报的核心话题是“AI Agent的长期记忆机制”那我就会让模型基于当天的信息池推荐几个相关的往期主题或外部链接。这个功能最初是为了解决一个问题很多单篇新闻单独看没什么感觉但如果你能把它放在一个连续的技术演进脉络里看价值就完全不一样了。日报不应该只是一份当天的信息清单它更应该是一条贯穿时间的技术观察线。5. 分发与自动化让日报每天准点出现在该出现的地方5.1 输出格式模板一份清爽的Markdown日报所有处理完成之后最后一步是把内容组装成一份可以发布的日报。我用的是Markdown格式模板固定字段清晰这样无论是在邮箱里、群里、还是放在自己的知识库里阅读体验都是一致的。我目前的日报模板大致长这样开头是日期和当天的一句“核心判断”这是我自己写的不交给模型用来表达当天最重要的一个观点然后是“今日重点”区列出两三条我认为今天最值得关注的进展接着是分类内容区按模型进展、Agent工程实践、应用落地、行业信号四个板块排列每条包含标题、一句话摘要、原文链接最后是“延伸阅读”和“方法论备注”后者记录我今天在维护日报过程中的一些观察比如某个信源的质量下降了、某个话题的讨论热度异常了这些备注是我自己复盘用的。这个模板看起来简单但它是经过好几轮迭代才稳定下来的。早期版本的日报更像一个“合集”把所有抓到的内容都列上去问题是我自己第二天回看的时候完全不知道当天到底发生了什么重要的事。后来我把“判断”提到了日报的核心位置用模型过滤掉低信息量内容每天只保留真正值得细看的十条左右阅读体验和复盘价值才有了本质的提升。我自己的感受是一份日报最重要的不是覆盖了多少信息而是帮读者省掉了多少信息噪音。5.2 定时任务与推送渠道跑了一个月没断过自动化是整个流程里最省心的部分但对稳定性要求高。我用Cron定时任务把整条流水线串起来凌晨2点跑一次增量抓取凌晨3点跑一次内容清洗和初筛凌晨4点跑一次摘要生成和分类打标早上6点半之前完成所有内容的格式化推送到各个渠道。这里有一个运行细节值得分享整个流程里最耗时的不是爬虫也不是摘要生成而是大模型API的调用。如果当天抓到的原始内容比较多逐条调用API做过滤和摘要整体耗时可能超过一个小时。为了压缩这个时间我做了两个优化。第一是批量调用把多条内容一次性发给模型处理用JSON格式返回结果这样能极大减少API交互次数第二是并发控制在保持合理速率上限的前提下把请求做并发执行这里需要特别留意API的限流策略但把它保持在阈值以内整体提速是我单条跑法的三倍左右。推送渠道方面我目前同时推送到邮箱、团队群和自己维护的一个个人知识库。用邮箱是为了私密存档用群是为了方便团队协作用知识库是为了后续可以基于积累的历史日报做更长期的分析。这套自动化配置跑了一个多月中间只因为一次云服务器内存溢出中断过一次后面我会再提到这个问题。6. 常见问题与排查技巧实录6.1 抓取被限流怎么办三个换着用的应对策略做采集最常遇到的就是限流。我的处理策略有三个按优先级排列。第一个是降低请求频率把单源请求间隔从10秒调整为20秒到30秒虽然采集速度会变慢但好在日报对时效性的要求是“小时级”而不是“分钟级”慢一点完全能接受。第二个是切换请求入口部分站点屏蔽了数据中心的IP段我会尝试配置代理池或者直接换成目标站点的公开API。第三个是调整采集策略本身牺牲掉一些实时性要求不高的源把它们的抓取频率调到一天一次重点保障核心源。如果以上策略都无法解决我的底线原则是先记录告警不阻塞整体流程。日报可以缺少某一个源的数据但不能因为一个源的问题导致整条流水线挂掉。自动化流程设计的核心不是追求每个环节最优而是保证整个系统在任何情况下都能稳定地产出一个结果——哪怕这个结果稍微晚一点、稍微缺一点内容。6.2 大模型输出不稳定结构化输出与降噪技巧用大模型处理日报内容最头疼的问题就是输出不稳定。同一批输入有时候给你规范的JSON有时候给你一段带着解释的散文。这个问题我试过很多方案最终的落地做法是三步。第一步在提示词里强制指定输出格式要求“严格输出JSON不要包含任何解释性文字”。第二步在代码层做容错解析不直接信任模型输出的“JSON字符串”而是先尝试用正则提取里面的JSON片段再交给解析器解析失败就自动触发重试。第三步对重试仍然失败的条目直接放弃自动处理把它扔进人工队列宁可在日报里少一条内容也不要让一条格式错误的数据把整个推送流程带崩。还有一个细节是温度参数。做摘要和分类这类任务我会把大模型的温度调得偏低这样输出更稳定、更贴近原文内容但如果要让模型做一些发散性的事情比如生成延伸阅读的推荐理由我会把温度稍微调高一点避免每条推荐看起来都是一种模板味道。“加工能力”和“创造力”本身是两回事做信息流处理时我更看重前者。6.3 AI幻觉问题在真实业务场景里如何防御前面提到了AI幻觉这里我想多聊一点。在纯聊天场景里AI幻觉顶多让对话看起来有点“言之凿凿”但内容存疑但在我的日报流程里幻觉是会直接误导读者的。比如模型在摘要里写“某开源模型在MMLU基准上超过了顶尖闭源模型”如果这个信息是模型自己编的那这份日报就发了一个假消息。我的防御体系分三层。第一层是提示词约束明确要求摘要中所有关键事实必须能在原文中找到依据如果找不到就必须明确标注“原文未提及”。第二层是人工抽查我会用脚本每天随机抽取五条左右的摘要拿原文快速比对一遍重点检查时间、数字、主体称谓这些容易被模型搞错的地方。第三层是信源加权来自官方发布和高信誉信源的内容模型生成的摘要可以被直接信任的权重更高来自二手转述的信息权重就调低人工抽查的比例也会相应提高。这套三层防御不能做到百分之百不出错但到目前为止我还没发现过一条实质性错误信息被直接推送到读者面前。这让我更加坚定了一个判断AI幻觉这个问题短期内不可能从技术层面彻底根治但可以通过流程设计把它约束到可控的范围内。6.4 服务器资源不足一次内存溢出的排查过程最后分享一下我踩过的一个实打实的坑。前面的内容提到过我的整套流程跑在一台2核4G的低配云服务器上本来觉得足够了但有一次连续三天日报都没准时推送。排查下来发现问题出在内存上。原因是这样的采集阶段有一个字段我存的是整篇网页正文有些文章特别长几十篇加在一起占用了几百兆内存加上大模型调用时的并发处理线程以及SQLite连接缓存没有及时释放服务器的内存峰值直接顶到了上限。最终表现就是进程被系统杀掉Cron任务执行失败日志里全是内存不足的错误。我的解决方案有三个。第一调整配置把并发调用数从10降到4压缩内存峰值第二优化存储正文存入数据库前做截断处理超过一定长度的内容只保留开头部分第三增加了进程守护核心任务的执行脚本被异常杀死后会自动重启同时推送一条告警通知我。经过这些调整之后这套流程已经稳定运行了很长时间没再出过类似问题。7. 从“做日报”到“用日报”一点个人总结整套AI日报系统从构思到稳定运行前后花了大概两周时间。第一周主要在搭框架和选信息源第二周在优化提示词、处理各种异常和打磨输出模板。现在每天维护它只需要花十分钟左右但每天回看这份日报我都能清晰地知道过去24小时AI领域发生了什么、什么值得跟进、什么只是在制造噪音。我个人的感受是这套系统的价值远不止于“省时间”。更重要的收获是它帮我建立了一种稳定的信息摄入节奏和判断框架。在2026年这个AI信息高度爆炸的环境里真正稀缺的不是信息本身而是对信息说“不”的能力。我做这份日报的过程本质上就是在持续训练自己对信息的筛选标准和判断力——大模型负责处理信息而我负责判断什么值得被看见。如果你也想搭一套类似的东西我的建议是不要一开始就想做一个功能完整的重型系统。先把最核心的链路跑通——抓一个源、做一条摘要、推一条消息——然后基于真实使用体验一点点加功能、调细节。这个从轻到重的过程本身就是你对“AI信息处理”这件事理解逐渐深入的过程。AI工具再强也只是放大你的判断力而不是替代你的判断力。