技能使用指南

rss-aggregator（RSS聚合器）Skill 是什么？

RSS聚合器Skill（rss-aggregator）能按预定义OPML订阅源聚合近期更新，一句话生成含标题、作者、摘要、时间与链接的结构化清单，默认回溯3天。本文详解安装验证、使用步骤、竞品对比与典型场景，帮你把碎片信息变成可审阅的简报，快速上手提升信息处理效率。

RSS聚合器Skillrss-aggregator
8 个章节 约 12 分钟阅读 AI 智能生成

RSS聚合器Skill：一句话让 AI 把多个 RSS 源的最新更新汇总成一份简报

  • 定位清晰：RSS聚合器Skill（rss-aggregator）专注一件事——从你预先定义好的 RSS 订阅源列表里，把最近一段时间的新内容抓下来、整理成结构化清单。
  • 零平台依赖：不需要打开浏览器、不依赖第三方阅读器账号，订阅源写在一个 OPML 文件里，随时可增删改。
  • 一句话触发：你只要说"过去 3 天有什么新内容"，技能就会调用脚本执行聚合，默认回溯 3 天。
  • 输出可直接用：每条更新包含标题、作者、约 500 字摘要、更新时间、链接，适合直接喂给 AI 做二次总结或选题判断。
  • 配置即扩展：订阅源列表维护在 references/feeds.opml 中，换行业、换关注方向只需改这个文件。

1. 该技能叫什么？如何一键安装 AI 技能提升开发效率？

基本信息

项目 内容
中文名 RSS聚合器Skill
英文名 rss-aggregator
技能ID 12488
核心脚本 scripts/aggregate.py
订阅源配置 references/feeds.opml

它解决什么问题？

信息获取的痛点通常不是"没有源"，而是"源太多"。技术博客、团队公告、行业媒体、开源项目动态分散在十几个站点，逐个打开成本极高，用通用阅读器又容易陷入"收藏了但不看"的状态。RSS聚合器Skill 把这件事收敛成一个动作：告诉 AI 一个时间范围，拿回一份聚合好的更新清单。它不追求做一个完整的阅读器，而是把"聚合 + 摘要"这一步交给 AI 在工作流里顺手完成。

一键安装的思路与步骤

所谓"一键安装"，本质是把技能目录放到 AI 助手能识别的技能位置，之后由 AI 根据技能描述自动决定何时调用。具体流程如下：

  1. 确认安装前提：需要一个支持 Skill 机制的 AI 助手 / 编程助手环境；由于技能脚本通过 uv run 执行，环境里需要有 uv 工具链；feedparser 依赖由 --with 参数在运行时自动拉起，无需手动预装。具体环境要求以官方说明为准。
  2. 找到技能入口：在技能市场或技能库中，用技能ID 12488 或英文名 rss-aggregator 检索并安装。安装命令、入口路径与账号要求以官方说明为准。
  3. 确认目录结构完整：安装后检查技能目录下是否同时存在 scripts/aggregate.py 与 references/feeds.opml 两个关键文件，前者是执行入口，后者是订阅源清单。
  4. 验证是否生效：对 AI 助手说一句"过去 3 天有什么新内容"或"RSS 更新"，若技能被正确触发并返回更新列表，说明安装成功；也可以在本地直接运行 uv run --with feedparser scripts/aggregate.py --days 3 做一次独立验证。
  5. 接入自己的源：把 references/feeds.opml 替换或补充为自己的 OPML 订阅列表（多数 RSS 阅读器都支持导出 OPML，可直接复用）。

需要提醒的是：安装环节的下载方式、权限设置、是否需要登录账号等细节，请以官方说明为准，不要凭经验假设。

2. 该技能的主要功能和特点

  • 预定义源聚合：不是全网搜索，而是严格按 references/feeds.opml 中列出的精选订阅源抓取，信源可控、噪声低。
  • 按时间窗口回溯：通过 --days <天数> 指定回溯范围，未指定时默认 3 天，适合"日报/周报"式的节奏化使用。
  • 结构化五要素输出：每条更新固定输出标题、作者、摘要（约 500 字，从订阅源内容中提取）、更新时间、链接，信息密度高且便于二次加工。
  • 摘要而非全文搬运：约 500 字的摘要长度是刻意设计——足够判断"值不值得点开"，又不会把上下文窗口塞满。
  • 自然语言触发：技能描述里明确了触发语境（“近期更新”“有什么新内容”“RSS 更新”），用户不必记命令，用日常表达即可。
  • 配置与逻辑分离：换关注领域只改 OPML，不动代码，非工程角色也能维护。
  • 轻量无服务：没有后台常驻进程、没有数据库、不依赖第三方账号，本地脚本按需执行。

