没有实时热榜，我也能追踪 AI 热点：用 RSS、GitHub Release 和官方博客搭建「最近 7 天」信息流

早上刷了半小时社交媒体，看到十几条“AI 又变天了”，却始终没搞清楚：到底发布了什么？和我有什么关系？需要立刻升级吗？

直到几天后，项目突然报错，你才发现常用的 SDK 已经更新；某个 API 调整了调用方式；一个重要模型早已开放，但热榜上讨论的仍是夸张标题和二手解读。

问题并不是信息太少，而是传播热度和事实价值并不相等。

真正重要的 AI 更新，往往早已出现在官方博客、产品公告和 GitHub Release 中，只是它们没有进入你每天刷的热榜。

本文要搭建的不是分钟级快讯系统，而是一条更实用的信息流：

统一采集 RSS、GitHub Release 和官方博客，只保留滚动 168 小时内的内容，再进行事件级去重、分类和 AI 摘要。

它不会让你成为第一个转发新闻的人，但能让你更早知道：哪些变化真正影响自己的工具、模型选择和开发工作。

---

一、为什么不用热榜，反而更容易抓住重要更新

实时热榜优化的是“什么最容易被讨论”，而不是“什么最值得行动”。

一条充满争议的模型评价，可能在短时间内获得大量传播；一次不够吸睛的 API 弃用公告，却可能直接影响生产环境。

两者的价值完全不同。

对于 AI 用户和开发者，真正值得持续追踪的信息通常来自三类一手来源：

  • 模型、API和产品的官方公告；
  • 开源框架、SDK及客户端的 GitHub Release；
  • 研究机构、技术团队和专业媒体的 RSS/Atom。

本文把时间窗口设置为最近 7 天，也就是滚动 168 小时，而不是只看“今天”。

这样设计有三个原因：

1. 周末没有查看信息，也不容易漏掉更新；

2. 可以容忍时区差异、订阅延迟和偶发抓取失败；

3. 窗口足够短，不至于让旧消息不断回流。

需要注意，滚动 7 天不是“今天减去 7 个自然日”。如果当前时间是周三下午 3 点，那么截止线就是上周三下午 3 点，而不是上周三零点。

---

二、先看最终效果：我们要的不是收藏夹，而是信息卡片

完成后的每日信息流，不应该只是一串链接，而应该像下面这样：

## 1. Example SDK 发布 v2.4.0


  • 时间：2025-XX-XX 10:30（北京时间）
    • 

  • 类型：GitHub Release
    • 

  • 重要级别：高
    • 

  • 发生了什么：该版本新增某项能力，并调整部分接口。
    • 

  • 影响对象：正在使用该 SDK 的开发者。
    • 

  • 是否需要行动：升级前检查变更说明和兼容性要求。
    • 

  • 官方来源：https://github.com/OWNER/REPO/releases/tag/v2.4.0
    • 

  • 补充来源：https://example.com/blog/example-sdk-v2-4
    •

读者不必依次打开十几个页面，就能先回答三个问题：

  • 这件事是什么？
  • 是否与我有关？
  • 我现在要不要行动？

整套流程可以概括为：

flowchart LR

A[RSS / Atom] --> D[采集器]


B[GitHub Releases] --> D


C[官方博客] --> D


D --> E[字段统一]


E --> F[最近 7 天过滤]


F --> G[事件级去重]


G --> H[分类 / 打分 / AI 摘要]


H --> I[Markdown / 邮件 / 飞书 / 知识库]



style F fill:#ffdf80,stroke:#d98b00,stroke-width:3px


style G fill:#ffb3b3,stroke:#c62828,stroke-width:3px

其中最关键的不是“采集”，而是两个中间步骤：

最近 7 天过滤，解决旧闻回流；事件级去重，解决同一条新闻反复出现。

---

三、RSS、GitHub Release 和官方博客各负责什么

这三类来源并不是互相替代，而是各司其职。

1. RSS/Atom：负责批量获取更新

RSS适合订阅：

  • AI 产品博客；
  • 研究机构动态；
  • 技术媒体；
  • 开发者公告；
  • 支持订阅的官方新闻页面。

