1. 一份AI日报的诞生逻辑每天早上八点半我习惯性打开自己搭建的AI日报聚合面板扫一眼过去24小时里全球AI圈发生了什么。这个习惯坚持了快两年从最开始手动刷十几个信息源到后来写脚本自动抓取、去重、分类、摘要再到如今形成一套相对稳定的日报生产流程——今天这篇就把这套东西完整拆开讲一遍。所谓“AI日报”本质上是一份信息密度极高的行业动态摘要它要解决的核心问题是在AI领域每天产生海量论文、产品更新、开源项目、融资消息、政策动向的情况下如何用最短时间让读者抓住真正重要的那几条。适合谁来参考三类人一是想持续跟踪AI行业但没时间逐条刷信息的从业者二是想搭建自己信息聚合系统的开发者三是做内容运营、需要快速产出行业简报的团队。我做的这份日报每天覆盖大约15到25条精选条目分五个固定板块模型与论文、产品与工具、开源与社区、行业与资本、值得一读的深度内容。每条包含一句话摘要、来源链接、以及我自己的简短点评。整份日报从抓取到发布全流程自动化程度大概在80%左右剩下20%是人工筛选和点评——这部分恰恰是最有价值的。下面我从整体设计思路开始把每个环节的考量、踩过的坑、以及可以直接抄作业的配置都讲清楚。2. 整体架构设计与信息源选型2.1 为什么选择“聚合人工筛选”而不是纯自动最开始我试过纯自动方案爬虫抓取→NLP摘要→直接生成日报。跑了大概两周就放弃了。问题出在三个地方第一AI领域大量信息是重复报道同一篇论文被十几个媒体转述纯自动去重很难判断哪些是同一事件的不同角度第二重要性判断需要行业背景知识一个开源项目star数暴涨和一个大模型发布哪个更值得放头条算法很难给出符合人类直觉的排序第三摘要质量参差不齐很多自动摘要把关键数字和结论丢掉了。所以最终方案是机器负责“广撒网”和“初筛”人负责“精挑”和“点评”。具体分工是这样的——抓取层定时任务从RSS、API、网页抓取原始内容清洗层去重、去广告、提取正文、统一时间格式初筛层基于关键词权重和来源可信度打分筛掉明显不相关的人工层我每天早上花20到30分钟过一遍候选列表选出15到25条写点评发布层渲染成Markdown或HTML推送到目标渠道这个架构的好处是机器处理了90%的脏活累活人只做最有价值的判断。而且随着时间推移我可以不断调整初筛规则让候选列表越来越精准。2.2 信息源的分层管理信息源是整个日报的命脉。我目前维护着大约40个信息源分成四个层级第一层一手信源权重最高各大AI实验室的官方博客和公告页顶级会议NeurIPS、ICML、ICLR等的论文列表页主流开源社区的trending页面几个核心预印本平台的每日新论文列表第二层高质量媒体权重中高专注AI领域的垂直媒体科技大媒体的AI频道几个我信任的行业分析师的个人博客第三层社区信号权重中等用于发现热点技术社区的热榜社交平台上AI相关的高互动帖子几个活跃的行业群组讨论第四层补充信源权重低用于交叉验证综合科技媒体的AI板块行业报告和调研机构的公开摘要提示信息源不是越多越好。我一开始加了上百个源结果每天候选列表超过500条根本看不过来。后来砍到40个左右反而覆盖率更高——因为很多源内容高度重叠留最权威的那个就够了。每个源我都配置了三个参数抓取频率高频源每小时一次低频源每天一次、可信度权重1到10分影响初筛排序、内容类型标签论文/产品/融资/观点等用于分类。这套配置存在一个YAML文件里改起来很方便。2.3 去重策略的设计去重是聚合系统里最容易被低估的环节。AI领域的信息重复率极高一条重要消息可能在几小时内被几十个源报道。如果不去重日报会变成同一件事的复读机。我的去重分三层第一层URL精确去重。最简单直接比对链接。但只能处理完全相同的链接对于同一事件的不同报道无能为力。第二层标题相似度去重。用编辑距离或余弦相似度计算标题之间的相似程度超过阈值我设的是0.75就判定为同一事件。这一层能处理大部分媒体转述的情况。第三层实体时间窗口去重。提取标题和摘要中的关键实体模型名、公司名、人名、产品名如果两个条目在同一个时间窗口比如6小时内包含相同的核心实体组合就判定为同一事件。这一层能处理标题写法差异很大的情况。三层去重跑下来500条原始内容通常能压缩到80到120条候选效果还是很明显的。不过要注意去重阈值不能设得太激进否则会把相关但不同的事件误合并。我踩过一次坑把两个不同团队在同一天发布的不同模型误判为同一事件结果日报漏掉了一条重要消息。后来把阈值调保守了一些宁可多留几条人工判断也不轻易合并。3. 核心环节的实操细节3.1 抓取层的实现要点抓取层我用的是Python核心依赖就几个feedparser处理RSSrequestsBeautifulSoup处理网页httpx做异步请求。没有用重型框架因为需求不复杂轻量方案更好维护。RSS源的处理最直接feedparser几行代码就能搞定。但要注意两个坑一是时间格式不统一不同源的发布时间格式五花八门需要统一转换成ISO 8601格式再做后续处理二是部分RSS只给摘要不给全文需要额外请求原文页面提取正文。网页抓取要复杂一些。我的原则是能用API就不用网页抓取能用RSS就不用网页抓取实在没有前两者才写针对性的爬虫。因为网页结构随时可能变维护成本很高。对于必须抓取的页面我会写一个配置化的解析规则把CSS选择器存在配置文件里页面改版时只需要改配置不用改代码。# 抓取层核心逻辑示意 import feedparser import httpx from datetime import datetime async def fetch_rss(url: str, source_config: dict) - list: 抓取RSS源并标准化输出 feed feedparser.parse(url) items [] for entry in feed.entries: items.append({ title: entry.get(title, ).strip(), link: entry.get(link, ), summary: entry.get(summary, ), published: parse_time(entry.get(published, )), source: source_config[name], weight: source_config[weight], category: source_config.get(category, general), }) return items def parse_time(raw: str) - str: 统一时间格式失败则返回当前时间 formats [ %a, %d %b %Y %H:%M:%S %z, %Y-%m-%dT%H:%M:%S%z, %Y-%m-%d %H:%M:%S, ] for fmt in formats: try: return datetime.strptime(raw, fmt).isoformat() except (ValueError, TypeError): continue return datetime.now().isoformat()抓取频率的控制也很重要。我用的方案是分级调度高频源每30分钟抓一次中频源每2小时低频源每天一次。所有抓取任务通过一个调度器管理避免同时发起太多请求。另外一定要设置请求间隔和超时我一般设3到5秒间隔、10秒超时既不会给目标站点造成压力也能保证抓取成功率。3.2 初筛打分的参数设计初筛打分是整个系统里最需要调参的环节。我的打分公式大致是这样的总分 来源权重 × 0.4 关键词得分 × 0.35 时效性得分 × 0.15 互动信号 × 0.1来源权重就是前面说的1到10分。关键词得分基于一个我维护的关键词表分三档核心关键词如具体模型名、重要技术术语加3分重要关键词如“发布”“开源”“融资”加2分一般关键词加1分。时效性得分按发布时间线性衰减24小时内的内容得分最高。互动信号主要看社区讨论的热度比如评论数、转发数等。这套参数不是拍脑袋定的是我根据大概两个月的实际筛选记录反推出来的。具体做法是每天记录我最终选了哪些条目、放弃了哪些条目然后定期回顾看看被放弃的条目里有没有打分很高但被我忽略的以及被打分很低但我手动捞回来的。根据这些反馈调整权重。注意关键词表需要定期更新。AI领域新词层出不穷上个月还不存在的模型名这个月可能就成了核心关键词。我一般每周花10分钟过一遍候选列表里的高频新词把有价值的加进关键词表。3.3 人工筛选的判断标准机器筛完之后剩下的80到120条候选需要人工过一遍。这个过程我总结了几个判断标准按优先级排列第一优先级是否改变了某个重要的事实。比如某个模型的能力边界被刷新了、某个重要项目开源了、某个关键人物有重大动向。这类信息无论来源权重高低都值得收录。第二优先级是否提供了新的视角或数据。有些内容本身不是新闻但提供了有价值的分析框架或独家数据比如一份深入的行业调研、一个有意思的实验结果。第三优先级是否具有实操参考价值。比如新的工具、新的教程、新的最佳实践读者看完能直接上手用的。第四优先级是否反映了某种趋势。单条信息可能不重要但多条信息放在一起能看出方向性变化这类也值得收录并加点评。反过来以下几类内容我一般会跳过纯公关稿、没有实质内容的观点输出、重复报道且没有新增信息、标题党、以及明显是营销内容的条目。3.4 点评撰写的经验每条日报条目我都会加一句自己的点评这是整份日报区别于普通聚合页的核心价值。点评不需要长一两句话就够但要做到以下几点说清楚为什么这条值得关注而不是复述内容如果有背景信息补充一句帮助读者理解上下文如果有实操建议直接给出来比如“这个工具我试过XX场景下比XX好用”保持克制不确定的事情不要下结论用“可能”“值得观察”这类措辞写点评最忌讳的是空洞。比如“这个模型很强”就是废话“这个模型在XX基准上比前代提升了XX%但实际使用中XX场景下提升不明显”才是有信息量的点评。我一般会要求自己每条点评至少包含一个具体的信息点。4. 常见问题与排查技巧4.1 抓取失败怎么办抓取失败是家常便饭原因五花八门。我整理了一个排查顺序按这个顺序走基本能定位到问题现象可能原因排查方法解决方案全部源抓取失败网络问题或调度器挂了检查调度器日志、手动请求一个源重启调度器、检查网络配置单个源持续失败源站改版或封禁手动访问源站看是否正常更新解析规则、降低抓取频率间歇性失败请求超时或限流查看失败时间分布增加超时时间、加请求间隔抓取成功但内容为空解析规则失效检查返回的HTML结构更新CSS选择器时间格式解析失败源站改了时间格式查看原始时间字符串在parse_time里加新格式我踩过最坑的一次是某个重要源突然开始返回JavaScript渲染的页面requests抓到的全是空壳。后来加了playwright做兜底对于检测到内容为空的页面自动用浏览器渲染再抓一次。虽然慢一些但至少不会漏掉重要信息。4.2 去重误判怎么处理去重误判分两种漏合并同一事件被当成两条和过度合并不同事件被当成一条。漏合并的问题相对小大不了日报里出现两条相关条目读者也能理解。过度合并就严重了会直接导致信息丢失。我的处理策略是宁可漏合并不可过度合并。具体做法是把去重阈值设得保守一些同时在人工筛选环节加一道检查——如果发现两条候选内容相关但被判定为不同事件手动合并如果发现某条候选明显是另一条的重复手动删除。另外我会定期回顾去重日志看看哪些条目被合并了、哪些没有。如果发现某类事件经常被误合并就调整对应的规则。比如有一段时间两个不同团队在同一天发布模型更新因为标题里都包含“模型更新”这个短语被误判为同一事件。后来我在实体提取里加了团队名的权重这个问题就解决了。4.3 日报质量波动的应对日报质量不可能每天都一样。有些日子AI圈确实没什么大事硬凑15条只会稀释质量。我的做法是设定弹性区间最少10条最多25条根据当天实际情况调整。如果某天确实没什么重要消息就少发几条但在开头说明“今日信息量较少”。反过来如果某天大事特别多就多发几条但每条保持精简。另一个质量波动来源是我自己的状态。有时候早上时间紧筛选和点评会比较仓促。后来我养成了一个习惯前一天晚上先把候选列表过一遍把明显要选的标出来第二天早上只需要确认和写点评效率高很多。4.4 几个独家避坑技巧技巧一给每个源加“健康检查”。我写了一个简单的脚本每天检查每个源最近一次成功抓取的时间。如果超过预期频率的3倍还没成功就发提醒。这样能在源出问题的早期就发现而不是等到日报缺内容才察觉。技巧二保留原始内容快照。抓取到的原始内容我会存一份到本地保留30天。这样做的好处是如果后来发现某条信息有误或者需要补充可以回溯原始内容。另外如果某个源的内容后来被删了我本地还有备份。技巧三用“周回顾”代替“日纠结”。不要纠结某一天日报的完美程度把视角拉到一周。每周花半小时回顾这一周的日报看看有没有系统性遗漏、有没有重复出现的问题、关键词表需不需要更新。周回顾比日纠结有效得多。技巧四点评模板化开头。写点评最耗时的不是思考内容而是组织语言。我总结了几个常用的点评开头句式比如“这条值得关注是因为……”“背景是……”“实操层面……”需要的时候直接套能省不少时间。当然不能每篇都用同一个句式要轮换着来。5. 工具链与自动化配置5.1 核心工具选型整套系统用到的工具不多但每个都是经过比较后选的调度APScheduler轻量、Python原生、支持cron表达式够用抓取feedparserhttpxBeautifulSoup覆盖RSS和静态网页兜底渲染playwright处理JS渲染页面存储SQLite单文件、零配置、够用数据量大了再考虑迁移去重rapidfuzz做标题相似度自己写的实体提取逻辑输出Jinja2模板渲染Markdown没有用数据库服务器、没有用消息队列、没有用容器编排。不是这些技术不好而是这个场景下没必要。一个人维护的系统越简单越好。我见过不少人一上来就上重型架构结果光维护基础设施就耗掉大半精力真正核心的筛选和点评反而没时间做。5.2 自动化流程的配置整个流程通过一个主脚本串联用APScheduler定时触发。核心配置如下# config.yaml 核心配置示意 schedule: high_freq: */30 * * * * # 每30分钟 mid_freq: 0 */2 * * * # 每2小时 low_freq: 0 6 * * * # 每天早上6点 daily_report: 0 7 * * * # 每天早上7点生成日报 dedup: title_similarity_threshold: 0.75 entity_window_hours: 6 url_exact: true scoring: source_weight: 0.4 keyword_score: 0.35 freshness: 0.15 engagement: 0.1 output: min_items: 10 max_items: 25 format: markdown sections: - 模型与论文 - 产品与工具 - 开源与社区 - 行业与资本 - 深度阅读这个配置文件是我整个系统的核心所有可调参数都在这里。改参数不用改代码重启一下调度器就生效。5.3 输出模板的设计日报的输出模板我改过很多版。最开始是简单的列表后来加了板块分类再后来加了点评最后形成了现在的结构。每个板块的条目格式是统一的### [条目标题] **来源**来源名称 | **时间**X小时前 **摘要**一句话说清楚发生了什么 **点评**我的简短分析或建议这个格式的好处是信息层次清晰读者扫一眼就能抓住重点。摘要控制在一句话以内逼着自己提炼核心信息。点评控制在两句话以内避免啰嗦。模板用Jinja2渲染这样格式调整只需要改模板文件不用动生成逻辑。我一般每个月会微调一次模板根据读者反馈优化排版。6. 内容运营与读者反馈6.1 发布渠道的选择日报做出来得有人看。我试过几个渠道各有优劣邮件列表到达率高适合深度读者但打开率在下降即时通讯群组传播快互动强但信息容易被淹没内容平台有推荐流量但格式限制多个人站点完全可控但需要自己引流我目前的策略是以个人站点为主邮件列表为辅即时通讯群组做分发。个人站点是内容的家所有历史日报都能查到邮件列表触达核心读者群组用来做即时讨论和反馈收集。6.2 读者反馈的收集与利用读者反馈是改进日报的重要依据。我主要通过三个渠道收集邮件回复、群组讨论、以及一个简单的反馈表单。反馈内容我一般分三类处理内容建议类比如“希望增加XX板块”“XX类信息太多了”这类反馈我会认真考虑但不会立刻改而是观察一段时间看是不是普遍需求。纠错类比如“XX条目的信息有误”“链接打不开”这类反馈优先级最高确认后立刻修正并在下期日报里说明。鼓励类比如“这个日报帮我省了很多时间”这类反馈虽然不直接指导改进但能让我知道哪些做法是对的值得坚持。6.3 持续运营的心得做日报最难的不是技术是坚持。每天雷打不动地筛选、点评、发布时间长了很容易倦怠。我总结了几条让自己坚持下去的经验第一降低单日负担。不要把日报做成一个大工程。我的目标是每天总投入不超过1小时其中机器自动跑的部分占大头人工部分控制在30分钟以内。负担轻了才容易坚持。第二允许不完美。有些日子就是没什么好内容那就少发几条。有些日子点评写得不够精彩那也没关系。日报是长期工程单日质量波动不重要重要的是持续输出。第三从反馈中获取动力。每次收到读者说“这个日报对我有帮助”都是继续做下去的动力。我会把这些反馈存下来倦怠的时候翻一翻。第四定期迭代。不要一直用同一套流程。每隔一段时间回顾一下看看哪里可以优化、哪里可以简化。迭代本身也是一种乐趣。提示如果你也想做自己的AI日报建议从最小可行版本开始——先手动做一周感受一下工作量和内容偏好然后再逐步自动化。不要一上来就搭复杂系统那样很容易在技术细节里迷失忘了做日报的初衷是提供有价值的信息。