从信息洪流到可读清单：一套AI日报系统的完整拆解

1. 一份日报的诞生从信息洪流到可读清单每天早上七点我的手机屏幕上会准时弹出一份自己给自己推送的“AI 日报”。它不是某个平台自动生成的摘要也不是爬虫抓来的标题堆砌而是我花了将近两年时间打磨出来的一套信息处理流程的最终产物。2026年9月23日这一期恰好是这套流程迭代到第三版之后跑得最顺的一天我把它完整拆开来讲讲——从信息源筛选、去重、分级到摘要生成、人工复核再到最终排版推送每一步都有它存在的理由也都有踩过的坑。先说清楚这份日报到底解决什么问题。做AI方向的人都有一个共同的痛点信息过载。每天醒来各种渠道涌来的新模型发布、论文预印本、开源项目更新、行业融资动态、政策风向变化少说几百条多则上千条。你不可能全看但你又怕漏掉真正重要的那几条。大多数人的做法是关注几个头部账号等别人嚼碎了喂给自己。但这样做有两个问题一是别人的筛选标准未必适合你二是等别人消化完再输出时效性至少损失半天。我想要的是一份只属于我自己关注维度的日报它知道我在跟踪什么方向、我关心哪些公司的动作、我对哪类技术细节有需求。这份日报的读者只有一个人就是我。但它的设计逻辑其实可以适配任何有类似信息焦虑的从业者。你不需要会写代码才能复现这套流程核心思路是通用的定义信息源、建立过滤规则、设计分级标准、加入人工判断。下面我会把每个环节拆到你能直接抄作业的程度。2. 信息源的取舍为什么我只留了十一个渠道2.1 渠道筛选的三条硬标准最开始我订阅了四十多个信息源RSS、邮件列表、社群推送、聚合站点全都有。结果就是每天光“扫一眼标题”就要花掉四十分钟而且大量内容重复。后来我给自己定了三条硬标准不满足的直接砍掉信噪比连续跟踪两周如果这个渠道推来的内容里我觉得有价值的比例低于百分之二十就取消订阅。这条标准砍掉了将近一半的渠道。不可替代性如果同一个消息在三个渠道都能看到只保留最快、最全的那一个。比如某个模型发布的消息官方博客、科技媒体、社群转发都会出现我只保留官方博客的RSS。可解析性渠道的输出格式必须能被程序稳定解析。纯图片推送、需要登录才能查看全文的、反爬机制频繁变动的一律放弃。这条标准把很多社群渠道排除了虽然它们有时会有独家消息但维护成本太高。最终留下来的十一个渠道大致分为四类官方发布渠道三个、学术预印本平台两个、开源社区动态三个、行业分析通讯三个。每个渠道我都记录了它的更新频率、平均每日条目数、历史有效信息占比这些数据直接决定了它在日报里的权重。2.2 每个渠道的抓取策略差异不同渠道的抓取方式完全不同这里不能一刀切。官方博客通常有标准的RSS输出直接用feedparser解析就行但要注意有些博客的RSS只输出摘要需要额外请求全文页面。学术预印本平台有开放的API接口可以按关键词和时间范围拉取但需要处理作者重名和机构消歧的问题。开源社区动态最麻烦有些项目用Release Notes有些用Commit Message格式极不统一我后来写了一套基于规则和轻量模型结合的解析器才能稳定提取出“这个更新到底改了什么”。提示抓取频率不要设得太高。我一开始设了每十分钟一次结果被某个渠道限流了。后来改成每天固定三个时间点抓取早上六点、中午十二点、下午六点。日报只需要早上那一批中午和下午的抓取是为了给突发重要消息留一个补充通道。2.3 渠道权重的动态调整机制十一个渠道不是平等的。我维护了一张权重表初始权重根据历史有效信息占比来定但每周会做一次微调。调整的依据是过去七天里这个渠道有多少条内容最终进入了日报的“必读”或“推荐”层级。如果一个渠道连续两周没有产出任何进入前两级的条目它的权重会被下调抓取优先级也会降低。反过来如果某个渠道突然连续产出高质量内容权重会临时上调确保不错过它的爆发期。这套机制听起来有点复杂但实现起来就是一个简单的计分板。我用一个表格记录每个渠道的周度表现每周一早上花五分钟更新一下权重。这个习惯坚持了半年之后日报的有效信息密度明显提升从最初的不到三成提高到了现在的七成以上。3. 去重与分级让真正重要的内容浮上来3.1 去重不只是比对标题信息去重听起来简单做起来坑很多。最开始我用标题的编辑距离来判断是否重复结果发现同一个事件在不同渠道的标题写法差异极大编辑距离根本靠不住。后来改成标题关键词集合的Jaccard相似度加上正文前两百字的语义向量相似度双重判断准确率才上来。具体做法是先把标题分词提取出实体词公司名、产品名、技术术语和动作词发布、开源、融资、更新组成一个关键词集合。然后计算两个条目关键词集合的交集除以并集得到一个相似度分数。如果分数超过零点六再计算正文前两百字的语义向量余弦相似度超过零点八五就判定为重复。两个条件同时满足才去重避免误杀。去重之后还要做事件合并。比如某个模型发布官方博客是一条科技媒体报道是一条开源社区讨论又是一条。去重只能去掉完全重复的但这三条其实讲的是同一件事。我的做法是以官方渠道的条目为主条目把其他渠道的链接作为“相关阅读”附在主条目下面这样既保留了多角度信息又不会让日报显得冗长。3.2 三级分层的判断逻辑日报的内容分为三个层级必读、推荐、速览。必读层级每天控制在三到五条推荐层级十到十五条速览层级不超过三十条。这个数量限制是硬性的逼着我去做取舍。分级的判断逻辑是多个维度的加权打分维度权重说明与我关注方向的相关度0.35基于我预设的关键词列表和语义匹配信息来源的权威性0.25官方渠道高于媒体一手高于二手内容的实质性0.20有具体技术细节、数据、代码的得分高时效性0.10越新得分越高但超过四十八小时的急剧衰减讨论热度0.10开源社区的Star增长、社交平台的讨论量这个权重表不是拍脑袋定的是我用了一个月的历史数据做回归分析调出来的。每个人的关注方向不同权重应该根据自己的需求调整。比如你做投资分析那“讨论热度”和“信息来源权威性”的权重应该更高如果你做技术研发“内容的实质性”和“相关度”应该占主导。3.3 那些被误判的案例与修正分级系统不是一开始就这么准的。我印象最深的一次误判是某个开源项目的小版本更新按照规则它应该进速览但那个更新里其实藏了一个非常重要的API变更会影响很多下游项目。当时我扫了一眼速览就过去了结果三天后才发现问题。从那以后我加了一条规则如果更新日志里出现了“breaking change”“deprecated”“security”这几个关键词无论其他维度得分多低都强制提升到推荐层级。另外对于我长期跟踪的十几个核心项目它们的任何更新都至少进推荐层级不参与速览的筛选。这条规则牺牲了一些日报的简洁性但换来了安全感。4. 摘要生成机器打底人工点睛4.1 为什么不用纯自动摘要我试过完全依赖模型来生成摘要效果怎么说呢能用但不够好。模型生成的摘要有两个通病一是喜欢复述原文的句子缺乏提炼二是对技术细节的处理不够准确经常把参数名、版本号搞错。对于AI领域的日报来说一个版本号写错可能就会导致读者做出错误的判断。所以我的方案是机器生成初稿人工做最终润色。机器负责的是提取关键实体、识别事件类型、生成一个结构化的摘要框架。人工负责的是核对技术细节、调整语气、补充背景信息、判断这条内容到底值不值得读者花时间。4.2 摘要模板的设计与填充每条进入必读和推荐层级的内容都会套用一个摘要模板。模板的结构是固定的但内容因条目而异事件一句话说清楚发生了什么。要点两到三个关键细节用短句列出。影响这件事对哪些方向、哪些人可能有影响。链接原文地址。这个模板的好处是强迫我在写摘要的时候想清楚“这件事到底意味着什么”。很多时候我在填“影响”这一栏的时候才发现自己对这条信息的理解还不够深于是回去重新读原文。这个过程本身就是一种学习。4.3 人工复核的检查清单每天早上生成日报初稿之后我会花十五到二十分钟做人工复核。复核的时候对照一个检查清单技术术语和版本号是否准确公司名、产品名、人名是否写对摘要是否遗漏了原文中的关键限制条件分级是否合理有没有该进必读的被压到了推荐有没有同一事件的重复条目没有合并干净速览层级的条目是否真的都值得保留这个清单看起来琐碎但每一条都是踩过坑之后加上的。比如“关键限制条件”这一条是因为有一次某个模型发布摘要里只写了它的性能提升没写它只支持特定硬件导致我兴冲冲去试的时候才发现跑不起来。5. 排版与推送让日报真正被读完5.1 排版的核心原则扫读友好日报的排版只有一个目标让读者在最短时间内获取最多信息。我的做法是必读层级用加粗标题下面跟三到五行摘要一眼就能看完。推荐层级用普通标题摘要压缩到两行以内。速览层级只保留标题和来源不展开。每个层级之间用分隔线隔开视觉上清晰。颜色方面我克制地使用了两种强调色一种用于标注“新”或“更新”一种用于标注“重要”。其他全部用默认的黑色文字。花哨的排版只会分散注意力。5.2 推送渠道的选择与格式适配日报生成之后我会推送到两个地方一个是自己的邮箱一个是本地的笔记软件。邮箱用于存档和搜索笔记软件用于快速浏览和标注。两个渠道的格式要求不同邮箱支持完整的HTML笔记软件只支持Markdown。所以我写了一个转换脚本把同一份内容渲染成两种格式。推送时间固定在早上七点半。这个时间是我试出来的太早了我还没醒太晚了我会急着出门没时间看。七点半推送我通常在通勤路上花十分钟扫完必读和推荐速览留到午休时再看。5.3 反馈闭环日报本身也需要迭代每期日报的末尾我会留一个简单的反馈区记录三个数据今天必读层级我实际读了几条、推荐层级读了几条、有没有哪条内容是我觉得“不应该出现在这里”的。这些数据每周汇总一次用来调整分级权重和渠道权重。这个反馈闭环是整套流程里最容易被忽略但最重要的一环。没有它日报就会慢慢偏离你的实际需求变成一份“看起来很美但没人看”的文档。我坚持记录反馈数据已经一年多了日报的打开率和阅读完成率一直保持在比较高的水平。6. 2026年9月23日这一期的具体复盘6.1 当天信息流的整体特征9月23日这一天的信息流有一个明显特点开源社区的动态异常活跃而官方发布渠道相对平静。当天抓取到的总条目数是四百三十七条经过去重和合并之后剩下两百一十八条最终进入日报的是四十二条。必读层级只有三条推荐层级十二条其余为速览。三条必读分别是一个主流开源框架的重大版本更新涉及API变更、一篇关于模型推理效率的预印本论文方法有创新且代码已开源、一个行业分析通讯对近期技术趋势的深度梳理。这三条的共同点是有实质性内容、有可操作的信息、对我的当前工作有直接影响。6.2 分级过程中的一次争议判断当天有一条关于某个模型微调工具更新的消息按照常规打分它应该进推荐层级。但我在复核的时候注意到这个更新里包含了一个对训练数据格式的调整而这个调整会影响我之前写的一个脚本。虽然它的“讨论热度”和“信息来源权威性”得分都不高但我手动把它提升到了必读层级。这个判断的依据是个人工作流的关联度而不是通用的权重表。这也是人工复核存在的意义机器只能按照预设的规则打分但人知道哪些东西对自己真正重要。我在反馈数据里记录了这次调整如果后续类似情况反复出现我会考虑在权重表里增加一个“与个人项目关联度”的维度。6.3 摘要撰写中的一次纠错当天有一条关于某公司融资的消息机器生成的摘要初稿里写的是“B轮融资”但我核对原文后发现是“B轮”。虽然只差一个符号但对于关注融资动态的人来说B轮和B轮的含义完全不同。这个错误如果没被发现可能会影响读者对该公司估值阶段的判断。这件事再次提醒我机器可以处理百分之九十的常规情况但剩下的百分之十必须靠人工兜底。尤其是数字、版本号、轮次、日期这类精确信息一定要逐条核对。7. 如果你也想搭一套自己的日报系统7.1 从最小可行版本开始不要一上来就追求全自动。我的建议是先用最笨的办法跑通流程手动收集信息、手动分级、手动写摘要坚持一周。这一周的目的不是产出日报而是搞清楚你到底需要什么样的信息。等你对自己的需求有了清晰的认识再逐步引入自动化工具。最小可行版本只需要三个东西一个信息收集的容器可以是笔记软件、表格、甚至纸笔、一个分级标准哪怕只是“重要/不重要”两档、一个固定的输出时间。先跑起来再优化。7.2 工具选型的几个建议如果你决定走自动化路线工具选型上有几个原则抓取工具优先选支持RSS和开放API的实在没有再考虑网页解析。网页解析的维护成本很高渠道改版一次就要修一次。存储方案用简单的文件系统就行JSON或Markdown格式方便后续处理和迁移。不要一开始就上数据库除非你的条目量真的很大。摘要生成可以用现成的模型API但一定要加人工复核环节。模型适合做初稿不适合做终稿。推送渠道选你每天一定会看的地方。邮箱、笔记软件、即时通讯工具的自建机器人都可以。7.3 长期维护的心态准备这套系统不是搭完就一劳永逸的。渠道会失效、解析规则会过时、你的关注方向会变化。我平均每个月会花一到两个小时做维护检查渠道是否正常、更新关键词列表、调整权重表、清理不再需要的规则。但这份投入是值得的。在信息过载的环境里拥有一份为自己量身定制的日报意味着你不再被算法推荐牵着走而是主动定义自己每天需要知道什么。这种掌控感比日报本身的内容更有价值。最后分享一个我最近在试的小改进在日报的速览层级里我会随机保留一两条“看起来不太相关”的内容目的是给自己留一点意外的信息接触面。完全精准的过滤会让人陷入信息茧房偶尔的“噪音”反而可能带来新的灵感。这个做法还在试验阶段等跑够三个月再来看效果。