1. 从一条“空白”的资讯日报说起你看到的这个标题——“2026-09-23 AI最新资讯日报”正文是空的关键词是空的摘要也是空的。这其实是一个非常典型的场景很多人每天想追AI领域的动态但信息源太散公众号、技术社区、论文预印本、开源仓库、行业快讯各看一圈两个小时就没了最后脑子里只剩下一堆碎片。于是有人就想做一个“日报”类的产品把当天最值得看的AI资讯聚合起来用最短的时间让读者抓住重点。这个想法听起来简单但真正动手做过资讯聚合的人都知道难点根本不在“抓取”而在“筛选”和“组织”。抓取这件事写个脚本定时拉取几个源就行难的是每天几百上千条更新里哪些值得放进日报哪些应该直接过滤掉放进去的又该怎么排序、怎么归类、怎么用一两句话把核心信息说清楚。我前后做过三个不同领域的资讯聚合项目踩过的坑足够写一本小册子今天就把这套东西完整拆开讲一遍。这篇文章适合三类人看第一类是想自己搭一个AI资讯日报的技术人第二类是在团队里负责技术情报收集的工程师第三类是对信息聚合产品感兴趣、想理解背后逻辑的产品或运营同学。不管你是哪种读完应该都能拿到一套可以直接复用的思路和代码骨架。需要先说明一点标题里的日期是2026年9月23日这只是一个示例日期实际运行时日期是动态生成的。整篇文章讲的是“如何构建一个AI资讯日报系统”而不是某一天的具体新闻内容。这个区分很重要因为资讯本身有时效性但生产资讯的方法论是可以长期复用的。2. 资讯日报的核心难点不是抓取是信噪比2.1 为什么“全量抓取”是一条死路刚开始做资讯聚合的人最容易犯的错误就是贪多。觉得信息越多越好把能找到的源全部接进来RSS、API、网页抓取、邮件列表恨不得把整个互联网的AI相关内容都收进来。我第一个版本就是这么干的结果每天产出三千多条“资讯”读者打开一看直接懵了根本不知道从哪看起第二天就取关了。问题的本质在于资讯产品的价值不在于“多”而在于“少而准”。读者的时间是最稀缺的资源你帮他省下来的每一分钟都是价值你浪费他的每一分钟都是伤害。三千条未经筛选的信息等于零条有效信息。所以整个系统的设计重心必须从“怎么抓更多”转向“怎么筛更准”。这里有个反直觉的结论一个资讯日报的质量90%取决于过滤和排序策略只有10%取决于数据源的丰富程度。你哪怕只接三个高质量源只要筛选逻辑做得好产出的日报就比接三十个源但不过滤的系统强得多。我后来把数据源从二十多个砍到六个日报的打开率和读完率反而翻了一倍。2.2 信噪比的三个层次筛选这件事我把它拆成三个层次来理解每一层的处理逻辑完全不同。第一个层次是源级过滤。有些源本身就是高信噪比的比如顶级实验室的官方博客、核心开源项目的release note、几个公认高质量的论文速递渠道。这些源可以直接全量收录不需要逐条判断。而有些源是低信噪比的比如某些聚合平台的热榜里面大量重复和标题党就需要更激进的过滤策略。源级过滤的核心是给每个源打一个“基础信任分”这个分数决定了后续处理的严格程度。第二个层次是条目级过滤。同一条资讯来自不同源的价值是不一样的。比如“某公司发布新模型”这条消息官方博客发的和某个营销号转发的可信度和信息密度差了好几个量级。条目级过滤要解决的是这条内容本身值不值得看而不是它来自哪里。这里会用到关键词匹配、来源权重、内容长度、是否有实质信息比如有没有代码、有没有数据、有没有具体参数等信号。第三个层次是去重与聚类。同一个事件往往会被多个源报道如果不去重日报里会出现五条内容几乎一样的条目读者体验极差。去重不是简单的字符串比对因为不同源的表述差异很大。我试过用编辑距离效果一般后来改用语义相似度配合关键实体提取效果好很多。聚类则是把同一事件的不同角度报道归到一起让读者一次看全而不是分散在好几条里。2.3 一个可量化的筛选框架光讲道理没用得有一套能落地的打分机制。我目前用的框架是给每条资讯算一个综合分公式大致是这样的综合分 源信任分 × 0.3 内容质量分 × 0.4 时效性分 × 0.2 热度分 × 0.1源信任分是预先配置的0到1之间官方源给0.9以上聚合平台给0.4左右。内容质量分是动态算的看标题是否有实质信息、正文长度是否达标、是否包含具体的技术名词或数据。时效性分是随时间衰减的越新的分越高超过48小时的基本归零。热度分则参考该条目在多个源的被提及次数。这个公式不是拍脑袋来的是我调了好几版之后的结果。权重分配的依据是内容质量最重要因为读者最终看的是内容本身源信任次之因为它决定了内容的可信度时效性再次因为AI领域虽然更新快但真正重要的东西不会一天就过时热度分权重最低因为热度高不等于价值高很多爆款其实是噪音。提示这套权重不是固定的如果你的日报面向的是研究者内容质量分的权重可以再调高如果面向的是投资人时效性和热度分的权重应该加大。关键是先有一套可量化的框架再根据反馈微调而不是凭感觉拍。2.4 过滤策略的常见误区做过滤最容易踩的坑是“一刀切”。比如设一个关键词黑名单只要标题里出现“震惊”“重磅”“必看”就直接过滤。这个策略在初期有效但很快就会出现误杀。有些真正重要的发布标题里确实会带“重磅”两个字。所以过滤策略必须是多信号综合判断而不是单条件否决。另一个误区是过度依赖规则。规则能解决80%的常见情况但剩下20%的长尾情况规则会越来越复杂最后变成一堆互相冲突的if-else。我的做法是规则负责粗筛把明显不相关的干掉剩下的交给一个轻量的分类模型或者打分模型来精排。规则和模型结合比纯规则或纯模型都稳。还有一个容易被忽略的点过滤策略需要定期回顾。AI领域的表达方式变化很快半年前有效的关键词现在可能已经过时了。我一般每两周会抽一天把最近被过滤掉的条目随机抽50条人工看一眼检查有没有误杀。这个习惯帮我挽回了好几个本来会被漏掉的重要资讯。3. 数据源的选择与接入少即是多3.1 什么样的源值得接入选源的标准我总结成三条稳定、高信噪比、有独特信息。稳定是底线一个三天两头挂掉的源接进来就是给自己找麻烦。高信噪比是核心前面已经讲过了。有独特信息是关键如果一个源的内容在别处也能看到那它的价值就大打折扣。具体到AI领域我目前保留的源大概分四类。第一类是官方渠道比如主要实验室和公司的博客、模型发布页。这类源的信噪比最高但更新频率低有时候一周才一条。第二类是技术社区的高质量板块比如某些论坛的特定标签下的热门讨论这类源能反映一线开发者的真实关注点。第三类是论文速递渠道每天会推送新上架的预印本量比较大需要配合关键词过滤。第四类是开源项目的动态比如重要项目的release和issue里的高赞讨论这类源对工程实践者特别有价值。我特意没有接入新闻门户和综合科技媒体。原因很简单它们的AI报道大多是二手信息而且夹杂大量非技术内容信噪比太低。与其花精力过滤它们不如把精力放在前面四类源上。3.2 接入方式的技术选型接入方式主要有三种RSS、API、网页解析。优先级是API RSS 网页解析。API最稳数据结构清晰但很多源不提供公开API或者有严格的调用限制。RSS是折中方案大部分博客和社区都支持格式统一解析成本低。网页解析是最后的选择因为页面结构随时可能变维护成本高。我一般会优先找RSS找不到再考虑解析页面而且解析规则要写得足够健壮比如用多个选择器做fallback。这里有个实操细节RSS的更新频率和实际发布时间往往有延迟。有些源是每小时批量更新一次有些是实时推送。如果你的日报要求时效性就得对不同的源设置不同的抓取频率。我的配置是官方源每30分钟抓一次社区源每15分钟抓一次论文源每天固定时间抓两次。抓取频率太高会被限流太低会漏掉突发消息这个平衡需要根据实际源的行为来调。3.3 数据清洗的必做步骤抓回来的原始数据不能直接用必须经过清洗。清洗主要包括四步。第一步是编码统一。不同源的编码格式可能不一样有的是UTF-8有的是GBK混在一起会出现乱码。统一转成UTF-8是基本操作。第二步是HTML标签剥离。RSS里的正文通常带HTML标签需要剥掉只保留纯文本。但要注意有些标签是有意义的比如代码块和链接不能无差别地全部删掉。我的做法是先把代码块和链接提取出来单独处理再剥离其余标签。第三步是时间标准化。不同源的时间格式五花八门有的是ISO格式有的是RFC格式有的甚至是“3小时前”这种相对时间。全部转成统一的时间戳后续的时效性计算才能做。第四步是字段补全。有些源只提供标题和链接没有正文摘要。这时候需要根据链接去抓取正文或者至少抓取meta description。如果连这个都拿不到就得考虑用标题做后续处理但效果会打折扣。import feedparser from bs4 import BeautifulSoup from datetime import datetime, timezone def clean_entry(entry, source_config): # 剥离HTML保留代码块和链接的文本 soup BeautifulSoup(entry.get(summary, ), html.parser) for code in soup.find_all([code, pre]): code.replace_with(code.get_text()) text soup.get_text(separator , stripTrue) # 时间标准化 published entry.get(published_parsed) if published: ts datetime(*published[:6], tzinfotimezone.utc).timestamp() else: ts datetime.now(timezone.utc).timestamp() return { title: entry.get(title, ).strip(), link: entry.get(link, ), summary: text[:500], published_ts: ts, source: source_config[name], source_trust: source_config[trust] }这段代码是清洗环节的核心骨架实际使用时还要加上异常处理和日志记录。我踩过的一个坑是有些源的summary字段是空的但content字段有内容如果不做兼容处理这些条目就会被丢掉。所以字段读取一定要做fallback不能假设某个字段一定存在。3.4 源配置的管理方式源多了之后配置管理会变成一件麻烦事。我的做法是把所有源的配置写在一个独立的配置文件里用YAML格式每个源包含名称、URL、类型、信任分、抓取频率、过滤规则等字段。这样增删源只需要改配置不用动代码。sources: - name: lab_blog_a url: https://example.com/feed.xml type: rss trust: 0.95 interval_minutes: 30 keywords_required: [] - name: community_hot url: https://example.com/api/hot type: api trust: 0.6 interval_minutes: 15 keywords_required: [AI, model, training]keywords_required这个字段很关键。对于低信任分的源可以设置必须包含某些关键词才收录这样能大幅降低噪音。对于高信任分的源这个字段留空表示全量收录。这种差异化的配置比全局统一规则灵活得多。4. 筛选与排序的工程实现4.1 关键词策略的层次设计关键词是筛选的基础但怎么用关键词差别很大。我见过很多人就是简单地把关键词列表和标题做包含判断命中就留不命中就丢。这种做法在初期能用但很快就不够了。我的做法是把关键词分成三层。第一层是核心词比如“模型”“训练”“推理”“开源”这些命中任意一个就进入候选池。第二层是加分词比如“发布”“突破”“首次”“SOTA”这些命中就加分但不命中也不淘汰。第三层是排除词比如“招聘”“活动预告”“课程广告”这些命中直接淘汰。这三层的关键词列表需要持续维护。我的经验是核心词相对稳定几个月才需要调整一次加分词和排除词变化很快基本每两周就要更新。更新的时候不要凭感觉而是看数据把最近一周被淘汰的条目抽样看一遍如果发现有误杀就把对应的词从排除词里拿掉把最近一周入选但阅读量很低的条目看一遍如果发现某类内容持续表现差就把相关词加进排除词。4.2 内容质量分的计算逻辑内容质量分是整个打分体系里最核心的部分也是最难做好的部分。我目前用的是一套组合信号包括标题信息密度标题里是否包含具体的技术名词、数字、版本号。比如“某模型在某某基准上提升15%”就比“某模型大幅提升”信息密度高。正文长度太短的正文比如少于100字通常信息量不足但也不是越长越好超过2000字的正文可能是长篇分析需要单独处理。技术实体数量用简单的实体识别统计正文里出现了多少个技术名词、模型名、数据集名。实体越多通常技术含量越高。链接密度正文里如果有指向论文、代码仓库、官方文档的链接说明内容有实质支撑加分。来源一致性如果多个高信任源都报道了同一事件说明这个事件重要加分。这些信号加权求和得到0到1之间的质量分。权重需要根据实际效果调我目前的配置是标题信息密度0.3、正文长度0.15、技术实体数量0.3、链接密度0.15、来源一致性0.1。def quality_score(entry, all_entries): score 0.0 # 标题信息密度 title entry[title] has_number any(c.isdigit() for c in title) has_tech_term any(term in title for term in TECH_TERMS) score 0.3 * (0.5 * has_number 0.5 * has_tech_term) # 正文长度归一化到0-1500字左右为满分 length_score min(len(entry[summary]) / 500, 1.0) score 0.15 * length_score # 技术实体数量 entities extract_entities(entry[summary]) entity_score min(len(entities) / 10, 1.0) score 0.3 * entity_score # 链接密度 link_count entry[summary].count(http) link_score min(link_count / 3, 1.0) score 0.15 * link_score # 来源一致性同一事件被多少源报道 similar_count count_similar(entry, all_entries) consistency_score min(similar_count / 5, 1.0) score 0.1 * consistency_score return score这段代码是简化版实际使用时要考虑性能。如果每天几千条逐条算相似度会很慢需要先做粗筛再做精算。我的做法是先用标题的simhash做快速去重把相似条目聚成簇然后在簇内算一致性分这样计算量能降一个数量级。4.3 去重与聚类的具体做法去重这件事我试过三种方案最后选了第三种。第一种是精确匹配标题完全一样才算重复。这个太严格实际效果很差因为不同源的标题几乎不可能完全一样。第二种是编辑距离算标题之间的Levenshtein距离小于某个阈值就算重复。这个比精确匹配好但有两个问题一是计算量大二是对语义相同但表述差异大的标题无能为力。比如“某公司发布新模型”和“某公司推出新一代模型”编辑距离可能很大但其实是同一件事。第三种是语义相似度把标题转成向量算余弦相似度。这个效果最好但需要embedding模型。我目前用的是轻量级的句子向量模型本地部署单条推理在毫秒级几千条也就几秒钟。阈值设在0.85左右高于这个值就认为是同一事件。聚类是在去重的基础上做的。去重是把完全重复的合并聚类是把同一事件的不同角度报道归到一起。比如一个模型发布官方博客是一条技术社区的讨论是一条论文解读又是一条这三条应该聚成一个簇在日报里作为一个条目呈现但可以附上多个链接。聚类的实现我用的是简单的层次聚类因为每天的量不大不需要上复杂的聚类算法。具体做法是先算所有条目两两之间的相似度然后从相似度最高的开始合并直到没有相似度超过阈值的对为止。每个簇选一个代表条目通常是质量分最高的那个作为主条目其余作为附属链接。4.4 排序策略与多样性控制排序不是简单地按综合分从高到低排。如果只按分数排很容易出现前十条都是同一类内容的情况比如全是模型发布读者会觉得单调。所以排序需要在分数和多样性之间做平衡。我的做法是分两步。第一步按综合分排序得到一个初始列表。第二步做多样性重排用一个滑动窗口每次从窗口里选分数最高的但如果和已选条目的类别重复就跳过选下一个。窗口大小设为5这样既保证了高分条目优先又避免了同类扎堆。类别怎么定义我用的是简单的规则分类比如“模型发布”“论文”“开源项目”“行业动态”“工具推荐”这几类。分类不需要很精确粗粒度就够了。如果某个类别在日报里占比超过40%就触发多样性控制强制插入其他类别的内容。注意多样性控制不能过度。我试过把多样性权重调得很高结果日报里什么都有但每条都不够深入读者反而觉得没有重点。后来把多样性控制在“避免单一类别超过40%”这个程度效果最好。这个度需要根据读者反馈来调。5. 日报的生成与呈现5.1 日报的结构设计一份好的AI资讯日报结构应该让读者在30秒内抓住重点3分钟内看完核心内容有兴趣的再深入。我目前用的结构是三层今日头条、重点推荐、快速浏览。今日头条只放1到2条是当天最重要的资讯配一段150字左右的解读说清楚这件事为什么重要、影响是什么。重点推荐放5到8条每条配一句话摘要和链接。快速浏览放10到15条只有标题和链接供有兴趣的读者自行深入。这个结构的依据是读者的阅读行为。大部分人只会看头条和重点推荐快速浏览是给重度用户的。所以头条的选择至关重要它决定了读者对这份日报的第一印象。我选头条的标准是综合分最高且必须是“事件性”内容而不是观点或教程。事件性内容有明确的时间点和影响范围更适合做头条。5.2 摘要生成的实用方案摘要生成有两种方案抽取式和生成式。抽取式是从原文里选最重要的句子生成式是用模型重新组织语言。我两种都试过最后选了抽取式为主、生成式为辅的混合方案。抽取式的优点是稳定、不会胡编缺点是可能不够流畅。生成式的优点是流畅但有小概率产生事实错误在资讯场景下这是不可接受的。所以我的做法是先用抽取式生成一个基础摘要再用生成式做润色但润色后的结果要和原文做事实一致性检查不一致就回退到抽取式的结果。抽取式的具体做法是把正文分句给每个句子打分分数由位置首句和尾句权重高、关键词密度、是否包含技术实体等因素决定选分数最高的两到三句拼成摘要。这个方案实现简单效果稳定适合大多数场景。def extract_summary(text, max_sentences3): sentences split_sentences(text) if len(sentences) max_sentences: return text scores [] for i, sent in enumerate(sentences): score 0.0 # 位置分首句和尾句加分 if i 0 or i len(sentences) - 1: score 0.3 # 关键词密度 keyword_count sum(1 for kw in KEYWORDS if kw in sent) score 0.4 * min(keyword_count / 3, 1.0) # 技术实体 entity_count len(extract_entities(sent)) score 0.3 * min(entity_count / 5, 1.0) scores.append((score, i, sent)) scores.sort(reverseTrue) selected sorted(scores[:max_sentences], keylambda x: x[1]) return .join(s[2] for s in selected)这段代码的核心思路是摘要不是简单截取开头而是选信息量最大的句子。位置分保证首尾句优先关键词密度保证技术内容优先实体数量保证有实质信息的句子优先。三个信号加权效果比单纯截取开头好很多。5.3 多格式输出的工程考量日报的呈现格式我目前支持三种Markdown、HTML、纯文本。Markdown适合发在技术社区HTML适合做网页版纯文本适合邮件推送。三种格式从同一份结构化数据生成保证内容一致。生成的时候要注意几个细节。Markdown里的链接要用标准格式方便读者点击。HTML要做响应式因为很多人用手机看。纯文本要控制行宽太宽了在邮件客户端里会换行混乱。这些细节看起来小但直接影响阅读体验。另外日报的标题格式也要统一。我用的格式是“AI资讯日报 | YYYY-MM-DD”这样在邮件列表和社区里都能一眼识别。标题里不要加“重磅”“必看”这类词一是显得不专业二是容易被过滤规则误伤。5.4 发布渠道与时机发布渠道的选择取决于你的目标读者在哪。技术社区、邮件列表、即时通讯群组各有各的特点。我一般会同时发多个渠道但内容做微调。比如技术社区的版本会保留更多技术细节邮件版本会更简洁。发布时机也很重要。AI领域的读者主要集中在几个时间段看资讯早上通勤时间、午休时间、晚上下班后。我的经验是早上8点左右发布效果最好因为读者刚到工位有看资讯的习惯。如果当天有重大发布可以加发一次晚间版但不要频繁加发否则会打扰读者。提示发布频率要稳定。日报之所以叫日报就是每天固定时间出现。如果今天早上发、明天晚上发读者就养不成阅读习惯。稳定比频繁更重要。6. 运行中的坑与长期维护6.1 源失效与反爬的应对做资讯聚合源失效是家常便饭。有的源改域名了有的改页面结构了有的直接关停了。如果不做监控可能好几天都不知道某个源已经挂了日报里少了重要内容也发现不了。我的做法是给每个源加健康检查。每次抓取后记录抓取到的条目数如果连续三次抓取条目数为零就触发告警。告警方式可以是邮件、即时消息看你的习惯。收到告警后人工检查一下确认是源挂了还是规则失效了然后修复。反爬是另一个常见问题。有些源会对频繁请求做限制表现为返回403或者返回空内容。应对方法有几个一是降低抓取频率二是加请求头模拟浏览器三是用多个出口IP轮换。但要注意反爬策略要适度不要给源服务器造成压力。我一般会把抓取频率控制在合理范围内宁可慢一点也不要被封。6.2 过滤规则的定期回顾前面提过过滤规则需要定期回顾这里展开讲一下具体怎么做。我一般每两周做一次回顾流程是导出最近两周被过滤掉的所有条目随机抽100条人工判断哪些是误杀。如果误杀率超过5%就说明过滤规则太严了需要放宽。同时导出最近两周入选但阅读量最低的20条看看它们有什么共同特征如果发现某类内容持续表现差就把相关特征加入过滤规则。这个回顾过程听起来麻烦但每次也就花半小时能避免过滤规则越来越偏。我见过很多资讯项目刚开始效果不错几个月后质量明显下降就是因为没有做定期回顾规则还停留在几个月前的状态。6.3 读者反馈的收集与利用读者反馈是最宝贵的优化信号但很多人不知道怎么收集。我的做法是在日报末尾加一行“如果觉得有用欢迎转发如果有建议欢迎回复”然后认真看每一条回复。回复里提到的具体问题比如“某类内容太多了”“某类内容漏掉了”都是调整过滤和排序策略的直接依据。除了被动收集我还会主动做小范围调研。比如每季度发一次问卷问读者最关注哪类内容、最不喜欢哪类内容、希望增加什么。问卷不用太长三五个问题就够。收集到的数据用来调整权重和类别定义。6.4 系统扩展的边界最后说一下扩展性。这套系统在日处理几百到几千条的量级下运行良好但如果量级再大就需要做架构调整。主要的瓶颈在相似度计算和聚类这两个操作的时间复杂度是O(n²)条目多了会明显变慢。如果要扩展到万级需要引入近似最近邻搜索把O(n²)降到O(n log n)。另外抓取环节也需要做分布式单机抓取在源多了之后会成为瓶颈。但这些优化在初期不需要做过早优化是浪费。我的建议是先把单机版跑通等真的遇到性能瓶颈了再优化而不是一开始就设计一个复杂的分布式系统。这套系统我从第一版到现在前后迭代了大概七八次每次都是遇到具体问题才改。现在每天稳定产出读者反馈也不错。如果你也想做一个自己的资讯日报建议从最小的可用版本开始先跑起来再根据实际效果慢慢调。最怕的是一开始就想做一个完美的系统结果永远停留在设计阶段。
