从信息洪流到每日必读：AI日报系统搭建与自动化筛选实战

1. 一份AI日报的诞生：从信息洪流到每日必读

每天早上八点，我的手机都会准时弹出一份自己做的AI日报。不是那种机器自动抓取、标题党满天飞的聚合页，而是一份经过人工筛选、带点评、带延伸阅读的“人味儿”日报。这份日报从2024年初开始做，最初只是发给团队内部几个人看，后来慢慢扩展到几百人的读者群，到现在已经迭代了十几个版本。今天这篇博文，我就把“AI日报”这个项目的完整搭建思路、技术选型、实操细节和踩过的坑，毫无保留地拆解一遍。

你可能会问，现在AI资讯号那么多，为什么还要自己做日报？答案很简单：信息过载时代，筛选比获取更重要。公开渠道每天产生的AI相关新闻、论文、产品更新、融资动态，少说也有几百条。但真正值得关注的，可能不到十条。一份好的日报，核心价值不在于“全”，而在于“准”和“省时间”。它要解决的是三个问题：第一，帮读者过滤噪音；第二，用最短的时间传递最关键的信息；第三，提供机器无法替代的判断和点评。

这份日报适合谁来参考？如果你是AI从业者、产品经理、投资人，或者只是对AI行业保持好奇的开发者，这套方法论都能直接复用。哪怕你完全不懂编程，也可以用我后面提到的低代码方案跑起来。全文会围绕“AI日报”这个核心，从整体设计、技术选型、实操流程、问题排查四个维度展开，中间会穿插大量可直接抄作业的配置和代码片段。

2. 日报系统的整体设计与核心思路拆解

2.1 为什么选择“人工+自动化”的混合模式

做日报的第一天，我就面临一个根本性的选择：是全自动抓取生成，还是纯人工编辑？全自动方案听起来很酷，用爬虫抓取几十个源，再用大模型摘要，最后自动排版推送。我试过，跑了一周就放弃了。原因有三个：第一，自动摘要经常丢失关键上下文，把一条重要的融资消息压缩成一句废话；第二，源站的反爬策略变化频繁，维护成本极高；第三，也是最致命的，自动生成的内容没有“观点”，读者看完不知道这条新闻到底意味着什么。

纯人工方案也不现实。每天手动浏览上百个信息源，再逐条撰写点评，至少需要三到四个小时，长期坚持几乎不可能。所以最终我选择了混合模式：自动化负责“采集”和“初筛”，人工负责“精选”和“点评”。具体来说，用脚本定时抓取RSS、API和特定页面，把原始内容存入数据库；然后用一套简单的规则引擎做第一层过滤，比如关键词匹配、来源权重、热度阈值；最后我每天花30到40分钟，从筛选后的20到30条候选里挑出8到10条，逐条写点评。

这个模式的核心逻辑是：机器做它擅长的（速度、广度、重复劳动），人做人擅长的（判断、关联、表达）。自动化把信息从“几百条”压缩到“几十条”，人工再把“几十条”精炼成“十条”。整个流程的瓶颈不在技术，而在编辑的判断力。这也是为什么我坚持不把点评环节交给大模型——至少目前阶段，大模型的点评还是太“正确”了，缺少那种“这条新闻其实意味着某某公司要转型”的锐利感。

2.2 信息源的分层管理策略

信息源的质量直接决定日报的质量。我一开始贪多，订阅了上百个源，结果每天光是浏览标题就花了两个小时。后来我学乖了，把信息源分成三个层级，每个层级用不同的处理策略。

第一层是核心源，大约10到15个。这些是必须每天逐条查看的，包括头部AI实验室的官方博客、几个关键人物的社交账号、以及两三个高质量的行业通讯。这一层的特点是信噪比极高，几乎每条都值得看。处理策略是“全量人工过目”，不依赖自动化过滤。

第二层是扩展源，大约30到40个。包括主流科技媒体的AI频道、学术论文预印本平台的近期热门、以及一些垂直领域的新闻站。这一层用关键词和热度做初筛，每天自动挑出10到15条候选。处理策略是“机器初筛+人工抽查”。

第三层是长尾源，数量不限。包括各种小众博客、论坛讨论、产品更新日志。这一层不直接进入日报，而是作为“背景信息”存在。当我在写某条点评需要补充上下文时，会主动去这一层搜索。处理策略是“按需检索”，不主动推送。

