每天早晨打开手机，几十个订阅号、十几个网页、好几个群里的转发链接，这种信息轰炸相信不少人都经历过。我大概在三周前做了个决定：与其被新闻追着跑，不如让机器替我盯。这个项目的核心很简单——把"采集新闻、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、推送时段——都是在真实数据中慢慢长出来的，这比一次性设计一个大而全的系统靠谱得多。
