DM 链路端到端提速分析

「评论→发出」秒级账本 + 一次提速实验的完整复盘（诊断 → 上线 → 实测 → 翻车 → 回滚）· 2026-06-11

单条 lead 端到端 p5012–20 min

理论极限~4 min 15s

提速实验结果翻车·已回滚

真正的可提速点打分并发 ×5

这条链路所有的“几分钟”，九成是 cron 节拍 + 轮询等待，真干活都是秒级。下面把每一跳拆成「等待（排队/节拍）+ 执行（真干活）」，并复盘一次想压缩它、却反而搞慢了的真实实验。

一、单条 lead 秒级账本（评论 → 发出）

环节	做什么	等待（节拍/轮询）	执行（真干活）	典型合计
B1 评论→抓取	定时刷视频评论区，抓新评论入库	抓取节拍 ~60s + 抖音评论可见延迟 30–120s	单视频抓取 6.8s	p50 ~4–6 min
B2 抓取→打分	批量给评论打意向分（高/中/低/无关）+ 关键词	analyze `*/2` 半周期 ~60s + batch 排队 0~数 min	单条 3s（整批 15 条 44.7s，deepseek-v4-flash）	1–3 min
B3 打分→生成话术	高/中意向生成破冰首句	0（多为 claim 时现生，不等 cron）	opener 6–8s（qwen3-235b-2507）	6–8 s
B4 话术→派单	claim 4h 锁，写 dispatch_queue	dispatch `*/1` 半周期 ~30s	claim+insert <0.1s	~30 s
B5 派单→触达起	云电脑 agent 轮询拉走 claim，写 CSV，启动发送脚本	云电脑轮询 60s 半周期 ~30s	RPC+CSV <0.1s	~30–60 s
B6 GUI 实发（单条）	搜人→定位→核身份→打字→点发送	条间 sleep 30–90s（反检测硬墙）	净操作 30–60s（逐步见下）	60–150 s
B7 触达→回复	轮询对方是否回复	用户侧不可控	check-replies 现为 no-op	—

B6 GUI 发送逐步秒表（一条 DM 的真实分解）

10–20 s搜人（粘抖音号/昵称 → 点搜，固定坐标）

5–10 sVL 定位（用户 tab → 第一条头像，Qwen-VL + OpenCV 模板匹配）

3–8 s身份核查 OCR（主页昵称比对，不匹配 → 标 wrong_user 跳过）

3–5 s进主页 → 点私信 → 粘文案

5–10 s点发送 + 反应

3–8 s发送验证 OCR（读气泡 / 限频提示，判 sent/rejected/7911）

= 30–60 s单条净操作小计

+ 30–90 s条间 sleep（到下一条）= 反检测硬墙，压不动

累计时间线对比（mm:ss）

环节	① 理想最快	② 图里青箱（实样本）	③ 典型 p50
B1 评论→抓取	1:30	5:00	6:00
B2 抓取→打分	0:50	1:00	2:00
B3 生成话术	0:08	1:00	0:30
B4 派单	0:30	1:00	1:00
B5 派单→触达起	0:30	—	1:00
B6 GUI 实发（首条）	0:45	2:00（含 B5）	1:30
合计（评论→发出）	≈ 4:15	9:18	12–20 min

极限 ≈ 4 分 15 秒再往下压不动，地板是三块：抖音评论可见延迟（B1，几十秒，不可控）+ cron/轮询节拍（B1/B2/B4/B5 各半个周期）+ GUI 单条净操作 30–60s + 条间反检测 30–90s（B6）。

二、上游：号源生命周期（天级，每个号一次性）

这段不在单条 lead 时间线里，但它决定一条评论的视频在不在抓取快车道——是 2 分钟还是 4 小时被抓到。

阶段	做什么	耗时	说明 / 瓶颈
A1 选词	从 6 维度词库挑词	~3 min	本地免费；词库用尽会卡产能提升点
A2 捞作者	CDP Chrome 触发抖音搜索直链	~2–3 min/100	不花蝉妈妈钱
A3 f2 富化	本地 f2 拉每号视频，算 avg_comments	~13 min/100	串行硬墙 ≈ 12 号/min，并发会崩 + 限流
A4 实拉验证（可选）	拉新鲜评论 LLM 打分	~5–8 min	可 soft-skip
A5 入库	置信度分流 + 标 tier1	~10 s	org_id 必填
一轮扩源	手工驱动	~20–25 min	日产 tier1 ~4–10 / 总号 ~50–100
A6 tier0→tier1 升级	近 3 天高意向 ≥5 自动升	最快 3 天	需先抓够评论、打够分；每天 01:00 UTC 跑改滑窗可压到 1–2 天

三、提速实验复盘：想压 B1，却把它搞慢了 4 倍

结论：同时段实测抓取慢 4 倍 → 已回滚止血（根因未坐实，待复测）

① 诊断（先想再写）

瓶颈是节拍还是吞吐？跑队列诊断：scrape_jobs 队列全空、worker 利用率 ~10%（8s/job）。判定瓶颈是 cron 节拍 + 视频进快车道的资格门，不是 worker 吞吐 → 调密 cron“应该”能压延迟、不会堆积队列。（这一步对：队列确实没堆。但下一步的赌注错了。）