和普通工具比强在哪？ 通用 RSS 阅读器强在"长期订阅与已读管理"，弱在"交付形态"——它给你一个信息流界面，你还得自己读完、自己判断。RSS聚合器Skill 强在"交付成稿"：它把结果直接整理成一份带摘要的清单，交回到你正在对话的 AI 上下文里，可以立刻追问"哪几条和我正在做的项目相关"“帮我按主题归类”。一个管"存"，一个管"用"。

3. 如何使用该技能？

Step 1：准备订阅源

打开 references/feeds.opml，确认里面是你要跟踪的源。文件遵循 OPML 标准格式，可以从主流 RSS 阅读器导出后直接使用。建议源数量控制在 10–30 个之间：太少价值有限，太多则单次摘要过长、后续阅读负担回升。

Step 2：用自然语言提出需求

常见说法（与技能设计的触发语境一致）：

  • “近期更新”
  • “过去 3 天有什么新内容”
  • “RSS 更新”
  • “帮我看看这几天的更新”

Step 3：技能调用脚本执行

技能内部执行的命令形态为：

uv run --with feedparser scripts/aggregate.py --days <天数>

其中 <天数> 替换为你要回溯的天数；不传该参数时默认 3 天。

Step 4：读取输出

脚本按条目输出以下五个字段：

  • 标题
  • 作者
  • 摘要（约 500 字，从订阅源内容提取）
  • 更新时间
  • 链接

示意性输出（仅示意格式，非真实数据）：

  • 标题：某开源项目发布新版本
  • 作者：项目维护者
  • 摘要：（约 500 字的内容摘要，概述本次更新的主要改动与背景）
  • 更新时间：2024-XX-XX
  • 链接：（对应文章地址）

Step 5：让 AI 做二次加工

拿到清单后可以继续追问，例如"把技术类更新和行业类更新分开"“挑出和支付系统相关的三条并说明理由”“按重要性排序”。这一步才是这个技能真正的价值放大器。

Step 6：按节奏调整窗口

日常跟进用默认 3 天；周末复盘可以传 --days 7；长假归来可以放宽到 14 天先做一次粗筛。

4. 同类型竞品对比分析

方案名称 定位 核心功能 安装/使用门槛 适用场景 优势与不足
RSS聚合器Skill（rss-aggregator） 面向 AI 工作流的按需聚合器 按预定义 OPML 源抓取，按天数回溯，输出标题/作者/摘要/时间/链接 需支持 Skill 的 AI 环境与 uv，装好后一句话触发 技术雷达、选题扫描、节奏化简报 优势：与对话上下文无缝衔接、结果可直接二次加工、配置极简；不足：不做已读管理与长期归档，源需自行维护
Feedly 等在线 RSS 阅读器 面向个人的长期订阅阅读平台 订阅管理、分类、已读标记、AI 精选、移动端阅读 注册账号即可用，无需技术环境 长期重度阅读、跨设备信息流 优势：阅读体验成熟、生态完善；不足：需要人工逐条浏览，结果不在 AI 上下文里，部分能力需订阅（以官方说明为准）
Inoreader 等进阶阅读器 面向信息工作者的规则化订阅工具 订阅管理、过滤规则、关键词监控、自动化 注册与配置规则有一定学习成本 舆情监控、关键词追踪 优势：过滤与自动化能力强；不足：规则配置偏复杂，输出仍是信息流而非成稿清单
RSSHub + 通用阅读器/自动化平台 自建源 + 自行编排 把无 RSS 的站点转成 RSS，再接入阅读器或自动化流程 需自行部署或编排，门槛最高 需要抓取非标准站点的深度用户 优势：源覆盖广、可定制性最强；不足：维护成本高，摘要与聚合逻辑需自己写

