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 三级分层的判断逻辑

日报的内容分为三个层级：必读、推荐、速览。必读层级每天控制在三到五条，推荐层级十到十五条，速览层级不超过三十条。这个数量限制是硬性的，逼着我去做取舍。

分级的判断逻辑是多个维度的加权打分：

这个权重表不是拍脑袋定的，是我用了一个月的历史数据做回归分析调出来的。每个人的关注方向不同，权重应该根据自己的需求调整。比如你做投资分析，那“讨论热度”和“信息来源权威性”的权重应该更高；如果你做技术研发，“内容的实质性”和“相关度”应该占主导。

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 长期维护的心态准备

这套系统不是搭完就一劳永逸的。渠道会失效、解析规则会过时、你的关注方向会变化。我平均每个月会花一到两个小时做维护：检查渠道是否正常、更新关键词列表、调整权重表、清理不再需要的规则。

但这份投入是值得的。在信息过载的环境里，拥有一份为自己量身定制的日报，意味着你不再被算法推荐牵着走，而是主动定义自己每天需要知道什么。这种掌控感，比日报本身的内容更有价值。

最后分享一个我最近在试的小改进：在日报的速览层级里，我会随机保留一两条“看起来不太相关”的内容，目的是给自己留一点意外的信息接触面。完全精准的过滤会让人陷入信息茧房，偶尔的“噪音”反而可能带来新的灵感。这个做法还在试验阶段，等跑够三个月再来看效果。