Runtime & hosting — 云端全自动闭环,与一条需要常开机器的可选支线
每日舆情发现、AI 预分类、入库、首页更新、站点部署、日报盘点、全部门禁 —— 都跑在 GitHub Actions 与 Cloudflare Pages 上。 关掉所有本地机器,系统照常出结果。
暂缓自托管社媒线(微博官微直采)已实测打通但暂不接线 —— 它要求一台 24×7 醒着的机器,与"零本机依赖"冲突。管道与手册就位,想开随时两步接上, 见第 4 节。
这一页回答一个很实际的问题:这套系统到底靠什么在转,断了谁会停。 系统怎么打分在系统如何运作那一页。
flowchart TB
subgraph CLOUD["☁️ 全部跑在云端 · 无需任何本机"]
direction TB
D["每日 10:17 北京
舆情发现
四路召回"]
C["AI 预分类
维度 / 严重度 / 方向
全部标注 model-judged"]
F["折入事件库
重算 id · 重生成首页舆情条"]
P["开 PR → CI 绿 → 自动合并"]
S["Cloudflare Pages
推 main 即部署"]
R["每日 09:00 北京
日报盘点
从 git 派生"]
D --> C --> F --> P --> S
end
P -.->|"累积到阈值"| T["建议重审
首页亮灯"]
T --> H["人发起重审
评委 in-character 打分"]
H --> V["新版本 vN+1"]
V --> S
style H fill:#fff7ed,stroke:#c1440e,stroke-width:2px
style CLOUD fill:#fbf9f4,stroke:#111
橙色框是唯一需要人的环节 —— 也是分数唯一会变的地方。
| 何时 | 干什么 | 人工介入 |
|---|---|---|
| 每日 10:17(北京) | 四路召回(媒体 / 官方新闻室 / 官网直采 / 知乎)→ 候选 → AI 预分类 → 折入事件库 → 重生成首页舆情条 → 开 PR | 无,CI 绿后自动合并 |
| 每日 09:00(北京) | 从 git 派生前一日工作盘点 | 补充说明人工补 |
| 手动触发 | L1 预筛:哪些品牌够格触发重审 | 读结论的人 |
| 每个 PR / push | 反捏造防火墙 · 结构质量 · 舆情校验 · 一致性守卫 · 报告完整性 | 修红的人 |
推 main | 站点部署 | 无 |
三个出口也都在云上:网站(Cloudflare Pages)、JSON API(随站点静态发布)、 MCP server(npm 包)。没有一台需要自己维护的服务器。
前两条不影响"日常运行零本机依赖" —— 它们由人主动发起,不是每天必须发生的事。
管道、门禁、手册全部就位,也已经端到端实测打通: 从公网侧拉自托管 RSSHub,微博路由返回 10 条真实条目,再过本项目的解析器 —— 日期全部归一、链接可核。技术上没有问题。
| 完全线上(当前) | 加上本机社媒线 | |
|---|---|---|
| 依赖 | 只依赖 GitHub + Cloudflare | 多一台必须 24×7 醒着的机器 |
| 失效模式 | 平台故障 —— 罕见,且全网可见 | 睡眠 / 断网 / cookie 过期 / IP 被风控 —— 静默,靠哨兵喊 |
| 拿到的信号 | 媒体 + 官方新闻室 + 官网直采 + 知乎 | 多出品牌官微一手发布 |
| 运维 | 0 | 升级镜像、换密钥、盯哨兵 |
当前选择:保持零本机依赖。 这是取舍,不是缺陷 —— 少一个信号源,换掉一整类静默失效。
下面是全过程,想开的时候照做即可。约 20 分钟。 顺序不能换 —— 先上锁再暴露到公网,否则中间有一段裸奔窗口。
KEY=$(openssl rand -hex 24); echo "$KEY" # 记到密码管理器
docker rm -f rsshub
docker run -d --name rsshub --restart unless-stopped -p 1200:1200 \
-e ACCESS_KEY="$KEY" diygod/rsshub:chromium-bundled
curl -s -o /dev/null -w "无 key → %{http_code}\n" "http://localhost:1200/weibo/user/<uid>"
curl -s -o /dev/null -w "带 key → %{http_code}\n" "http://localhost:1200/weibo/user/<uid>?key=$KEY"
镜像必须是 :chromium-bundled,不是 latest —— 新版微博路由走
Playwright 抓 m.weibo.cn,latest 没打包浏览器、直接报错。
验收看返回码:无 key 必须非 200。若无 key 也 200,说明这版鉴权参数名不是
key(历史上有两种)—— 查官方文档,别硬猜。以返回码为准,不以指南为准。
macOS 装不上 Docker Desktop(brew 要 sudo 去链 /usr/local/bin)?
用 OrbStack,更轻、免 sudo,docker 命令完全一样。
Cloudflare Dashboard → Zero Trust → Networks → Tunnels → Create a tunnel → 取名 → 保存后复制它给的 token。
⚠️ 不要用页面给的 cloudflared service install —— 它要写
/Library/LaunchDaemons、需要 sudo。改用:
cloudflared tunnel run --protocol http2 --token <你的 token>
--protocol http2 往往是必需的:cloudflared 默认走 QUIC(UDP 7844),
很多网络把它阻断,表现为隧道建不起来或时断时续。连不上先试这个,别怀疑 RSSHub。
隧道 HEALTHY 后加 Public Hostname:子域 rsshub + 你的域名 →
HTTP → localhost:1200。DNS 记录 Cloudflare 自动建。
第 2 步那条命令跑在前台,关终端就停。用用户级 LaunchAgent
(~/Library/LaunchAgents/,不需要 sudo)常驻,完整 plist 见
docs/29 §3。
plist 里是明文 token,记得 chmod 600。
机器必须在北京 10:17 醒着(每日发现的时刻)。系统设置里打开 "接通电源时防止自动进入睡眠"即可 —— 这项不需要命令行、不需要 sudo。 笔记本合盖仍会睡,长期跑建议插电常开或换台常驻机器。
本机 curl 通 ≠ GitHub Actions 通 —— 云上走的是公网这一侧。 用手机流量或另一台机器测,家里 WiFi 可能命中本地 DNS,测不出真实路径。
curl -s -o /dev/null -w "healthz → %{http_code}\n" https://<域名>/healthz
curl -s -o /dev/null -w "无 key → %{http_code}\n" "https://<域名>/weibo/user/<uid>"
curl -s "https://<域名>/weibo/user/<uid>?key=<KEY>" | head -40
三条同时满足才算过:healthz 200 · 无 key 非 200 · 带 key 出含
<item> 的真实条目。
本项目仓库是公开的,而 RSSHub 的 key 必须跟在 URL 上 —— 直接写进配置文件 等于公开发布密钥。机制:配置里只存占位符,真值放 Actions secrets。
# GitHub → Settings → Secrets and variables → Actions
# Name: RSSHUB_KEY Secret: 第 1 步那串
# 配置文件里只写占位符:
rss_feeds:
- https://<域名>/weibo/user/<官微uid>?key=${RSSHUB_KEY}
两道保险:门禁会拦住任何明文密钥(CI 直接红);哨兵在变量没配时 跳过该源并明确喊"环境变量未设置",而不是拿空 key 去请求 —— 空 key 会被拒,那会把配置错误伪装成路由故障,排错追错方向。
浏览器打开该品牌官方微博主页,地址栏形如 weibo.com/u/1746173800,
u/ 后面的数字就是 uid。别抄别处给的 uid,自己从主页地址栏确认 ——
抄错了等于监控了别人家。
候选会标 source_type: social,与知乎共用"社区 ≤1/4 名额" ——
但桶内自备源排在知乎泛查询之前(否则知乎召回量大的品牌会把微博条目
100% 静默挤掉:源确实抓到了,只是没进候选,哨兵还不会响)。
每品牌候选总量不变,下游成本不涨。
ACCESS_KEY 是唯一一道门 ——
不配等于开放代理,别人能用你的 IP 和带宽去请求微博。
不是"越多源越好"。满足下面任一条再开:
反过来,如果只是"想多一个源",按第 3 节那张表算账,不划算。
相关: 系统如何运作 · 全站舆情驾驶舱 · docs/30 完全线上运行 · docs/29 命名隧道手册。