每天早晨打开手机几十个订阅号、十几个网页、好几个群里的转发链接这种信息轰炸相信不少人都经历过。我大概在三周前做了个决定与其被新闻追着跑不如让机器替我盯。这个项目的核心很简单——把采集新闻、AI摘要、定时推送到群里整条链路自动化做一个真正的自动化新闻推送机器人。我给自己定了五天的观察周期从第一天的骨架搭建到第五天的效果复盘中间踩了不少坑也验证了一些想法。这套东西到底能做什么简单说它把过去打开十几个网站→筛选重要内容→阅读全文→决定要不要转发的完整动作压缩成了扫一眼机器人推送的摘要点开有兴趣的原文。连续观察五日之后我对自动化的边界、AI摘要的可靠性、推送频率的度都有了更具体的判断。这篇博文就不绕弯了把我这五天的完整记录、技术方案、翻车经历和最终数据都摊开来说给同样被信息过载困扰的读者也打算把AI和机器人技术用到新闻信息处理上的开发者做个参考。1. 为什么会想到做AI盯新闻这件事1.1 信息过载背后的真实成本先说个扎心的事实我大概统计过自己在信息获取上的时间分配。每天花在看新闻上的时间平均要一个半到两个小时但真正有价值、值得深读并可能会影响决策的内容往往不超过五条。大量时间浪费在重复内容、标题党、以及早就看过的旧闻上。更有意思的是即使花了这么多时间还是会出现重要新闻从身边漏过去的焦虑。这其实是典型的筛选焦虑——信息本身不缺缺的是可靠的筛选机制。市面上的新闻聚合App很多但推荐算法是黑盒它认为重要的不一定是我关心的而且我关注的某些垂直领域通用平台覆盖得很浅。所以我想要的其实是一个自己能掌控规则的筛选系统明确关注哪些信源、按什么标准过滤、几点推送、推多少条。这个需求用常规App很难满足但用自动化脚本加AI能力完全可以自己搭一套。1.2 自动化管道的三个核心任务这套系统拆到底就三件事采集、摘要、触达。采集要解决信息从哪来的问题。我采用的是RSS为主、定时爬虫为辅的方案。RSS是成熟且对源站点友好的协议能拿到结构化的标题和正文但对于部分没有RSS、或者RSS输出不完整的站点再补几个定向爬虫。这里要特别注意爬虫必须遵守目标站点的robots协议控制请求频率我是强制设了单站点请求间隔不低于30秒跑了一周没有触发任何反爬机制。摘要要解决信息太长怎么办的问题。拿到全文之后调用大语言模型接口生成摘要。这里的关键不是简单地丢一段文本让模型总结而是通过Prompt控制摘要的风格、长度和结构。后面我会专门讲讲怎么调这个Prompt它直接决定了推送内容有没有人看。触达要解决推送送到哪里的问题。我选择了IM群机器人的Webhook方式把摘要、原文链接、发布时间打包成一条结构化消息推到群里。为什么选IM而不是邮件因为IM的打开率高、延迟低、支持富文本卡片而且在手机上点一下就能跳转到原文。实际测试下来IM推送的点击率比邮件高出一个数量级。1.3 为什么把观察周期定为五天自动化推送系统上线后不能只看一天的运行状态。一天的数据太少可能系统跑了几个小时就崩了也可能因为当天新闻很少导致判断失误。定五天是因为这个周期能覆盖工作日和周末的不同场景能观察到人们打开推送的时段差异也能给系统留出跑稳定之后暴露真实问题的时间。我原本以为第一天就能让系统稳定运行实际发现完全不是这么回事。第一天接口就限流了第二天摘要出现幻觉第三天推送时段出了问题第四天压缩摘要质量时反复调试到第五天才敢说它基本能独立运转。这五天里系统每天都变了个样这种快速迭代的节奏本身就是观察自动化系统最有价值的部分。2. 技术底座选型三件事必须同时想清楚2.1 内容源RSS优先定爬虫兜底内容源是整个系统的起点源选不好后面的AI和推送都是白搭。我的选源原则有三条第一优先选择官方RSS源因为它稳定、格式规范、信息结构完整第二对于圈内公认重要但缺少RSS的站点用定向爬虫补充第三所有内容源在进入系统前都要过一遍质量打分主要看更新频率和内容相关性。具体落地时我用了一个自建RSS聚合器把二十多个信源的输出统一解析成同一种数据格式。每个条目包含标题、链接、发布时间、作者、正文全文。这里有个细节容易被忽略很多RSS源只输出文章开头几行摘要正文是全的但HTML格式很乱直接丢给大模型会浪费Token而且效果差。我是先做了正文清洗把标签、脚本、样式全部剥掉只保留纯文本再按段落拆分成结构清晰的内容块。对于爬虫部分我只保留了三个必需的定向源用一个Python脚本定时抓取。脚本很简单核心就几十行发起请求、解析HTML、提取正文、更新时间入库。但需要注意抓取逻辑必须做异常容忍——网络超时、页面改版、字段缺失任何一种异常都不能让整个爬虫崩掉我用的是单源失败不影响其他源的逐源隔离设计每个源的错误单独记进日志。2.2 AI摘要Prompt设计决定推送的生死这一步是整个系统中最重要、也最容易被低估的环节。很多人以为所谓AI摘要就是把这篇文章总结一下我第一天也是这么干的效果非常糟糕——模型输出的摘要内容泛泛而谈缺乏重点甚至偶尔会编造原文没有的信息。后来我把Prompt调整成了结构化指令核心要求有四点第一摘要不能超过120字第二只可基于原文信息改写禁止补充任何背景知识或推测第三优先提取涉及数字、结论、政策变化、产品发布这类硬信息第四如果原文包含明显的观点要用原文的立场不带模型自身态度。这里分享一个很关键的技巧可以在Prompt里要求模型先输出文章类型判断再基于判断生成摘要。比如判断出这是一篇产品评测和这是一篇突发新闻摘要的侧重点应该完全不同——前者要讲体验结论后者要讲事件要素谁、何时、何地、何事、何果。模型在做了类型判断之后生成的摘要质量明显上了一个台阶。另外Temperature参数也很有讲究。我最终设到了0.2低温度让输出更稳定也减少了模型自由发挥的空间。如果你也做类似需求建议不要超过0.5温度越高摘要越容易跑偏成自己的评论。2.3 推送通道IM群机器人是最合适的触达方式触达这一步我对比过邮件、IM群机器人、自建Web页面三种方案。邮件的问题在于打开率不可控而且推送量一旦多了就容易被归入垃圾箱自建Web页面等于让用户主动来访问违背了推送的初衷。IM群机器人是唯一满足主动触达、延迟低、富文本支持、可点链接四个条件的方案。实际我用了IM群机器人的Webhook接口把摘要、标题、原文链接、发布时间做成一个结构化文本块推送到群里。格式上花了一点心思标题加粗摘要正文控制在四到五行原文链接单独放一行时间戳放在最后。目的只有一个——让用户在群里扫一眼就能决定要不要点进去。这里必须提一个安全细节Webhook地址等于群的管理权限泄露出去任何人都可以往群里发消息。所以我把它存在本地的配置文件中不进代码仓库并且在脚本里做了环境变量引用而不是硬编码。这个习惯不只适用于这个项目所有涉及Token、密钥的场景都应该这么做。3. 五日实战记录从翻车到稳定每天都有一课3.1 Day 1骨架跑通但接口限流给了个下马威第一天我搭的是最小可用版本定时任务每30分钟抓一次RSS发现新条目就调用大模型接口生成摘要然后推送到群里。看着逻辑简单真跑起来才发现问题。最大的坑是接口限流。我用的模型接口并发上限比较低第一天上午因为一次性积压了前一天的几十条旧闻脚本用多线程并发调用直接把限流触发了后续请求全部返回异常。结果就是第一天上午的推送断断续续有的新闻推了摘要有的只推了个标题连摘要都没生成。这次翻车的教训很明确调用外部接口必须做速率控制和队列不能无脑并发。我立刻把调用的方式改成了单线程队列每条请求之间强制间隔0.5秒同时对失败的请求做指数退避重试最多重试三次。改完之后同样的条数推送时间从几分钟拉长到了二十多分钟但系统稳定了再也没有中途断过。另外我还在第一天末尾把历史条目跳过逻辑写上了。用数据库记录下已经处理过的条目标识重启脚本之后不会重复推送。这个逻辑看起来不起眼但后续五天里避免了大量重复内容——尤其在手动重启调试的时候如果没有它同一个新闻会被反复推到群里。3.2 Day 2标题党过滤与摘要幻觉的第一轮修正第二天的新闻量正常起来我才开始真正审视推送质量。最明显的问题是某些标题极其夸张的娱乐类新闻系统也照推不误更麻烦的是有一个摘要里居然出现了一句原文完全没有的结论这在行业媒体里是个大忌。先处理标题党。我不打算用复杂的语义模型直接用规则匹配出现了震惊万万没想到不点后悔紧急通知删前速看这类高频标题党词汇直接降级为低优先级不予推送。规则能覆盖大部分常见标题党剩余漏网的靠摘要模型判断内容质量。再处理摘要幻觉。所谓幻觉就是模型在生成摘要时编造了原文没有的信息。这次是某篇关于存储芯片价格波动的行业分析模型在摘要里加了句业内预计下季度将出现供应短缺这句在原文根本没有依据。解决办法是修改Prompt在要求前面加上一句如果原文没有明确提到的东西一律不允许出现在摘要中并且把此次修复后Temperature降到0.2。这轮修正的直接收获是当天下午开始的推送摘要言之有物且言不由衷的现象基本消失。我开始意识到系统参数和Prompt调优不是上线前一次做好的而是要在真实数据下持续迭代。3.3 Day 3固定时段推送验证打开率的真实差异前两天的推送是全天随来随推到第三天我发现一个尴尬的问题群里的消息数量很多但高频推送让大部分人干脆把群置顶消息提醒关了。这让我意识到推送频率和推送时段和内容质量同样重要。我做了一件事把整天的推送全部停下来重新设计了时间段窗口。设定三个推送批次早间8点推送前夜到早晨的精选内容午间12点推送上午的内容晚间18点半推送下午的内容。每个批次控制在三到五条其余时间系统只采集、不推送。这个调整的效果非常明显。从第三天的晚上开始群里反馈明显减少刷屏的抱怨从点击情况来看晚间时段的原文打开率最高早间次之午间最低。这其实符合大多数人的时间规律早上刚睁眼还没进入工作状态晚上下班后有整块时间阅读午间都在忙扫一眼标题就不错了。这里有个值得分享的小细节周末的推送时段和工作日不能共用一套配置。我第四天增加了按星期判断的逻辑周末把早间批次删掉只保留上午十点和晚间两个窗口。数据虽然只观察了两天但趋势已经说明问题——休息日没几个人愿意早八点被工作群里的新闻吵醒。3.4 Day 4让AI学会压缩摘要从300字降到80字到第四天摘要的质量基本稳定了但新的问题浮出来模型生成的摘要普遍偏长平均每条在250到300字之间。群消息卡片里满满一大段文字阅读成本还是很高有的用户看了前两行就不想继续了。我重新设计了摘要的压缩策略把完整摘要和一句话快讯分开。群推送的主体只保留一句话快讯控制在80字以内让人用五秒判断值不值得点原文页面保持不变点进去之后继续由AI生成完整摘要供快速阅读。实现上不算复杂改Prompt就行。我让模型先输出一个不超过30字的一句话概括再输出不超过150字的要点摘要。实际测试后发现一句话概括往往到了40字左右但已经比之前的一大段精炼得多。我把推送卡片改成了标题加粗 一句话概括 原文链接。这个版本从第四天下午开始推送直观感受是群里消息清爽了点开原文的比例也明显提升。压缩摘要这个动作其实是整个项目里体验提升最大的一次改动。它让我意识到自动化推送的成败不完全取决于技术更大程度上取决于你在替用户节省多少阅读成本。3.5 Day 5封板复盘漏推、重推、错推都在哪里第五天不再追求新功能专门做数据检查和问题排查。我翻了一遍五天的推送记录把出过的问题归纳成三类漏推、重推、错推。漏推的主要原因是RSS源本身不稳定。某个技术博客源在第二天下午突然停止更新输出自建聚合器拉不到新内容系统自然无米下锅。这个问题靠改代码解决不了只能加监控如果某个源连续六小时没有输出机器人发一条告警通知我人工检查。重推主要出现在第三天之前原因是重启脚本时历史记录的比对字段选择不当重复推送了同一篇文章的两个版本。我把比对逻辑改成链接去重也就是用URL做唯一标识问题彻底解决。错推的情况相对少但有一例挺典型一个不算知名的三线科技自媒体发布了一篇完全复制转载的新闻稿内容和其他源高度重复AI摘要生成后推送了出来。这个问题的根源是内容源质量参差单靠规则无法完全规避。我目前的方案是给每个信源设了权重热门权威源权重高转载频发的源权重低同类新闻优先推送权重高的源低权重的重复内容自动丢弃。封板复盘的结果让我挺意外五天跑下来真正需要人工处理的异常只有三处而且每一处都对应着一类可以提前预判的系统缺陷。这大概就是以小步快跑的方式搭建自动化系统的魅力——小规模观察快速纠正比一开始追求大而全的架构要高效得多。4. 数据复盘准确、时效、可读三个维度的权衡4.1 五天观察期的核心数据汇总先把关键数字摆出来。五天下来系统累计采集原始信息条目三百余条经过标题党过滤和内容源权重排序后实际推送的条数是六十三条占比在20%左右。这六十三条推送里原文打开率平均在38%左右晚间批次的打开率明显高到了50%左右早间和午间分别落在35%和25%上下。模型摘要的可靠性方面我做了人工抽检抽取其中二十条摘要逐字核对原文发现严重信息偏差的只有一条大概5%的误差率。虽然这个数字跟样本量小有关但对于一个辅助筛选目的的推送机器人来说完全可以接受。值得单独说的是推送带宽。五天内群消息总量是六十三条平均每天十三条左右分布在两个时段没有任何一天出现刷屏式推送。这个密度维持了群内成员的阅读兴致也侧面验证了三到五条每批的推送量是比较合理的区间。4.2 摘要质量与人工校对成本的博弈看数据的时候我一直在想一个问题摘要质量做到什么程度才够如果追求百分之百准确每天需要人工逐条核对全部推送那这个自动化系统相比手动转发的效率优势就荡然无存。我个人认为把摘要准确率目标定在95%左右是合理的。剩下5%的偏差通过两个手段弥补一是推送卡片上保留原文链接用户判断有疑问可以一键核实二是保留的4到5条判断为高风险的高复杂度新闻涉及政策解读、数据报告、行业预判仍然采取人工把关后推送的模式不进自动队列。这里有个很实在的体会自动化和人工不是非此即彼的关系而是各管一段。机器负责从三百条信息里筛出六十条人工只需要在六十条里再挑出四五条做二次确认这个成本比一开始完全手动筛三百条低了接近一个数量级这才是自动化真正划算的地方。4.3 机器人推送的度频率与被屏蔽的临界点说实话做这个项目之前我没有认真想过推送频率的问题觉得每天推个三五十条也不算多。但第三天改版前的数据让我清醒了前两天每条推送的打开率是持续走低的从最初的60%掉到了第三天的20%出头照这个趋势跑下去整个群很快就会变成人见人厌的垃圾信息集散地。推送频率过高的代价不只是用户反感还有平台的限制。IM群机器人其实有一定频控策略短时间大量调用会被临时禁言。我虽然没有被正式禁过但第二天下午高频推送时确实遇到过一次几十条消息被延迟分发的现象。经历过第三天下午的调整之后我给自己定了一条规矩宁缺毋滥。每天最多两个推送批次每批三到五条如果某天的信息特别少宁可只推一条也不为了凑数硬推。这个少即是多的原则在第五天的数据里得到了正面验证——最后两天单日推送量下降但两天加起来的打开率是五天里最高的。5. 这五天的避坑清单比代码更值钱5.1 关键词过滤要小心的语义盲区自动化过滤的第一反应通常都是加关键词黑名单但关键词过滤有个明显的坑容易误伤。我在第三天设定机器人相关关键词时差点把一个儿童编程机器人玩具评测的内容当作硬科技新闻推了出去——从关键词看它完全匹配但从内容实质看这根本不是目标读者关心的方向。后来我把过滤逻辑从出现关键词就通过改成了出现关键词且上下文有行业关联词才通过。判断的粒度更细误伤率降了一些。但必须承认规则过滤永远存在盲区我现在的做法是规则兜底加模型二次判断先用关键词粗筛再用AI判断该条内容是否真的属于目标领域。两层筛下来基本能把语义盲区的范围压缩到可以接受的程度。5.2 第三方API的不确定性必须做降级方案任何外部依赖都有不可用的可能大模型接口也不例外。第五天上午接口偶尔出现了几秒超时如果系统没有超时重试机制这几秒就会变成推送里的空白。我的方案是做了两级降级主用模型接口挂了的时候自动切换到一个备用的轻量模型接口备用接口也失败的话最后兜底是直接推送原文标题加链接不带AI摘要。这种降级策略在这五天里只触发过一次但印象深刻。那次备用模型摘要质量明显下降但至少推送链路没有中断。对自动化系统来说残缺地工作永远好过彻底罢工这个思路在所有依赖第三方服务的系统里都适用。5.3 推送内容必须保留人可追踪的痕迹机器人推送最容易出的问题是内容看起来没有来处。我见过一些自动化推送项目摘要一看就是AI生成的但链接、作者、发布时间全都丢掉了读者看到一条信息想追根溯源完全找不到原始出处。我在推送格式里强制保留了三个字段原文链接、发布时间、原始来源名称。这个改动很小但对信任度提升非常大。读者看到一条新闻想查证时能直接点进原文去看而不是无条件相信机器人的摘要。自动化系统不能取代人做判断它应该做的是帮助人更高效地找到值得判断的内容。5.4 五天观察结束之后这套系统该怎么维护如果说五天里有什么最大的教训那就是自动化系统上线只是开始维护才是常态。信息源会变化接口会调整模型行为会漂移这些不会因为系统跑通了就消失。我的维护计划是这样的每周检查一次的台账看信源更新频率是否有异常各源推送数量是否有突变每月人工抽检一次摘要质量如果发现摘要质量下滑优先检查Prompt是否被模型行为变化影响了每季度重新评估一次内容源列表新增值得关注的源移除质量下降的源。用一句通俗的话概括机器人负责每天跑人负责定期校正方向。从第一天的限流折腾到第五天的数据复盘这个五日观察项目带给我的最大收获是一个朴素但重要的认知AI和机器人解决的不是人该看什么的问题而是人能在更短时间内看到更多值得看的候选的问题。真正的判断权始终应该留在人手里。如果有人看完这篇也想自己搭一套我的建议是先不要追求完整形态。第一天就用最简单的方式跑通采集到摘要到推送的最小链路哪怕摘要粗一点、推送丑一点都无所谓先让链路转起来。之后的每一步优化——过滤规则、摘要Prompt、推送时段——都是在真实数据中慢慢长出来的这比一次性设计一个大而全的系统靠谱得多。