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(hours24): 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(keylambda x: x[heat], reverseTrue) return filtered[:30]这套规则引擎的参数需要持续调优。我每个月会回顾一次“漏报”和“误报”。漏报是指那些最终被其他日报报道但我没选中的条目误报是指我选入候选但最终没进日报的条目。根据这些反馈调整关键词列表和权重系数。这个过程很繁琐但效果显著。三个月后我的初筛准确率从最初的60%提升到了85%以上。3.3 人工精选与点评的写作框架从20到30条候选里选出8到10条并逐条写点评是整个日报最核心的环节。我总结了一个“三问框架”每一条候选都要过这三问第一问这条新闻的本质是什么很多新闻的标题和实质是两回事。比如“某公司发布新模型”本质可能是“某公司在追赶竞争对手的某个能力”。写点评的第一步就是剥开标题找到实质。第二问它对谁有影响一条新闻可能对开发者有影响对投资人没影响或者对短期股价有影响对长期格局没影响。明确影响对象才能写出有针对性的点评。第三问我的判断是什么这是点评的灵魂。不是复述新闻而是给出一个明确的判断看好还是看衰重要还是不重要值得跟进还是可以忽略。判断可以错但不能没有。基于这三问我形成了一个固定的点评模板事实一句话 背景一句话 判断一句话。三句话不超过100字。这个模板强迫我提炼核心避免废话。实操心得写点评时我习惯先写判断再补事实和背景。因为判断是最难的先写判断能避免被事实带偏。如果一条新闻我写不出判断那说明它可能不值得入选。4. 实操过程与核心环节实现4.1 环境搭建与依赖安装整个系统的运行环境很简单一台最低配的云服务器1核1G内存就够。操作系统用Ubuntu 22.04Python版本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.shcollect.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, itemsitems) 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, timeout10) 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”后者打开率更高。那个小圆点让标题看起来更精致也更符合阅读习惯。这种细节看起来不起眼但日积月累对读者的阅读体验影响很大。
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(hours24): 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(keylambda x: x[heat], reverseTrue) return filtered[:30]这套规则引擎的参数需要持续调优。我每个月会回顾一次“漏报”和“误报”。漏报是指那些最终被其他日报报道但我没选中的条目误报是指我选入候选但最终没进日报的条目。根据这些反馈调整关键词列表和权重系数。这个过程很繁琐但效果显著。三个月后我的初筛准确率从最初的60%提升到了85%以上。3.3 人工精选与点评的写作框架从20到30条候选里选出8到10条并逐条写点评是整个日报最核心的环节。我总结了一个“三问框架”每一条候选都要过这三问第一问这条新闻的本质是什么很多新闻的标题和实质是两回事。比如“某公司发布新模型”本质可能是“某公司在追赶竞争对手的某个能力”。写点评的第一步就是剥开标题找到实质。第二问它对谁有影响一条新闻可能对开发者有影响对投资人没影响或者对短期股价有影响对长期格局没影响。明确影响对象才能写出有针对性的点评。第三问我的判断是什么这是点评的灵魂。不是复述新闻而是给出一个明确的判断看好还是看衰重要还是不重要值得跟进还是可以忽略。判断可以错但不能没有。基于这三问我形成了一个固定的点评模板事实一句话 背景一句话 判断一句话。三句话不超过100字。这个模板强迫我提炼核心避免废话。实操心得写点评时我习惯先写判断再补事实和背景。因为判断是最难的先写判断能避免被事实带偏。如果一条新闻我写不出判断那说明它可能不值得入选。4. 实操过程与核心环节实现4.1 环境搭建与依赖安装整个系统的运行环境很简单一台最低配的云服务器1核1G内存就够。操作系统用Ubuntu 22.04Python版本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.shcollect.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, itemsitems) 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, timeout10) 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”后者打开率更高。那个小圆点让标题看起来更精致也更符合阅读习惯。这种细节看起来不起眼但日积月累对读者的阅读体验影响很大。