② 决策 + 上线（PR #298）

cron	提速前	提速后	意图
vip-video-rescan	*/5	*/2	VIP 视频更勤复扫
scrape-hot（tier1 源）	*/3	*/2	新视频更快发现
hot-video-rotation	日更	每 6h	新爆款当天进快车道

部署 ~07:58 UTC。上线前明确标过唯一风险：抖音对单视频评论 API 的限频。这一把赌它扛得住——赌输了。

③ 实测：四轮测量，方向一致地变差

测量	口径	全部 p50/p90	中高意向 p50	判读
基线（提速前）	近 3h 窗口快照	11 / 690 min	6（n小）	参考
R1 · 部署后 67min	只看部署后新评论	4.2 / 22.5	—（n=4 太薄）	早期像正面，但有右删失偏差
R2 · 部署后 128min	只看部署后新评论	15.2 / 48.5	16.5（n=9）	明显变差，但混着时段/删失
决定性 · 提速前	06-10 08:00–09:00 UTC	3.4 / 20.7	4.4（n=14）	同一北京下午时段、隔天对比，排除时段混淆 → p50 3.4 → 15.1，约 4× 恶化
决定性 · 提速后	06-11 08:00–09:00 UTC	15.1 / 49.3	16.4（n=6）	同一北京下午时段、隔天对比，排除时段混淆 → p50 3.4 → 15.1，约 4× 恶化

测量教训：早测会骗人R1（部署后 67min）看着是正面的（p50 4.2），其实是右删失偏差——早测时只看得到“已经被抓到”的评论（偏快），慢的那批还没进数据。同时段隔天 cohort 比较才把时段混淆和删失都控住，得出真相。

④ 根因：未坐实（曾误判为限速，已撤回）

第一版根因「抖音限速」证据不足，已撤回。最初看 _diag-scrape-lag 的 6h 滚动平均，以为 worker 单抓耗时 6.8→10.3s「一路爬」=被限速。但那是被 limit 截断的伪趋势。按完成时间分桶重测，结论反转：

时段	单抓耗时
提速前·基线	12.0s
提速期	7.8–8.4s
回滚后	9.6–10.7s

提速期执行耗时反而更低，没有限速变慢的信号 → 限速根因不成立。

那 4× 慢是真的，但归因未定。「06-11 比 06-10 同时段慢 4 倍」的观测为真；可能的解释（均未坐实）：① 隔天本身差异（当天热视频/评论量/抖音侧变动）；② 优先级饿死长尾——提速让 worker 把更多力气花在高优先级 VIP 重扫上，挤占常规视频覆盖（priority 0/1 饿死 priority 5），长尾评论等更久（队列空、执行不变、延迟升——fits，但未验）。回滚是零下行风险的预防动作，但不等于「修好了」，需回滚跑 1–2h 后同口径复测才能坐实/排除。

⑤ 回滚（PR #303，10:14 UTC 合并）

三条 cron 全部退回提速前原值，止血。纯 vercel.json 改，git revert 即回。回滚后再测一轮：延迟回到 ~4min = 坐实因果；仍高 = 抖音独立事件另查。

四、结论与教训

1 · 真正的可提速点不是抓取，是打分并发抓取的快车道本来就 ~4min，主导项是抖音可见延迟 + worker 轮询，不是 */5 vs */2 的 cron——所以提速 cron 不仅没用，还触发了限速。真正有肉的是 打分 intra-run 并发（现在一批批串行、吞吐 margin 仅 1.7×，改 5 并发 → 吞吐 ×5）。

2 · 触达 GUI 30–90s/条是反检测地板永远压不动，压了像机器人触发 7911 限频。要提吞吐只能加账号数（N 个号各守 30–90s = N 倍），不能压单号、不能并发（一台云电脑一个抖音窗口）。

3 · 打分按批省调用，生成话术按条无法批量打分一次 LLM call 打 15 条（省调用，瓶颈在批间串行）；生成话术每条单独 6–8s（要个性化，无法拼批，只能对热 lead 预生成省那 6–8s）。

4 · 量化方法论：同时段隔天 cohort 才干净“近 N 小时”快照同时受右删失（慢样本还没进数据）和时段混淆（午 vs 下午负载不同）污染。要判一个改动的因果，固定同一时刻、隔天对照、且两批都沉淀够。

5 · 别急着拍根因——先有干净数据再归因本次翻车后第一时间把根因拍成「抖音限速」，结果分桶数据反转、限速不成立，不得不当场撤回。教训：① 6h 滚动平均会造伪趋势，判趋势要按时间分桶；② 观测到回归 ≠ 知道原因，归因前先排除隔天变异、且验证机制；③ 提速实验小步灰度（先 */5→*/3）+ 同口径快速验比一次拉满更稳，也更容易归因。

数据来源：本机 _diag-scrape-lag / _diag-cohort-compare 实测（2026-06-11）。相关 PR：#298（提速·已回滚）、#303（回滚）。链路涉及 Vercel cron + Fly worker（f2 抓取）+ 阿里无影云电脑 GUI 发送。