推荐算法替你决定了你应该看什么——它比你更了解你的弱点，于是不断推送那些让你停留更久的内容，而不是对你更有价值的内容。RSS 是这套规则的反面：没有算法、没有推荐、没有广告。只有你主动订阅的来源，按你决定的顺序出现。
本文从基础定义到 AI 时代的最新演进、从阅读器选择到端到端自动化管线搭建，逐层拆解这套被严重低估的信息基础设施。
| 关键词 | 一句话说明 |
|---|---|
| ⭐ RSS | 一种让网站主动推送更新给你的 XML 格式——信息聚合的元老级标准，1999 年沿用至今 |
| ⭐ RSS 阅读器 | 聚合你所有订阅源的应用，在一个界面中消费所有内容 |
| Feed / 源 | 一个 RSS 订阅地址，指向一个 XML 文件，阅读器定期拉取 |
| RSSHub | 万能 RSS 生成器——为不提供 RSS 的网站（B站、微博、小红书等）生成源 |
| Podcast Index | 开源播客目录，扩展 RSS 协议支持播客的现代需求 |
| 全文输出 vs 摘要输出 | 有些源输出完整文章内容，有些只给标题+简介 |
| 自托管阅读器 | 在自己服务器上部署 RSS 服务（如 Miniflux、FreshRSS） |
| WebSub | RSS 的实时推送协议——让延迟从分钟级降到秒级 |
RSS（Really Simple Syndication，真正简易聚合）的核心逻辑惊人地简单：它让网站主动"推送"更新给你，而不是你逐个网站去"拉取"。
没有 RSS 的世界：你每天手动打开 30 个网站看有没有新文章——像在没有通知栏的时代反复下拉刷新。
有 RSS 的世界：所有网站的新内容自动发到你的阅读器，你一个界面读完所有。
这个差异的实质是控制权的转移。在 RSS 体系下：你决定订阅什么来源，你决定阅读什么内容。没有推荐算法替你排序，没有"你可能也喜欢"的干扰，没有广告穿插在你的信息流中。你不是产品，你只是读者。
| 社交媒体信息流 | RSS 信息流 | |
|---|---|---|
| 谁选内容 | 推荐算法 | 你本人 |
| 排序依据 | 互动概率预测——你停留最久的排最前 | 发布时间——最新的排最前 |
| 内容边界 | 平台生态内（算法认为你可能喜欢的） | 你订阅的源（你明确选择要看的） |
| 广告 | 穿插在信息流中，伪装成内容 | 无（除非源本身就有广告） |
| 你的角色 | 被优化的对象（注意力 = 商品） | 自主的读者（注意力 = 你的资产） |
| 信息过载的解法 | 算法帮你"过滤"（但你看不到它过滤了什么） | 你自己管理订阅源 + 设置过滤规则 |
| 跨平台 | 锁定在单一平台 | 任何阅读器都能订阅任何 RSS 源 |
一种常见的误解是"RSS 是留给极客的古老技术"。恰恰相反——RSS 是留给每一个在意自己注意力的人的生存工具。它不是一项需要学习的技术，而是一种你可以重新拥有的权利。
RSS 的雏形由网景公司（Netscape）在 1999 年提出，最初是为了让 My.Netscape.com 门户聚合新闻内容。随后二十多年经历了多个版本的迭代：RSS 0.9（原型）→ RSS 1.0（基于 W3C RDF 标准，语义网取向）→ RSS 2.0（今天的主流版本）。同一时期还诞生了 Atom（IETF 标准化版本，RFC 4287，2005 年）——结构更严谨，但普及度始终不及 RSS 2.0。
2005 年 Google 收购了 FeedBurner 并推出了 Google Reader，RSS 由此进入大众视野。到 2012 年，Google Reader 是全球最大的 RSS 阅读平台。2013 年 3 月 13 日，Google 宣布关闭它——官方口径是"使用量下降"，但更真实的背景是 Google 的战略重心已转向封闭的社交平台 Google+。RSS 是开放的，而开放不符合封闭平台的利益。
主流媒体在那一天纷纷撰写了 RSS 的悼词。"RSS 已死"成为科技圈的年度叙事。但真正理解这项技术的人知道：杀死的是 Google Reader 这个产品，不是 RSS 这个协议。
Google Reader 的死洗掉的是"被动使用 RSS 的用户"。留下来的是真正需要它的人——研究员、记者、独立博客作者、写作者、信息成瘾者——形成了一个小而坚定的用户群。2020 年代出现了几股推动 RSS 复兴的力量：
RSS 没有死。它只是从聚光灯下回到了它该在的位置——一个可靠、开放、不受平台控制的信息基础设施。
信心等级：高——RSS 在绝对用户数上远不及社交平台，但在技术写作、学术研究、独立媒体生态中，它的渗透率没有下降，甚至在缓慢回升。2022-2025 年，Readwise Reader、NetNewsWire 等新产品/重要更新进一步证实了生态的活跃度。
RSS 本质上是一个 XML 文件，放在网站上，结构大致如下：
<rss version="2.0">
<channel>
<title>博客名称</title>
<link>https://example.com</link>
<description>博客简介</description>
<item>
<title>文章标题</title>
<link>https://example.com/article</link>
<description>文章摘要或全文</description>
<pubDate>Mon, 01 Jun 2026 12:00:00 GMT</pubDate>
</item>
</channel>
</rss>你的阅读器定期（通常每 15-60 分钟）去检查这个文件，发现 <item> 有新增就拉下来展示给你。这个协议轻到可以手写，可靠到跑了二十多年没有需要替换的充分理由。
| 格式 | 技术基础 | 特点 | 现状 |
|---|---|---|---|
| RSS 2.0 | XML | 最广泛、最简单，但规范有些模糊（"description"可以含 HTML 也可以不含） | 绝对主流 |
| Atom | XML（IETF RFC 4287） | 结构更严谨，日期格式强制 RFC 3339，<entry> 更规范 | 技术博客/标准组织偏爱 |
| JSON Feed | JSON | JSON 格式而非 XML，天然适合 Web 开发者，规范清晰（https://jsonfeed.org） | 小众但有增长趋势 |
作为用户，你不需要关心区别——所有现代阅读器都支持三者。如果你自己建站输出 Feed，Atom 是更规范的选择；要兼容最广，RSS 2.0 仍然是最安全的。
| 概念 | 说明 |
|---|---|
| Feed / 源 | 一个 RSS 订阅地址，指向一个 XML/JSON 文件 |
| Item / 条目 | 一篇文章、一则播客、一条 YouTube 视频——Feed 中每一个独立的内容单元 |
| 全文输出 | 源在 <description> 或 <content:encoded> 中输出完整正文。你可以在阅读器里读完 |
| 摘要输出 | 只有标题和简介，阅读体验依赖跳转原文 |
| 轮询（Polling） | 阅读器定期请求 Feed 文件。不是真正的实时推送 |
| WebSub | 原称 PubSubHubbub——发布者主动通知订阅者的实时推送协议。YouTube、GitHub 等已支持。延迟从分钟级降到秒级 |
| Enclosure | RSS 2.0 的附件机制——播客音频文件、视频文件通过它附加在条目中 |
市面上的阅读器种类繁多，按使用场景可以分五条路线。
| 阅读器 | 平台 | 费用 | 特点 |
|---|---|---|---|
| Inoreader | Web / iOS / Android | 免费版够用 / Pro $10/月 | 功能最全：规则引擎、全文提取、搜索归档、标签系统。生态位中的主力选手 |
| Feedly | Web / iOS / Android | 免费版有限 / Pro $8/月 | 老牌玩家，UI 漂亮，AI 辅助功能（Leo 摘要），但免费版限制较多 |
| NetNewsWire | macOS / iOS | 完全免费 | 开源、Apple 原生设计、极简。同步需搭配 iCloud 或自建服务后端 |
| Readwise Reader | Web / iOS / macOS | $9.99/月（全功能） | 集 RSS + 高亮 + 笔记 + AI 于一体。适合深度阅读和知识管理需求，支持导入 EPUB、PDF、Newsletter |
| 阅读器 | 平台 | 特点 |
|---|---|---|
| Reeder | macOS / iOS | 付费买断，设计感极强的标杆级阅读器。支持 Inoreader/Feedly/Miniflux 等服务后端 |
| Fluent Reader | Windows / Linux / macOS | 开源、Electron 构建、支持本地阅读和自托管服务 |
| NewsFlash | Linux（GNOME） | GNOME 原生阅读器，干净利落，支持 FreshRSS/Miniflux 后端 |
| FeedMe | Android | Android 上口碑最好的阅读器，支持多个服务后端，可定制性强 |
| 方案 | 语言 | 部署难度 | 推荐理由 |
|---|---|---|---|
| Miniflux | Go | ★☆☆ | 单二进制部署，极轻量，SQLite/PostgreSQL，完善 REST API。个人认为自托管首选 |
| FreshRSS | PHP | ★★☆ | 功能更全，支持多用户，API 兼容 Google Reader 协议，可对接 Reeder/NetNewsWire |
| Miniflux 的 API | Go | ★☆☆ | 兼容 Fever API，完美对接 Reeder、NetNewsWire 等客户端 |
| Tiny Tiny RSS | PHP | ★★☆ | 老牌、插件生态丰富，但界面稍显陈旧 |
| Yarr | Go | ★☆☆ | 更轻量的 Miniflux 变体——单文件、SQLite、无外部依赖 |
| 工具 | 说明 |
|---|---|
| Newsboat | 终端 RSS 阅读器，Vim 快捷键操作，可搭配 tmux 常驻后台。支持播客下载 |
| rsstail | tail -f 风格——终端中滚动显示新条目，适合搭配通知脚本 |
| RainbowStream | 终端内三栏布局，类邮箱操作体验 |
| sfeed | 纯 C 实现的 RSS/Atom 解析工具集，极简主义者的选择 |
我的建议：入门选 NetNewsWire（macOS + iOS，免费且优雅）。需要跨平台和规则引擎选 Inoreader 免费版。做知识管理可以从 Readwise Reader 起步（付费但整合度高）。想要完全掌控自己的数据——Miniflux 部署一次，几乎无需维护。
很多网站不再主动宣传自己的 RSS 源，但它们通常还在。
https://example.com/feed/
https://example.com/feed.xml
https://example.com/rss/
https://example.com/rss.xml
https://example.com/atom.xml
https://example.com/index.xml
https://example.com/feed/atom/技术类博客尤其标准——/feed.xml 或 /atom.xml 几乎是行业惯例。
| 扩展 | 用途 |
|---|---|
| RSSHub Radar | 识别当前页面的 Feed 链接 + 通过 RSSHub 生成源。Chrome/Firefox/Safari 均可用 |
| Feedbro | 内置阅读器 + 自动发现，适合入门用户一步到位 |
| QuiteRSS 的发现器 | 桌面端 Feed 发现工具 |
RSSHub 是一个开源项目（rsshub.app），能把"没有 RSS 的网站"的内容转换成 RSS 格式。以下是你可以实际使用的路由：
# 视频平台
/rsshub.app/bilibili/user/video/2267573 → B站 UP 主视频更新
/rsshub.app/bilibili/user/dynamic/2267573 → B站 UP 主动态（含转发）
/rsshub.app/youtube/channel/UC... → YouTube 频道（RSSHub 包装）
/rsshub.app/douyin/user/xxx → 抖音
# 社交媒体
/rsshub.app/weibo/user/xxx → 微博用户
/rsshub.app/twitter/user/elonmusk → Twitter/X 用户（可能受限）
/rsshub.app/xiaohongshu/user/xxx → 小红书用户
# 知识/社区
/rsshub.app/zhihu/people/activities/xxx → 知乎用户动态
/rsshub.app/zhihu/zhuanlan/xxx → 知乎专栏
/rsshub.app/douban/group/xxx → 豆瓣小组
/rsshub.app/douban/movie/playing → 豆瓣正在上映
/rsshub.app/jianshu/user/xxx → 简书用户
# 新闻/资讯
/rsshub.app/36kr/motif/xxx → 36氪
/rsshub.app/huxiu/article → 虎嗅RSSHub 有公共实例（rsshub.app），也可以自部署。重度用户建议自部署——公共实例有请求频率限制和稳定性问题。
Inoreader 和 Feedly 都内置了搜索发现功能。输入域名或关键词，直接找到相关源。这是最懒惰也最适合初学者的方法。
YouTube 每个频道都有一个隐藏的原生 RSS 源：
https://www.youtube.com/feeds/videos.xml?channel_id=UC...把它扔进阅读器，新视频自动出现——不需要打开 YouTube 首页被推荐算法轰炸。
播客本质上就是 RSS + 音频附件（Enclosure）。所有播客客户端底层都是 RSS 协议。这就是为什么你可以用任意播客应用订阅任意播客，不会被锁定在某个平台内。这个开放生态是 Apple Podcasts 和 Spotify 始终无法"垄断"播客的原因。
https://github.com/用户名/仓库名/releases.atom → Release 发布通知
https://github.com/用户名/仓库名/commits.atom → 提交动态
https://github.com/用户名.atom → 用户动态（Star、Fork 等）https://www.reddit.com/r/子版块名/.rss → Reddit 版块新帖
https://hnrss.org/frontpage → Hacker News 首页
https://hnrss.org/newest → Hacker News 最新
https://hnrss.org/user/用户名 → 特定用户hnrss.org 是社区维护的项目，支持按关键词、用户、分数阈值过滤。
https://mastodon.example/@用户名.rss → Mastodon 用户公开嘟文
https://mastodon.example/tags/tagname.rss → 话题标签用 Kill the Newsletter!（kill-the-newsletter.com）生成一个临时邮箱地址——邮件发进来，自动转为 RSS 源。还可以自托管 mado（一个更简单的邮件转 RSS 方案）。
| 方案 | 玩法 |
|---|---|
| IFTTT / Zapier / Make | RSS 新条目 → Telegram / Slack / 邮件 / Discord 通知 |
| Huginn | 自托管自动化平台——监听 RSS 变化后触发任意动作，比 IFTTT 灵活百倍 |
| n8n | Node-RED 风格的可视化工作流引擎，RSS 节点 + AI 节点 + 通知节点自由组合 |
| Miniflux API + 任意脚本 | 通过 REST API 拉取未读条目，用 Python/JS 写出任何你想要的处理逻辑 |
当订阅源积累到 30+ 时，"读不完"是最常见的问题。解决方式是加一层过滤，而不是放弃 RSS：
过滤的黄金法则：先增加，再删减。初期不要怕订阅太多——先用一段时间，看清楚哪些源你实际在读、哪些你从来不看，再逐步修剪。不要为了追求"零未读"而过度过滤。
这是 2024-2026 年 RSS 生态中最令人兴奋的新方向。RSS 解决了信息获取的自主权问题，AI 解决了信息过载的处理效率问题——两者结合，产生的是远大于各自之和的效果。
| 能力 | 说明 | 典型场景 |
|---|---|---|
| 智能摘要 | 用 LLM 为每篇条目生成 2-3 句摘要，快速判断是否值得精读 | 早晨打开阅读器，先扫摘要再决定点开哪篇，而不是逐篇扫读 |
| 多语言翻译 | 把不同语言的条目翻译成你的母语摘要 | 关注日本 tech 博客、德语媒体、法语期刊，不需要会这些语言 |
| 兴趣筛选 | 根据你设定的兴趣维度，自动给条目打分/标记/归类 | "只标记涉及 LLM 推理架构的文章""跳过所有 iPhone 评测" |
⚠️ 关键区分：AI 筛选和推荐算法有本质区别。推荐算法决定了"你看什么"——你失去了选择权。AI 筛选决定了"你从你已经选择的内容中优先看什么"——你仍然控制着信息来源，AI 只是帮你提高处理效率。前者是剥夺，后者是赋能。
macro 功能绑定外部脚本，选中条目后按一个键触发 AI 摘要假设你的阅读器收到一篇关于 Rust 异步编程的 5000 字英文技术文章。AI 管线可以自动：
你看到的就是这样一条条目——标题 + 中文摘要 + 分类标签。5 秒钟决定要不要点开。效率提升是数量级的。
不要把 AI 当成新的推荐算法——让 AI 帮你处理你已经决定要读的内容，而不是替你做决定。这条线一旦模糊，RSS 最珍贵的价值（自主选择权）就消失了。
很多人不知道的是：播客生态是今天 RSS 协议最活跃、最创新的应用领域。每一次你用播客客户端搜索和订阅一个新节目，底层都是 RSS。
RSS 2.0 的 <enclosure> 标签允许在条目中附加一个媒体文件：
<enclosure url="https://.../episode.mp3"
length="12345678"
type="audio/mpeg" />这就是播客的全部技术起源——一个 1999 年为聚合文本设计的协议，因为一个附件标签延展出了整个播客产业。这个例子的启示：简单开放的协议，演化能力远超精心设计的封闭系统。
2020 年，一群播客布道者启动了 Podcast Index（podcastindex.org）——一个完全开源、去中心化的播客目录，不依赖 Apple Podcasts 或 Spotify。同时他们发起了 Podcasting 2.0 倡议，为 RSS 增加了大量新标签：
| 新标签 | 作用 |
|---|---|
<podcast:transcript> | 关联播客的文字稿（支持多语言） |
<podcast:chapters> | 章节标记——听众可以跳转到指定时间点 |
<podcast:person> | 标注嘉宾/主持人身份 |
<podcast:funding> | 捐赠/赞助链接 |
<podcast:socialInteraction> | 关联评论/社交互动 |
<value> | Value4Value——通过比特币闪电网络实现微支付 |
截至 2026 年，Podcasting 2.0 的标签已经被大量播客客户端（Pocket Casts、AntennaPod、Podverse 等）部分或全部支持。
信心等级：高——Podcast Index 的索引量已超过 600 万个节目，Podcasting 2.0 是播客行业最活跃的标准制定工作。
当你把前面所有章节的内容串起来，就得到了一条完整的信息管线——从源头的信息获取到最终的知识沉淀，全链路受你控制。
工作流 A：Miniflux + AI 摘要 → Telegram 推送
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│ RSS 源 │ → │ Miniflux │ → │ Python │ → │ Telegram │
│ (50+) │ │ (自托管) │ │ 脚本 │ │ 频道 │
└──────────┘ └──────────┘ │ + LLM │ └──────────┘
│ 摘要 │
└──────────┘Python 脚本定时（如每 30 分钟）通过 Miniflux API 拉取新条目，对感兴趣的条目调用 LLM 生成中文摘要，推送到自己的 Telegram 频道。你刷 Telegram 的时候就能扫完所有重要信息——但控制权握在你自己手里。
工作流 B：RSSHub + Huginn + 多通道分发
┌──────────┐ ┌──────────┐ ┌──────────┐
│ B站动态 │ → │ │ │ Telegram │
│ 知乎专栏 │ → │ Huginn │ → │ 邮件 │
│ Twitter/X │ → │ (过滤/ │ │ Slack │
│ 播客 │ → │ 转换) │ │ 本地归档 │
└──────────┘ └──────────┘ └──────────┘Huginn 是自托管的 IFTTT 替代品。你定义 Agent：RSS 源 → 过滤（保留含特定关键词的）→ 转换格式 → 分发给不同通道。较 IFTTT 的优势是数据完全本地，无限制，可编程。
工作流 C：Newsboat 终端全流
tmux 窗口 1 tmux 窗口 2 tmux 窗口 3
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Newsboat │ │ 终端浏览器 │ │ 笔记文件 │
│ (浏览条目) │ → │ (阅读全文) │ → │ (摘录+笔记) │
└──────────────┘ └──────────────┘ └──────────────┘
↓ ↓
AI 摘要脚本 Git 提交备份这个工作流的魅力在于：你不离开终端，就完成了从阅读到存档的全过程。Newsboat 支持播客下载（podboat），连音频内容都可以纳入这条管线。
信息管线不只是工具链——它是一种信息摄入的架构思维：
信息管线的最终目标不是"不错过任何东西"——这是不可能的。它的目标是让你对"你错过了什么"有完全的知情权和控制权。
RSS 不是万能的。它的局限源于它的核心设计原则——开放和简单——在特定场景下会变成短板。
| 局限 | 说明 | 应对方案 |
|---|---|---|
| 部分网站已取消 RSS | 大平台主动移除或屏蔽 RSS 输出 | RSSHub 生成桥接，或直接放弃该平台 |
| 仅输出摘要 | 只输出标题 + 一两句简介，打断阅读流 | Inoreader/FreshRSS 有"全文提取"功能，或部署 Mercury Parser |
| 没有互动功能 | 你不能在阅读器里点赞、评论 | RSS 是阅读层，不是社交层。想互动？点击链接回到原页面 |
| 订阅膨胀 | 加源太容易，很快被"几百条未读"淹没 | 定期清理 + 过滤规则 + 接受"读不完就跳过"的心态 |
| 不是实时 | 基于轮询，通常 15-60 分钟延迟。突发新闻不够快 | WebSub 协议可秒级推送，但支持有限。对博客内容完全够用 |
| 隐私风险 | 你的阅读器 IP 对源站可见；RSS 也可以嵌入追踪像素 | 自托管阅读器 = 只有你的服务器 IP 暴露；使用 Miniflux 等可禁用图片加载 |
| 图片/样式丢失 | 很多源输出纯文本或精简 HTML | 全文提取或直接打开原页面阅读 |
| 源可能不再更新 | 独立博客可能停更但 Feed 仍在 | Miniflux 可设置"超过 X 天无更新自动移除"规则 |
信心等级：高——这些局限是 RSS 协议本身的特性，而非实现缺陷。
RSS 用户最终都会遇到同一个问题：订阅了好几十个源，每天几百条未读，逐渐失去打开阅读器的动力。这不是 RSS 的问题，是缺乏信息卫生习惯的问题。
不要把所有源扔进一个收件箱。分出层级：
📁 每日必读（2-3 个源——每天必须扫完的）
📁 兴趣关注（10-15 个——有兴趣就看，没兴趣跳过）
📁 技术研究（特定领域深挖，少量高质量源）
📁 新闻资讯（时效性强，可以设置为每 2 小时更新）
📁 偶尔看看（无关紧要但不想取消订阅的——有空再看）每季度做一次"源清理"：
读不完不是你的错——是你订得太多了。削减源比找新源更需要勇气。
如果你现在想开始用 RSS，按这个节奏走——不需要一次性全部搞懂。
关于 RSS，最重要的一句话：它是你的信息自主权的最后堡垒。没有算法、没有推荐、没有广告、没有"你可能也喜欢"——只有你决定要看的东西，按你决定的顺序出现。它是 1999 年的技术，但在 2026 年的今天，它比任何"AI 推荐引擎"都更诚实地对待你的注意力。
docker-compose up 启动<value> 标签如何通过比特币闪电网络实现听众到创作者的直接打赏