从312条到9条：AI日报自动化筛选与摘要实战

1. 一份AI日报的诞生：从信息洪流到结构化输出

每天早上七点，我的手机屏幕上会准时弹出一份自己搭建的AI资讯日报。它不是某个平台推送的，也不是花钱订阅的，而是我用一套跑了快两年的自动化流程，从几十个信息源里筛出来、去重、分类、摘要之后生成的。2026年9月26日这一期，恰好是一个比较典型的样本——当天没有那种“某大厂发布万亿参数模型”的爆炸性新闻，但散落着几条值得琢磨的动向，涉及模型推理成本、端侧部署、以及一个挺有意思的开源工具更新。

很多人做资讯聚合，第一反应是“抓就完了”。但真正做过的人都知道，抓取是最简单的一步，难的是后面：怎么判断一条消息值不值得进日报？怎么把不同来源的同一件事合并成一条？怎么在几十秒内生成一段人话摘要而不是机器翻译腔？这些问题我在过去两年里反复踩坑，今天借着这份日报的拆解，把整套思路和实现细节摊开讲。

这篇文章适合几类人看：一是想自己搭一套个人信息过滤系统的开发者；二是做技术选型时需要快速了解AI领域动态的工程师；三是对自动化内容生产流程感兴趣的产品或运营同学。我会从信息源的选取逻辑讲起，一直讲到最终日报的排版和推送，中间涉及的具体工具、参数配置、踩坑记录都会给到。你不需要有很深的编程背景，但如果你会一点Python或者愿意用现成的自动化平台，复现起来会顺畅很多。

先说结论：一份好的AI日报，核心不在于信息量有多大，而在于信噪比有多高。我现在的日报每天大概只保留8到15条内容，但每一条都是我判断“如果今天只看这一条，值不值”之后留下来的。下面拆开讲。

2. 信息源的分层策略：为什么我只留了23个源

2.1 从“贪多”到“做减法”的转变

刚开始做日报的时候，我恨不得把能找到的AI相关网站全塞进去。最多的时候有80多个源，包括各种科技媒体、个人博客、论文预印本平台、甚至社交平台上的讨论帖。结果就是每天抓回来几百条，光去重和筛选就要花一个多小时，而且很多内容重复度极高——同一篇论文被五六个媒体翻来覆去地写，真正有价值的一手信息反而被淹没了。

后来我做了一次大砍，把源分成三个层级，每个层级只留最核心的几个。现在的配置是这样的：

第一层：一手信息源（6个）

• 主要AI实验室的官方博客和公告页
• 几个核心预印本平台的最新论文列表
• 重要开源项目的Release页面

这一层的价值在于“快”和“准”。官方发布的东西不需要二次解读，直接看原文最靠谱。但缺点是更新频率不稳定，有时候一周没动静，有时候一天发好几篇。

第二层：高质量二手解读（9个）

• 几个我长期跟踪的技术分析博客
• 两个做深度报道的科技媒体
• 一个专门做论文解读的通讯

这一层的作用是“翻译”和“补充背景”。一手信息往往很干，比如一个模型更新公告只说了“推理速度提升40%”，但没说在什么硬件上、什么batch size下测的。好的二手解读会把这些上下文补上。

第三层：社区信号（8个）

• 两个开发者社区的热门讨论
• 一个问答平台的高赞回答
• 几个技术群组的每日摘要

这一层不是用来获取“事实”的，而是用来感知“情绪”和“关注点”。有时候一条消息在官方渠道看起来平平无奇，但在社区里被反复讨论，那说明它可能触到了某个真实的痛点。

提示：信息源不是越多越好。每增加一个源，你就要多花一份精力去维护它的解析规则、处理它的格式差异。我现在的原则是，如果一个源连续两周没有产出被日报收录的内容，就果断砍掉。

2.2 每个源的抓取方式与解析要点

不同源的抓取难度差别很大。官方博客通常有RSS，直接订阅就行，但有些实验室的页面是动态渲染的，需要走API或者用无头浏览器。预印本平台一般有结构化的列表页，但摘要和作者信息的提取需要针对性的解析规则。

我用的工具组合比较简单：feedparser处理RSS，requests加BeautifulSoup处理静态页面，遇到动态渲染的就用Playwright。没有上重型爬虫框架，因为源的数量不多，维护成本比性能更重要。

