公众号是中文互联网里最别扭的一种信息源：内容天天更，却没有一个像样的订阅出口。想按自己的节奏读、想给文章打标签、想看最近几天哪件事被反复提起，靠收藏夹和聊天记录基本做不到。WeRSS 做的就是这件事——不过要先说清楚，这个网址是它的线上文档站，主程序和文档源文件都在 GitHub 仓库里。

项目定位写得很明确：面向个人私有自托管场景的公众号内容整理与分析系统。订阅管理、摘要 RSS、标签、热点追踪、消息通知、后台管理，都在自己机器上跑。当前版本 v1.1.5，MIT 协议，Python 3.11+，仓库约 80 星、20 余次 fork——规模不大，但文档和默认配置比多数同量级项目克制得多。

一、先把边界讲在功能前面

这类工具最容易被误读，所以值得先把项目自己写的合规声明放在最前面。README 和文档站「概览」页都用加粗写明：项目只提供自托管软件与技术实现，不提供、不销售、不代运营任何第三方内容服务；订阅源、采集方式、频率、凭据、保存范围与再分发行为全部由部署者自行配置，用户只应在自己有权访问和使用的范围内启用。

几条硬边界照抄一遍：不得用于规避登录、验证码、访问控制或其他技术保护措施；不得批量抓取未授权内容、侵犯版权，或把第三方内容用于未经许可的商业分发；项目里出现「微信」「微信公众号」等名称只表示兼容对象，不代表与相关权利方存在授权、合作或背书。官方也明说不建议部署成公开内容聚合、全文转载或对外分发服务。

更值得留意的是它给的「低风险用法」清单：仅私有部署并启用登录认证、不开放匿名访问、不提供真实内容演示，默认关闭正文采集、RSS 全文输出、图片转存和导出；收到平台或权利方通知后及时删除内容并停止处理。换句话说，这套东西的设计目标是个人信息处理工具，不是内容站后台。后面所有能力，都应该放在这个前提下来看。

二、一条链路：从订阅到热点

文档站把主干流程画得很直白，按它整理成一条线：

订阅来源 → 定时采集 → 文章入库
              ↓
   标签提取（手动 / AI） ← 来源信息
              ↓
   标签聚类 ← 标签管理 ← 标签筛选
              ↓
   热点发现 ← 近期文章
              ↓
   RSS 输出 / 消息任务 / 导出与存储

几个环节各有讲究：

消息模板用 Jinja2 风格语法，既能按单个来源推，也能用 feeds_with_articles 变量把多个来源汇成一条日报；模板里不含这个变量时会回退到默认汇总模板，后台有「测试」可先预览渲染结果。这个设计比单纯「有新文章就推一条」安静得多。

三、界面：偏后台工作台，不是阅读器

数据概览把家底一次摊开：总文章数、来源数量、今日/本周新增，下面是来源分布饼图和抓取趋势气泡图。左侧导航是数据概览、文章列表、订阅管理、导出记录、标签管理、消息任务、配置信息、系统信息——一眼能看出它是管理后台，不是给你沉浸式刷文章用的。

热点页给的是关键词维度：上方按出现次数排列热门词，下方按日期做堆叠柱状图，可切一周/三十天、堆叠/折线。配合前面说的「事件型主题」，这类视图回答的是「这几天大家在聊什么」，而不是「今天有哪几篇新文章」。

文章列表则是日常工作区：按标题搜索、按状态或标签筛选，逐行看标题、来源、关键词、发布时间与状态，右侧是导出、订阅入口和批量删除。标签在这里既是筛选条件，也是后面聚类与热点分析的信号源。

仓库另附了深色主题的数据概览、订阅管理页截图，浅色深色是同一套后台的两种皮肤。

四、技术栈，以及默认关掉的那些开关