选择建议：如果你已经有稳定的 AI 工作流，希望"少一个界面、多一份成稿"，选本技能；如果你需要长期归档与跨端阅读体验，选成熟阅读器；如果目标站点根本不提供 RSS，先用 RSSHub 补源，再交给本技能聚合。

5. 该技能的典型应用场景与实际体验情况

场景一：开发者的技术雷达日报

角色：后端工程师。痛点：想跟进框架版本、依赖安全公告，但每天翻十几个博客不现实。用法：把官方博客、Release Notes 页面的 RSS 放进 OPML，每天早上问一句"过去 3 天有什么新内容"，先看摘要判断是否与自己的技术栈相关，再决定点开哪条。实际体验：触发几乎零学习成本，摘要长度刚好够做"要不要读"的判断；注意 Release Notes 类源的更新频率可能很高，源太多时单次清单会偏长，建议按主题分批维护。

场景二：内容运营与选题扫描

角色：技术内容运营。痛点：选题灵感依赖长期浸泡，靠手动刷容易漏。用法：把行业媒体、竞品博客、社区聚合源放进 OPML，每周传 --days 7 跑一次，再让 AI"按主题归类并给出三个可写的选题角度"。实际体验：从"刷信息"变成"审清单"，注意力更聚焦；需要提醒的是，摘要来自订阅源内容的提取，选题判断仍要回到原文核对，不要只凭摘要下结论。

场景三：投研与行业跟踪

角色：行业研究员。痛点：需要覆盖多个信息源，但输出物要求结构化。用法：按赛道维护不同 OPML，切换赛道时替换文件即可；输出清单可直接作为周报素材底稿。实际体验：配置与逻辑分离的设计在这里收益明显，非技术角色也能通过编辑 OPML 完成调整；但要注意信息时效与来源可靠性仍需人工复核。

场景四：团队内部信息同步

角色：项目负责人。痛点：团队公告、上游依赖变更分散在多处。用法：把内部公告源和上游项目源合并到一个 OPML，周会前跑一次，用清单做同步提纲。实际体验：省去了"这次该讲什么"的整理时间；建议固定回溯窗口、固定提问句式，形成稳定节奏。

6. 该技能能为用户带来的价值

  • 把"浏览"变成"审阅"：你不必打开十几个页面，只需要对一份带摘要的清单做取舍，单次信息处理时间通常能从数十分钟压缩到几分钟量级。
  • 降低工具门槛：不需要学习阅读器界面、不需要配置过滤规则，一句自然语言就是入口；维护成本集中在一个可读可编辑的 OPML 文件上。
  • 让 AI 拿到"新鲜上下文"：很多 AI 输出之所以空泛，是因为没有当下的事实输入。这个技能补上了这一环，让后续的总结、归类、判断有据可依。
  • 信源自主可控：聚合范围完全由你的 OPML 决定，不受平台推荐算法影响，长期看有助于维持稳定的信息结构。
  • 可复用的工作流资产：一次配置好的 OPML 与提问句式，可以在团队内共享，形成标准化的信息同步流程。

7. 常见问题 FAQ

Q1：这个技能怎么安装？ A：在支持 Skill 机制的 AI 助手中，用技能ID 12488 或英文名 rss-aggregator 检索并安装；安装后确认技能目录下存在 scripts/aggregate.py 与 references/feeds.opml。具体的安装命令、入口位置与账号要求以官方说明为准。

Q2：使用要收费吗？ A：技能详情中没有涉及定价信息，是否收费、是否有额度限制请以官方说明为准。可以确认的是，脚本运行时通过 uv run --with feedparser 拉取依赖，不涉及额外的第三方服务账号。

Q3：只能看 3 天内的更新吗？ A：不是。默认窗口是 3 天，你可以通过 --days <天数> 指定任意回溯范围，例如 --days 7；也可以直接用自然语言说明时间范围。

Q4：怎么增加或更换订阅源？ A：编辑 references/feeds.opml 即可。它是标准 OPML 格式，多数 RSS 阅读器支持导出 OPML 后直接复用，无需改动脚本。

Q5：它和 Feedly、Inoreader 这类阅读器怎么选？ A：看你要"读"还是要"用"。需要长期归档、跨设备阅读和已读管理，选成熟阅读器；希望结果直接落进 AI 对话里、立刻做总结归类，选本技能。两者也可以并存：用阅读器维护 OPML，把同一份文件交给技能做按需聚合。