1. 一份日报的诞生从信息洪流到可读清单每天早上七点我的信息采集脚本会准时跑完最后一轮抓取。屏幕上滚动的原始条目通常有四百到六百条来源横跨十几个技术社区、模型发布页、论文预印本平台和开发者论坛。这些内容如果直接堆给人看不出十分钟就会让人产生严重的认知疲劳。所以“AI 日报”这件事表面上看是内容聚合实际上做的是一份信息降噪与价值排序的工作。我做这份日报的起点很朴素自己每天要花一个多小时刷各种渠道刷完之后却发现真正值得记住的没几条。后来索性把这个过程自动化让机器先做一轮粗筛我再做一轮精编。2026年10月4日这一期恰好是一个比较典型的样本——当天既有多模态模型的迭代消息也有开源工具链的重要更新还有几条容易被忽略但影响深远的工程实践讨论。我拿这一期作为案例把整条流水线拆开来讲包括采集策略、去重逻辑、优先级打分、人工复核的取舍标准以及最终排版发布时的一些细节处理。这份日报适合几类人参考一是想建立自己信息筛选机制的技术从业者二是做内容聚合产品的开发者三是单纯想知道“一份高质量日报背后到底有多少道工序”的读者。我不打算讲什么宏大的方法论只讲我实际跑通的这套流程包括踩过的坑和目前仍然没解决好的问题。2. 采集层的设计源清单维护比爬虫代码更重要2.1 源清单的分层管理很多人做信息聚合第一反应是写爬虫。但我的经验是源清单的维护才是决定日报质量的上限。爬虫代码写一次可以管半年但源清单几乎每周都要调整。我把所有信息源分成三个层级核心层大约十五到二十个源包括主流模型厂商的官方发布页、几个高信噪比的论文速递账号、以及三四个我长期跟踪的独立开发者博客。这一层的内容几乎每条都会进入候选池。扩展层大约四十到五十个源覆盖细分领域的工具更新、行业分析报告、技术会议议程。这一层的内容需要经过关键词过滤才会进入候选池。观察层数量不固定主要是一些新兴平台和边缘渠道。这一层的内容不直接进入日报但会作为趋势判断的参考。核心层的源我每周会手动检查一次可用性因为很多发布页的结构会变RSS地址也可能失效。扩展层则依赖脚本自动检测连续三天抓取量为零的源会被标记出来由我决定是修复还是移除。2.2 抓取频率与时间窗口抓取频率不是越高越好。我试过每十五分钟跑一次结果发现大量重复内容反复进入队列去重压力陡增。后来调整为每天三个固定窗口早上六点半、中午十二点、下午五点半。每个窗口抓取过去八小时内更新的内容。这样既能覆盖大部分发布节奏又不会让队列膨胀得太厉害。时间窗口的设定有个细节不同源的更新习惯差异很大。官方发布页通常在工作日的上午更新论文预印本平台的高峰在凌晨而开发者论坛的活跃时段是下午到晚上。所以三个窗口的抓取权重是不一样的早上的窗口侧重官方发布和论文下午的窗口侧重社区讨论和工具更新。2.3 原始数据的标准化处理抓回来的原始数据格式五花八门有的是完整的HTML有的是JSON还有的只有标题和链接。我统一把它们转换成包含以下字段的结构字段名说明是否必填title条目标题是url原始链接是source来源标识是publish_time发布时间戳否raw_content原始正文或摘要否language语言标识是publish_time缺失的情况很常见尤其是社区类来源。我的处理方式是如果抓取时间与条目在列表页的位置可以推断出大致时间范围就填一个估算值并标记为“推断”否则留空在后续排序时降权处理。3. 去重与初筛把四百条压到八十条3.1 基于标题指纹的快速去重四百多条原始条目里重复内容通常占三成以上。同一件事可能被多个渠道转发标题略有差异但核心信息一致。我用的是标题指纹方案先把标题转成小写去掉标点和停用词然后取前若干个字符的哈希值作为指纹。指纹相同的条目只保留来源权重最高的那一条。这个方案简单但有效能干掉大部分明显的重复。剩下的漏网之鱼主要是标题改写幅度较大的情况比如“某模型发布新版本”和“某模型迎来重大更新”指的是同一件事但指纹不同。这类重复靠后续的语义相似度检测来处理。3.2 语义相似度兜底语义相似度检测我用的是一套轻量级的向量化方案。把标题和摘要拼在一起过一个本地部署的小型嵌入模型得到向量后计算余弦相似度。阈值设在0.85左右高于这个值的条目归为一组只保留信息量最大的那条。这里有个经验阈值不能设太低。我一开始设了0.75结果把“某模型发布”和“某模型评测”这种相关但不同的事件合并了导致日报漏掉了重要内容。后来调到0.85又发现一些真正重复的条目没被合并。最终的解决办法是分两档处理0.85以上直接合并0.75到0.85之间的标记为“疑似重复”由我在人工复核时决定。3.3 关键词过滤与黑名单机制扩展层的内容需要经过关键词过滤。我维护了一个正向关键词列表和一个负向关键词列表。正向关键词包括模型名称、技术术语、工具名称等负向关键词主要是一些营销味太重的词比如“震撼发布”“颠覆行业”之类。黑名单机制则是针对特定来源的。有些源偶尔会产出高质量内容但大部分时候是噪音。对这类源我不会直接移除而是给它设置一个较高的过滤阈值——只有同时命中多个正向关键词才会进入候选池。经过这一轮处理四百多条原始条目通常会压缩到八十条左右。这八十条就是进入人工复核的候选集。4. 优先级打分什么样的内容值得放在前面4.1 打分维度的确定八十条候选内容最终能上日报的通常只有十五到二十条。中间这个筛选过程我设计了一个简单的打分模型包含四个维度来源权重核心层来源默认高分扩展层来源根据历史表现动态调整。时效性发布时间越近得分越高超过二十四小时的内容大幅降权。信息密度标题和摘要中包含的具体信息越多得分越高比如有具体版本号、具体数据、具体工具名称的条目会加分。话题热度如果多个独立来源都在讨论同一话题该话题下的条目会获得额外加分。每个维度的权重不是固定的。比如在模型集中发布的时期来源权重和时效性的权重会调高在行业会议密集的时期话题热度的权重会调高。这套权重我每个月会回顾一次根据当月的日报反馈做微调。4.2 人工复核的取舍标准打分模型给出排序后我会逐条过一遍。人工复核主要做三件事第一判断真伪。有些条目看起来很像重要新闻但点进去发现是旧闻重发或者标题党。这类内容直接剔除。第二补充上下文。有些条目本身信息量不大但放在当天的整体语境里很重要。比如某个工具发布了一个小版本更新单独看没什么但如果当天正好有多条相关内容都指向同一个技术方向这条更新就值得保留并加以说明。第三调整顺序。打分模型的排序是参考最终顺序由我根据当天内容的整体结构来定。通常我会把最重要的两到三条放在最前面中间穿插一些工具和实践类内容最后放一两条轻松但有启发的条目。4.3 一条内容的完整评估示例拿2026年10月4日的一则条目举例。原始标题是某开源推理框架发布了新的量化方案。打分模型给它的初始分数是中等偏上来源权重高但时效性一般发布时间是前一天晚上。人工复核时我发现这个量化方案的核心改进是在保持精度的前提下把显存占用降低了约三成。这个数据在原始摘要里没有明确写出是我点进技术文档后找到的。于是我把它提到比较靠前的位置并在日报里补充了这个关键数据。后来这条内容在读者反馈里被多次提到说明这个判断是对的。5. 日报的编排逻辑让读者三分钟抓住重点5.1 分区结构的确定日报的排版我试过好几种方案最终稳定下来的是一种三分区结构头条区当天最重要的一到两条内容每条配一段简短的背景说明和影响判断。动态区按主题分组的若干条内容每条控制在两三句话只讲核心事实。工具与实践区偏工程和实操的内容包括新工具发布、教程更新、踩坑分享等。这个结构的好处是层次分明。读者如果只有一分钟看头条区就够了如果有五分钟可以扫一遍动态区如果对某个方向特别感兴趣工具与实践区提供了进一步探索的入口。5.2 每条内容的写法头条区的内容我会写得更完整一些通常包含三个要素发生了什么、为什么重要、接下来可以关注什么。比如某模型发布新版本我会写清楚版本号、核心改进点、与前一个版本的主要差异以及这个改进对实际使用可能产生的影响。动态区的内容则尽量精简。我的原则是如果一条内容不能用两句话讲清楚核心事实那它就不适合放在动态区。要么升格到头条区展开写要么降格到工具区用更聚焦的角度来写。工具与实践区的内容写法又不一样。这里更看重可操作性所以我会尽量保留具体的命令、配置片段、参数说明。如果原始内容里有代码示例我会判断是否值得完整保留如果太长就摘取关键部分并注明完整内容的获取方式。5.3 标题的打磨日报里每一条的标题我都会重新写一遍。原始标题往往带有来源平台的风格有的过于口语化有的又太学术。我的目标是让标题在脱离原文语境的情况下依然能独立传达核心信息。举个例子某条原始标题是“我们刚刚发布了 v2.3”这种标题放在日报里毫无意义。我会改成“某工具 v2.3 发布新增批量处理与自定义输出格式”。改动之后读者即使不点开链接也能知道这条内容大概讲什么。6. 发布之后的反馈闭环6.1 读者反馈的收集方式日报发布后我会关注几个渠道的反馈直接回复、转发时的评论、以及私下里朋友发来的消息。这些反馈里最有价值的是指出遗漏和指出错误两类。遗漏说明我的信息源覆盖还不够全错误则说明我的复核环节还有漏洞。我专门建了一个反馈记录表每次收到有价值的反馈就记一笔。每个月回顾一次看看哪些类型的遗漏反复出现然后针对性地补充信息源或调整过滤规则。6.2 日报内容的二次利用单期日报的生命周期很短但积累下来的内容可以做二次利用。我会把每期日报里的工具类内容单独抽出来按主题归类形成一个持续更新的工具索引。这个索引后来成了我自己查资料时最常用的入口比搜索引擎的效率高很多。另外每季度我会做一次日报内容的趋势分析看看哪些技术方向出现的频率在上升哪些在下降。这个分析不对外发布但对我自己的方向判断很有帮助。6.3 目前仍然没解决好的问题这套流程跑了挺长时间但有几个问题一直没解决好。一个是多语言内容的处理非中文和英文的内容目前只能靠翻译工具过一遍质量不稳定所以大部分时候我直接跳过了。另一个是视频和播客类内容的整合这类内容的信息密度不低但提取成本太高目前还没有找到性价比合适的方案。还有一个更根本的问题自动化程度越高日报的“人味”就越难保持。我试过把更多环节交给脚本结果日报读起来越来越像机器生成的摘要。后来我把人工复核的环节保留了下来虽然每天多花半小时但日报的可读性和判断力明显更好。这个平衡点我还在继续摸索。7. 给想做类似事情的人几条实在建议如果你也想做一份自己的信息日报不管是公开分享还是内部使用我有几条从实际操作中总结出来的建议。第一先跑通最小闭环再考虑优化。我一开始就想把采集、去重、打分、排版全部自动化结果每个环节都卡在细节上两周都没产出第一期。后来改成先用最笨的办法手动做三天搞清楚哪些环节真正耗时、哪些环节可以省略然后再逐个自动化。这个顺序很重要。第二源清单的质量比数量重要。我见过有人一口气加了上百个源结果每天光是处理噪音就耗尽了精力。宁可先维护好十个高质量源再慢慢扩展。第三打分模型不要一开始就搞复杂。我最初设计了一个包含十几个维度的打分公式调参调到怀疑人生。后来砍到四个维度效果反而更稳定。维度多了之后每个维度的权重变得很难直观理解调起来完全是黑盒。第四保留人工判断的环节。至少在目前这个阶段完全自动化的日报在信息取舍和上下文补充上还是差一口气。人工复核花的时间不多但对最终质量的影响很大。第五别追求日更。我试过日更坚持了两个月就扛不住了。后来改成工作日更新周末停更反而能保持更长时间。日报这件事可持续比高频更重要。最后说一个我自己的体会做日报最大的收获不是日报本身而是被迫建立了一套持续跟踪信息的方法。这套方法后来被我迁移到了很多其他场景比如技术选型调研、竞品分析、甚至日常的阅读管理。如果你也在做类似的事情不妨把重点放在流程的打磨上而不是单期内容的质量上。流程跑顺了内容质量是水到渠成的事。
1. 一份日报的诞生从信息洪流到可读清单每天早上七点我的信息采集脚本会准时跑完最后一轮抓取。屏幕上滚动的原始条目通常有四百到六百条来源横跨十几个技术社区、模型发布页、论文预印本平台和开发者论坛。这些内容如果直接堆给人看不出十分钟就会让人产生严重的认知疲劳。所以“AI 日报”这件事表面上看是内容聚合实际上做的是一份信息降噪与价值排序的工作。我做这份日报的起点很朴素自己每天要花一个多小时刷各种渠道刷完之后却发现真正值得记住的没几条。后来索性把这个过程自动化让机器先做一轮粗筛我再做一轮精编。2026年10月4日这一期恰好是一个比较典型的样本——当天既有多模态模型的迭代消息也有开源工具链的重要更新还有几条容易被忽略但影响深远的工程实践讨论。我拿这一期作为案例把整条流水线拆开来讲包括采集策略、去重逻辑、优先级打分、人工复核的取舍标准以及最终排版发布时的一些细节处理。这份日报适合几类人参考一是想建立自己信息筛选机制的技术从业者二是做内容聚合产品的开发者三是单纯想知道“一份高质量日报背后到底有多少道工序”的读者。我不打算讲什么宏大的方法论只讲我实际跑通的这套流程包括踩过的坑和目前仍然没解决好的问题。2. 采集层的设计源清单维护比爬虫代码更重要2.1 源清单的分层管理很多人做信息聚合第一反应是写爬虫。但我的经验是源清单的维护才是决定日报质量的上限。爬虫代码写一次可以管半年但源清单几乎每周都要调整。我把所有信息源分成三个层级核心层大约十五到二十个源包括主流模型厂商的官方发布页、几个高信噪比的论文速递账号、以及三四个我长期跟踪的独立开发者博客。这一层的内容几乎每条都会进入候选池。扩展层大约四十到五十个源覆盖细分领域的工具更新、行业分析报告、技术会议议程。这一层的内容需要经过关键词过滤才会进入候选池。观察层数量不固定主要是一些新兴平台和边缘渠道。这一层的内容不直接进入日报但会作为趋势判断的参考。核心层的源我每周会手动检查一次可用性因为很多发布页的结构会变RSS地址也可能失效。扩展层则依赖脚本自动检测连续三天抓取量为零的源会被标记出来由我决定是修复还是移除。2.2 抓取频率与时间窗口抓取频率不是越高越好。我试过每十五分钟跑一次结果发现大量重复内容反复进入队列去重压力陡增。后来调整为每天三个固定窗口早上六点半、中午十二点、下午五点半。每个窗口抓取过去八小时内更新的内容。这样既能覆盖大部分发布节奏又不会让队列膨胀得太厉害。时间窗口的设定有个细节不同源的更新习惯差异很大。官方发布页通常在工作日的上午更新论文预印本平台的高峰在凌晨而开发者论坛的活跃时段是下午到晚上。所以三个窗口的抓取权重是不一样的早上的窗口侧重官方发布和论文下午的窗口侧重社区讨论和工具更新。2.3 原始数据的标准化处理抓回来的原始数据格式五花八门有的是完整的HTML有的是JSON还有的只有标题和链接。我统一把它们转换成包含以下字段的结构字段名说明是否必填title条目标题是url原始链接是source来源标识是publish_time发布时间戳否raw_content原始正文或摘要否language语言标识是publish_time缺失的情况很常见尤其是社区类来源。我的处理方式是如果抓取时间与条目在列表页的位置可以推断出大致时间范围就填一个估算值并标记为“推断”否则留空在后续排序时降权处理。3. 去重与初筛把四百条压到八十条3.1 基于标题指纹的快速去重四百多条原始条目里重复内容通常占三成以上。同一件事可能被多个渠道转发标题略有差异但核心信息一致。我用的是标题指纹方案先把标题转成小写去掉标点和停用词然后取前若干个字符的哈希值作为指纹。指纹相同的条目只保留来源权重最高的那一条。这个方案简单但有效能干掉大部分明显的重复。剩下的漏网之鱼主要是标题改写幅度较大的情况比如“某模型发布新版本”和“某模型迎来重大更新”指的是同一件事但指纹不同。这类重复靠后续的语义相似度检测来处理。3.2 语义相似度兜底语义相似度检测我用的是一套轻量级的向量化方案。把标题和摘要拼在一起过一个本地部署的小型嵌入模型得到向量后计算余弦相似度。阈值设在0.85左右高于这个值的条目归为一组只保留信息量最大的那条。这里有个经验阈值不能设太低。我一开始设了0.75结果把“某模型发布”和“某模型评测”这种相关但不同的事件合并了导致日报漏掉了重要内容。后来调到0.85又发现一些真正重复的条目没被合并。最终的解决办法是分两档处理0.85以上直接合并0.75到0.85之间的标记为“疑似重复”由我在人工复核时决定。3.3 关键词过滤与黑名单机制扩展层的内容需要经过关键词过滤。我维护了一个正向关键词列表和一个负向关键词列表。正向关键词包括模型名称、技术术语、工具名称等负向关键词主要是一些营销味太重的词比如“震撼发布”“颠覆行业”之类。黑名单机制则是针对特定来源的。有些源偶尔会产出高质量内容但大部分时候是噪音。对这类源我不会直接移除而是给它设置一个较高的过滤阈值——只有同时命中多个正向关键词才会进入候选池。经过这一轮处理四百多条原始条目通常会压缩到八十条左右。这八十条就是进入人工复核的候选集。4. 优先级打分什么样的内容值得放在前面4.1 打分维度的确定八十条候选内容最终能上日报的通常只有十五到二十条。中间这个筛选过程我设计了一个简单的打分模型包含四个维度来源权重核心层来源默认高分扩展层来源根据历史表现动态调整。时效性发布时间越近得分越高超过二十四小时的内容大幅降权。信息密度标题和摘要中包含的具体信息越多得分越高比如有具体版本号、具体数据、具体工具名称的条目会加分。话题热度如果多个独立来源都在讨论同一话题该话题下的条目会获得额外加分。每个维度的权重不是固定的。比如在模型集中发布的时期来源权重和时效性的权重会调高在行业会议密集的时期话题热度的权重会调高。这套权重我每个月会回顾一次根据当月的日报反馈做微调。4.2 人工复核的取舍标准打分模型给出排序后我会逐条过一遍。人工复核主要做三件事第一判断真伪。有些条目看起来很像重要新闻但点进去发现是旧闻重发或者标题党。这类内容直接剔除。第二补充上下文。有些条目本身信息量不大但放在当天的整体语境里很重要。比如某个工具发布了一个小版本更新单独看没什么但如果当天正好有多条相关内容都指向同一个技术方向这条更新就值得保留并加以说明。第三调整顺序。打分模型的排序是参考最终顺序由我根据当天内容的整体结构来定。通常我会把最重要的两到三条放在最前面中间穿插一些工具和实践类内容最后放一两条轻松但有启发的条目。4.3 一条内容的完整评估示例拿2026年10月4日的一则条目举例。原始标题是某开源推理框架发布了新的量化方案。打分模型给它的初始分数是中等偏上来源权重高但时效性一般发布时间是前一天晚上。人工复核时我发现这个量化方案的核心改进是在保持精度的前提下把显存占用降低了约三成。这个数据在原始摘要里没有明确写出是我点进技术文档后找到的。于是我把它提到比较靠前的位置并在日报里补充了这个关键数据。后来这条内容在读者反馈里被多次提到说明这个判断是对的。5. 日报的编排逻辑让读者三分钟抓住重点5.1 分区结构的确定日报的排版我试过好几种方案最终稳定下来的是一种三分区结构头条区当天最重要的一到两条内容每条配一段简短的背景说明和影响判断。动态区按主题分组的若干条内容每条控制在两三句话只讲核心事实。工具与实践区偏工程和实操的内容包括新工具发布、教程更新、踩坑分享等。这个结构的好处是层次分明。读者如果只有一分钟看头条区就够了如果有五分钟可以扫一遍动态区如果对某个方向特别感兴趣工具与实践区提供了进一步探索的入口。5.2 每条内容的写法头条区的内容我会写得更完整一些通常包含三个要素发生了什么、为什么重要、接下来可以关注什么。比如某模型发布新版本我会写清楚版本号、核心改进点、与前一个版本的主要差异以及这个改进对实际使用可能产生的影响。动态区的内容则尽量精简。我的原则是如果一条内容不能用两句话讲清楚核心事实那它就不适合放在动态区。要么升格到头条区展开写要么降格到工具区用更聚焦的角度来写。工具与实践区的内容写法又不一样。这里更看重可操作性所以我会尽量保留具体的命令、配置片段、参数说明。如果原始内容里有代码示例我会判断是否值得完整保留如果太长就摘取关键部分并注明完整内容的获取方式。5.3 标题的打磨日报里每一条的标题我都会重新写一遍。原始标题往往带有来源平台的风格有的过于口语化有的又太学术。我的目标是让标题在脱离原文语境的情况下依然能独立传达核心信息。举个例子某条原始标题是“我们刚刚发布了 v2.3”这种标题放在日报里毫无意义。我会改成“某工具 v2.3 发布新增批量处理与自定义输出格式”。改动之后读者即使不点开链接也能知道这条内容大概讲什么。6. 发布之后的反馈闭环6.1 读者反馈的收集方式日报发布后我会关注几个渠道的反馈直接回复、转发时的评论、以及私下里朋友发来的消息。这些反馈里最有价值的是指出遗漏和指出错误两类。遗漏说明我的信息源覆盖还不够全错误则说明我的复核环节还有漏洞。我专门建了一个反馈记录表每次收到有价值的反馈就记一笔。每个月回顾一次看看哪些类型的遗漏反复出现然后针对性地补充信息源或调整过滤规则。6.2 日报内容的二次利用单期日报的生命周期很短但积累下来的内容可以做二次利用。我会把每期日报里的工具类内容单独抽出来按主题归类形成一个持续更新的工具索引。这个索引后来成了我自己查资料时最常用的入口比搜索引擎的效率高很多。另外每季度我会做一次日报内容的趋势分析看看哪些技术方向出现的频率在上升哪些在下降。这个分析不对外发布但对我自己的方向判断很有帮助。6.3 目前仍然没解决好的问题这套流程跑了挺长时间但有几个问题一直没解决好。一个是多语言内容的处理非中文和英文的内容目前只能靠翻译工具过一遍质量不稳定所以大部分时候我直接跳过了。另一个是视频和播客类内容的整合这类内容的信息密度不低但提取成本太高目前还没有找到性价比合适的方案。还有一个更根本的问题自动化程度越高日报的“人味”就越难保持。我试过把更多环节交给脚本结果日报读起来越来越像机器生成的摘要。后来我把人工复核的环节保留了下来虽然每天多花半小时但日报的可读性和判断力明显更好。这个平衡点我还在继续摸索。7. 给想做类似事情的人几条实在建议如果你也想做一份自己的信息日报不管是公开分享还是内部使用我有几条从实际操作中总结出来的建议。第一先跑通最小闭环再考虑优化。我一开始就想把采集、去重、打分、排版全部自动化结果每个环节都卡在细节上两周都没产出第一期。后来改成先用最笨的办法手动做三天搞清楚哪些环节真正耗时、哪些环节可以省略然后再逐个自动化。这个顺序很重要。第二源清单的质量比数量重要。我见过有人一口气加了上百个源结果每天光是处理噪音就耗尽了精力。宁可先维护好十个高质量源再慢慢扩展。第三打分模型不要一开始就搞复杂。我最初设计了一个包含十几个维度的打分公式调参调到怀疑人生。后来砍到四个维度效果反而更稳定。维度多了之后每个维度的权重变得很难直观理解调起来完全是黑盒。第四保留人工判断的环节。至少在目前这个阶段完全自动化的日报在信息取舍和上下文补充上还是差一口气。人工复核花的时间不多但对最终质量的影响很大。第五别追求日更。我试过日更坚持了两个月就扛不住了。后来改成工作日更新周末停更反而能保持更长时间。日报这件事可持续比高频更重要。最后说一个我自己的体会做日报最大的收获不是日报本身而是被迫建立了一套持续跟踪信息的方法。这套方法后来被我迁移到了很多其他场景比如技术选型调研、竞品分析、甚至日常的阅读管理。如果你也在做类似的事情不妨把重点放在流程的打磨上而不是单期内容的质量上。流程跑顺了内容质量是水到渠成的事。