它的优势是格式统一、抓取成本低，也不必为每个网站单独写爬虫。

但要注意：网站首页地址不等于 RSS 地址。 把一个普通 HTML 页面填进 feedparser，并不会自动变成可用订阅源。

2. GitHub Release：负责版本变化

对于推理框架、模型 SDK、桌面客户端和开发工具，Release 往往比社交媒体更快、更准确。

GitHub 仓库通常可以直接使用 Atom：

https://github.com/OWNER/REPO/releases.atom

例如：

https://github.com/vllm-project/vllm/releases.atom

https://github.com/langchain-ai/langchain/releases.atom

如果需要更多字段，再调用 GitHub API：

GET https://api.github.com/repos/OWNER/REPO/releases

重点关注：

  • tag_name：版本标签；
  • name：Release 名称；
  • published_at：正式发布时间；
  • html_url：官方页面；
  • prerelease：是否为预发布版本；
  • draft：是否为草稿。

面向普通用户的信息流，建议默认排除 draft 和 prerelease。如果你在追踪开发工具，可以保留预发布版本，但必须明确添加“预发布”标签，避免读者误认为它已适合生产使用。

3. 官方博客：负责最终确认事实

当媒体 RSS、GitHub Release 和社交平台说法不一致时，应优先回到官方来源确认：

  • 模型是否正式发布；
  • API 是否已经开放；
  • 价格或调用规则是否调整；
  • 更新适用于哪些地区和用户；
  • 这是正式版本还是测试功能。

建议先从 20—30 个高质量来源起步。源太多不仅不会更全面，反而会带来更多转载、旧闻和维护成本。

可以用 YAML 管理：

sources:

- name: OpenAI News


type: rss


url: https://openai.com/news/rss.xml


category: model_and_product


priority: 5


enabled: true



- name: vLLM Releases


type: github_release


url: https://github.com/vllm-project/vllm/releases.atom


category: inference


priority: 4


enabled: true



- name: LangChain Releases


type: github_release


url: https://github.com/langchain-ai/langchain/releases.atom


category: developer_tool


priority: 4


enabled: true

订阅地址可能随网站调整而变化，正式运行前应在浏览器中检查返回内容是否为 RSS 或 Atom XML。

每个来源还应回答一个问题：我为什么订阅它？

如果说不清用途，就先不要加入。

---

四、核心代码：只保留最近 7 天的更新

先安装依赖：

pip install feedparser

下面这段 Python 可以同时处理普通 RSS、Atom 和 GitHub Release Atom：

from datetime import datetime, timedelta, timezone

import calendar


import feedparser



WINDOW_DAYS = 7



now = datetime.now(timezone.utc)


cutoff = now - timedelta(days=WINDOW_DAYS)



def parse_entry_time(entry):


"""按优先级解析发布时间，并统一为 UTC。"""


time_struct = (


entry.get("published_parsed")


or entry.get("updated_parsed")


)



if not time_struct:


return None



return datetime.fromtimestamp(


calendar.timegm(time_struct),


tz=timezone.utc,


)



def fetch_recent_items(feed_url):


feed = feedparser.parse(feed_url)


items = []


pending_review = []



for entry in feed.entries:


published_at = parse_entry_time(entry)



item = {


"title": entry.get("title", "").strip(),


"url": entry.get("link", ""),


"source": feed.feed.get("title", feed_url),


}



# 没有可验证日期时，不把抓取时间冒充发布时间


if published_at is None:


item["status"] = "pending_date_verification"


pending_review.append(item)


continue



if cutoff <= published_at <= now:


item.update({


"published_at": published_at.isoformat(),


"status": "verified",


})


items.append(item)



return {


"recent_items": items,


"pending_review": pending_review,


}



result = fetch_recent_items(


"https://github.com/vllm-project/vllm/releases.atom"


)



for item in result["recent_items"]:


print(item)

这段代码有几个刻意做出的选择。

第一，内部时间全部使用 UTC

不同信息源可能使用 UTC、当地时区或带偏移量的时间。内部统一为 UTC，能减少日期边界错误。

