1. 从一条速递说起AI资讯聚合到底在解决什么问题每天早上打开手机AI圈的信息就像开了闸的水龙头——某家发了新模型、某家更新了API定价、某个开源项目一夜之间冲上热榜、某篇论文提出的方法让某个老问题有了新解法。信息本身不稀缺稀缺的是筛选和消化信息的时间。我做AI资讯聚合这件事断断续续有两年多了从最早手动刷十几个信息源到后来写脚本抓取、做去重、做摘要再到形成一套相对固定的“速递”格式踩过的坑不算少。“衍辉AI速递”这个系列本质上是一个AI领域每日资讯的聚合与解读产品。它的核心工作流可以拆成三段信息采集、筛选排序、摘要加工。听起来简单但真正做起来每一段都有大量细节决定最终质量。比如信息采集环节你得知道哪些源值得盯、哪些源噪音大筛选排序环节你得有一套判断“什么算重要”的标准否则每天几十条更新你根本不知道该放哪十条摘要加工环节你得在几十个字里把一条资讯的核心讲清楚同时不丢失关键信息。这篇文章我会把这套东西完整拆开讲。适合谁看如果你也在做类似的信息聚合产品、或者想给自己团队做一份内部AI日报、又或者你只是好奇“那些每天发AI速递的账号到底怎么运作的”下面的内容应该都能给你一些可直接参考的东西。我不会只讲概念每个环节都会给出具体的操作方式、参数设置和我在实际运行中总结出来的经验。先说一下我对这类产品的基本判断AI资讯速递的价值不在于“快”而在于“筛”和“解”。快是新闻媒体的事但AI领域的很多信息是技术性的、需要背景知识才能判断价值的。一条“某模型发布”的消息对普通读者来说就是一句话但对从业者来说需要知道它的参数规模、训练数据、评测表现、API定价、和同类模型的对比——这些才是真正影响决策的信息。所以速递类产品的核心竞争力其实是在筛选和解读这两个环节上。2. 信息采集源的选择与抓取策略2.1 信息源的分类与优先级做AI资讯聚合第一步是确定信息源。我把信息源分成四类每类的抓取策略和优先级都不一样。第一类是官方发布渠道包括各大AI实验室的博客、官方公告页面、模型卡页面。这类源的特点是权威性最高、信息最准确但更新频率不固定有时候一周没动静有时候一天发好几条。对于这类源我的策略是全量抓取、不设阈值——只要是官方发的不管看起来重不重要都先收进来后面再筛。第二类是技术社区和论文平台比如arXiv、Papers with Code、Hugging Face的模型趋势榜。这类源的特点是量大、更新快但质量参差不齐。arXiv每天新增的AI相关论文少则几十篇多则上百篇你不可能全部看完。我的做法是设置关键词过滤加引用量阈值只抓取标题或摘要中包含特定关键词如模型架构、训练方法、评测基准等的论文同时结合社区的讨论热度做二次筛选。第三类是行业媒体和资讯平台这类源的好处是已经做过一轮筛选和加工坏处是可能存在信息延迟或偏差。我的策略是作为补充源不作为主要信息入口但用来交叉验证官方信息的解读角度。第四类是社交媒体和技术论坛这类源的价值在于“第一时间”和“真实反馈”。很多模型发布后的实际使用体验、bug反馈、性能对比最早都是在这类平台上出现的。但噪音也最大需要配合关键词监控和情感分析来提取有效信息。下面这张表是我目前使用的信息源分类和对应的抓取策略源类型代表平台抓取频率筛选策略优先级官方渠道各实验室博客、模型卡每小时全量收录最高技术社区arXiv、HF趋势榜每2小时关键词热度高行业媒体科技资讯站每4小时去重后收录中社交论坛技术讨论区实时监控热度情感中2.2 抓取工具选型与实操配置抓取环节我用的是Python技术栈核心是feedparser处理RSS源、requestsBeautifulSoup处理网页抓取、arxiv官方库处理论文数据。为什么不直接用现成的聚合服务因为现成服务通常不支持自定义筛选规则而且很多AI领域的专业判断需要你自己写逻辑。以arXiv抓取为例官方提供了Python库可以直接按分类和关键词检索。我用的配置大概是这样的import arxiv def fetch_arxiv_papers(keywords, max_results50): query OR .join([fabs:{kw} for kw in keywords]) search arxiv.Search( queryquery, max_resultsmax_results, sort_byarxiv.SortCriterion.SubmittedDate, sort_orderarxiv.SortOrder.Descending ) results [] for paper in search.results(): results.append({ title: paper.title, summary: paper.summary, published: paper.published, url: paper.entry_id, authors: [a.name for a in paper.authors] }) return results关键词列表需要根据当前AI领域的热点动态调整。比如最近一段时间我会重点关注“large language model”、“multimodal”、“reasoning”、“agent”这些方向。但关键词不能设太窄否则会漏掉一些跨领域的重要工作也不能太宽否则噪音太多。我的经验是保持15到25个核心关键词每两周根据实际抓取结果做一次调整。注意arXiv的API有频率限制建议每次请求间隔至少3秒否则会被临时封禁。我一开始没注意这个连续快速请求了十几次结果IP被限了半小时。对于官方博客的抓取很多实验室的博客没有提供RSS需要自己写解析规则。这里有个技巧优先找页面里的结构化数据。很多现代博客会在HTML里嵌入JSON-LD格式的元数据直接解析这个比解析HTML结构稳定得多因为页面改版时JSON-LD通常不会变。2.3 去重与增量更新机制信息采集里最容易被低估的环节是去重。同一条消息可能出现在多个源上比如一个模型发布官方博客有、arXiv有论文、技术社区有讨论、行业媒体有报道。如果不去重你的速递里就会出现多条内容重复的条目。我的去重策略分两层URL级去重和内容级去重。URL级去重比较简单维护一个已抓取URL的集合新抓到的URL如果在集合里就跳过。内容级去重复杂一些我用的是标题相似度加发布时间窗口的方式如果两条信息的标题相似度超过0.85且发布时间相差不超过6小时就判定为同一事件只保留优先级最高的那条。相似度计算我用的是简单的编辑距离加词袋模型没有上深度学习模型因为在这个场景下没必要——标题通常很短简单方法足够用而且速度更快。实际跑下来去重率大概在30%到40%之间也就是说每天抓到的原始信息里有三分之一左右是重复的。增量更新方面我用了一个简单的状态文件来记录每个源的最后抓取时间戳每次只抓取这个时间戳之后的新内容。这样既减少了请求量也避免了重复处理。3. 筛选与排序十条资讯是怎么选出来的3.1 重要性判断的五个维度从每天几十上百条原始信息里选出十条这是整个流程里最考验判断力的环节。我总结了一个五维度的评分体系每个维度1到5分加权求和后排序取前十。第一个维度是技术影响力。这条信息涉及的技术是否具有通用性是否可能影响多个方向比如一个新的模型架构如果只在特定任务上有效影响力就有限但如果是一个通用的训练方法改进那影响力就大得多。这个维度权重我设的是0.3。第二个维度是时效性。AI领域变化太快一条三天前的信息和一条三小时前的信息价值完全不同。时效性评分我按发布时间做衰减6小时内5分6到12小时4分12到24小时3分24到48小时2分超过48小时1分。权重0.2。第三个维度是来源权威性。官方发布和顶级会议论文的权威性最高行业媒体次之社交讨论再次之。权重0.2。第四个维度是社区热度。这条信息在技术社区里引发了多大规模的讨论我用的是评论数、转发数、引用数等指标的综合。权重0.15。第五个维度是实用性。这条信息对从业者的实际工作有没有直接帮助比如API降价、新工具发布、重要bug修复这些实用性就很高纯理论突破实用性相对低一些。权重0.15。实际跑下来这个评分体系能覆盖大部分情况但也有例外。有些信息虽然综合评分不高但属于“必须知道”的类型比如某个主流框架的重大版本更新。对于这类信息我会设置一个白名单机制特定来源或特定关键词的信息直接进入候选池不参与评分排序。3.2 排序算法的参数调优上面说的权重不是拍脑袋定的是我根据实际运行效果调了大概两个月才稳定下来的。一开始技术影响力权重设了0.4结果选出来的十条里有七八条都是论文普通读者根本看不懂。后来降到0.3同时提高了实用性的权重选出来的内容就均衡多了。时效性的衰减曲线也调过。最早用的是线性衰减24小时内从5分降到1分结果发现很多前一天下午发布的重要信息到第二天早上就已经降到2分以下了容易被漏掉。后来改成分段衰减前12小时降得慢12小时之后降得快这样既保证了新鲜度又不会让前一天的重要信息被完全埋没。还有一个细节是同源限制。如果某个来源在同一天有多条信息进入候选我会限制最多选两条避免整个速递被一家机构的消息占满。这个限制不是硬性的如果某天确实有多个重大发布可以放宽到三条。3.3 人工干预的边界虽然有一套自动评分体系但我一直保留人工干预的环节。每天早上我会花大概十五分钟快速过一遍自动选出的十条做三件事检查是否有明显遗漏、调整排序、补充背景信息。人工干预的边界很重要。我的原则是只做加减法不做大改。也就是说我可以把某条信息从第十位提到第三位或者把某条自动选入的信息拿掉换成候选池里的另一条但不会完全推翻自动排序的结果。这样做的好处是既保证了效率又保留了人的判断力在关键环节的作用。实操心得人工干预最容易犯的错误是“过度干预”。我有一段时间每天都要手动调整五六条结果发现调整后的效果并不比自动排序好反而花了很多时间。后来我把干预限制在最多两条效率和质量都提升了。4. 摘要加工把一条资讯讲清楚的最小字数4.1 摘要的结构化模板速递里的每一条资讯我用的都是一个固定的四段式结构发生了什么、关键细节、为什么重要、延伸阅读。这个结构看起来简单但实际写起来有很多讲究。“发生了什么”用一句话概括核心事件不超过30个字。比如“某实验室发布新一代多模态模型”或者“某开源项目更新至3.0版本”。这一句的要求是让读者在3秒内判断这条信息是否与自己相关。“关键细节”是摘要的主体用三到五句话展开。这里要回答的是具体是什么模型/工具/方法有什么核心参数或特性和之前的版本或同类产品相比有什么变化这部分的信息密度最高也是最容易写砸的地方。我的经验是每句话都必须包含一个具体信息点不能有废话。比如“该模型在多个基准测试上取得了领先成绩”这种话就是废话应该改成“该模型在MMLU上得分90.2比上一代提升3.1个百分点”。“为什么重要”是我认为最有价值的部分也是很多速递类产品缺失的。一条信息本身可能只是一个事实但它背后的意义是什么对哪些人、哪些工作会产生影响这部分不需要长一两句话点透就行但需要写作者对AI领域有足够的理解。“延伸阅读”放原文链接和相关背景材料的链接。这部分看起来简单但链接的选择也有讲究——优先放官方来源其次放高质量的解读不要放低质量的二手信息。4.2 信息压缩的取舍原则摘要的本质是信息压缩而压缩必然有取舍。我的取舍原则是保留可验证的事实舍弃主观评价保留具体数字舍弃模糊描述保留变化点舍弃背景铺垫。举个例子。假设原始信息是一篇关于新模型的论文里面有几十个实验数据、多个消融研究、详细的训练配置。摘要里不可能全部放进去我会优先保留模型的核心架构特点一句话、关键评测结果两到三个最重要的数字、与同类模型的对比如果有的话。训练配置、消融实验这些细节除非特别有创新性否则不放。另一个取舍是技术深度和可读性的平衡。速递的读者群体是混合的有资深研究者也有刚入门的从业者。我的做法是默认按中级水平写专业术语该用就用但第一次出现时用括号加一个简短解释。比如“该模型采用了MoE混合专家架构”这样不同背景的读者都能跟上。4.3 标题的写法与避坑每条资讯的标题我一般控制在20个字以内要求是包含主体和动作。好的标题比如“某实验室开源70B参数代码模型”读者一眼就知道是谁、做了什么、规模多大。差的标题比如“AI领域又一重大突破”说了等于没说。标题写作有几个坑我踩过。第一个是过度追求吸引力而牺牲准确性比如把“实验室发布技术报告”写成“实验室发布重磅模型”虽然吸引眼球但不够准确。第二个是术语堆砌把论文标题直接翻译过来又长又难懂。第三个是缺少关键信息比如只写“新模型发布”但不写是谁发布的、什么类型的模型。我现在写标题的流程是先写一个包含所有关键信息的版本然后逐步删减到20字以内删减时优先保留“谁”和“什么类型的东西”其次保留“规模”或“关键特性”。5. 常见问题与排查技巧实录5.1 抓取环节的典型故障做信息聚合抓取环节出问题是家常便饭。我整理了一个常见问题速查表覆盖了我遇到过的绝大部分情况问题现象可能原因排查方法解决方案某源连续多天无新内容页面改版或RSS失效手动访问源页面确认更新解析规则或更换源抓取内容出现乱码编码识别错误检查响应头Content-Type显式指定编码为utf-8请求被拒绝频率超限或IP被封查看返回状态码增加请求间隔、更换出口抓取到大量无关内容关键词过宽或解析错误抽样检查抓取结果收窄关键词、修正解析逻辑去重后仍有重复相似度阈值过高检查重复条目的标题差异降低阈值或增加发布时间判断其中最常见的是页面改版导致解析失败。我监控的源里大概每个月会有一两个改版。应对方法是为每个源写解析规则时尽量依赖稳定的结构特征比如特定的class名或data属性而不是依赖位置关系。同时加一个内容长度校验如果解析出来的内容长度突然变成0或者异常短就触发告警。另一个常见问题是时区处理。不同源发布的时间戳时区不一样有的用UTC有的用本地时间如果不统一处理排序就会乱。我的做法是所有时间戳在入库时统一转为UTC展示时再根据读者所在时区转换。5.2 筛选环节的判断偏差筛选环节最大的问题是判断偏差。我总结了几种常见的偏差类型热度偏差容易被社区讨论热度高的信息吸引忽略了一些讨论少但技术价值高的内容。应对方法是定期检查候选池里评分中等但未被选中的条目看看是否有被遗漏的重要信息。熟悉度偏差对自己熟悉的领域判断更准确对不熟悉的领域容易误判。比如我比较熟悉NLP方向对CV方向的判断就没那么准。应对方法是对不熟悉的领域设置更保守的筛选阈值宁可多选几条也不错漏。时效性偏差过于追求“新”导致一些发布稍早但仍有价值的信息被忽略。应对方法是对特定类型的信息如重要开源项目、深度技术分析放宽时效性要求。5.3 摘要写作的质量控制摘要写作的质量控制我主要靠自查清单。每写完一条摘要我会对照以下问题检查第一句话是否能让读者判断相关性是否包含了至少两个具体的事实或数字“为什么重要”部分是否提供了原文没有的视角是否有模糊表述如“显著提升”、“大幅改进”可以替换为具体数据专业术语是否都有必要的解释这个清单看起来简单但实际执行下来能过滤掉大部分质量问题。我一开始觉得自查很浪费时间但坚持了一段时间后发现自查花的两分钟比事后被读者指出错误再修改要划算得多。避坑技巧摘要里最容易出问题的是数字。我遇到过好几次把百分比写错、把参数规模写错的情况。后来养成了一个习惯所有数字在写完后都回原文核对一遍虽然麻烦但能避免低级错误。6. 工具链与自动化一个人怎么维护一个日更速递6.1 技术栈选型与理由整套系统的技术栈我选的是Python SQLite 静态站点生成。为什么不用更“现代”的方案比如Node.js加MongoDB因为在这个场景下简单可靠比技术先进更重要。Python的优势是生态成熟处理文本、调用API、做数据分析都有现成的库。SQLite的优势是零配置、单文件、足够快——我的数据量每天也就几百条SQLite完全够用不需要上PostgreSQL或MySQL。静态站点生成的优势是部署简单、访问快、不需要维护服务器。整个系统的运行流程是定时任务触发抓取脚本抓取结果存入SQLite筛选脚本从数据库读取数据并评分排序摘要生成后写入Markdown文件最后用静态站点生成器渲染成HTML页面。6.2 自动化调度的配置定时任务我用的是系统自带的cron配置很简单# 每小时抓取一次官方源 0 * * * * /usr/bin/python3 /path/to/fetch_official.py # 每2小时抓取一次技术社区 0 */2 * * * /usr/bin/python3 /path/to/fetch_community.py # 每天早上7点执行筛选和摘要生成 0 7 * * * /usr/bin/python3 /path/to/select_and_summarize.py # 每天早上7点30分生成静态页面 30 7 * * * /usr/bin/python3 /path/to/generate_site.py这个调度配置的关键是错开抓取和生成的时间。抓取是持续进行的但筛选和生成只在每天早上执行一次这样既保证了信息的及时性又避免了频繁生成页面带来的资源浪费。6.3 监控与告警机制自动化系统最怕的是“悄无声息地挂了”。我设置了三个监控点抓取量监控如果某个源连续两次抓取返回0条新内容触发告警。这通常意味着源出了问题。运行时间监控如果某个脚本的运行时间超过正常值的3倍触发告警。这通常意味着网络问题或数据处理逻辑出了异常。输出质量监控如果生成的速递条目少于8条或多于12条触发告警。这通常意味着筛选逻辑出了问题。告警方式我用的是邮件加即时消息通知。虽然简单但足够可靠。我试过用更复杂的监控系统但后来发现对于这种单人维护的项目简单的方案反而更不容易出问题。7. 内容运营的长期经验7.1 读者反馈的收集与利用速递做了两年多我最大的体会是读者的反馈比任何评分体系都更能反映内容的真实价值。我收集反馈的方式主要有三种直接回复、阅读完成率、链接点击率。直接回复是最直接的反馈读者会告诉你哪条资讯有用、哪条没用、哪里写错了。阅读完成率反映的是整体质量如果某天的完成率明显低于平均说明那天的内容可能有问题。链接点击率反映的是单条资讯的吸引力点击率高的条目通常说明读者对这个方向更感兴趣。这些反馈我会定期整理用来调整筛选权重和摘要写法。比如有一段时间读者反馈“为什么重要”部分写得太抽象我就调整了写法要求每一条的“为什么重要”都必须包含一个具体的应用场景或影响对象。7.2 内容风格的迭代速递的内容风格不是一开始就定下来的是经过多次迭代才稳定的。最早的版本偏“新闻播报”语气正式、信息密度低。后来改成“从业者视角”语气更直接、信息密度更高。再后来加入了“为什么重要”部分让内容更有深度。风格迭代的原则是跟着读者需求走。我做过一次小范围的读者调研发现大部分读者最看重的是“省时间”和“有判断”。省时间意味着摘要要短、要准有判断意味着不能只罗列事实要有分析和观点。现在的风格就是围绕这两个需求设计的。7.3 持续运行的挑战与应对日更最大的挑战是持续性和稳定性。偶尔做一期高质量的速递不难难的是每天都保持差不多的质量。我遇到过几次差点断更的情况一次是出差在外没带电脑一次是生病起不来还有一次是源大面积故障导致没有足够的内容可选。应对这些情况我做了几件事建立内容储备平时遇到特别重要的信息但当天没选上的存起来作为备用简化应急流程如果实在没时间做完整流程至少保证抓取和基本筛选能跑摘要可以简化但不能没有接受不完美偶尔一期质量差一点没关系重要的是不断更。个人体会做内容产品稳定输出比偶尔爆发更重要。读者养成阅读习惯需要时间但打破习惯只需要几次断更。我见过很多质量很高的速递账号就是因为更新不稳定慢慢没人看了。8. 从速递到知识库内容的二次利用速递的内容其实是一座金矿但如果不做二次整理这些信息就会随着时间流逝而失去价值。我最近在尝试的一个方向是把速递内容结构化建成一个可检索的知识库。具体做法是每条速递在入库时除了基本的标题、摘要、链接之外还打上多个标签——技术方向、模型类型、应用场景、相关机构等。这样积累一段时间后就可以按标签检索比如“所有关于多模态模型的资讯”或者“所有关于推理优化的资讯”。这个知识库的价值在于趋势分析。单条资讯看不出什么但把时间拉长到几个月就能看出某些方向的讨论在增加、某些方向在降温。这种趋势判断对做技术规划很有参考价值。另一个二次利用的方向是专题整理。比如某个方向积累了几十条相关资讯后可以整理成一篇综述性的文章把分散的信息串联起来。这种专题文章的价值比单条速递高得多因为它提供了完整的脉络和上下文。目前这个知识库还在建设中数据量还不够大但已经能看到一些有意思的模式了。比如我注意到关于模型效率优化的资讯在过去几个月明显增多而关于纯规模扩展的资讯在减少。这种变化单看某一天是看不出来的只有把数据积累起来才能发现。9. 一些零散但有用的经验最后分享几个零散的经验点都是实际运行中总结出来的不一定系统但应该有用。关于信息源的维护定期检查信息源的质量我一般每个月做一次。检查的内容包括这个源最近一个月贡献了多少条被选中的资讯如果连续一个月没有贡献考虑降级或移除。同时也要关注新的源AI领域变化快新的高质量信息源不断出现。关于摘要的长度我试过不同的摘要长度最后稳定在每条150到250字之间。太短了信息量不够太长了读者没耐心看完。这个长度大概能容纳三到五个信息点足够把一件事说清楚。关于发布时间的测试我试过不同的发布时间最后发现早上7点到8点之间发布的效果最好。这个时间段读者通常在通勤或刚到办公室有时间浏览信息。太早了读者还没醒太晚了已经被其他信息淹没了。关于错误处理速递里出现错误是难免的关键是怎么处理。我的原则是发现错误立即更正并在下一期里说明。不要试图掩盖错误读者比你想象的更细心。坦诚更正反而能增加信任。关于工具的选择不要追求“最好的工具”要追求“最合适的工具”。我用过很多花哨的工具和框架最后发现最常用的还是那几个最基础的。工具的目的是解决问题不是炫技。关于内容的边界速递的内容范围要清晰。我最早什么都放结果内容太杂读者不知道这个速递到底是关注什么的。后来收窄到“AI模型、工具、方法”三个方向内容聚焦了读者群体也更明确了。关于更新的节奏日更听起来很厉害但实际做起来压力很大。如果精力有限周更但每期质量高比日更但质量参差要好。我见过一些周更的速递质量比日更的高很多读者忠诚度也更高。关于数据的备份这个听起来很基础但很重要。我有一次服务器出问题差点丢了一个月的数据。后来设置了自动备份每天凌晨把数据库和生成的内容打包备份到另一个位置。虽然多花了一点存储成本但安心很多。关于读者的沟通不要害怕和读者沟通。我最早觉得读者反馈是挑刺后来发现大部分反馈都是善意的、有帮助的。而且和读者沟通多了你会更清楚他们真正需要什么做出来的内容也更有针对性。关于长期规划速递做久了容易陷入“为了更新而更新”的状态。我每隔几个月会停下来想一想这个速递的长期价值是什么是帮读者省时间是提供判断依据还是建立知识库想清楚这个问题才能决定下一步往哪个方向走。