分层管理的好处是，我的注意力始终集中在最高价值的信息上，不会被长尾噪音干扰。具体的信息源列表我会在下一节详细列出，这里先说一个原则：宁缺毋滥，动态调整。每个月我会回顾一次各源的“命中率”——也就是它提供的条目最终被选入日报的比例。连续两个月命中率低于5%的源，直接降级或移除。

2.3 日报的结构设计与阅读节奏

一份日报的结构，决定了读者的阅读体验。我试过很多种排版，最终固定为四个板块：头条深度、快讯速览、产品更新、一句话点评。每个板块的定位和篇幅都不一样。

头条深度通常只有一条，占整个日报30%的篇幅。它必须是当天最重要的新闻，而且我会写300到500字的详细分析，包括背景、影响、我的判断。快讯速览是5到6条短消息，每条100字左右，只讲事实，不加点评。产品更新是2到3条，专门收录工具和产品的版本迭代、新功能发布。一句话点评是3到5条，每条只有一句话，但必须犀利，通常是那些“看起来不起眼但可能很重要”的信号。

这个结构的逻辑是匹配不同的阅读场景。早上通勤时，读者可能只扫一眼快讯；午休时有空，才会细读头条分析。四个板块的篇幅比例大约是3:3:2:2，整体阅读时间控制在8到10分钟。超过这个时间，日报就变成了负担，读者会放弃。

注意：日报的“日报感”很重要。不要做成周报的浓缩版，也不要做成深度长文。它的核心是“每天花几分钟，跟上行业节奏”。一旦某天的内容超过15分钟阅读量，我就会强制删减，哪怕有些条目我觉得很可惜。

3. 核心细节解析与实操要点

3.1 信息采集：RSS、API与页面抓取的取舍

信息采集是整个系统的入口，也是最容易出问题的环节。我试过三种方式：RSS订阅、官方API、以及直接抓取网页。每种方式都有各自的适用场景和坑。

RSS是最省心的方式，但前提是源站提供RSS。我常用的RSS阅读器是Miniflux，轻量、自托管、API友好。对于提供RSS的源，我直接用Miniflux的API拉取未读条目。这里有个小技巧：不要用RSS阅读器的“已读”状态来管理，而是把所有条目都拉到一个临时表里，用自己的规则引擎去重和过滤。因为RSS阅读器的已读状态是全局的，一旦你在阅读器里点开了，脚本就拉不到了。

官方API适合那些不提供RSS但提供结构化接口的源。比如一些论文平台和产品更新日志。API的好处是数据干净，坏处是通常有频率限制。我的做法是用一个简单的调度器，把API调用分散到全天，而不是集中在早上。比如每30分钟拉一次，每次只拉最新的一页。这样既不会触发限流，也能保证早上生成日报时数据是新鲜的。

页面抓取是最后的选择，只用于那些既不提供RSS也不提供API的源。我用的是Playwright，因为它能处理JavaScript渲染的页面。但页面抓取极其脆弱，源站改一次样式，脚本就挂了。所以我的策略是：能用RSS就用RSS，能用API就用API，实在不行才抓页面，而且抓页面的源不超过5个。每次源站改版，我都会收到通知，然后手动更新选择器。

# 一个简单的RSS拉取示例，使用feedparser import feedparser import sqlite3 from datetime import datetime, timedelta def fetch_rss(feed_url, source_name): feed = feedparser.parse(feed_url) conn = sqlite3.connect('ai_daily.db') c = conn.cursor() for entry in feed.entries: # 只保留最近24小时的条目 published = datetime(*entry.published_parsed[:6]) if datetime.now() - published > timedelta(hours=24): continue c.execute('''INSERT OR IGNORE INTO raw_items (title, link, summary, source, published, fetched_at) VALUES (?, ?, ?, ?, ?, ?)''', (entry.title, entry.link, entry.summary, source_name, published, datetime.now())) conn.commit() conn.close()

这段代码的核心逻辑是：拉取RSS，只保留24小时内的条目，存入SQLite。用INSERT OR IGNORE配合链接的唯一索引，天然去重。SQLite对于个人项目来说完全够用，不需要上PostgreSQL或MySQL。