如果最终生成北京时间日报，可以在展示阶段转换：

from zoneinfo import ZoneInfo


beijing_time = published_at.astimezone(


ZoneInfo("Asia/Shanghai")


)

第二，缺少日期的内容进入待核验区

最危险的做法，是把“抓取时间”直接当成“发布时间”。

一篇半年前的旧文章，如果今天刚被采集到，就可能伪装成今日热点。更稳妥的做法是：

  • 尝试从页面元数据补充日期；
  • 回到官方页面人工确认；
  • 无法确认时标记为“待核验”；
  • 不直接进入正式简报。

第三，未来时间也要排除

代码使用：

cutoff <= published_at <= now

这可以过滤明显异常的未来日期，避免错误时间字段污染结果。

---

五、真正的难点：不能只按标题去重

假设系统抓到三条内容：

来源A：某公司发布 Model X 2.0

来源B：Model X API now available


来源C：SDK v3.2 adds support for Model X 2.0

如果只比较标题，它们完全不同；如果看到“Model X 2.0”就全部合并，又可能丢失重要信息。

正确结构应该是：

  • 主事件：Model X 2.0 发布；
- 关联更新：Model X API 开放；

- 工具适配：SDK v3.2 支持 Model X 2.0。

判断标准是：它们是否拥有独立的发布时间、版本号和用户影响。

如果三个页面只是对同一发布公告的重复转述，就合并为一条，并以官方公告为主链接；如果 API 开放和 SDK 更新会让不同用户采取不同动作，就应作为主事件下的子更新保留。

基础去重键可以写成：

dedupe_key = (

normalized_source,


normalized_repo_or_product,


version_or_event_date,


)

URL 也应先清理常见追踪参数：

from urllib.parse import urlsplit, urlunsplit


def normalize_url(url):


parts = urlsplit(url)


return urlunsplit((


parts.scheme.lower(),


parts.netloc.lower(),


parts.path.rstrip("/"),


"",  # 移除 query


"",  # 移除 fragment


))

更进阶的做法，是组合以下特征进行聚类：

  • 标题相似度；
  • 公司、模型、项目等实体名称；
  • 版本号；
  • 发布时间；
  • 官方链接指向；
  • 更新影响对象。

但无论使用规则还是模型，都要保留人工复核入口。因为“是不是同一事件”并不是纯文本相似度问题，而是编辑判断。

---

六、从链接列表升级为可读热点

采集完成后，可以为每条信息生成统一卡片：

  • 发生了什么；
  • 发布时间与原始来源；
  • 为什么值得关注；
  • 影响哪些用户；
  • 是否需要立即行动；
  • 官方链接与补充链接。

排序不必完全交给 AI，可以先设计一套透明公式：

热点分数 = 来源可信度 × 0.35 + 更新重要性 × 0.30 + 主题匹配度 × 0.20 + 多源印证 × 0.15

每个维度可以使用 1—5 分，但要明确：这只是个人信息流的排序工具，不是行业权威排名。

例如：

  • 官方模型或 API 公告，来源可信度较高；
  • 文档错别字修复，更新重要性较低；
  • 与自己使用的框架直接相关，主题匹配度较高；
  • 多个独立一手来源能够相互确认，多源印证得分更高。

AI适合负责摘要、分类和影响点提取，但不应负责凭空“补全新闻”。

可以使用下面的提示词：

你是一名AI行业信息编辑。请根据输入的标题、正文摘要、

发布日期和原始链接，输出以下字段：



1. 一句话概述发生了什么


2. 涉及的产品、模型或项目


3. 版本号


4. 影响哪些用户


5. 是否需要立即行动


6. 重要级别：高/中/低



要求：


  • 不添加输入中不存在的事实；
    • 

  • 日期、版本号和产品名称必须原样保留；
    • 

  • 信息不足时写“无法确认”；
    • 

  • 同一事件的多个来源合并，不要重复输出；
    • 

  • 如果来源之间存在冲突，标记“待核验”；
    • 

  • 官方来源作为主链接，其他来源作为补充链接。
    •

