企业官网建设流程全解析

你有没有过这种体验：一打开手机，资讯就自动涌上来，你今天看什么、先看谁、信什么，好像早被一张看不见的清单安排好了。我一度沉浸在算法推荐里，觉得它懂我的兴趣、知道我喜欢什么，直到某天发现自己连续一个月刷到的都是同一个圈层的观点，才猛地意识到——我已经把自己的注意力菜单，交给了别人去写。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 解决大部分问题，如果公众号是刚需再上 wewe rss，不要一上来就把工具箱买满。工具越多，维护量越大，最后容易把人劝退。

4. 从零搭建自己的 RSS 管道：选型、部署与启动

有了“造源”工具，接下来还缺两样东西：一个阅读器用于统一消费，以及一套合理的订阅源管理方式。

4.1 阅读器选型到底该怎么选

阅读器大致分两类：在线托管服务和自建服务。

在线服务以 Feedly、Inoreader 为代表，优点是上手快、App 齐全、移动端体验好；缺点是免费档有上限、数据在别人手里、时常插入推荐位和广告。自建服务以 FreshRSS、Miniflux、Tiny Tiny RSS 为代表，需要一台长期在线的服务器，但数据完全在自己手里，没有广告，也没有“你的订阅”之外的任何干预。

我最终选择了自建方案：服务器上跑一个 Miniflux 作为主力阅读器，加一个 RSSHub 提供自定义源。选 Miniflux 主要是因为它的界面极简、响应快、自带全文抓取和过滤规则，资源占用也很低，一步到位性比较好。FreshRSS 也不错，功能更全面，有插件系统，适合喜欢图形化设置的人。

说句公道话：不想维护服务器的，直接用在线服务完全没问题；只要你有耐心折腾服务器，自建的综合体验反倒更好。

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.yml：

version: "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_URL=postgres://miniflux:your_db_password@miniflux-db/miniflux?sslmode=disable - RUN_MIGRATIONS=1 - CREATE_ADMIN=1 - ADMIN_USERNAME=admin - ADMIN_PASSWORD=your_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 三层订阅策略：我现在的订阅结构参考

被过载教育之后，我把订阅源分成了三层，每一层的处理方式完全不同：

每周日晚抽十分钟做一次“源体检”：这个源最近两周有没有更新？更新质量是否还值得留在当前层级？该降级的降级，该搁置的搁置。

6.4 给新人的四条起步建议

最后我也总结不出什么漂亮的大道理，就是四条实操建议，每条都是我当时希望有人提前告诉我的：

• 先从少于十个源开始，跑顺了再加，不要高估自己的信息吸收量。
• 优先订阅你能持续读到三年以上的源，比如个人博客和开源项目，这类源的长期回报远高于新闻聚合。
• 把“稍后读”当成订阅的一部分。RSS 最适合做深度阅读，不适合追热点。
• 不要在工具选择上徘徊太长时间，Miniflux、FreshRSS、Feedly 任意选一个撑过第一周，都比反复横跳更重要。

现在每天打开阅读器，是我一天中为数不多全程不带“猜你喜欢”的数字时刻。那些排着队的未读文章来自我亲手挑选的作者和团队，没有插入式广告，没有情绪测试，没有为我精心准备的茧房。这种朴素的无聊感，恰恰是我在算法围困时代里找到的出口。

最后再分享一个我很喜欢的细节：RSS 阅读器永远不会问“你的兴趣是什么”，因为答案由你自己保管。而这份保管权，才是“信息主权”真正的内容。