后端是 FastAPI + SQLAlchemy，浏览器自动化用 Playwright，定时任务交给 APScheduler；数据库可选 SQLite / MySQL / PostgreSQL，Playwright 浏览器支持 Firefox / Chromium / WebKit。前端是 React 18 + TypeScript + Vite，配 Tailwind CSS、Radix UI / shadcn/ui、React Router v6、Zustand 和 Axios。前后端分离，代码结构按 apis / core / jobs / driver / web_ui 分块，读代码时有个容易踩的坑：界面上叫「订阅」，落库的主实体其实是 Feed。

更能说明项目态度的是默认值。把配置模板里几项列出来：

也就是说，「多存一点、多分发一点」的能力都在，但每一次扩大数据范围都要自己动手打开。这种保守默认值和前面的合规声明是对得上的，比在文档末尾贴一行免责声明实在。

五、跑起来：三条路径

• 一键开发环境：克隆仓库后 ./start_dev.sh，前端在 localhost:5174，后端与接口文档在 localhost:8001（/api/docs）。这是官方推荐的上手方式。
• 手动安装：uv venv + uv sync（或 pip install -r requirements.txt），playwright install firefox，复制 config.example.yaml 为 config.yaml，设好 WERSS_USERNAME / WERSS_PASSWORD / DB，再用 python main.py 完成数据库初始化，然后启动服务。
• Docker：先从环境变量模板复制一份配置，再用 docker compose up -d 起完整栈，访问 8001；已有外部数据库或对象存储改用 docker-compose.app-only.yml，开发调试再叠 docker-compose.dev.yml。

配置优先级是环境变量高于 config.yaml，所以容器里改行为不必进文件。首次运行务必设管理员账号与密码；默认账号属于本地开发环境，别把它带到能访问到的网络里。

六、接口、MCP 与文档站

接口用 JWT（Authorization: Bearer）或 API Key（X-API-Key）鉴权，启动即有 Swagger UI、ReDoc 和 OpenAPI Schema。常用端点集中在 /api/v1/wx/ 下：认证、API Key 轮换、来源列表与详情、文章列表与复杂筛选、热点结果和手动重建；对外订阅出口是 /rss、/rss/{feed_id} 和 /feed/{feed_id}.xml。

另外还暴露了一个基于 Streamable HTTP 的远程 MCP 入口（GET/POST /mcp），可用 WERSS_MCP_TOKEN 加令牌、用 MCP_ALLOWED_ORIGINS 限制来源，工具覆盖 articles.list、tags.list、tag_clusters.visualization 等。想在自己的智能体里查文章、看聚类网络图，走这条路比自己拼 REST 省事。

回到尊上给的那个网址：文档站按角色分了四条阅读线——独立开发者、算法与模型工程、内容运营、技术决策者，另有核心概念、核心流程、架构概览、页面说明、API 与 MCP 参考。有一点很值得夸：概览里专门列了「已有能力 vs 规划中」，把基于 GLiNER 的轻量标签提取、微信内容自动生成、社区共建计划明确标成未实现，不把路线图当功能卖。

七、什么情况下别用它

它的前提是「你有权访问并保存这些内容，且只在自己机器上看」。想做公开聚合站、全文转载、对外分发或商业内容服务，不但超出项目建议范围，还可能直接踩到平台协议与版权红线。同理，如果你只是想找个 RSS 阅读器，这套带 Playwright、定时任务、对象存储和 AI 接口的后台显然过重。

但对已经在为几十个来源手动整理、又确实需要标签聚类和热点归纳的人来说，它把「订阅—整理—发现—输出」收进了一个可控的自托管后台，还把高风险能力默认关在门后。这种克制，在同类工具里反而是最少见的部分。

本文配图为官方仓库界面截图与线上文档站首页，均来自公开资料；页面未做像素级修改，仅统一格式、去除元数据并按需限宽，文中未复述项目页的推广与引导信息。

本文整理自公开资料并做重写，原始出处：https://letuswerss.github.io/werss/。文中配图已去除站点叠加水印与推广信息；版权归原作者所有。