3.2 初筛规则引擎的设计与参数调优

采集到的原始条目，每天大概有200到300条。直接人工看是不现实的，所以需要一套规则引擎做初筛。我的规则引擎分三步：关键词过滤、来源加权、热度排序。

关键词过滤是最粗的一层。我维护了一个关键词列表，分为“必选词”和“排除词”。必选词包括“发布”“开源”“融资”“收购”“突破”等动作词，以及具体的公司名和产品名。排除词包括“招聘”“活动预告”“课程推广”等明显不是新闻的内容。这一层能把条目数从300降到150左右。

来源加权是第二层。每个源有一个权重分，核心源权重是10，扩展源是5，长尾源是1。同时，如果一条新闻被多个源同时报道，它的权重会累加。比如一条新闻被3个核心源报道，权重就是30。这一层能把条目数从150降到50左右。

热度排序是第三层。热度不是简单的点击量，而是综合了社交媒体的讨论量、新闻的时效性、以及我个人的兴趣标签。我用的公式是：热度 = 来源权重 × 时效因子 × 兴趣因子。时效因子是发布时间越近越高，兴趣因子是我手动给某些话题打的标签权重。这一层最终输出20到30条候选，按热度从高到低排列。

# 规则引擎的核心逻辑 def filter_items(items): # 第一步：关键词过滤 must_words = ['发布', '开源', '融资', '收购', '突破', '上线', '更新'] exclude_words = ['招聘', '活动预告', '课程', '广告'] filtered = [] for item in items: text = item['title'] + ' ' + item['summary'] if any(w in text for w in exclude_words): continue if not any(w in text for w in must_words): continue filtered.append(item) # 第二步：来源加权 for item in filtered: item['weight'] = source_weights.get(item['source'], 1) # 第三步：热度排序 for item in filtered: hours_ago = (datetime.now() - item['published']).total_seconds() / 3600 time_factor = max(0.1, 1 - hours_ago / 24) interest_factor = interest_tags.get(item['source'], 1) item['heat'] = item['weight'] * time_factor * interest_factor filtered.sort(key=lambda x: x['heat'], reverse=True) return filtered[:30]

这套规则引擎的参数需要持续调优。我每个月会回顾一次“漏报”和“误报”。漏报是指那些最终被其他日报报道但我没选中的条目，误报是指我选入候选但最终没进日报的条目。根据这些反馈，调整关键词列表和权重系数。这个过程很繁琐，但效果显著。三个月后，我的初筛准确率从最初的60%提升到了85%以上。

3.3 人工精选与点评的写作框架

从20到30条候选里选出8到10条，并逐条写点评，是整个日报最核心的环节。我总结了一个“三问框架”，每一条候选都要过这三问：

第一问：这条新闻的本质是什么？很多新闻的标题和实质是两回事。比如“某公司发布新模型”，本质可能是“某公司在追赶竞争对手的某个能力”。写点评的第一步，就是剥开标题，找到实质。

第二问：它对谁有影响？一条新闻可能对开发者有影响，对投资人没影响；或者对短期股价有影响，对长期格局没影响。明确影响对象，才能写出有针对性的点评。

第三问：我的判断是什么？这是点评的灵魂。不是复述新闻，而是给出一个明确的判断：看好还是看衰，重要还是不重要，值得跟进还是可以忽略。判断可以错，但不能没有。

基于这三问，我形成了一个固定的点评模板：事实一句话 + 背景一句话 + 判断一句话。三句话，不超过100字。这个模板强迫我提炼核心，避免废话。

实操心得：写点评时，我习惯先写判断，再补事实和背景。因为判断是最难的，先写判断能避免被事实带偏。如果一条新闻我写不出判断，那说明它可能不值得入选。

4. 实操过程与核心环节实现

4.1 环境搭建与依赖安装

整个系统的运行环境很简单：一台最低配的云服务器，1核1G内存就够。操作系统用Ubuntu 22.04，Python版本3.10以上。核心依赖只有四个：feedparser用于RSS解析，playwright用于页面抓取，sqlite3用于数据存储，requests用于API调用。如果要用大模型做辅助摘要，再加一个openai或类似的SDK。