调用 API 时，不要把密钥直接写进代码：

import os

import requests



API_KEY = os.environ["AI_API_KEY"]



payload = {


"model": "YOUR_MODEL",


"messages": [


{


"role": "user",


"content": (


"请将以下最近7天的更新整理成中文信息卡片："


"..."


),


}


],


}



response = requests.post(


"YOUR_API_ENDPOINT",


headers={


"Authorization": f"Bearer {API_KEY}",


"Content-Type": "application/json",


},


json=payload,


timeout=60,


)



response.raise_for_status()


print(response.json())

模型拿到的最好不是未经处理的网页全文，而是已经完成日期过滤、URL 标准化和规则去重的 JSON。这样既能减少重复内容，也能降低调用成本。

---

七、三种落地方式：从当天可用到完全自动化

1. 小白版：RSS 阅读器＋Release Atom

把常用官方博客和 GitHub Release Atom 加入 RSS 阅读器，再手动查看最近一周。

优点是零开发成本，适合先验证信息源质量。缺点是事件级去重仍需人工完成。

2. 进阶版：Python＋定时任务

使用本文脚本每天抓取一次，输出 Markdown 或 JSON。

Linux/macOS 可以使用 cron，Windows 可以使用任务计划程序。建议同时记录：

  • 抓取时间；
  • HTTP或解析错误；
  • 连续失败次数；
  • 新增条目数量；
  • 待核验条目数量。

3. 自动化版：过滤后调用模型 API

完整链路可以是：

定时采集

→ 最近7天过滤


→ 规则去重


→ 模型生成中文摘要与标签


→ 输出Markdown


→ 推送到邮箱、飞书、Telegram或知识库

如果你已经完成 RSS 和 GitHub Release 的采集，可以把标准化 JSON 交给模型做中文摘要、分类和影响判断。

你可以前往 api.884819.xyz，根据站内文档选择适合的模型和接口，把本文提示词接入脚本。平台使用用户名和密码即可注册，不需要邮箱验证；内置 AI 对话功能，注册后可以直接使用。国产模型如 Deepseek、千问等完全免费，没有月租和订阅，其他服务按量付费。

建议先用 10—20 条信息测试输出格式，确认事实约束和去重逻辑有效，再开启定时任务。

新用户注册即送体验token。

接入时记住两条原则：

1. API Key 放进环境变量，不要上传到 GitHub；

2. 先过滤、再去重、最后调用模型，不要为重复内容浪费额度。

---

八、维护清单：源越多，不代表信息越好

一套信息流能否长期有用，取决于维护，而不是第一次配置时有多复杂。

建议：

  • 每月检查失效或跳转异常的订阅源；
  • 每季度清理长期没有高价值内容的来源；
  • 对连续抓取失败的源设置提醒；
  • 避免重复订阅同一项目的多个转载渠道；
  • 保留官方博客与 Release 的关联关系；
  • 定期抽查 AI 摘要是否忠于原文；
  • 对“待核验”内容设置自动过期时间。

过滤前，你面对的可能是旧闻、转载和重复链接；过滤后，只剩最近 7 天且可回溯来源的事件；经过 AI 整理后，每条信息都能快速判断是否与自己有关。

真正决定质量的，从来不是抓到了多少条，而是三件事：

一手来源比例、事件级去重质量，以及持续维护能力。

热榜告诉你大家正在讨论什么，而自己的信息流，才能告诉你哪些变化真正与你有关。

下一篇，我会在这套采集系统上继续加一层：让 AI 自动区分“小版本修复”和“可能影响模型选择、兼容性与开发成本的重要更新”，再生成一份可直接推送到飞书、邮箱或 Telegram 的中文 AI 日报。

你更想先看哪一种输出方式？

  • A. 飞书机器人每日推送
  • B. 邮件版 AI 周报
  • C. Telegram 更新提醒
  • D. 自动生成 Markdown 并提交到 GitHub
本文由8848AI原创，转载请注明出处。关注8848AI，带你从零开始学AI。

#AI教程 #RSS #GitHub #人工智能 #信息流 #AI自动化 #8848AI #Python