MBA 在哪里运行

Runtime & hosting — 云端全自动闭环,与一条需要常开机器的可选支线

当前状态完全线上运行,零本机依赖。

每日舆情发现、AI 预分类、入库、首页更新、站点部署、日报盘点、全部门禁 —— 都跑在 GitHub ActionsCloudflare Pages 上。 关掉所有本地机器,系统照常出结果。

暂缓自托管社媒线(微博官微直采)已实测打通但暂不接线 —— 它要求一台 24×7 醒着的机器,与"零本机依赖"冲突。管道与手册就位,想开随时两步接上, 见第 4 节

这一页回答一个很实际的问题:这套系统到底靠什么在转,断了谁会停。 系统怎么打分在系统如何运作那一页。

目录

  1. 云端跑什么:一张时刻表
  2. 哪些事不在云上(诚实边界)
  3. 社媒线为什么暂缓
  4. 可选支线:自托管 RSSHub 完整接入指南
  5. 什么时候值得开

01云端跑什么:一张时刻表

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 包)。没有一台需要自己维护的服务器。

02哪些事不在云上(诚实边界)

1
评委重审 —— 人发起审计是人跑 skill 触发的。这是设计如此:分数从不自动变,舆情只能提出"建议重审",不能自己改分。
2
一手取数 —— 开发动作抓原文、深化评委档案,需要能出网的会话。这些是开发动作,不是每日流水线的一环。
3
自托管社媒线 —— 暂缓唯一真正需要"一台常开机器"的东西。见下。

前两条不影响"日常运行零本机依赖" —— 它们由人主动发起,不是每天必须发生的事。

03社媒线为什么暂缓

管道、门禁、手册全部就位,也已经端到端实测打通: 从公网侧拉自托管 RSSHub,微博路由返回 10 条真实条目,再过本项目的解析器 —— 日期全部归一、链接可核。技术上没有问题。

问题不是技术,是依赖。 RSSHub 跑在你自己的机器上,隧道从你家出口连出去 —— 机器睡了、断网了、搬家了,当天这条源就没了。这与"完全线上、零本机依赖"直接冲突
完全线上(当前)加上本机社媒线
依赖只依赖 GitHub + Cloudflare多一台必须 24×7 醒着的机器
失效模式平台故障 —— 罕见,且全网可见睡眠 / 断网 / cookie 过期 / IP 被风控 —— 静默,靠哨兵喊
拿到的信号媒体 + 官方新闻室 + 官网直采 + 知乎多出品牌官微一手发布
运维0升级镜像、换密钥、盯哨兵

当前选择:保持零本机依赖。 这是取舍,不是缺陷 —— 少一个信号源,换掉一整类静默失效。

04可选支线:自托管 RSSHub 完整接入指南

下面是全过程,想开的时候照做即可。约 20 分钟。 顺序不能换 —— 先上锁再暴露到公网,否则中间有一段裸奔窗口。

第 1 步 · 起服务并先上锁(ACCESS_KEY)
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 命令完全一样。

第 2 步 · 建命名隧道(避开需要 sudo 的那条命令)

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 + 你的域名 → HTTPlocalhost:1200。DNS 记录 Cloudflare 自动建。

第 3 步 · 免 sudo 开机自启(macOS LaunchAgent)

第 2 步那条命令跑在前台,关终端就停。用用户级 LaunchAgent (~/Library/LaunchAgents/,不需要 sudo)常驻,完整 plist 见 docs/29 §3。 plist 里是明文 token,记得 chmod 600

机器必须在北京 10:17 醒着(每日发现的时刻)。系统设置里打开 "接通电源时防止自动进入睡眠"即可 —— 这项不需要命令行、不需要 sudo。 笔记本合盖仍会睡,长期跑建议插电常开或换台常驻机器。

第 4 步 · 公网侧三段验收(这一步不做等于没验证)

本机 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> 的真实条目。

第 5 步 · 密钥交给 GitHub,绝不进仓库

本项目仓库是公开的,而 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 会被拒,那会把配置错误伪装成路由故障,排错追错方向。

第 6 步 · 找官微 uid,先配 1~2 个品牌观察一周

浏览器打开该品牌官方微博主页,地址栏形如 weibo.com/u/1746173800, u/ 后面的数字就是 uid。别抄别处给的 uid,自己从主页地址栏确认 —— 抄错了等于监控了别人家。

候选会标 source_type: social,与知乎共用"社区 ≤1/4 名额" —— 但桶内自备源排在知乎泛查询之前(否则知乎召回量大的品牌会把微博条目 100% 静默挤掉:源确实抓到了,只是没进候选,哨兵还不会响)。 每品牌候选总量不变,下游成本不涨。

风险由使用者拍板。 自动化抓取违反微博 / 小红书服务条款;配 cookie 的账号可能被风控。 隧道 URL 公网可达,ACCESS_KEY 是唯一一道门 —— 不配等于开放代理,别人能用你的 IP 和带宽去请求微博。

05什么时候值得开

不是"越多源越好"。满足下面任一条再开:

反过来,如果只是"想多一个源",按第 3 节那张表算账,不划算

全线不变的边界。 标题 / 日期 / 链接逐字取自源,不改写不翻译; 维度、严重度、方向是 model-judged 分类并明确标注; 审计分数从不自动变 —— 分数的每一次变化都来自评委重新 in-character 打分。

相关: 系统如何运作 · 全站舆情驾驶舱 · docs/30 完全线上运行 · docs/29 命名隧道手册