解析的时候有几个细节容易忽略：

• 时间戳的时区问题：不同源用的时区不一样，有的用UTC，有的用当地时间。如果不统一转换，排序就会乱。我统一转成UTC+8，然后在日报里标注“北京时间”。
• 摘要的截断策略：很多源的RSS只给前200个字符，遇到这种情况我会去抓原文页面的meta description，通常比RSS摘要完整。
• 去重的指纹设计：不能只用标题去重，因为同一件事不同媒体的标题差异很大。我用的是“标题关键词集合+正文前100字的SimHash”，效果比单纯标题匹配好很多。

2.3 源的健康监控：怎么知道某个源“死”了

这个坑我踩过好几次。有个博客突然改版，RSS地址变了，我的抓取脚本连续一周返回空列表，但我没发现，直到有一天想找之前看过的一篇文章才意识到漏了很多内容。

后来我加了一个简单的健康检查：每次抓取后记录每个源返回的条目数，如果连续三次低于历史均值的30%，就发一条提醒到我的通知渠道。同时每周生成一份源活跃度报告，看看哪些源在“摸鱼”。

这个机制帮我及时发现了好几个源的问题，包括一个被墙的、一个改版的、还有一个因为作者停更而变成僵尸源的。

3. 筛选与排序：怎么从300条里挑出15条

3.1 第一道筛子：硬性规则过滤

抓回来的原始条目大概在200到400条之间，第一步是用规则砍掉明显不相关的。我的规则列表不长，但每一条都是根据实际踩坑总结的：

• 关键词黑名单：比如“招聘”“活动报名”“课程推广”这类明显是营销内容的，直接过滤。但要注意，有些技术文章标题里带“招聘”其实是公司在招人时顺便发的技术分享，这种要保留。我的做法是看正文里招聘内容的占比，超过50%才过滤。
• 来源权重阈值：第三层来源的条目，如果标题里没有出现我关注的核心关键词（比如“推理”“部署”“开源”“评测”等），就直接跳过。第一层和第二层的不做这个限制。
• 重复内容合并：用前面说的SimHash做近似去重，相似度超过85%的合并成一条，保留信息量最大的那个版本。

这一步之后，通常还剩80到120条。

3.2 第二道筛子：基于兴趣模型的打分

剩下的条目我会用一个简单的打分模型来排序。这个模型不复杂，就是几个维度的加权和：

这个权重不是拍脑袋定的，是我用大概三个月的历史数据回归出来的。简单说就是，我记录了自己每天实际点开了哪些条目，然后反推哪些特征最重要。结果发现“来源层级”和“关键词匹配”加起来解释了大部分选择，所以这两个给了比较高的权重。

注意：这个模型不需要很精确。它的作用是把明显不相关的排到后面，而不是精确预测我会看什么。我每天还是会扫一眼排名20到30的条目，有时候会有意外收获。

3.3 人工兜底：为什么我坚持每天花5分钟手动过一遍

完全自动化的日报我试过，跑了两个月就放弃了。问题在于，有些重要的东西机器判断不了。比如某天有一条关于某个模型许可证变更的消息，标题很平淡，关键词也没命中，但我知道这个变更会影响很多商业项目的合规性。这种就得靠人。

所以现在的流程是：机器筛完、排完序之后，我会花5分钟快速扫一遍前30条，手动调整一下顺序，偶尔补一两条机器漏掉的。这5分钟是整个流程里性价比最高的投入。

4. 摘要生成：怎么让机器说人话

4.1 抽取式摘要的局限与改进

最开始我用的是TextRank做抽取式摘要，就是从原文里挑几个句子拼起来。效果怎么说呢，能看，但读起来很别扭。因为AI领域的文章经常有大量的指代和省略，抽出来的句子单独看往往缺主语或者缺上下文。

后来我改成“抽取+轻量改写”的方式。具体做法是：先用TextRank选出3到5个关键句，然后用一个小的语言模型把这些句子改写成一段连贯的话。这个模型不需要很大，我用的是一个7B参数的开源模型，量化之后在本地跑，生成一段100字左右的摘要大概需要1.5秒。

改写的时候有几个约束条件：

• 必须保留原文中的数字和专有名词
• 不能添加原文没有的信息
• 长度控制在80到120字之间

4.2 不同内容类型的摘要模板

不是所有条目都适合同一种摘要方式。我根据内容类型分了几个模板：

