1. 一份AI日报的诞生逻辑每天早上八点半我习惯性打开自己搭建的AI日报聚合面板扫一眼过去24小时里全球AI圈发生了什么。这个习惯坚持了快两年中间换过三种方案踩过的坑足够写一本小册子。今天这篇内容就是把这套AI日报从信息采集到最终成稿的完整流程拆开讲清楚包括我为什么这么设计、每个环节的关键参数怎么定、遇到问题怎么排查。先说清楚这份AI日报2026年10月7日到底是什么。它不是某一家媒体的新闻汇总而是一套自动化程度较高的信息聚合与筛选系统产出的每日简报。核心目标只有一个用最少的时间把当天最值得关注的AI动态筛出来并且附上足够的上下文让读者不用再点开原文就能判断这条信息跟自己有没有关系。适合谁来参考这套方案三类人。第一类是跟我一样做技术内容输出的从业者需要稳定的信息输入源第二类是在AI产品团队做市场或战略的同学需要每天跟踪竞品和行业动向第三类是对AI感兴趣但不想被信息洪流淹没的普通读者想要一份过滤后的清单。不管你是哪一类这套流程都可以按需裁剪。我做的这份日报每天覆盖的信息源大概在40到60个之间最终进入日报正文的通常只有8到12条。这个比例是刻意控制的——筛选比采集重要得多。下面从整体设计思路开始拆。2. 整体架构与信息源选型2.1 为什么采用分层过滤而不是全量聚合最开始我做日报的时候思路很简单把所有能抓的源全抓下来按时间排序一股脑输出。结果就是每天产出两三百条自己都不想看更别说读者。后来改成三层过滤架构才真正跑通。第一层是信源层负责原始信息的采集。第二层是去重与初筛层把重复报道、低质量内容剔掉。第三层是价值排序层按重要性和相关性打分取Top N进入日报。这三层是串行关系每一层都有明确的淘汰率目标信源层采集100%初筛层保留30%到40%排序层最终保留10%到15%。为什么这么设计因为AI领域的信息有个特点同一件事会被几十个源反复报道但真正有价值的增量信息往往只藏在其中一两个源里。如果不在初筛层做去重排序层就会被大量同质内容淹没打分再准也没用。2.2 信源清单的构成与取舍标准我的信源清单分四大类每类的采集方式和更新频率都不一样。信源类型数量采集方式更新频率取舍标准官方博客与公告12个RSS 页面监控实时只保留一手发布转载源全部剔除学术预印本平台3个API拉取每日两次按关键词过滤只留cs.AI/cs.CL/cs.LG技术社区热榜5个公开接口每小时只取前20且需满足最低讨论量行业媒体20个左右RSS聚合实时按历史准确率动态调整权重这里有个关键取舍我没有把社交媒体个人账号纳入信源。原因很实际——个人账号的信息噪声太大验证成本高而且容易带入主观判断。日报的定位是事实简报不是观点合集所以宁可漏掉一些早期爆料也要保证每一条都有可追溯的出处。提示信源清单不是越多越好。我实测下来超过60个源之后边际信息增量急剧下降但维护成本线性上升。建议新手从15到20个核心源起步跑顺了再扩。2.3 采集频率与时间窗口的设定日报叫日报但采集不能只在早上做一次。我的方案是滚动采集 定时成稿。采集端每30分钟跑一次把新内容写入临时库成稿端固定在每天早上7点触发取过去24小时的数据做处理。为什么是24小时而不是自然日因为AI圈的新闻发布有明显的时间分布特征。北美团队的发布集中在我们的深夜到凌晨如果按自然日切很多重要发布会被切到两天里读者体验很差。24小时滚动窗口能保证每天早上看到的都是最近一整天的完整信息。时间窗口的边界处理也有讲究。跨窗口的同一事件我会在去重层用事件指纹做关联避免同一条新闻连续两天出现。这个后面在去重部分详细说。3. 核心处理环节的技术细节3.1 去重从URL指纹到语义聚类去重是整套流程里最容易被低估的环节。我一开始只用URL去重结果发现同一篇报道被不同源转载时URL完全不同根本去不掉。后来升级到三级去重效果才稳定下来。第一级是URL规范化去重。把URL里的追踪参数、会话ID、排序参数全部剥掉只保留路径主体再做哈希。这一步能干掉大约40%的重复。第二级是标题指纹去重。对标题做分词、去停用词、提取关键词集合用Jaccard相似度比较。阈值设在0.75超过就判定为同一事件。这一步再干掉30%左右。第三级是语义聚类。对前两级没去掉的内容用轻量级句向量模型做嵌入按余弦相似度聚类。这一步主要处理标题不同但讲的是同一件事的情况比如某模型发布新版本和某团队推出升级版模型。# 语义聚类核心逻辑示意 from sklearn.cluster import DBSCAN import numpy as np def cluster_news(embeddings, eps0.25, min_samples1): embeddings: 句向量矩阵 eps: 余弦距离阈值实测0.25比较合适 clustering DBSCAN(epseps, min_samplesmin_samples, metriccosine) labels clustering.fit_predict(embeddings) return labels参数选择上eps设0.25是反复调出来的。设太小同一事件会被拆成多簇设太大不相关的内容会被合并。这个值跟嵌入模型的选择强相关换模型需要重新调。注意语义聚类不要追求100%准确。我的目标是宁可少合并不要错合并因为错合并会把不同事件的信息混在一起读者一眼就能看出来信任度直接崩。3.2 价值排序多因子打分模型去重之后每天还剩30到50条。怎么从中选出最值得看的10条左右我用的是一个多因子加权打分模型因子和权重如下。打分因子权重说明信源权威度0.25按历史准确率动态维护0到1之间内容完整度0.20是否有具体数据、时间、主体话题热度0.20跨源出现次数 社区讨论量时效性0.15越新越高24小时内线性衰减领域相关性0.20与预设关键词表的匹配度每个因子归一化到0到1加权求和得到总分。总分排序后取Top 12进入日报正文第13到20名进入简讯区。这里重点说信源权威度的动态维护。我给每个源设一个初始分0.7然后根据历史表现调整如果某源发布的内容在24小时内被其他权威源交叉验证加0.02如果被证伪或出现明显错误扣0.1。这个分数每周更新一次避免短期波动影响太大。领域相关性的匹配用的是关键词表加语义匹配的组合。关键词表覆盖大模型、多模态、Agent、推理优化、训练框架、评测基准等方向每个方向有权重。语义匹配用嵌入相似度做补充防止关键词表覆盖不到的新话题被漏掉。3.3 摘要生成为什么不用纯自动摘要日报的每条内容都需要一段摘要。我试过纯自动摘要效果不理想——要么太短信息量不够要么太长失去摘要意义。现在的方案是模板化骨架 自动填充 人工微调。模板化骨架的意思是每条摘要必须包含四个要素谁、做了什么、关键数据、为什么值得关注。自动填充负责从原文里抽取主体、动作和数字人工微调负责补上为什么值得关注这一句。为什么最后一步要人工因为为什么值得关注需要判断而判断依赖上下文。比如同样是某模型在某个基准上提升3个点如果这个基准是公认的硬骨头那3个点就很值钱如果是已经饱和的基准那3个点就没那么重要。这种判断目前自动化做不好人工花30秒补一句价值远超成本。# 摘要骨架填充示意 summary_template {主体} {动作}{关键数据}。值得关注的是{价值判断}。 def fill_summary(entity, action, data, value_judgment): return summary_template.format( entityentity, actionaction, datadata, value_judgmentvalue_judgment )实操心得摘要长度控制在80到120字之间最舒服。低于80字信息量不够高于120字读者会跳过。这个区间是看了几百条读者反馈后定下来的。4. 完整实操流程与关键配置4.1 环境准备与依赖安装整套系统跑在一台4核8G的云主机上操作系统用Ubuntu 22.04。为什么选这个配置因为采集和去重是IO密集型排序和嵌入是轻量计算4核8G足够再高就是浪费。依赖清单如下# 核心依赖 pip install feedparser requests beautifulsoup4 pip install sentence-transformers scikit-learn numpy pandas pip install apscheduler pyyaml # 可选如果要做本地嵌入加速 pip install onnxruntime嵌入模型我选的是轻量级多语言模型参数量在100M左右。为什么不用更大的因为日报场景对嵌入精度要求不高聚类和相关性匹配用轻量模型完全够而且推理速度快单条处理时间在50毫秒以内。4.2 采集任务的调度配置调度用APScheduler配置如下from apscheduler.schedulers.blocking import BlockingScheduler scheduler BlockingScheduler() # 采集任务每30分钟一次 scheduler.add_job( collect_all_sources, interval, minutes30, idcollect_job, max_instances1 ) # 成稿任务每天早上7点 scheduler.add_job( generate_daily_report, cron, hour7, minute0, idreport_job ) scheduler.start()max_instances1这个参数很关键。我踩过一次坑某次采集任务因为网络问题卡住下一次调度又启动了新实例结果两个实例同时写库数据出现重复。加上这个限制后同一任务永远只有一个实例在跑。4.3 去重与排序的串联执行成稿任务触发后执行顺序是固定的先取数据再去重再打分最后生成摘要。每一步的输出都落盘方便出问题时回溯。def generate_daily_report(): # 1. 取过去24小时数据 raw_items fetch_recent_items(hours24) # 2. 三级去重 deduped dedup_by_url(raw_items) deduped dedup_by_title(deduped) deduped dedup_by_semantic(deduped) # 3. 多因子打分 scored score_items(deduped) # 4. 取Top N top_items sorted(scored, keylambda x: x[score], reverseTrue)[:12] # 5. 生成摘要 report build_report(top_items) # 6. 落盘 save_report(report)每一步的中间结果我都会保留7天。为什么是7天因为大部分问题在3天内会被发现7天足够排查再长就是浪费存储。4.4 日报成稿的排版规则最终输出的日报有固定结构头条区、重点区、简讯区、观察区。头条区放1到2条当天最重要的重点区放5到6条有实质内容的简讯区放3到4条一句话能说清的观察区放1到2条趋势性判断。为什么要有观察区因为纯事实罗列读者只能看到点看不到线。观察区的作用是把当天几条相关信息串起来给一个轻量的趋势判断。这部分完全靠人工写每天花10到15分钟。提示观察区不要写太长150字以内。写长了就变成评论文章偏离日报定位。5. 常见问题与排查技巧5.1 采集端典型问题速查问题现象可能原因排查方法解决方案某源连续多天无数据RSS地址失效或改版手动访问源站确认更新RSS地址或改用页面监控采集量突然翻倍源站分页参数变化检查采集日志的URL模式修正分页逻辑采集任务卡死网络超时未设限制查看任务执行时长加timeout参数设30秒数据写入重复任务实例并发检查调度日志加max_instances1采集端最常见的问题是源站改版。我的经验是每个源都要有备用采集方案。RSS失效就切页面监控页面结构变了就用XPath兜底。这套冗余设计让我这两年几乎没有因为单源问题断过日报。5.2 去重环节的误判处理去重最怕两种误判该合的没合和不该合的合了。该合的没合表现为同一条新闻出现两次。排查方法是看两条内容的标题相似度和嵌入距离如果都接近阈值但没触发说明阈值设高了。我的处理是把阈值下调0.05观察一周。不该合的合了表现为两条不同新闻被合并成一条。这个更严重因为会丢信息。排查方法是看聚类结果里同一簇的内容如果发现主题明显不同说明阈值设低了。处理是上调0.05。实操心得阈值调整一次只动0.05动完观察至少三天。我见过有人一次调0.2结果整个去重逻辑崩掉回滚都来不及。5.3 排序结果的偏差修正排序偏差通常表现为某类内容长期霸榜或长期缺席。比如有一段时间我发现融资类新闻总是排前面但读者反馈说更想看技术进展。排查后发现是话题热度因子里融资新闻的跨源出现次数天然就高导致权重被放大。修正方法是给不同类别设类别配额。比如技术类至少占40%产品类不超过30%融资类不超过20%。配额不是硬性截断而是在打分时给超出配额的类别一个惩罚系数。def apply_category_quota(scored_items, quota): quota: {tech: 0.4, product: 0.3, funding: 0.2, other: 0.1} category_counts {} for item in scored_items: cat item[category] category_counts[cat] category_counts.get(cat, 0) 1 total len(scored_items) for item in scored_items: cat item[category] actual_ratio category_counts[cat] / total if actual_ratio quota.get(cat, 0.1): item[score] * 0.85 # 惩罚系数 return scored_items惩罚系数0.85是试出来的。太低没效果太高会把好内容也压下去。5.4 摘要质量的把控要点摘要最容易出的问题是信息失真。自动抽取的数字或主体搞错了读者一看就发现问题。我的做法是加一道数字校验摘要里出现的所有数字必须能在原文里找到对应。找不到就标红人工确认。另一个问题是价值判断空洞。比如值得关注的是这标志着重要进展——这种话等于没说。我的标准是价值判断必须包含至少一个具体维度是性能提升、成本下降、能力扩展还是生态影响。写不出具体维度就说明这条内容可能不值得进日报。6. 让日报真正有用的几个经验6.1 读者反馈的收集与利用日报做出来是给人看的所以反馈必须收集。我在日报末尾放了一个极简的反馈入口只有两个选项有用和没用。为什么不做更细的评分因为读者懒选项越多越没人填。两个选项的填写率是五档评分的三倍以上。收集到的反馈怎么用每周统计一次看哪些类型的内容没用比例高。如果某类内容连续两周没用超过30%就降低它的排序权重。这个机制让日报的内容结构能跟着读者需求慢慢演化而不是我拍脑袋决定。6.2 人工介入的边界整套系统自动化程度不低但人工介入是必须的。我的原则是机器负责筛人负责判。筛选、去重、排序、摘要骨架填充这些交给机器价值判断、趋势观察、最终成稿的取舍这些交给人。人工介入的时间控制在每天早上30到45分钟。超过这个时间说明自动化环节出了问题要去排查而不是硬扛。我见过有人每天花三小时手工整理日报那不是做系统那是做苦力。6.3 长期维护的节奏这套系统不是搭完就一劳永逸的。信源会失效模型会过时读者口味会变。我的维护节奏是每周小调每月大调每季度重构一次。每周小调是看反馈数据微调权重和阈值。每月大调是检查信源清单替换掉失效或低质的源。每季度重构是看整体架构有没有需要升级的地方比如嵌入模型要不要换、打分因子要不要加。这个节奏跑下来系统一直保持在一个够用且不臃肿的状态。我不追求完美追求的是每天早上七点能稳定产出一份我自己愿意看的日报。6.4 一个容易被忽略的细节时区处理最后说一个特别容易踩的坑时区。AI新闻是全球性的如果时区处理不对会出现昨天的新闻今天才出现或者今天的新闻被算到明天的问题。我的做法是所有时间戳统一存UTC只在最终展示时转成目标时区。这个规则听起来简单但我在早期因为混用本地时间和UTC导致去重逻辑判断错误同一事件被当成两天的事件处理连续一周日报都有重复内容。后来统一成UTC存储问题再没出现过。注意如果你的读者分布在不同时区日报的日期定义要明确。我的做法是以目标读者主要所在时区的自然日为准采集窗口仍然是24小时滚动但成稿时的日期标签按目标时区标注。这套AI日报的流程从最初的手工整理到现在半自动化前后迭代了大概七八个版本。每个版本的改进都来自实际使用中遇到的问题而不是预先设计出来的。如果你也想做一份自己的日报我的建议是先从最简单的版本跑起来哪怕每天只聚合5个源、只输出3条内容先跑通再优化。系统是在使用中长出来的不是在设计图上画出来的。