从零搭建NewsNow：RSS信息聚合与AI摘要推送全攻略

NewsNow这个名字最近在折腾信息聚合的朋友圈子里被反复提起。说白了它就是一个帮你把全网散落的消息自动抓回来、筛一遍、生成摘要、再推到你手机上的工具。尤其2026年这版很多细节跟早前流传的教程已经不一样了我把自己从零搭起来的过程完整写一遍包含踩过的坑和调整过的参数照着做基本能一次跑通。这套方案适合谁呢平时需要盯多个资讯源、又不想装一堆App的人或者做内容运营、需要快速掌握行业动态的朋友。不管你是第一次接触自建消息流还是之前试过别的聚合工具觉得不顺手这篇都能给你一套可以直接抄作业的玩法。1. NewsNow整体设计与架构思路1.1 项目到底要解决什么问题先聊聊我为什么放着现成的RSS阅读器不用非要自己折腾一套。市面上的RSS阅读器确实能订阅但有两个核心痛点解决不了一是纯RSS拿到的往往只有文章摘要想看清全文还得跳转二是信息过载严重几百条更新里真正值得看的可能就两三条。NewsNow的思路是把“订阅、抓取、筛选、摘要、推送”串成一条流水线只把结果送到你面前。我在设计时定了几条硬指标全自动运行、不需要租服务器普通电脑或低配NAS就能跑、摘要生成要调用大模型接口以便保证质量、推送要能直接到微信或者Telegram。整个项目从代码到部署大概控制在三到四百行核心代码以内不引入重型框架方便后续维护和改造。1.2 技术选型的逻辑和取舍技术栈选择上我围绕“轻量、稳定、易改”三个原则来做取舍。后端语言选了Python原因是生态里做爬虫和数据处理最顺手而且不管后续想接哪个大模型SDK基本上都有现成包。调度这一块用APScheduler而不是系统自带的crontab这样程序内部就能管理定时任务Windows和Linux通吃不用额外配置系统计划任务。抓取用httpx库支持异步和HTTP/2比老牌的requests在现代站点兼容性上更好。解析HTML我用BeautifulSoup加lxml引擎如果源站意外返回了网页而不是RSS也能兜底提取正文。存储这块我选了SQLite很多人觉得它“玩具”其实配合WAL模式单机场景下性能完全够用还省掉了数据库服务的安装维护。推送部分做成插件式结构微信方面用Pushplus接口Telegram走Bot API邮件作为兜底三个通道互相独立。摘要生成统一走OpenAI兼容格式的接口这样哪天想换模型只改配置不改代码。1.3 目录结构与数据流设计项目目录我建议按功能拆成模块而不是把所有逻辑写在一个文件里。我的目录结构长这样newsnow/ ├── config.yaml ├── requirements.txt ├── main.py ├── core/ │ ├── fetcher.py │ ├── parser.py │ ├── deduplicator.py │ ├── summarizer.py │ └── notifier.py ├── data/ │ ├── newsnow.db │ └── logs/ └── tests/数据流是一条单向管道定时触发器唤醒采集器采集器同时抓取多个订阅源解析器把RSS里乱七八糟的格式统一成标准结构去重模块用哈希表过滤掉重复信息摘要器把长文压缩成两百字以内的要点最后通知器把成品推出去。全程无人工介入任何一步挂掉都不影响其他环节下次触发会自动恢复。这种分层设计最大的好处是调试方便。推送出问题了单独测试notifier模块就行不用把整套流程跑一遍。2. 核心细节解析与实操要点2.1 采集器的并发策略和请求参数采集器是整个流水线的入口这里的细节直接决定你能稳定抓到多少内容。并发我推荐用3到5个线程对大多数个人使用场景足够了。别贪多源站不是你家开的并发太高容易被封IP5个线程抓一百个源实测大概两分钟能完成一轮这个速度足够及时。请求头伪装要认真做。UA字符串别用默认的Python标识我观察了很多源站的反爬策略它们第一道关卡就是看UA。构造一个尽量像真实Chrome浏览器的UA同时加上Accept和Accept-Language头。但有一点要提醒不要用同一套UA抓所有网站最好给每个源配置独立的请求头或者至少准备几套轮换。超时参数我设的是连接5秒、读取10秒。RSS源大多是小站点服务器性能参差不齐给太长超时会拖慢整体节奏太短又容易误判。重试策略我用的是指数退避第一次失败等2秒第二次4秒最多重试3次。这里有个经验是如果某个源连续7天都抓取失败就自动在数据库里给它标记降级后续抓取频率从30分钟拉长到6小时避免反复对失效源发请求。2.2 解析器对不同RSS格式的统一处理RSS这潭水深得很光格式就有RSS 2.0、Atom、RDF三种不同的站点实现细节千奇百怪。有的把全文放在description里有的放在content:encoded还有的用Media RSS扩展字段。解析器的核心职责就是把这些差异抹平。解析这块用现成库。feedparser在Python社区扛了十几年了兼容性和稳定性都经过充分验证没必要自己造轮子。从解析结果里我重点取三类数据标题、链接、时间戳。时间戳要万分注意——RSS规范里的时间格式是RFC 822但很多源站直接给ISO 8601格式两者混在一起不处理直接存数据库后面做“近24小时新闻”筛选时就会漏掉内容。我的做法是写一个时间归一化函数先尝试解析RFC 822失败就退回ISO 8601再不行就取当前时间兜底。链接清洗也容易被忽略。有些站点会在RSS链接里带上追踪参数比如?utm_sourcerss。这些参数不影响打开文章但会导致同一个内容的去重哈希对不上明明同一篇文章却存了两遍。我在解析阶段就把查询参数里的常见追踪字段白名单删除保留核心参数。2.3 去重模块的思路与哈希策略新闻领域“同源文章”特别多同一件大事不同媒体发的稿子有七八成内容重合。去重不能只比对URL完全一致那样只能去掉转发链上的重复拦不住不同媒体间的洗稿式转载。我用的是双通道去重第一道是内容指纹比对。把正文取前300字清洗掉所有空白和标点用MD5生成指纹指纹一致就判定重复。这道门槛比较严但能绝对保证不误伤。第二道是标题近似匹配用编辑距离计算相似度超过0.85就打上“疑似重复”标签。对第二类我没直接删掉而是单独存放等摘要生成后比较摘要相似度再决定保留哪个版本。这里有个容易踩的坑哈希比对要在去停用词之前完成。如果你先清洗文本再算哈希原文是“我国成功发射卫星”和“我国成功发射卫星”当然没问题但碰到“我国成功发射了卫星”和“我国成功发射卫星”就差了一个字MD5完全不同。我的解决方案是双轨并行保留一个只做字符过滤的原文哈希另算一个分词后的语义哈希两者同时过一遍。2.4 摘要生成时的prompt调优和成本控制摘要模块是所有环节里最值得下功夫的地方。我最初的是简单prompt让模型总结新闻要点出来的结果经常带有模型自己的评论甚至夹带情绪化表达。后来改成结构化prompt把输出限制成固定的三段式核心事实、关键数据、影响范围。实测下来这种格式的可读性和信息密度提升非常明显。我用的prompt模板大致是这样你是一名资深新闻编辑。请将以下新闻压缩为不超过200字的摘要必须包含 1. 发生的事件主体和核心事实 2. 关键数字或时间节点 3. 可能产生的影响范围 要求只陈述客观事实不做评价不含预测。新闻原文如下 {content}参数方面temperature我设为0.2模型越是低随机性越不容易跑题。max_tokens控制在300到400之间太长了成本高太短了有时候三段式没写完。成本控制有个经验值一天抓三百条新闻约七八十条需要生成摘要按tokens估算一天大约消耗15万token一个月下来大概一杯咖啡的钱。如果觉得成本高可以把摘要只在第一次入库时生成已经存过的旧闻不重复调用。另外一个细节大模型对超长文本的处理有限制正文超过5000字的文章直接丢进去不仅浪费token还可能截断关键信息。我做了前置切片取开头2000字加结尾1000字中间部分如果有小标题就拼接几个小标题让模型获得文章骨架这个“头尾提纲”的组合效果实测比全量塞入更稳定。3. 实操实录从零搭建到跑通全流程3.1 环境准备与依赖安装开始动手前先准备好Python 3.10以上的环境。我自己用的3.11新语法特性支持完整一些标准库的API也更顺手。建议用venv建独立虚拟环境别直接装到系统Python里不然过一阵子依赖冲突会让你怀疑人生。依赖列表不长核心就这几项fastapi0.115.0 uvicorn[standard]0.30.0 httpx0.27.0 feedparser6.0.11 beautifulsoup44.12.3 lxml5.2.0 apscheduler3.10.4 sqlalchemy2.0.32 pyyaml6.0.2 openai1.35.0版本号是我实测过的不建议贪新直接升级大版本尤其是openai和sqlalchemy大版本间API变动比较多教程里的代码可能直接跑不起来。安装命令很简单pip install -r requirements.txt安装过程中如果遇到lxml编译报错多数是因为系统缺libxml2的头文件。Windows用户建议直接装预编译的whl包Linux用户先执行apt install libxml2-dev libxslt1-dev再重装。3.2 配置文件的完整解读所有可调参数我统一放在config.yaml里不写死在代码中。配置分四大块订阅源、调度频率、大模型参数、推送渠道。下面贴一份带注释的配置基本是我的实际配置脱敏后的版本feeds: - name: 36kr url: https://36kr.com/feed category: 科技 priority: 1 - name: 少数派 url: https://sspai.com/feed category: 效率 priority: 2 schedule: interval_minutes: 30 initial_delay_seconds: 10 llm: api_base: https://api.example.com/v1 api_key: sk-xxxx model: gpt-4o-mini temperature: 0.2 max_tokens: 400 notify: pushplus_token: xxxx telegram_bot_token: xxxx telegram_chat_id: xxxx email_smtp: smtp.example.com email_user: userexample.com email_pass: xxxx email_to: receiverexample.com dedup: similarity_threshold: 0.85 hash_length: 300 database: path: ./data/newsnow.db调度频率这个参数我做过几轮实测。每10分钟跑一轮能最早抓到突发新闻但绝大部分源站10分钟内根本没有更新白白浪费资源。每30分钟一轮突发新闻损失最多二十分钟的窗口期对绝大多数人来说完全能接受。如果你关注的是科技圈的发布会爆料建议单独把高优先级的几个源设成10分钟轮询其他源保持30分钟。APScheduler里可以同时挂多套触发器按优先级分配不同的抓取间隔这个思路在配置里就能实现。3.3 采集与解析模块的代码实现采集器我用httpx的异步客户端来实现并发请求。这里有个细节复用同一个Client实例而不是每篇请求都新建连接能显著降低握手开销。我用自定义的fetch_all函数把每个源的抓取任务扔进异步队列限流用信号量控制。import asyncio import httpx async def fetch_feed(client, feed): headers {User-Agent: random_ua(), Accept: application/rssxml, application/xml, text/xml} response await client.get(feed[url], headersheaders, timeout10.0, follow_redirectsTrue) response.raise_for_status() return feed, response.text async def fetch_all(feeds, concurrency5): async with httpx.AsyncClient(http2True) as client: sem asyncio.Semaphore(concurrency) async def bounded(feed): async with sem: return await fetch_feed(client, feed) results await asyncio.gather(*[bounded(f) for f in feeds], return_exceptionsTrue) return results解析器的核心是feedparser但要把它的输出映射成统一结构。我定义了一个Article的dataclass后面所有模块都基于这个结构工作不再关心原始RSS长什么样from dataclasses import dataclass from datetime import datetime dataclass class Article: guid: str title: str url: str summary: str content: str published_at: datetime source: str category: str3.4 去重和摘要的串联逻辑去重模块运行在入库之前否则数据库里堆一堆重复记录后面摘要也要重复生成。主流程里是这样一个顺序抓取 → 解析 → 去重 → 过滤 → 入库 → 摘要 → 推送。入库之后就不再对原始内容做任何修改摘要只作为独立字段追加。去重的实现不算复杂维护一张哈希表键是MD5值是入库时间。新文章进来先算哈希在表里查得到就直接跳过查不到就插入。MD5碰撞的概率在个人数据量级下可以忽略不计没必要上SHA256自找麻烦。相似度阈值我调过几版0.8的时候容易误杀两个不同发布会可能因为文案风格相近就被折叠0.9又放走不少转载。0.85是个平衡点实测两百篇文章里误判大概两三篇可接受。摘要模块我封装成一个独立的函数内部又把“判断是否需要摘要”和“调用模型”分成两步避免对已摘要的文章重复调用。def summarize_article(article, config): if article.summary is None: return None text truncate_content(article.content) messages [ {role: system, content: 你是一名严谨的新闻编辑只陈述事实。}, {role: user, content: PROMPT_TEMPLATE.format(contenttext)} ] response client.chat.completions.create( modelconfig[llm][model], messagesmessages, temperatureconfig[llm][temperature], max_tokensconfig[llm][max_tokens] ) return response.choices[0].message.content3.5 推送模块的三种通道对比推送通道我做了三种使用方法各不相同对比一下通道接入成本送达速度适合场景Pushplus最低扫码关注即可拿token秒级个人微信接收Telegram Bot需科学注册但API最开放秒级重度用户自建频道SMTP邮件需要邮箱授权码分钟级备份归档我日常主力用的是Pushplus效率最高直接在微信里看摘要卡片点一下能跳转原文。Telegram适合做频道型的公共资讯站如果你建了频道还可以开放订阅。邮件推送这版我权重最低只在Telegram或Pushplus连续失败时作为fallback触发。推送模块的接口我统一抽象成send(title, content, url)三种通道各自实现这个接口调用方不用关心底层细节。内容格式上有个细节微信的链接预览抓取站点信息比较慢我干脆把摘要正文和链接放在同一段文字里避免推送卡片出现“无标题”的情况。3.6 定时任务与主程序入口主程序入口做的事情不多读配置、初始化数据库、注册任务、启动调度器。真正干活的逻辑都在各个模块里main.py只做编排。定时任务我用的APScheduler的BackgroundScheduler。为什么不用cron因为cron只能做到分钟级定时我想让不同优先级源拥有不同频率这需要代码级别的定时逻辑。APScheduler自带持久化作业存储重启后不会丢失任务状态。from apscheduler.schedulers.background import BackgroundScheduler def main(): config load_config(config.yaml) init_db(config) scheduler BackgroundScheduler(timezoneAsia/Shanghai) scheduler.add_job( run_pipeline, triggerinterval, minutesconfig[schedule][interval_minutes], idnews_pipeline, misfire_grace_time60 ) scheduler.start() print(fNewsNow已启动每{config[schedule][interval_minutes]}分钟抓取一轮) try: asyncio.get_event_loop().run_forever() except KeyboardInterrupt: scheduler.shutdown()misfire_grace_time这个参数别忽视。假设调度器在凌晨三点触发任务但电脑当时处于休眠状态等早上开机的时任务到底补跑还是跳过就有讲究。我设的是60秒超过这个窗口的任务直接丢避免补跑带来的重复推送。推送频率我已基本控制在每天十几条阈值都用配置里的关键词黑白名单控制。4. 常见问题与排查技巧实录4.1 抓取源经常超时或返回空数据这个问题几乎所有自建聚合项目都会遇到。RSS源站服务器稳定性参差不齐我一度频繁从日志里看到超时错误。排查下来的结论很简单单线程串行请求背锅了。你按顺序一个个请求三十个源任何一个慢源都会堵住后面的请求。改成异步并发之后整体耗时立刻降到一个可接受的范围。但还有一个隐蔽因素Redis缓存导致内容不变。某些源站对同一IP抓取返回304 Not Modified此时RSS内容其实没变不能再生成一条“新”数据。我在解析器里加了校验只有状态码为200且内容体与上次不一致时才入库。如果你发现“一天只抓到三条但源站明明更新了”优先检查是不是被缓存了可以让源站每次响应带一个随机缓存破坏参数。4.2 摘要内容与原文不符或出现幻觉这是我最头疼的问题用过一阵子的大模型都躲不开“幻觉”。明明新闻里没提某个数字摘要里凭空多出一个。我的应对策略是双保险。第一道在prompt里加一句“所有数据必须来自原文任何原文未提及的信息都不得添加”这个约束对大多数模型有效。第二道在代码里做程序校验用正则把摘要里的数字全部抠出来去原文里检查这些数字是否出现。如果超过三个数字在原文里找不到对应摘要直接打回重生成直到通过校验。重生成也不是无限重试我限制最多两次。两次都失败就放弃摘要只推原文链接。记住宁可推送格式不完美也不能推送编造内容。4.3 不同时区时间戳混乱的问题如果你同时订阅了北美、欧洲、东亚的源站时间戳混乱几乎是必然的。RSS时间格式里带了时区偏移比如GMT0800或者-0700抓回来如果不统一归一化排序就会错乱欧洲的新闻可能会被排到亚洲新闻前面。我第二次重建项目时就踩了这个坑当时按时间排序总是觉得哪里不对调了半天才发现。解决方案是统一转成UTC时间戳存库显示时再按本地时区转换。数据库里不存带时区的字符串只存Unix时间戳整数。排序、筛选都基于这个整数操作彻底杜绝时区问题。4.4 推送消息丢失或重复推送推送丢失最常见的原因是消息体里带了特殊字符。某些新闻标题里会有引号、emoji或其他Unicode字符推送到Telegram时如果没做转义API会直接报错。我做了一个sanitize函数在推送前过滤掉控制字符和非法引用。Pushplus那边丢消息则多是因为链接里的某些字符触发了平台的过滤对策是统一对URL做百分号编码。重复推送一般是程序崩溃重启导致任务重复执行。APScheduler默认设置了misfire逻辑已经处理了一部分但如果Redis或数据库锁没配置原生调度器并无法完全防重复。我加的方案是在推送表里给(article_guid, channel)建唯一索引同一条新闻对同一通道只允许推一次数据库层面兜底。4.5 程序长时间运行后内存占用持续上升运行三五天后内存越吃越高最后干脆卡死。这个问题排查起来不难用tracemalloc很快锁定位置feedparser解析大体积RSS时在内部缓存了完整DOM树调用方拿到结果后不会主动释放。标准的解决方法是解析函数内部用完后立即del d并调用gc.collect()强制回收。但更治本的是限制单次解析的源数量分批处理每批结束打一个日志标记释放状态。另外httpx的AsyncClient如果反复创建而不关闭文件描述符也会泄漏几万次请求之后跑满限制导致报错。用async with严格管理生命周期不要图省事把Client挂成全局变量。5. 进阶玩法与优化建议5.1 关键词过滤和个性化打分跑通基础流程后我加了简单的关键词过滤机制。用正则匹配标题和摘要命中关键词的新闻直接标记为“重点”推送到微信时在标题前加[重点]前缀。这个功能特别适合内容运营盯行业动态比如你是做AI方向的内容预设“大模型”“AIGC”“智能体”这些词系统每天自动把相关新闻挑出来节省大量人工筛选时间。打分逻辑也可以继续细化。我目前以一个三要素加权公式时效性权重0.4、来源站点权重0.3、关键词命中数权重0.3。每一项归一化到0到1之间综合得分超过0.6的才推送。公式不复杂但你可以根据自己的领域调整权重参数。注意推送别太勤微信轰炸式推送一定会被你自己关掉。5.2 双模型摘要策略大模型摘要的质量在不同场景下差异不小。头条级别的短讯用轻量廉价模型就能搞定深度长文分析摘要难度大就得上推理能力强的新模型。我后来加了一层路由逻辑文章字数少于2000的走轻量模型超过2000或者标题含“深度”“解读”“报告”字样的走更贵的模型。这样在质量和成本之间找到了一个相对最优的平衡点。粗算下来一天的总成本比全量大模型方案低了将近六成摘要在关键评测场景上的可用性反而更高了。5.3 数据报表与趋势统计运行一段时间后数据库里攒下来的历史新闻其实是个不错的分析素材。我把SQLite数据用Pandas定期汇总输出一份每日报告今天推送了几条、命中哪些关键词、哪些信源贡献最多、整体更新量相比前一周是涨是跌。这份报告每周发一封邮件给自己。数量不大但不定期看几眼能帮你判断订阅源需不需要清理。如果一个信源连续两周贡献量为零基本可以降级或剔除。另外可以做的还有简单的时序分析比如关键词在你的订阅源里出现频率的趋势。这个比任何行业资讯平台的“热点榜”都更贴合你自己的信息需求因为它是你自定义信源池的统计结果不受平台算法引导。5.4 懒人部署方案Docker化我不建议一上来就上Docker调试阶段频繁改代码重建镜像太消耗耐心。但跑通之后Docker能帮你彻底解决环境问题尤其是换设备部署时一条命令拉起整个服务不用再装Python依赖。我写了对应的Dockerfile构建命令很简单。Docker部署时要注意数据卷挂载。SQLite数据库文件如果在容器里存储容器重建数据就全丢了必须在宿主机挂载data目录。我用的挂载命令大致如下docker build -t newsnow . docker run -d --name newsnow \ -v ./data:/app/data \ -v ./config.yaml:/app/config.yaml \ --restart unless-stopped \ newsnowrestart unless-stopped保证服务器重启后服务自动拉起来不用手动干预。日志默认打到stdout用docker logs newsnow随时查看排障。6. 写在最后的几点实在话新闻聚合这个方向工具很多但“符合自己口味”的很少。我前后试过各类现成的阅读器和资讯App要么信息噪声太大要么算法推荐看不懂总觉得不受控制。自己搭NewsNow之后最大的变化倒不是推送的几条新闻而是每天打开手机知道哪些事情值得看哪些不值得看信息焦虑缓解了不少。实操中有两件事我想再强调一下。第一任何抓取行为都要有分寸感礼貌一点设置合理的间隔和超时尊重源站资源你的IP也才活得久。第二大模型摘要永远只能做辅助发布任何对外内容前关键信息务必回到原文确认。你要是把新闻聚合结果发到有读者的工作群里摘要里一个数字编错了丢的可是你自己的信用。如果后续想做更多扩展可以考虑给NewsNow加一个简单的Web界面把当天推送的新闻列表展示出来方便工作上查阅历史记录。也可以接入语音合成让摘要变成播报音频通勤时候听。这个项目的天花板不在技术在于你能从信息流里发掘出多少实际的用处。