论文类：结构是“提出了什么问题→用了什么方法→取得了什么效果”。重点放在方法和效果上，背景一笔带过。

工具/框架更新：结构是“更新了什么→解决了什么痛点→有什么注意事项”。重点放在“解决了什么”上，因为读者最关心的是“我要不要升级”。

行业动态：结构是“发生了什么→涉及哪些方→可能的影响”。重点放在影响分析上，但要注意不能过度推测，只写有依据的判断。

技术讨论：结构是“讨论的核心问题→主要观点→争议点”。重点放在争议点上，因为那才是讨论的价值所在。

4.3 摘要质量的自动检查

生成完摘要之后，我会跑几个自动检查：

• 长度检查：太短（<60字）或太长（>150字）的打回重做
• 数字一致性：摘要里的数字必须在原文中出现过
• 专有名词检查：摘要里出现的模型名、公司名必须在原文中出现过
• 重复度检查：摘要和原文的重复度不能太高（否则就是直接抄），也不能太低（否则可能跑偏）

这些检查能拦掉大部分明显有问题的摘要，剩下的偶尔有瑕疵的，我在人工过的时候会顺手改掉。

5. 日报的排版与推送：怎么让人愿意每天打开

5.1 版式设计的几个原则

我试过很多种排版，最后稳定下来的格式是这样的：

• 标题：一句话概括当天最值得关注的事，不超过20个字
• 导语：2到3句话说明今天的整体情况，比如“今天模型推理成本相关的内容比较多，另外有一个开源工具值得关注”
• 正文：按主题分块，每块一个小标题，下面跟2到4条相关条目
• 每条条目：标题+摘要+来源链接，摘要控制在100字以内
• 末尾：一个“今日数据”小栏目，显示抓取了多少条、筛掉了多少、最终保留了多少

这个格式的好处是，读者可以在30秒内扫完导语和标题，决定要不要细看。如果对某个主题感兴趣，再展开看具体条目。

5.2 推送渠道的选择

我目前用的是两个渠道：一个是邮件，每天早上7点准时发；另一个是即时通讯工具的一个私有频道，方便在手机上快速浏览。

邮件的好处是格式稳定、可以存档、方便搜索。即时通讯工具的好处是打开率高、可以快速转发。两个渠道的内容是一样的，只是排版上即时通讯工具的版本会更精简一些，去掉了来源链接的完整URL，改成短链接。

提示：推送时间很重要。我试过早上6点、7点、8点、9点，最后发现7点打开率最高。太早大家没醒，太晚已经被其他信息淹没了。当然这个跟你的读者群体有关，需要自己测。

5.3 反馈闭环：怎么知道日报有没有价值

我在每期日报的末尾放了一个很简单的反馈入口：一个“有用”按钮和一个“没用”按钮。点击之后会记录是哪一期、哪个位置的内容。积累了一段时间之后，我发现几个规律：

• 工具更新类的“有用”率最高，尤其是那种“解决了某个具体痛点”的更新
• 纯论文解读的“有用”率偏低，除非论文本身有很强的应用价值
• 行业动态类的“有用”率波动很大，跟当天事件的重要性强相关

这些反馈会反过来影响我的筛选权重。比如我现在会给“工具更新”类的条目额外加0.1分，因为数据显示这类内容更受欢迎。

6. 2026年9月26日这期日报的拆解

6.1 当天抓取与筛选的数据

这一期的情况是这样的：

• 抓取源：23个
• 原始条目：312条
• 硬性规则过滤后：97条
• 打分排序后进入人工筛选范围：前35条
• 人工筛选后保留：12条
• 最终日报呈现：9条（合并了3组重复内容）

从312到9，压缩率大概是97%。这个比例在正常范围内，有时候会更低，比如遇到某个大事件被反复报道的时候，压缩率能到99%。

6.2 当天几条值得说的内容

这一期有几条内容我印象比较深，拿出来说说筛选和摘要时的思考过程。

第一条是关于某个推理框架的更新。这个框架我之前在日报里提过两次，所以有历史记录。更新公告写得很技术，主要说了“优化了KV Cache的内存管理，在长上下文场景下显存占用降低约30%”。摘要的时候我特意加了一句“对长文本对话场景比较友好”，因为这是读者最可能关心的应用场景。来源是第一层，权重高，直接进了前五。

