云电脑 DM / RC 双通道时效分层

新增账号「文哥」上线 + 私信(DM)快通道 + 反向评论(RC)接力通道。核心思想:新鲜 lead 抢私信时效,放久的转评论区捡漏,单账号产能不浪费。

汇报日期 2026-06-16 ｜试点账号:文哥 (cloud_pc) ｜状态:DM 已跑通 · RC 已上线待 dry-run 验证

★ 今日成果速览

8/8

文哥 DM 当日发满

4/5

快通道后 ≤10min 达标

PR 合并/在途(#371/#372)

对其他账号的影响

一句话文哥从 0 接入自动化 DM 通道并当天发满 8 条;RC「DM 发满后接力发旧 lead」的设计已编码上线,通过纯叠加 + 试点收口做到对现有 4 个号零影响,等 dry-run 验证后放真发。

1 设计:为什么要两条通道

同一个号、同一个抖音前台窗口,按 lead 的「评论新鲜度」分层触达,把单号产能榨干又不抢时效。

DM
私信

主力 · 快通道 ——只发评论 ≤10min 的新鲜 lead,抢端到端时效。每分钟派单,发到当日 daily_limit 封顶。（文哥日限 8 暖机,稳定后提到 30）

▼ DM 当日发满后

RC
反评

接力 · 慢通道 ——专挑评论已 >15min 的旧 lead(没赶上 DM 快通道、放久了的),转去评论区楼中回复继续触达。每小时派单,守自己的日上限。（文哥 RC 日限 5,全局默认 15）

一人一首触互斥(系统内建)同一个用户被 DM 私信过就不会再被 RC 反评,反之亦然。两条通道共用同一去重池,物理上不会重复打扰同一人。

关键设计点

维度	DM 私信	RC 反评
触达对象	评论 ≤10min 的新鲜 lead	评论 >15min 的旧 lead
派单频率	每分钟 `* * * * *`	每小时 `15 * * * *`
触发条件	有新鲜 lead 即发	该号当日 DM 发满后才接力
日上限	`daily_limit`(文哥 8)	`rc_daily_limit`(文哥 5 / 默认 15)
执行方式	云电脑搜索→主页→私信	云电脑视频评论区楼中回复

2 文哥账号落地(DM 通道)

镜像克隆的云电脑 + 自动派单闭环,当天跑通并发满。

自动闭环

派单 cron(每分钟) → dispatch_queue(公告板) → 云电脑 poller 抢锁(60s/轮)
   → 搜索+OCR身份门+关注+点赞+私信 → 气泡确认 → 回写 sent + 永久去重

当日发送(8/8)

时间	用户	评论→触达	说明
15:48	泥彩哪	🔴 420min	设快通道前的老库存,历史数据
15:52	渔歌JUNG	🔴 1026min
15:55	180B2小伙	🔴 99min
16:00	柠檬	🟢 4.7min	设 10min 快通道后,4/5 严格达标
16:06	南曦	🟢 3.4min
16:35	天空	🟢 4.4min
16:46	宸飞	🟢 5.3min
16:46	jo	🔴 10.3min

快通道生效后达标率 4/5柠檬/南曦/天空/宸飞全部 ≤10min;jo 10.3min 是 +3min 竞速 buffer 的边界值。3 条 🔴 是切快通道前发的存货,不计入新政策。

实时监控页(每条带 10min 达标徽章,60s 自刷):upio.ai/akke/cloudpc-dm-live-wenge

3 RC 接力通道落地(代码 + 配置)

代码改动(已合并 PR #371 / 待合 #372)

改动	内容
claim 取数	新增「评论年龄下限」参数(`p_min_comment_age_minutes`),让 RC 能专挑 >15min 旧 lead。纯叠加,默认不限 → DM/手动拉单零回归
RC 派单逻辑	① DM 接力门(当日 DM 发满才开 RC)② 只取 >15min ③ 日限支持 per-account 覆盖(文哥 5)
试点收口	`AKKE_RC_PILOT_ACCOUNT` 把 RC 锁死只对文哥,不污染其他号
补列(#372)	`accounts.rc_daily_limit` 列,承载 per-account 日限覆盖

配置(Vercel 环境变量)

变量	值	作用
`AKKE_RC_PILOT_ACCOUNT`	文哥 id	RC 只对文哥
`AKKE_RC_MIN_COMMENT_AGE_MINUTES`	15	只发 >15min
`AKKE_RC_DISPATCH_LIVE`	0(dry-run)	先预览不真发,验证后翻 1

4 风险控制:为什么对其他号零影响

风险点	护栏
改了共用的 claim 取数函数	纯叠加:新参默认不限,现有 DM/二触/手动拉单路径一行未改 → 其他号取数零回归
RC 全局开关一开影响所有号	试点过滤 `AKKE_RC_PILOT_ACCOUNT` 只放文哥;其他号 RC 隐形
首次上线就真发	先 dry-run(LIVE=0)只打印预览,确认只挑 >15min 后再放真发
DM/RC 计数互相干扰	DM 数私信、RC 数反评,两套计数互不污染

守规矩所有高危改动(数据库/派单逻辑/定时任务)均走 PR + CI 绿 + 自动 Code Review 通过才合并;改动可逆(配置可回滚、migration 带 rollback)。

5 遇到的卡点与解法

从账号上线到 RC 设计落地,实际踩到 7 个坑——记录现象/根因/解法,既是复盘也是后续加号的避坑清单。

卡点	现象	根因	解法
派单脚本跑错机器	在云电脑里跑派单脚本报错(命令还被换行截断)	派单是 PM 侧脚本(直连生产库),云电脑只负责跑 poller 抢锁发送,两边职责混了	澄清分工:派单走 PM 侧,云电脑只跑 poller。命令回到正确环境执行
心跳门挡住首次派单	第一次派单返回「已派 0 条 / agent_offline_skip」	新账号 poller 从没轮询过(无心跳),派单侧设计上只给在线 agent 派单(防死号把新鲜 lead 锁进无人消费的队列)	先在云电脑把 poller 起来写心跳,再派单 → 成功(「先有鸡」顺序:先在线、后派单)
老库存拖低达标率	前 3 条 DM 评论→触达 99~1026min 🔴 严重超标	这 3 条是设 10min 快通道之前就派进队列的旧 lead,评论早已超龄	政策分段看:快通道生效后只发新鲜,旧库存不计入新口径(快通道后 4/5 达标)
RC 需求与现有设计 5 处冲突	「>15min 旧 lead / 按账号日限 / DM 停 RC 开 / RC 现成跑」全做不到	系统现状是:只有「≤新鲜上限」、RC 日限全局、暂停开关 DM/RC 共用、RC 生产从未跑过	改代码补下限参数 + per-account 日限 + 试点过滤;「停 DM 留 RC」改用「DM 发满自动接力」替代(更省事且符合本意)
改到三通道共用的核心取数函数	claim 取数函数被 DM/二触/手动拉单同时调用	改错会波及所有号的 DM 取数(唯一能伤到大家的地方)	纯叠加(新参默认不限,旧调用路径一行未改)+ 走 PR + CI + 自动 Code Review + 单测兜
RC 真发开关早已被开启	查 Vercel 发现 `AKKE_RC_DISPATCH_LIVE` 已经是 `1`	历史遗留(别人早设),会导致 PR 一合并就真发、跳过我们要的 dry-run 验证	先把它压回 0 守住「先预览后真发」;现状 RC 0 发送,压 0 对生产无影响
漏建数据库列	代码读 `accounts.rc_daily_limit` 但该列不存在	首个 PR 写了读取逻辑却漏写「加列」的 migration	容错降级(列缺失→当默认值)没让线上崩;立即补 follow-up PR(#372)加列

共性经验① 自动化派单有「在线/背压/日限/时效」多道闸,新账号上线要顺着闸的顺序走;② 碰共用组件一律纯叠加 + 走 PR;③ 上线前先核对线上既有配置(别被历史 env 偷袭);④ 高危通道首发一律先 dry-run。

6 下一步

#372 合并 + 建列 → 设文哥 rc_daily_limit=5 进行中
看 18:15 dry-run 预览 → 确认 RC 只挑文哥的 >15min 旧 lead
放真发 → 把 AKKE_RC_DISPATCH_LIVE 翻回 1(需在文哥云电脑装好反评执行脚本 + 校准坐标)
试点观察几天 → 稳定后:文哥 DM 日限 8→30、RC 推广到其他号