1. 一份AI日报的诞生：从信息洪流到结构化简报
每天早上七点，我的手机屏幕上会准时弹出一份自己搭建的AI日报。它不是某个平台推送的资讯流，也不是订阅的付费简报，而是一套跑在我本地环境里的自动化流水线——从抓取、筛选、摘要、分类到排版输出，全程无人值守。这套东西最初只是为了解决一个很具体的痛点：AI领域的信息更新速度太快，公众号、技术社区、预印本平台、开源仓库、行业博客，每天产生的有效信息少说几百条，靠人工刷根本刷不过来，而且刷完也记不住。我需要的是一个每天固定时间、固定格式、只保留真正值得看的内容的简报。
这份日报的核心价值不在于“聚合”，而在于“过滤”和“压缩”。聚合谁都会做，RSS阅读器就能干。但过滤需要判断力，压缩需要理解力。我给自己定的目标是：每天输出不超过15条，每条不超过120字，但每条都要让我在30秒内判断出“这条跟我有没有关系、要不要点进去看原文”。这个标准听起来简单，做起来涉及一整套工程化的处理链路。下面我把这套系统的设计思路、关键模块、踩过的坑和调优经验完整拆开讲一遍，适合有一定Python基础、想自己搭建信息处理流水线的朋友参考。
2. 信息源的选择与权重设计：为什么不是越多越好
2.1 我最终保留的六类信息源
一开始我贪多，一口气接了二十多个RSS源，结果每天抓回来上千条，光去重和筛选就耗掉大量时间，而且噪音比例极高。后来我做了减法，最终稳定在六类源上，每类只保留两到三个最优质的：
- 预印本平台：arXiv的cs.AI、cs.CL、cs.LG三个分类，这是学术前沿的风向标，但需要过滤掉大量低质量投稿。
- 开源社区：GitHub Trending的Python和Jupyter Notebook分类，以及几个高星项目的Release页面。这里能第一时间发现工具链的更新。
- 技术博客：几个头部实验室和独立研究者的博客，更新频率低但质量极高，属于“必看”级别。
- 行业媒体：两到三家专注AI的垂直媒体，用来捕捉商业动态和产品发布。
- 社区讨论：个别技术论坛的热门帖，用来感知从业者真正在关心什么。
- 官方公告：主要框架和平台的版本更新日志，这个不能漏，否则容易踩兼容性的坑。
注意：信息源不是越多越好。每增加一个源，你就要多维护一套解析规则，而且噪音是线性增长的，但有效信息往往是对数增长的。我的经验是，超过15个源之后，边际收益几乎为零。
2.2 权重机制的设计逻辑
光有源还不够，不同源的信息价值差异很大。我给每个源设了一个基础权重，范围0到1，预印本平台给0.7，因为量大但需要筛选；头部实验室博客给0.95，因为几乎每篇都值得看；行业媒体给0.6，因为商业新闻的时效性强但深度有限。这个权重会参与后续的排序计算。
权重的调整不是拍脑袋定的，我跑了两周的数据，统计每个源被我点开原文的比例，然后反过来修正权重。比如某个媒体源我点开率只有8%，那它的权重就从0.6降到0.4。这个反馈闭环很重要，否则权重就是摆设。
2.3 抓取频率与时间窗口的取舍
抓取频率我试过三种方案：实时抓取、每小时抓取、每天固定两次。实时抓取对服务器压力大，而且很多源本身更新就不频繁，抓回来大量重复内容。每小时抓取稍微好一点，但去重逻辑要写得非常严谨。最终我选了每天两次：早上六点和下午两点。早上那次覆盖前一天下午到当天早上的更新，下午那次覆盖当天上午的更新。这样既不会漏掉重要内容，也不会因为频繁抓取被源站限流。
时间窗口的设定也有讲究。我最初用“过去24小时”作为窗口，但发现周末的更新量明显偏低，导致周一的日报内容很少。后来改成“距离上次抓取以来的所有新内容”，配合一个最大回溯三天的兜底机制，这样即使某天抓取失败，也不会永久丢失内容。
3. 去重与初筛：把一千条压到一百条的关键步骤
3.1 基于标题指纹的快速去重
抓回来的原始数据第一件事就是去重。同一篇内容可能被多个源转载，标题可能略有差异，但核心信息是一样的。我用的是标题指纹法：先把标题转成小写，去掉标点和停用词，然后取前若干个字符的哈希值作为指纹。如果两个标题的指纹相同，就认为是重复内容，只保留权重最高的那个源。
这个方法能干掉大约40%的重复内容，但有个漏洞：有些标题差异很大但内容其实一样，比如中文标题和英文标题的同一篇论文。这种情况指纹法就失效了。后来我加了一层基于URL的辅助去重，因为同一篇内容即使标题被改写，原始链接往往是一样的。
3.2 关键词白名单与黑名单的双重过滤
去重之后还有七八百条，接下来是关键词过滤。我维护了两个列表：白名单和黑名单。白名单是必须包含的词，比如“模型”“训练”“推理”“开源”“发布”等；黑名单是必须排除的词，比如“招聘”“广告”“课程推广”“抽奖”等。
这里有个经验：白名单不要设得太窄，否则会漏掉有价值的内容。我一开始只设了十几个词，结果很多重要的工具更新被过滤掉了，因为标题里没有那些词。后来我把白名单扩展到五十多个词，并且允许“标题或摘要中任意一个命中即可”，召回率明显提升。
黑名单则要设得狠一点。我最初只排除了明显的广告词，后来发现很多“软广”标题看起来很正经，但点进去是产品推销。我的做法是维护一个动态黑名单，每次发现误报就手动加进去，跑了一个月之后，黑名单已经能挡住90%以上的噪音。
3.3 基于摘要长度的质量预判
还有一个简单但有效的初筛规则：摘要长度。如果一条内容的摘要少于30个字符，大概率是标题党或者信息量极低的内容，直接丢弃。如果摘要超过500个字符，可能是全文被抓回来了，需要截断处理。这个规则帮我省了不少后续处理的时间。
经过这三步，一千条原始数据通常能压到一百条左右。这个量级才适合进入下一阶段的深度处理。
4. 摘要生成与分类打标：让机器读懂内容
4.1 抽取式摘要为什么比生成式更稳
摘要生成我试过两种方案：抽取式和生成式。生成式用的是本地部署的小型语言模型，效果确实更流畅，但有两个问题：一是偶尔会“幻觉”，编造原文没有的信息；二是速度慢，一百条内容跑完要十几分钟。抽取式则是从原文中直接选句子，虽然读起来没那么顺，但绝对不会出错，而且速度快。
最终我选了抽取式为主、生成式为辅的混合方案。具体做法是：先用TextRank算法从原文中抽出三到五个候选句，然后用一个轻量级的句子打分模型给每个句子打分，选分数最高的两个句子拼成摘要。如果原文本身就很短（比如GitHub的Release说明），就直接截取前两百个字符。
提示：摘要的目标不是“好看”，而是“准确”。一条摘要只要能让读者判断出“要不要看原文”，就算成功了。追求流畅度而牺牲准确性，在这个场景下是得不偿失的。
4.2 分类体系的搭建与迭代
分类我最初设了八个类别：模型发布、工具更新、论文解读、行业动态、教程资源、观点讨论、数据集、其他。跑了一段时间后发现，“其他”这个类别占比太高，说明分类体系不够细。后来我把“其他”拆成了“政策法规”“硬件芯片”“应用案例”三个新类别，并且把“论文解读”进一步细分为“新方法”和“综述”。
分类的实现用的是关键词匹配加规则引擎，没有上机器学习模型。原因很简单：规则引擎可解释、可调试，出了问题能马上定位。比如一条内容标题里有“开源”和“模型”，就归到“模型发布”；有“教程”和“实战”，就归到“教程资源”。规则大概写了三十多条，覆盖了绝大多数情况。
4.3 重要程度的四级打分
每条内容我会打一个重要程度分，分四级：必看、推荐、可选、存档。打分依据包括源权重、关键词命中情况、摘要长度、是否包含代码链接等。比如一条来自头部实验室博客、标题包含“突破”或“首次”、摘要超过一百字的内容，基本就是“必看”。
这个打分直接决定了日报的排版顺序。“必看”放最前面，加粗显示；“推荐”紧随其后；“可选”和“存档”折叠在最后，只显示标题。这样我早上扫一眼就能抓住重点，不用逐条读。
5. 排版输出与推送：怎么让日报真正被读进去
5.1 Markdown格式的排版细节
日报的输出格式我选了Markdown，因为它在任何设备上都能看，而且方便后续导入其他工具。排版上我定了几个规矩：每条内容占一行，格式是“序号.标题（来源）——摘要”。标题加粗，来源用括号标注，摘要用破折号引出。类别用二级标题分隔，比如“## 模型发布”“## 工具更新”。
这个格式看起来简单，但调整了好几版。最初我把摘要放在标题前面，读起来很别扭；后来改成标题在前、摘要在后，顺眼多了。还有序号，我试过用圆点、用方括号、用数字，最后发现数字加圆点最清晰。
5.2 推送渠道的选择与避坑
推送我试过三种：邮件、即时通讯工具、本地文件。邮件的问题是容易被归到垃圾箱，而且手机上读Markdown不方便。即时通讯工具最方便，但需要配置机器人，而且有消息长度限制，日报长了要分多条发。本地文件最简单，但需要我主动去打开。
最终我用了组合方案：日报同时输出到本地Markdown文件和一个即时通讯工具的机器人。本地文件作为存档，方便搜索和回溯；机器人推送作为提醒，让我知道日报已经生成好了。机器人推送我只发一个摘要消息，包含“今日必看X条，推荐Y条”和前三条的标题，详细内容还是看本地文件。
5.3 定时任务的稳定性保障
整个流水线跑在本地的一台小型服务器上，用cron定时触发。这里踩过一个坑：cron的环境变量和用户登录环境不一样，导致脚本里的某些命令找不到。解决办法是在脚本开头显式设置PATH，或者用绝对路径调用命令。
还有一个坑是网络波动。有些源站在特定时间段会超时，导致抓取失败。我的做法是给每个抓取任务设一个重试机制，失败后等三十秒重试，最多重试三次。如果三次都失败，就跳过这个源，但在日报末尾标注“本次抓取失败：XX源”，提醒我手动检查。
6. 运行三个月后，我总结出的五条实战经验
6.1 过滤规则要“宁松勿严”
刚开始我追求高精度，过滤规则设得很严，结果每天只剩五六条内容，很多有价值的信息被误杀了。后来我把规则放宽，宁可多留一些噪音，也不漏掉重要内容。因为漏掉的成本远高于多看的成本——多看一条噪音只浪费几秒钟，漏掉一条重要更新可能错过一个关键的工具版本。
6.2 摘要质量比数量重要
我一度追求每天输出二十条以上，觉得这样才“充实”。但实际读下来，超过十五条之后注意力就明显下降，后面的内容基本是扫过去的。后来我把上限压到十五条，并且要求每条摘要必须能独立传达核心信息。数量少了，但每条都读进去了，实际效果反而更好。
6.3 定期回顾“存档”类别
“存档”类别的内容我平时不看，但每周会花十分钟翻一遍。有些内容当时觉得不重要，过几天再看可能就有用了。这个回顾机制帮我捡回了不少有价值的信息，比如某个工具的次要更新，后来正好用上了。
6.4 源的健康度要持续监控
我写了一个简单的监控脚本，每周统计每个源的抓取成功率、内容量和被点开率。如果某个源连续一周抓取失败，或者内容量骤降，就说明源可能出了问题，需要手动检查。这个监控帮我及时发现了一个源站改版导致解析规则失效的问题。
6.5 不要过度依赖自动化
自动化能解决80%的重复劳动，但最后20%的判断还是得靠人。我每天会花五分钟快速扫一遍日报，把明显分类错误或者摘要不准的条目标记出来，周末统一修正规则。这个人工反馈环节是系统持续优化的关键，完全放手不管的话，规则会越来越偏离实际需求。
7. 后续可以继续打磨的几个方向
目前这套系统已经稳定跑了三个月，每天早上的日报成了我获取信息的主要渠道。但还有几个地方可以继续优化。一是摘要生成可以尝试用更好的本地模型，在准确性和流畅度之间找更好的平衡点。二是分类体系可以引入半自动的聚类方法，让机器发现新的类别，而不是完全靠我手动定义。三是可以加一个“关联推荐”功能，把同一主题的多条内容聚合在一起，方便我一次性看完一个事件的多个角度。
另外，我最近在考虑把日报的输出格式从Markdown扩展到HTML，这样可以加一些交互元素，比如折叠展开、标签筛选。不过这个优先级不高，因为Markdown已经够用了，加太多功能反而会增加维护成本。工具的目的是解决问题，不是炫技，够用就好。