第二条是一个社区讨论，关于某个模型在特定任务上的表现不如预期。这个讨论在社区里热度很高，但官方没有回应。我在摘要里没有下结论，只是客观陈述了讨论的主要观点和争议点。这条来自第三层，但因为社区热度高，打分被拉上来了。

第三条是一个开源工具的小版本更新，修复了一个之前被很多人吐槽的bug。这种内容在传统媒体上根本不会报道，但对于实际在用这个工具的人来说很重要。摘要里我直接写了“修复了XX场景下的崩溃问题，建议升级”，简单直接。

6.3 当天漏掉的一条和事后的反思

当天有一条关于某个数据集更新的消息，机器没有筛进来，我人工过的时候也漏掉了。后来在第二天的社区讨论里看到有人在提，才回去翻记录发现确实抓到了但被过滤了。原因是那条消息的标题里没有命中我的关键词列表，而且来源是第三层，权重不够。

这件事提醒我，关键词列表需要定期更新。我现在每个月会花10分钟看一下当月漏掉的重要条目，把相关的关键词补进去。这个习惯帮我慢慢把召回率提上来了。

7. 整套流程的自动化实现：从定时任务到最终推送

7.1 定时调度与错误处理

整套流程跑在一个小型的云服务器上，用cron做定时调度。每天凌晨5点开始抓取，5点10分开始处理，6点30分生成日报，7点推送。中间留了足够的缓冲时间，万一某个环节慢了也不影响推送。

错误处理方面，每个环节都有重试机制。抓取失败重试3次，间隔30秒。处理失败会记录日志并跳过当前条目，不影响整体流程。如果最终日报生成失败，会发一条告警到我的手机，我手动介入。

7.2 数据存储与历史查询

所有抓取到的原始条目、处理后的摘要、以及最终的日报，都存在一个本地的SQLite数据库里。这样做的目的是方便回溯和查询。比如我想找“过去三个月所有关于推理优化的内容”，直接写个SQL就能查出来。

数据库的表结构很简单，主要就是raw_items、processed_items和daily_reports三张表。raw_items存原始抓取内容，processed_items存去重、打分、摘要之后的内容，daily_reports存最终生成的日报。

7.3 成本估算：这套东西一年花多少钱

很多人关心成本，我算一下：

• 云服务器：最便宜的那种，一年大概200块
• 语言模型推理：本地跑的，电费忽略不计
• 邮件推送：用的免费额度，够用
• 即时通讯工具：免费

所以一年的硬成本就是200块左右。时间成本的话，搭建花了大概两个周末，之后每周维护大概10分钟。这个投入产出比我觉得很划算。

8. 踩过的坑与经验总结

8.1 不要追求“大而全”

我见过很多人做资讯聚合，一上来就想覆盖所有源、所有话题。结果就是维护成本爆炸，而且质量上不去。我的建议是，先选5个源跑通流程，然后慢慢加。每加一个源之前，先问自己：这个源能提供其他源没有的信息吗？如果不能，就别加。

8.2 摘要质量比数量重要

一开始我追求每天出20条以上，后来发现读者根本看不完。现在控制在10条左右，每一条都保证质量。宁可少一条，也不要凑数。

8.3 人工环节不能省

完全自动化的日报我试过，效果不好。机器可以处理90%的工作，但最后10%的判断需要人来做。这10%恰恰是决定日报质量的关键。

8.4 反馈机制要简单

我试过很复杂的反馈表单，结果没人填。现在就两个按钮，“有用”和“没用”，点击率反而高了。反馈机制越简单，越容易拿到真实数据。

8.5 定期回顾和调整

我每个月会花半小时回顾一下这个月的日报，看看哪些内容受欢迎、哪些被忽略、哪些源表现好、哪些源在摸鱼。然后根据回顾结果调整关键词、权重、源列表。这个习惯让整套系统一直在进化，而不是搭好之后就一成不变。

最后分享一个我最近在试的小改进：在摘要生成的时候，我会让模型额外输出一个“一句话推荐语”，比如“如果你关注推理成本，这条值得看”或者“这个工具更新解决了一个长期痛点”。这个推荐语会放在条目的最前面，帮助读者快速判断要不要细看。目前测试下来，加了推荐语的条目点击率比没加的高出大概20%。这个改进还在迭代中，等跑一段时间再跟大家分享完整数据。