💬 云电脑潜在触达监控 · 操作逻辑

无影云电脑「潜在触达（二次触达）」通道的健康脉搏 · 由 Vercel 服务端 cron 定时驱动 · 卡片由「云电脑潜在触达监控」机器人发 · 2026-06-18
一句话：每 8 小时（北京 08:00 / 16:00 / 24:00）自动盘一次「潜在触达」通道—— 上一窗口成功触达了几个人、节奏到没到顶、有没有异常，固定推一张卡（由「云电脑潜在触达监控」发）。 和 DM 监控「健康即静默」不同：这是定时脉搏，平稳日也推一张绿卡确认「活着」。 判定全是确定性代码，不调用大模型、不花钱。

它和「DM 监控」不是一个东西（先分清）

🖥️ 云电脑监控（同事那个）
监 一触 DM 通道 · 本机 Hermes 每 10min · 每条新发秒推 live 播报 · 健康即静默，只有出事才告警 · 走只读接口 /api/public/cloud-pc-status。
💬 潜在触达监控（本页）
监 潜在触达（对方视频 点赞+评论1+评论2）· Vercel 服务端 cron 每 8h · 汇总一窗口而非秒推 · 定时脉搏，总是推 · cron 自带 DB 权限，不需要公开接口/不建表。
为什么不照搬秒推：PM 决策走 8h 汇总（明确不要 10min 高频）。cron 在服务端，不依赖谁的电脑开着，24h 在线。

一次巡检的完整流程（每 8 小时跑一遍）

⏰
Vercel Cron 定时触发
路由 /api/cron/second-touch-monitor，节奏 0 0,8,16 * * *（UTC）= 北京 08:00 / 16:00 / 24:00。每次汇报前 8h 窗口。
▼
🔍
直查数据库（service-role，只读）
读：账号状态 / 是否开自驱 / 窗口内成功触达（second_touch_state.last_touch_at）/ 今日·24h 计数 / 队列 pending·claimed / 窗口内 failed·skipped。只读，不改库、不发抖音。
▼
⚖️
套确定性规则判异常
按下表判 5 类异常；夜间窗口（北京 08:00 那一跑报的是 00:00–08:00）只报号被禁，不报操作类（没人指望夜里发）。
▼
📤
拼一张卡，由「云电脑潜在触达监控」机器人推到其所在群
由专属「云电脑潜在触达监控」群 webhook（LARK_WEBHOOK_AKKE_SECOND_TOUCH_MONITOR，绕开应用 API 配额）发出。任一查询读失败 → 卡上声明「本轮未判全」，不冒充健康。
▼
🟢 无异常
绿卡：报窗口成功条数 + 明细 + 节奏，异常段写「✅ 无异常」。平稳日也推——这是定时脉搏，不是静默。
🟠/🔴 命中异常
卡变橙（warn）或红（号被禁），异常段逐条列「症状 + 怎么查」。最多延迟 8h 才现形——要实时盯 agent 死活看 wuying-agent-watchdog。

什么会告警 / 什么不会（异常判定）

情况级别判定逻辑
号不可发（被禁/冷却）🔴 告警账号 status ≠ active
没开自驱🟠 告警channel_pref ≠ cloud_pc（不会自动派二触）
有料没发 · 停摆🟠 告警队列有 pending/claimed，但全局 last_touch_at > 3h 没动（仅活跃窗口）
失败堆积🟠 告警窗口内 failed + skipped ≥ 5 条（误身份门 / no_works / 跳验证的 DB 投影）
活跃时段 0 触达🟠 告警成功 = 0 且队列有候选在途 且号正常（仅活跃窗口）
没料可发（池子空）不报队列空（backlog=0）→ 成功 0 但不是故障，绿卡
到日限 / 节奏限速不报正常完成 / 正常限速，不是故障
e2e 时效拉长不报只在卡上列数字，不当异常
和看门狗的分工：wuying-agent-watchdog（每 5min）已经管「agent 崩死 / 卡 claimed」的实时告警，推云电脑监控群。本卡不重复造，只补它没覆盖、且值得进 8h 视野的健康面，所以异常最多延迟 8h——它是脉搏不是传呼。

「成功触达」是怎么落库的

无影 GUI agent 在对方视频做完 点赞 + 评论1（评视频）+ 评论2（顺到产品） 后回写 → 串接 mark_second_touch(touched) → 写 second_touch_state： last_touch_at 推进、touch_count++、记 last_e2e_minutes（视频发布→触达的分钟数）。
为什么用 second_touch_state 当成功口径： 它是自动队列回写和手动 mark-second-touch 收尾两条路径的唯一汇合点（都过同一个 RPC）。盯它 = 两条路都不漏。

跳验证 / 异常时：能检测吗？

问题回答
能直接看到验证弹窗吗？不能 监控在服务端只读 DB，看不到无影屏；抖音跳验证不往库写「captcha」标记。
能间接发现吗？能 验证挡住发送 → 单子卡 claimed / 窗口内冒一批 failed·skipped → 停摆 / 失败堆积规则命中；agent 真崩 wuying-agent-watchdog 5min 内先报。
本卡能精确说是跳验证吗？不能精确分 只会报「停摆 / 失败堆积」，跳验证是其中一种可能，需人去无影确认。
两个盲区：① 本卡滞后最多 8h（实时靠看门狗补）；② 队列空时没有「卡住」信号 → 那一刻跳验证不报（但也没单可发，影响小）。

当前监控对象

饭粒（一筑·全屋定制）
二触日限 20   状态 ✅ active · cloud_pc
（暂只一台）
以后加号 改 env 或扩成遍历所有 cloud_pc 号
换/加监控号：改 Vercel env SECOND_TOUCH_MONITOR_ACCOUNT_ID；要多号一起监控，把路由改成遍历 getCloudPcAccounts() 每号一张卡。

关键组件 & 常用命令

⏰ 调度：Vercel Cron · 0 0,8,16 * * * 🔍 路由：src/app/api/cron/second-touch-monitor/route.ts 🃏 卡片：notifySecondTouchMonitor（larkAlert.ts） 📤 投递：云电脑潜在触达监控 webhook 📖 runbook：docs/runbooks/second-touch-monitor.md
操作命令
手动触发看一张真卡curl -H "Authorization: Bearer $CRON_SECRET" https://akke.vercel.app/api/cron/second-touch-monitor
本地只读 dry-run（不推 Lark）pnpm tsx scripts/_dryrun-second-touch-monitor.ts
改阈值 / 监控号 / 群Vercel env：SECOND_TOUCH_MONITOR_ACCOUNT_ID / _STALL_HOURS / _FAIL_THRESHOLD / SECOND_TOUCH_DAILY_CAP
潜在触达通道健康脉搏 · Vercel 服务端 cron 驱动 · 只看不发抖音 · 每 8h 定时一张卡