# 环境搭建命令 sudo apt update sudo apt install python3-pip python3-venv sqlite3 -y python3 -m venv ai_daily_env source ai_daily_env/bin/activate pip install feedparser playwright requests playwright install chromium

这里有个坑：Playwright安装Chromium会下载一个几百MB的浏览器，如果服务器带宽小，会很慢。我的做法是先在本地下载好，再传到服务器。或者直接用playwright install chromium --with-deps，让系统自动处理依赖。

数据库设计也很简单，三张表就够了：raw_items存原始条目，candidates存初筛后的候选，daily_issues存最终日报。每张表的字段不多，但索引要建好。raw_items的link字段建唯一索引，用于去重；candidates的heat字段建普通索引，用于排序。

CREATE TABLE raw_items ( id INTEGER PRIMARY KEY AUTOINCREMENT, title TEXT NOT NULL, link TEXT UNIQUE NOT NULL, summary TEXT, source TEXT, published DATETIME, fetched_at DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE candidates ( id INTEGER PRIMARY KEY AUTOINCREMENT, raw_id INTEGER, heat REAL, selected BOOLEAN DEFAULT 0, FOREIGN KEY (raw_id) REFERENCES raw_items(id) ); CREATE TABLE daily_issues ( id INTEGER PRIMARY KEY AUTOINCREMENT, issue_date DATE UNIQUE, content TEXT, created_at DATETIME DEFAULT CURRENT_TIMESTAMP );

4.2 定时任务的配置与调度

整个流程需要定时触发。我的调度方案很简单：用cron，每30分钟跑一次采集脚本，每天早上7点跑一次初筛和生成脚本。为什么采集要每30分钟一次？因为有些源更新频繁，如果只在早上采集，可能会漏掉凌晨的重要新闻。每30分钟一次，既能保证时效性，又不会给源站太大压力。

# crontab配置 */30 * * * * /home/user/ai_daily/collect.sh 0 7 * * * /home/user/ai_daily/generate.sh

collect.sh的内容就是激活虚拟环境，运行采集脚本。generate.sh则是运行初筛脚本，把候选写入数据库，然后发一封邮件或消息通知我。我收到通知后，打开一个简单的Web界面，从候选里勾选条目，写点评，最后点“发布”。这个Web界面我用Flask写了一个最简单的版本，只有一个页面，一个表单。

# 极简的Flask编辑界面 from flask import Flask, render_template, request import sqlite3 app = Flask(__name__) @app.route('/') def index(): conn = sqlite3.connect('ai_daily.db') c = conn.cursor() c.execute('''SELECT c.id, r.title, r.link, r.summary, r.source, c.heat FROM candidates c JOIN raw_items r ON c.raw_id = r.id WHERE c.selected = 0 ORDER BY c.heat DESC''') items = c.fetchall() conn.close() return render_template('index.html', items=items) @app.route('/publish', methods=['POST']) def publish(): selected = request.form.getlist('selected') # 处理选中的条目，生成日报内容 # ... return 'Published'

这个界面极其简陋，但足够用。我不需要复杂的后台，只需要一个能勾选和写字的页面。Flask的模板引擎Jinja2让这件事变得非常简单。

4.3 日报的排版与推送

日报的最终形态是一段Markdown文本。我选择Markdown而不是HTML，是因为它足够简单，而且可以方便地转换成其他格式。排版规则很固定：标题用二级标题，板块之间用分割线，每条新闻的链接用行内链接。

## AI日报 · 2026-10-03 ### 头条深度 **某公司发布新一代开源模型，参数规模翻倍** [链接](https://example.com) 事实：... 背景：... 判断：... --- ### 快讯速览 - **某实验室宣布新突破**：[链接](...) 一句话说明。 - **某产品更新重要功能**：[链接](...) 一句话说明。

推送渠道我试过很多：邮件、Telegram、企业微信、飞书。最终保留了邮件和飞书两个渠道。邮件适合存档和转发，飞书适合即时阅读。推送时间固定在早上8点，因为这是大多数人开始工作的时间。

注意：推送时间不要选在整点，因为整点往往是各种通知的高峰期，容易被淹没。我试过8:00、8:15、8:30，最终发现8:15的打开率最高。

5. 常见问题与排查技巧实录

5.1 采集环节的典型故障与修复

采集环节最常见的问题是源站改版导致抓取失败。RSS源相对稳定，但页面抓取的源经常出问题。我的排查流程是：先看日志，确认是网络问题还是解析问题；如果是解析问题，用Playwright的截图功能看看页面结构；然后更新选择器。

另一个常见问题是编码问题。有些源站返回的RSS不是UTF-8编码，导致中文乱码。解决方法是在feedparser.parse之前，先用requests获取内容，手动检测编码，再传给feedparser。

import requests import feedparser def fetch_rss_safe(url): resp = requests.get(url, timeout=10) resp.encoding = resp.apparent_encoding # 自动检测编码 feed = feedparser.parse(resp.text) return feed

还有一个坑是时间戳解析。不同源的RSS时间格式不一样，有的用RFC 822，有的用ISO 8601。feedparser能处理大部分格式，但偶尔会遇到无法解析的。我的做法是加一个fallback：如果解析失败，就用当前时间减去1小时作为发布时间。

5.2 初筛规则的误报与漏报调优

初筛规则最大的问题是误报和漏报的平衡。关键词设得太严，会漏掉重要新闻；设得太松，候选太多，人工负担重。我的调优方法是：每周统计一次误报率和漏报率，然后微调关键词列表。

误报的典型例子是“某公司发布财报”，关键词“发布”命中了，但财报不是AI新闻。解决方法是在排除词里加上“财报”“股价”“人事变动”等。漏报的典型例子是“某模型在某个基准测试上取得新纪录”，关键词里没有“发布”“开源”，但这条新闻很重要。解决方法是在必选词里加上“纪录”“基准”“评测”等。

5.3 人工编辑的效率提升技巧

人工编辑是瓶颈，所以效率提升很关键。我总结了几个技巧：

第一，批量处理。不要一条一条写点评，而是先把所有候选快速过一遍，标记出要选的，然后再集中写点评。这样能减少上下文切换的开销。

第二，模板化。点评的“事实+背景+判断”三句话结构，可以提前准备一些常用句式。比如“这条新闻意味着...” “值得注意的是...” “我的判断是...”。这些句式能加快写作速度。

第三，限时。给自己设定一个时间限制，比如30分钟。时间一到，不管写没写完，都强制发布。这能避免过度打磨，也能保证日报的时效性。

实操心得：我试过用大模型辅助写点评，但效果不好。大模型的点评太“正确”，缺少锐度。后来我改用大模型做“事实核查”，比如确认某个数据的准确性，这样既提高了效率，又保留了人工判断的核心价值。

5.4 推送与反馈的闭环设计

日报发出去不是终点，读者的反馈才是改进的依据。我在每份日报的末尾加了一个简单的反馈入口，读者可以点“有用”或“没用”，也可以直接回复邮件。每周我会统计一次反馈数据，看看哪些板块受欢迎，哪些板块被跳过。

反馈数据还能用来优化信息源。如果某个源的条目经常被读者标记为“没用”，我就会考虑降级或移除。如果某个话题的反馈特别热烈，我就会在兴趣标签里提高它的权重。

这个闭环设计让日报从一个单向输出变成了双向互动。读者的反馈不仅帮助我改进内容，也让我更了解他们的需求。有时候读者会指出我漏掉的重要新闻，这比任何自动化工具都有效。

6. 这套系统还能怎么扩展

这套日报系统跑了一年多，基本稳定了。但还有一些可以扩展的方向。比如，可以加一个“历史回顾”功能，每周日自动生成一份本周要闻汇总。或者加一个“主题追踪”功能，对某个特定话题（比如开源模型）做持续跟踪，自动生成时间线。

另一个方向是多语言支持。目前日报只覆盖中文和英文源，如果加上日文和韩文源，覆盖面会更广。但这需要额外的翻译环节，我还在评估成本。

技术层面，我考虑过把SQLite换成PostgreSQL，但后来觉得没必要。个人项目的并发量极低，SQLite完全够用。反而是一些边缘情况，比如数据库锁的问题，SQLite处理起来更简单。

最后分享一个小技巧：日报的标题格式很重要。我试过“AI日报 2026-10-03”和“AI日报 · 2026-10-03”，后者打开率更高。那个小圆点让标题看起来更精致，也更符合阅读习惯。这种细节看起来不起眼，但日积月累，对读者的阅读体验影响很大。