你有没有过这种体验一打开手机资讯就自动涌上来你今天看什么、先看谁、信什么好像早被一张看不见的清单安排好了。我一度沉浸在算法推荐里觉得它懂我的兴趣、知道我喜欢什么直到某天发现自己连续一个月刷到的都是同一个圈层的观点才猛地意识到——我已经把自己的注意力菜单交给了别人去写。RSS 是我想起来的老办法。这篇文章不打算劝你卸载所有 App更不是让你回到只能靠收藏夹过日子的原始网络。它只想讲清楚一件事在算法围困的时代如何用 RSS 这套最朴素、最古老的订阅协议重新夺回属于你自己的信息选择权。文章会从算法推荐的问题讲起讲到为什么沉寂多年的 RSS 在今天反而值得重启再给你一份可以照着抄的自建订阅管道方案以及我在实际操作中踩过的坑。1. 算法推荐的隐性代价是谁在决定你每天读什么很多朋友觉得算法推荐没什么不好——省事、精准、总能推送我感兴趣的内容。这个想法没错关键是“省事”和“精准”背后藏着一笔你没有意识到的交换推荐系统优化的是平台的指标不是你的认知质量。1.1 推荐系统真正在优化的指标推荐系统在机器学习领域的核心目标通常是点击率、阅读时长、互动率、留存率。平台的商业模式是广告或会员只有让用户停留更久、点更多商业循环才转得下去。也就是说系统向你推荐内容的逻辑是“这个东西更容易让用户多停留”而不是“这个东西对用户长期价值更高”。这两者大多数时候并不一致。一篇情绪化、观点极化的短内容比一篇严肃的长文更容易让人看完并转发一个和你立场完全一致的作者比一个跟你唱反调的作者更能让你停留。推荐系统会持续放大这些特征于是你刷到的内容越来越“对了口味”也越来越缺少意外的碰撞。1.2 “猜你喜欢”背后的信息窄化闭环“猜你喜欢”听起来很贴心但它本质上是一个闭合的反馈循环你点了一个内容系统记录一次你不点系统就减少同类内容的展示。结果是你看到的世界越来越接近“系统以为你喜欢的世界”而不是真实世界的全貌。举个很实在的例子同一个社会事件发生之后不同的人刷到的报道角度可以完全不同有人看到的是一边倒的声音有人看到的是另一边的分析。客观事实没有被改变改变的是每个人接收信息的入口宽度。时间拉长之后这种窄化会变成一种习惯性的思维方式——你会慢慢觉得自己常看到的那个角度就是最完整、最合理的角度。1.3 信息主权到底丢了什么所谓信息主权听起来很宏大落到日常其实就是四样东西选择权今天看什么、不看什么由谁拍板。透明度系统背后的推荐依据是什么你是否看得到。回溯能力你过去看过什么、当时为什么关注是否还能随时翻阅。创作者生态你的注意力有没有回报给真正持续输出的作者而不是被平台转包。在纯算法推荐的环境里这四样几乎全部被平台接管了。刷过即忘、看过即无痕你以为自己在主动获取信息实际上只是在一个预设好的传送带上被动接收。这就是“围困”的真实含义——不是有人禁止你看什么而是默认的决策权已经悄悄转移了。2. RSS 为什么被冷落又凭什么卷土重来既然题材带上了 RSS那就先把 RSS 到底是什么说清楚。它不新潮恰恰相反它是互联网早期的“老古董”但老古董能活到今天是因为它的设计逻辑足够朴素。2.1 RSS 的运作机制三分钟讲清RSS 全称 Really Simple Syndication本质上是一份遵循 XML 格式的文档。网站把最新文章的标题、链接、摘要、发布时间写进这份文档里读者只需要一个“订阅器”阅读器定期去这些地址看一眼有没有更新有就拿回来按时间排列给你。整个模型是“拉”而不是“推”你去订阅你来决定订阅谁阅读器按你的清单去取内容。没有暗箱没有中间页没有“根据你的历史行为调整权重”。你打开阅读器看到的那几十条内容就是你自己选定的那几十个来源的更新一条不多一条不少。2.2 被冷落的原因流量逻辑和订阅逻辑天然冲突RSS 在博客时代曾经是绝对主力2004 年到 2010 年之间几乎所有博客、新闻站都提供橙色的 RSS 图标。转折点是 2013 年 7 月 Google Reader 被关闭——这个事件像多米诺骨牌一样让大量普通用户失去了使用 RSS 的习惯入口也吓退了不少围绕 RSS 做产品的团队。但更深层的原因不是用户不爱 RSS而是 RSS 拆了平台流量的台。订阅意味着用户可以在阅读器里看完文章不需要一次次点进网站网站就少了展示广告、引导关注、推荐关联内容的机会。相比之下算法信息流把用户留在站内反复刷新广告展示次数可以无限拉高。换成你是平台你也会慢慢弱化甚至关闭 RSS 出口。这个选择无关道德是商业逻辑。2.3 为什么今天反而是重启 RSS 的好时机沉寂几年之后再回来看RSS 的缺点一个没变不美观、不智能、需要自己动手。但它的优点在今天显得格外值钱可控、稳定、可追溯、不干预判断。第一信息茧房问题已经普遍化很多人开始主动想要“数组型”摄取而不是被喂养。第二AI 生成内容泛滥之后平台内容质量波动变大订阅一个固定作者、固定领域的源至少能保证来源可信。第三你自己的阅读历史本身就是数字资产。用 RSS 看过的文章始终留在数据库里关键词一搜就能找回来刷过的算法信息流过三天就再也找不到入口了。所以我认为RSS 不是“死而复生”而是它的价值在环境变差之后重新被看见了。3. 现实困境RSS 真的还活着吗以及怎么自救决定重拾 RSS 之后第一个现实问题很快砸过来很多我想订阅的内容根本没有 RSS 输出。公众号没有热榜没有App 内资讯没有。还好这个问题有解法。3.1 现在还有哪些高质量 RSS 源先说不缺 RSS 的领域这些是新手起步时最舒服的入口个人博客尤其是技术、写作、设计类博主很多仍然把 RSS 作为默认输出。开源项目GitHub 的 Release 更新、仓库讨论、commit 动态都可以转成 RSS。学术文献arXiv 等预印本平台自带 RSS跟在某个领域的最新研究非常方便。播客几乎所有播客都有基于 RSS 的订阅地址这是播客行业的基础设施。部分新闻媒体、行业网站、政府公告、天气预报等仍保留标准输出。这几类来源都有同一个特点内容生产者希望内容被稳定、完整地分发出去RSS 恰好是成本最低、最不依赖平台算法的渠道。3.2 封闭平台自救指南RSSHub 与 wewe rss如果你的目标主要是公众号、微博、知乎热榜这类封闭生态就需要自己动手把内容“造”成 RSS 源。RSSHub 是目前社区最成熟的开源方案。它像一台万能转换器针对不同站点写了很多适配规则你给它一个路由参数它还你一个 RSS 地址。部署方式非常标准Docker 跑一个服务映射端口然后按文档填路由就能用。社区路由数量已经相当可观从技术资讯、漫画更新、交通公告到游戏公告都能覆盖。wewe rss 则是另一条思路它专注解决微信公众号内容无法通过标准方式订阅的问题把公众号更新聚合成可阅读的 RSS 服务部署上来比 RSSHub 稍重一些但针对公众号场景做了更多阅读体验优化。如果你恰好最常读公众号且受够了订阅助手的折叠和杂乱排版可以考虑它作为补充。注意这类工具部署在自己掌控的服务器上数据、日志和使用记录都留在自己手里这也是“信息主权”在工具层面最直接的体现。3.3 造源方案怎么选我把几种常见思路整理成一个对比表方便你按自己情况快速判断选哪种。方案适用场景部署难度维护成本适合谁RSSHub大量通用网站转 RSS低一个容器低多数人首选wewe rss微信公众号内容聚合中中公众号重度读者Huginn高度定制化抓取高高有编程经验的人自写脚本特定站点、定制格式高高愿意折腾的极客我的建议是先部署 RSSHub 解决大部分问题如果公众号是刚需再上 wewe rss不要一上来就把工具箱买满。工具越多维护量越大最后容易把人劝退。4. 从零搭建自己的 RSS 管道选型、部署与启动有了“造源”工具接下来还缺两样东西一个阅读器用于统一消费以及一套合理的订阅源管理方式。4.1 阅读器选型到底该怎么选阅读器大致分两类在线托管服务和自建服务。在线服务以 Feedly、Inoreader 为代表优点是上手快、App 齐全、移动端体验好缺点是免费档有上限、数据在别人手里、时常插入推荐位和广告。自建服务以 FreshRSS、Miniflux、Tiny Tiny RSS 为代表需要一台长期在线的服务器但数据完全在自己手里没有广告也没有“你的订阅”之外的任何干预。我最终选择了自建方案服务器上跑一个 Miniflux 作为主力阅读器加一个 RSSHub 提供自定义源。选 Miniflux 主要是因为它的界面极简、响应快、自带全文抓取和过滤规则资源占用也很低一步到位性比较好。FreshRSS 也不错功能更全面有插件系统适合喜欢图形化设置的人。维度MinifluxFreshRSS在线托管服务资源占用低中无需自管APP 生态一般PWA 为主一般很好过滤/全文处理强强较弱数据自主性完全自主完全自主依赖平台说句公道话不想维护服务器的直接用在线服务完全没问题只要你有耐心折腾服务器自建的综合体验反倒更好。4.2 部署 RSSHub 与 wewe rss先说 RSSHub。假设你已经有一台装好了 Docker 的服务器最简单的方式是docker run -d --name rsshub \ -p 1200:1200 \ -v $(pwd)/rsshub_data:/app/data \ --restart unless-stopped \ diygod/rsshub:latest启动之后访问http://你的服务器IP:1200能看到路由列表和测试页面说明服务已经正常。RSSHub 具体支持哪些站点直接去文档填路由参数即可地址形如/github/release/用户名/仓库名。wewe rss 更复杂一点需要按项目 README 准备数据库和账号配置项。它本身的部署核心也是 Docker Compose先git clone项目仓库再编辑docker-compose.yml和环境变量文件最后docker compose up -d拉起来。完成之后打开管理页面按界面提示把公众号内容接入它会自动生成对应的 RSS 订阅地址。提示服务器部署之后建议第一时间配好域名和 HTTPS否则订阅地址走 http 在手机端很容易被当作不安全链接对待后续使用会很别扭。4.3 部署阅读器Miniflux 的 Docker Compose 实战Miniflux 需要 PostgreSQL官方推荐用 Docker Compose 一次把两个服务都拉起来。这里给一份可以直接改用的docker-compose.ymlversion: 3.8 services: miniflux-db: image: postgres:15-alpine environment: POSTGRES_DB: miniflux POSTGRES_USER: miniflux POSTGRES_PASSWORD: your_db_password volumes: - miniflux-db-data:/var/lib/postgresql/data restart: unless-stopped miniflux: image: miniflux/miniflux:latest ports: - 8080:8080 environment: - DATABASE_URLpostgres://miniflux:your_db_passwordminiflux-db/miniflux?sslmodedisable - RUN_MIGRATIONS1 - CREATE_ADMIN1 - ADMIN_USERNAMEadmin - ADMIN_PASSWORDyour_admin_password depends_on: - miniflux-db restart: unless-stopped volumes: miniflux-db-data:执行docker compose up -d之后浏览器打开http://你的服务器IP:8080就能进入登录页。首次登录后第一件事是进入设置页修改站点地址和时区再添加订阅源。把 RSSHub 生成的地址贴进“添加订阅”框阅读器会自己抓取并拉回历史文章。4.4 第一次启动OPML 导入与订阅治理如果你之前有用过其他阅读器可以先把订阅源导出成 OPML 文件再在 Miniflux/FreshRSS 里导入几十个源几分钟就迁移完了。但比导入更重要的是“治理”。订阅源不是越多越好我的做法是先把所有源丢进未分类然后花一个晚上逐条判断这篇内容如果连续一周不出现我会不会想念它会保留不会删除。这个筛选过程本身就是一次信息主权的复盘做完之后你会对手头的信息目录有非常清醒的认识。5. 让 RSS 真正“能打”的进阶玩法很多人刚换到 RSS 会觉得它“太朴素”用一段时间又觉得“不够聪明”。其实它的朴素就是它的优点你再给它加一点处理规则它完全可以变成一个比算法推荐更高效的个人情报中心。5.1 从摘要 Feed 到全文解决“只给标题和摘要”的痛点不少网站的 RSS 只输出摘要想读全文得点回原站。在 Miniflux 里这个问题的解法是开启“抓取原文”Fetch Original Article选项。它会对每篇文章抓取正文内容去掉页头页脚和广告模块直接把全文放进阅读器。但这个功能偶尔会误抓尤其是排版怪异的站点。我的习惯是默认关掉全文抓取只对少数几个经常只发摘要的源单独开启。这样既不会因为某个站改版导致格式混乱也能保证重点内容看得完整。5.2 过滤规则在信息进来之前就做好分层订阅量稍大之后信息噪音会重新出现但 RSS 时代的噪音和算法时代的噪音不一样——前者是可控的后者是你无法干涉的。可控意味着可以用规则解决。Miniflux 的过滤规则支持按标题、正文、URL 等字段匹配可以执行标记为已读、标记星标、应用标签等动作。FreshRSS 也有类似的自定义过滤器和标签系统。我常用的一种做法是给“必读作者”的文章单独打标签并设置成未读高亮给某些只在自己想集中注意力时才能看的主题打上“慢读”标签平时进来不会被它们淹没。5.3 归档、搜索与读后留痕RSS 订阅久了你实际获得的是一个持续累积的个人资料库。Miniflux 把所有文章落在 PostgreSQL 里支持跨所有源的关键词搜索。你年初看过的一篇关于项目架构的文章半年后想翻出来只需要输入标题里记得的两个词就能定位到——这在算法信息流里几乎是不可能的。归档同样重要。数据库能跑全靠你备份。给 Miniflux 容器加一个定期导出数据库的定时任务或者直接把卷目录纳入备份工具都行。5.4 可持续使用的“低维护”原则自建 RSS 系统的最大风险不是技术难度而是你不想维护了留下一堆半死不活的服务。所以一开始就要控制复杂度服务数量控制在三个以内造源头、阅读器、数据库各一个。不要为了某个网页特意造一台专用抓取机器先用 RSSHub 的现成路由不够再定制。给每个自建服务写一个简单的手记记录端口、数据卷位置、重启命令。这套系统半年不出事你就很容易忘记它的结构配一份手记等于买保险。这套系统现在运行快一年我只在升级镜像时重启过两次平时基本不怎么管它。它不智能但足够稳定。6. 一段真实踩坑记录我的 RSS 回归之路技术层面的事讲得差不多了最后聊聊我自己的踩坑经历这些才是没人写进文档里的东西。6.1 一上来就订阅上百个源信息过载的第二轮爆发刚开始重拾 RSS 的时候我有点报复性地订阅了一百多个源——技术博客、新闻站、公众号、个人网站全塞进来。结果可想而知每天打开阅读器面对几百条未读反而比刷算法信息流更焦虑。RSS 没有算法替我过滤意味着过滤责任全都落在我自己身上我还没准备好。后来我老老实实把订阅数砍到一半再砍到每天打开阅读器只看到三四十条未读的规模。这时候 RSS 才真正变成一种“控制感”而不是另一种“被推送”。6.2 Feed 失效、图片失效和抓取不稳RSS 源最大的天敌是时间。网站改版、域名过期、作者停更都会让一个源慢慢失效。RSSHub 的社区路由偶尔也会因为平台页面结构调整而抓不到内容需要手动去社区提 issue 或者等待作者更新。图片防盗链则是另一个隐藏坑。很多网站的图片做了 Referer 校验在浏览器里能正常看放到阅读器里就裂开。遇到这类问题别急着骂工具先在浏览器里试试直接打开图片地址大概率是防盗链而非程序问题。6.3 三层订阅策略我现在的订阅结构参考被过载教育之后我把订阅源分成了三层每一层的处理方式完全不同层级规模处理方式必读层5-8 个每天固定时间全部读完高优先级精选层15-20 个每周扫两到三次有空才细读灵感层20-30 个只在搜索某个主题时主动翻不追求读完每周日晚抽十分钟做一次“源体检”这个源最近两周有没有更新更新质量是否还值得留在当前层级该降级的降级该搁置的搁置。6.4 给新人的四条起步建议最后我也总结不出什么漂亮的大道理就是四条实操建议每条都是我当时希望有人提前告诉我的先从少于十个源开始跑顺了再加不要高估自己的信息吸收量。优先订阅你能持续读到三年以上的源比如个人博客和开源项目这类源的长期回报远高于新闻聚合。把“稍后读”当成订阅的一部分。RSS 最适合做深度阅读不适合追热点。不要在工具选择上徘徊太长时间Miniflux、FreshRSS、Feedly 任意选一个撑过第一周都比反复横跳更重要。现在每天打开阅读器是我一天中为数不多全程不带“猜你喜欢”的数字时刻。那些排着队的未读文章来自我亲手挑选的作者和团队没有插入式广告没有情绪测试没有为我精心准备的茧房。这种朴素的无聊感恰恰是我在算法围困时代里找到的出口。最后再分享一个我很喜欢的细节RSS 阅读器永远不会问“你的兴趣是什么”因为答案由你自己保管。而这份保管权才是“信息主权”真正的内容。