1. 一份日报的诞生从信息洪流到可读清单每天早上七点我的手机屏幕上会准时弹出一份自己给自己推送的“AI 日报”。它不是某个平台自动生成的摘要也不是订阅号里那种复制粘贴的新闻合集而是我花了将近两年时间打磨出来的一套信息处理流程的产物。2026年9月17日这一期恰好是这套流程迭代到第三版之后运行的第一百天。我想借这个节点把整件事从头到尾拆开讲一遍——为什么做、怎么做、踩过哪些坑、哪些环节看起来多余其实关键、哪些环节看起来重要其实可以砍掉。先说清楚这份日报到底是什么。它是一份每天早晨生成的、长度控制在两千字以内的结构化文档内容覆盖过去二十四小时内人工智能领域值得关注的动态按“模型与产品”“行业与资本”“开源与工具”“论文与观点”四个板块组织每条信息包含一句话摘要、来源链接、以及我自己的简短判断。它解决的核心问题只有一个在信息过载的环境里用最低的认知成本获取当天真正需要知道的事情。适合谁来参考任何需要持续跟踪 AI 领域动态但又不希望被信息流淹没的人——开发者、产品经理、投资人、研究者甚至只是对这个领域保持好奇的普通读者。但我要提前说明一点这份日报的价值不在于“全”而在于“筛”。我试过追求全覆盖结果每天产出超过八千字自己都读不完更别说坚持。后来我把标准改成“如果今天只能记住三件事应该是哪三件”整个流程才真正跑通。这个思路的转变是后面所有技术选型和操作步骤的前提。2. 信息源的取舍为什么我砍掉了百分之八十的订阅2.1 从“多多益善”到“少而精”的转折点最开始做日报的时候我订阅了将近四十个信息源各大科技媒体的 RSS、十几个行业大佬的社交账号、五六个论文预印本平台的更新、还有一堆邮件列表和播客。结果是什么每天早上打开阅读器未读数轻松破百光是扫标题就要花二十分钟真正点进去读的不到十分之一。更糟糕的是大量内容重复——同一件事被五六个源反复报道只是措辞不同。转折点发生在某个周一我发现自己花了整整一个上午“读新闻”但回想起来什么都没记住。那天我做了个决定把所有信息源按“不可替代性”重新排序只保留那些能提供独家信息、或者筛选质量明显高于同行的源。具体操作是这样的列出所有当前订阅的源逐个问自己“如果这个源消失了我会不会明显感觉到信息缺失”答案是“不会”的直接砍掉。对于保留下来的源再问第二个问题“它提供的信息我能不能在别处用更低成本获取”如果能降级为“备用源”只在主源覆盖不足时查看。最后剩下的核心源控制在八个以内。这个筛选过程我重复做了三次每次间隔一个月最终稳定在六个核心源加四个备用源。数量少了但信息质量反而上去了因为每个源我都清楚它的定位和边界。2.2 核心源与备用源的搭配逻辑六个核心源的分工是这样的两个综合科技媒体负责覆盖重大发布和行业新闻一个专注模型评测的独立博客提供一手实测数据一个开源社区的热榜聚合追踪工具和框架的动态一个学术预印本的精选列表过滤掉低质量论文最后一个是我自己维护的“信源池”里面是几十个个人博主和技术专家的更新通过关键词过滤后只保留高相关内容。备用源的作用不是日常阅读而是在核心源出现明显遗漏时做补充。比如某天某个重要模型发布核心源只给了简讯我就会去备用源里找深度分析。这种“主次分明”的结构比平铺直叙的订阅列表效率高得多。提示筛选信息源时不要只看它“有没有好内容”要看它“坏内容的比例有多高”。一个源如果百分之八十都是噪音即使偶尔有独家也不值得每天花时间过滤。2.3 被砍掉的源教会我的事那些被砍掉的源里有一类特别值得说聚合类账号。它们把别人的内容重新打包发布看起来信息量大实际上没有任何增量价值。我统计过一个典型的聚合账号其内容与原始来源的重合度超过百分之九十五剩下的百分之五往往是标题党式的改写。这类源是效率杀手越早砍掉越好。另一类是“情绪驱动型”账号特点是标题夸张、内容空洞、评论区热闹。它们的问题不在于信息错误而在于消耗注意力却不提供认知增量。我后来给自己定了个规矩如果一个源的内容让我产生强烈情绪反应但没有任何可执行的信息就取消订阅。这条规矩帮我省下了大量时间。3. 抓取与清洗把杂乱信息变成结构化数据3.1 抓取环节的技术选型与理由信息源确定之后下一步是把内容抓下来。我试过三种方案直接用阅读器的导出功能、用现成的爬虫框架、以及自己写脚本。最终选择的是自己写脚本原因有三个第一阅读器导出格式不统一后续清洗成本高第二现成框架功能太多配置复杂而我只需要抓取固定几个源的更新第三自己写脚本可以精确控制抓取频率和字段避免给源站造成不必要的压力。脚本本身不复杂核心逻辑就是定时请求每个源的更新接口或页面提取标题、链接、发布时间、正文摘要这几个字段存到一个本地的 JSON 文件里。这里有个细节值得展开抓取频率的设置。我最初设的是每十分钟一次后来发现完全没必要——大部分源一天更新不超过五次高频抓取除了增加被封的风险没有任何收益。现在改成每小时一次运行了半年多稳定得很。# 抓取核心逻辑的简化示例 import requests import json from datetime import datetime def fetch_source(source_config): headers {User-Agent: MyDailyDigest/1.0} try: resp requests.get(source_config[url], headersheaders, timeout15) resp.raise_for_status() items parse_items(resp.text, source_config[parser]) return [item for item in items if is_recent(item, hours24)] except Exception as e: log_error(source_config[name], str(e)) return []这段代码里is_recent函数负责过滤掉超过二十四小时的内容parse_items根据每个源的页面结构做定制解析。异常处理是必须的因为总会有源临时不可用不能让一个源的失败影响整体流程。3.2 清洗环节去重、分类、打分抓下来的原始数据是杂乱的需要经过三步清洗才能进入日报。第一步是去重。同一件事被多个源报道时只保留信息量最大的那条。我的做法是计算标题和摘要的文本相似度超过阈值的归为一组然后从每组里选“来源权重最高、摘要最长”的那条作为代表。这里有个经验不要用严格的字符串匹配去重因为不同源的措辞差异很大必须用模糊匹配。我试过编辑距离和词向量两种方案最后选了编辑距离因为实现简单、效果够用。第二步是分类。每条信息根据关键词和来源标签归入“模型与产品”“行业与资本”“开源与工具”“论文与观点”四个板块之一。分类规则是手动维护的关键词表比如出现“发布”“上线”“更新”且来源是产品博客的归入第一类出现“融资”“收购”“估值”的归入第二类。这套规则看起来笨但准确率比自动聚类高得多而且容易调整。第三步是打分。每条信息根据来源权重、内容长度、关键词密度算一个分数用于决定在日报里的排序和是否入选。打分公式我调过很多次目前的版本是因素权重说明来源权重0.4核心源为1.0备用源为0.6内容长度0.2归一化后的摘要字数关键词密度0.3与当日热点关键词的匹配度时效性0.1发布时间越近得分越高这个公式不是理论最优但实测下来筛选效果稳定很少出现“重要信息被漏掉”的情况。3.3 一个容易被忽略的细节时区处理清洗环节里最容易出问题的是时区。不同源的发布时间格式和时区都不一样有的用 UTC有的用当地时间有的干脆只给日期。我最初没注意这一点导致日报里经常出现“昨天的事被当成今天的”这种错误。后来统一处理成 UTC 存储展示时再转成本地时间问题才解决。注意时区问题在跨源聚合时几乎必然出现越早统一处理越好。不要等到展示环节再转换那样会引入难以排查的 bug。4. 摘要生成从原文到一句话的压缩艺术4.1 为什么不用全自动摘要摘要生成是整份日报里最核心也最难的环节。我试过完全依赖自动摘要模型结果很不理想模型生成的摘要要么太长要么抓不住重点要么把关键数据漏掉。后来改成“自动生成加人工润色”的混合模式效率和质量都上去了。具体流程是这样的先用一个轻量级的摘要模型对每条信息的正文做初步压缩生成一个草稿然后我快速扫一遍草稿手动调整措辞、补充关键数据、删掉冗余表述。每条信息的润色时间控制在三十秒以内十条信息也就五分钟。这五分钟的投入换来的是日报可读性的大幅提升非常值得。4.2 摘要的写作规范经过大量实践我总结出几条摘要写作的规范写在这里供参考第一条摘要必须包含“谁做了什么”和“为什么重要”两个要素。只讲事实不讲意义的摘要读起来像新闻标题没有认知增量。第二条数字和专有名词必须准确。模型名称、参数规模、融资金额这些信息一旦出错会严重影响日报的可信度。第三条长度控制在一到两句话超过三句的摘要说明信息本身不够聚焦需要重新提炼。第四条避免使用“据悉”“据报道”这类模糊表述直接说信息来源和事实本身。这几条规范看起来简单但执行起来需要刻意练习。我最初写的摘要经常超过一百字后来强迫自己压缩到五十字以内信息密度反而更高了。4.3 人工判断的不可替代性自动摘要模型再强也有一个根本局限它不知道“对读者来说什么重要”。同一个模型发布对开发者重要的可能是 API 变化对投资人重要的可能是商业模式对研究者重要的可能是技术路线。这个判断只能由人来下。我的做法是在润色摘要时问自己一个问题“如果读者今天只读这一条他应该记住什么”这个问题的答案就是摘要的核心。围绕这个核心组织语言摘要自然就聚焦了。5. 日报的组装与分发让阅读体验对得起投入5.1 版面结构的设计考量日报的版面结构直接影响阅读体验。我试过几种方案按时间排序、按重要性排序、按板块分组。最终选择的是“板块分组加内部按分数排序”因为这种结构最符合阅读习惯——读者可以先扫板块标题决定看哪个部分然后在板块内部按重要性依次阅读。每个板块的条目数量控制在三到五条太少显得单薄太多则失去筛选的意义。如果某天某个板块确实没有值得收录的内容就标注“今日无重要更新”而不是硬凑。这个原则很重要日报的价值在于筛选不在于填充。5.2 分发渠道的选择分发渠道我试过邮件、即时通讯工具、以及本地文件三种。邮件的问题是容易被淹没在收件箱里即时通讯工具的问题是消息太短不适合长文阅读本地文件的问题是需要在电脑前才能看。最后我选择的是“本地文件加邮件备份”的组合每天早上生成 Markdown 文件存在本地同时发一份到自己的邮箱作为存档。这样既方便随时查看又有历史记录可追溯。5.3 存档与回溯的价值说到历史记录这里有个意外收获坚持做了几个月之后我发现这份日报的存档本身就是一个有价值的数据集。比如我想查某个模型是什么时候发布的、某个融资事件的具体金额、某个技术路线是什么时候开始流行的翻一翻过去的日报就能找到。这种“时间线”式的信息组织方式比搜索引擎更高效因为所有信息都经过了筛选和整理。我现在会定期对存档做一次回顾看看过去一个月有哪些趋势在形成、哪些热点在消退。这个习惯帮我避免了很多“追热点式”的浅层判断。6. 运行三个月后暴露的问题与调整6.1 信息茧房效应运行一段时间后我发现一个问题日报的内容越来越集中在几个熟悉的领域新兴方向的信息很少出现。原因是我的信息源和关键词表都是基于过去的认知建立的对新事物不够敏感。调整方法是定期做“信息源审计”每个月花半小时主动去找一些之前没关注过的源看看有没有值得加入的。同时关键词表也会定期更新加入最近出现的新术语。这个习惯帮我捕捉到了好几个早期趋势。6.2 处理时间的波动另一个问题是处理时间的波动。有些天信息量大清洗和润色要花一个小时有些天信息量小二十分钟就搞定了。这种不确定性对坚持做这件事很不利因为人天生倾向于回避不确定的任务。我的解决办法是设定一个硬性时间上限无论信息量多大处理时间不超过四十五分钟。超过上限时优先保证核心板块的质量次要板块可以简化甚至跳过。这个策略牺牲了一部分完整性但换来了可持续性我认为是值得的。6.3 质量与速度的平衡质量与速度的平衡是贯穿始终的难题。我试过追求每条摘要都完美结果每天花两个小时坚持了两周就放弃了。后来把标准降到“核心信息准确、表述清晰即可”速度提上来了反而能长期坚持。这个经验让我明白一个道理任何需要长期做的事情可持续性比单次质量更重要。先跑起来再慢慢优化比一开始就追求完美更靠谱。7. 如果你也想做一份自己的日报7.1 最小可行方案如果你看完上面的内容也想做一份自己的日报我建议从最小可行方案开始选三个信息源用一个简单的脚本抓取手动写摘要生成一个纯文本文件。不要一上来就搞复杂的分类和打分系统那些可以后面再加。最小方案的关键是“跑通流程”而不是“功能完整”。我见过太多人一开始就设计复杂的架构结果卡在实现细节上永远没做出第一份日报。7.2 常见的起步误区起步阶段最容易踩的坑有三个一是信息源贪多导致处理不过来二是追求自动化结果摘要质量太差三是没有固定时间想起来才做。这三个问题的共同点是“高估短期能力低估长期坚持的难度”。我的建议是信息源从三个开始摘要先手动写每天固定一个时间段处理。等这三件事都稳定了再考虑优化。7.3 长期维护的心态最后说一点心态上的体会。做日报这件事最大的挑战不是技术而是坚持。我见过很多人做了几天就放弃原因往往是“今天太忙”或者“今天没什么重要新闻”。但恰恰是那些“没什么重要新闻”的日子坚持做下去才有意义——因为筛选和判断的能力是在日复一日的练习中积累起来的。我现在把做日报当成一种日常习惯就像刷牙一样不需要特别的动力到时间就做。这种“习惯化”的状态比任何技术优化都重要。