Deployment Topic · 2026 Q2

整个项目的「时效」
是怎么从几小时压到几分钟的

📌 一分钟看懂(设计 + 卡点)

整体设计:我们把「一条评论 → 成交」这条流水线拆成五段:① 采集 → ② 分拣派单 → ③ 触达发送 → ④ 自动回复 → ⑤ 通道自驱,每一段单独提速,而不是笼统地"让它快点"。

真正的卡点不是"发得慢",而是几个堵点:① 采集等太久(所有号源一律 5 分钟才扫一遍);② 算太多(大量算力浪费在没有新评论的老视频和老评论上);③ 发不实(返回"成功"其实被静默丢弃);④ 看不到(客户回了消息,系统最坏要 12 小时才发现);⑤ 没人盯(全靠人工逐条发,深夜没人就断供)。

各个击破后,端到端最坏延迟从 4 小时 15 分 → 平均 ≤ 10 分钟。下面每一段都讲:第一次跑通时最快多少、原理怎么转、批量跑后的数据、踩过的坑怎么修的、以及目前还卡在哪。

端到端最坏4h 15min
现在平均≤ 10min

采集时效 — 盯梢谁刚留言

🪧 用大白话讲:就像门口蹲守,谁刚在视频下留言,我们要第一时间知道。原来不分轻重,所有号源一律排队 5 分钟才扫一遍;现在改成分层盯梢——热门号源 1 分钟扫一次,冷门的慢慢扫,还要防止老号源被永远晾在一边。
第一个案例 · 最快速度
29 秒
客户留言 →
抓取入库(采集)
真实成功案例「师傅 来一份」(中意向) · 2026-06-25 08:39 ✓ 已发出·达标
客户在一条 33 天前的老视频下留言,系统 29 秒就抓到入库;整条链路 评论 → 触达 2 分 34 秒,稳稳达标,已成功发出。
视频发布
05-22 19:24
+33天13时
评论
08:39:40
+29秒 · 采集
抓取
08:40:09
+13秒
打分
08:40:22
+15秒
生成话术
08:40:37
+0秒
派单
08:40:37
+1分37秒
触达 ✓
08:42:14
来源:lead 旅程实测时间线 2026-06-25(采集 评论→抓取 29 秒,全程 评论→触达 2分34秒 ✓达标)
0 → 1 是怎么跑通的
1
运营标热号
把出单多的号源点亮 ⭐
2
🏷️
系统贴 Tier-1
热号自动进"实时档"
3
⏱️
每 1 分钟扫
热号 1min,普通号 5min
4
📥
新评论秒进库
立刻进下一段分拣

⊕ 两条护栏:空跑就拉长间隔(老视频连续没新评论,回扫越来越慢,省算力);等太久自动加急(aging:老评论排队超时就升优先级,不被热号永久压住)。

按这套逻辑批量跑起来后
5.9min
48 个热号端到端平均
(对标过去 4h15min)
3→2min
活跃视频最坏延迟
45→30min
冷视频首次抓取
−77%
老视频无效复扫
(冷退避)
踩过的坑 & 怎么修的
遇到的问题(现象)怎么修的进展
老视频评论漏抓 6-11 天:热号只重扫最近 20 条视频,更老的视频底下还在冒新评论却扫不到加一条「历史视频低频回扫」专路,按"近 14 天仍冒高意向"挑钓点(PR #377)✅ 已修
新评论被"热度排序"埋掉,漏 33%:抖音评论按热度排序,刚发的新评论排到 50 名外,脚本翻一页全是老的就停了早停规则改成「连续两页全老才停」(PR #413);别贪心把每页拉到 150 条——实测会拖垮低优先级,坐死不做✅ 已修
普通号源被"高意向洪水"挤到饿死:高意向视频反复注入占了 30 倍流量,空跑率 88%,普通号源积压最久 13 小时高意向注入也纳入"空跑退避"(PR #381),积压 13h → 5.2h,注入量降 87%⚠️ 部分缓解
热号没有自动降级:靠人工升降档,出单掉下来后还占着实时档资源近 7 天没高/中意向自动降回普通档(PR #365)✅ 已修
🚧
目前还卡在哪:
  • 老视频的新评论还是抓得慢:有的视频发出去十几天了,底下还在冒新留言,但系统优先扫新视频,这类"老视频里的新评论"大约 4 成要等 6 小时到 7 天才被抓到。
  • 冷门号源偶尔排队久:不热门的号源碰上高峰,最久要等约 1 小时才轮到它被扫。
  • 想再扫更快但不敢冒进:把热门号源从"每 2 分钟扫一次"提到"每 1 分钟",会更快,但扫太勤可能被抖音判成机器、触发封号,得先让现在的频率连续跑 1-2 天不出事,才敢再加速。

分拣派单时效 — 别在没用的人身上花时间

🪧 用大白话讲:评论进来后先分拣——太老的评论(超过 2 小时)直接不送进 AI 打分,省钱又省时间;新鲜的才快速派给账号去触达。再把"派单节奏"从几十秒压到秒级。
第一个案例 · 最快速度
15 秒
打分分拣 →
派单完成
真实 DM 打招呼案例「师傅 来一份」(中意向) · 2026-06-25 08:40 ✓ 已发出
新鲜评论打完分,15 秒内完成分拣派单;派单后 1 分 37 秒打招呼私信就送达客户(评论→发出全程 2 分 34 秒达标)。注:这是给陌生客户发的"打招呼"私信(一触 DM),不是潜在触达评论。
来源:lead 旅程实测 2026-06-25(与采集案例同一条 lead)
0 → 1 是怎么跑通的
1
📥
评论进库
来自上一段采集
2
✂️
砍掉老评论
超 2 小时不送 AI
3
🎯
按新鲜窗派单
只派窗口内的新鲜 lead
4
软冷却连发
5 秒一条,不挤风控墙
按这套逻辑批量跑起来后
−86%
AI 打分调用成本
(砍老评论)
47→41s
派单总延迟
(目标 ~21s)
7-10min
号级新鲜窗
(≈4.3× 提升)
踩过的坑 & 怎么修的
遇到的问题(现象)怎么修的进展
紧窗口账号被派"老货"、opener 白烧:高危字段代码先于迁移直推上线,降级查询缺 fresh_window 列 → 只收 10 分钟内新鲜 lead 的账号被派了老评论,全被 skipped高危路径(迁移/派单)必须走 PR;降级查询阶梯式保住安全列(PR #499)✅ 已修
砍老评论怕"误杀":按评论时间砍掉超 2 小时的,但有些评论时间是空值(NULL),一刀切会把它们也误杀NULL 评论时间放行、不误杀,只砍明确超龄的✅ 已修
cron 广播派单"撒太广":每分钟 cron 给所有云电脑账号广播派单,有些账号本不该收CLOUD_PC_CRON_EXCLUDE 让指定账号退出 cron 广播派单✅ 已修
派单节奏被"记忆里的默认值"带偏:账号实际节奏已改成 60 秒,运维却按代码默认"45 分钟"理解,排查 2 周才发现铁律:报节奏/配额前先查库里账号真实值,不引用代码默认✅ 已纠正
🚧
目前还卡在哪:
  • 派单还能更快,但没压到极限:现在从给评论打完分到真正派出去约 41 秒,理论上能压到约 21 秒,这套"连续快速派发"还没完全开起来。
  • "发多少"和"发多准"在找平衡:发太多怕被抖音风控盯上、发太少又浪费了高意向客户,这个度还在调。
  • "只派新鲜评论"的时间窗是写死的:现在统一只派 7-10 分钟内的新评论,还没做到按号源冷热自动放宽或收紧(热号可以放宽到一天、冷号收紧)。

触达发送 — 把私信真发到客户手里

🪧 用大白话讲:"派单"只是把这条 lead 交给某个账号,客户还没收到。真正发出去要靠云电脑:认领 → 搜到本人 → 模拟人手把话术粘贴发送 → 解码返回验证"真发出了"才算数。这一段就是把"派了单"变成"客户真收到了"。
第一个案例 · 最快速度
1 分 37 秒
派单 →
私信触达
真实 DM 打招呼案例「师傅 来一份」(中意向) · 2026-06-25 08:40 ✓ 已送达
派单后云电脑认领 → 搜到用户开会话 → 模拟人手发 → 解码校验 status_code==0,1 分 37 秒私信触达客户(与采集/派单同一条 lead,评论→发出全程 2 分 34 秒)。
来源:lead 旅程实测 2026-06-25
0 → 1 是怎么跑通的
1
🔒
认领这条单
锁 4h 防重复发
2
🔎
搜到用户开会话
GUI 找到本人
3
🖱️
模拟人手发
粘贴话术发送
4
✔️
解码验证
status_code==0 才算送达
按这套逻辑批量跑起来后
~1.5min
派单→触达 典型耗时
1-2min
单条 GUI 串发
status_code==0
解码校验才算"真送达"
(不信协议层 OK)
踩过的坑 & 怎么修的
遇到的问题(现象)怎么修的进展
"发成功"是假的:抖音返回协议层 OK(cmd=100),但业务层被静默丢弃(status_code 7911=陌生人限速,24h 冷却),脚本还以为发出去了必须解码消息体、校验 status_code==0 才算成功;加速率防护 + 滚动 24h 配额计数✅ 已修
"输入框清空=已发"信号有假阳性:就地回复用输入框被清空判定"已发",偶发误判;打字前窗口没置前还会把按键漏进后台控制台打字前强制把抖音窗口置前;发送信号升级为读回对方气泡确认⚠️ 收敛中
🚧
目前还卡在哪:
  • 一个号只能一条一条发:同一个抖音号、同一个界面没法同时发多条,只能排队串行,量一大就慢(几十上百条要排很久)。
  • 抖音给陌生人发私信有天花板:每个号一天大约只能给 18-20 个陌生人发"打招呼",超了就被限流,这是平台硬规矩绕不过去,只能靠多开几个号来分摊。
  • "到底发出去没"判断还不够稳:现在靠"输入框被清空了"来猜已经发出,偶尔会误判,正在改成"去对方聊天框里看这条消息有没有真出现"来确认。

自动回复时效 — 目标"秒级接客",现在还卡在几分钟

🔴
高优先级 · 还在攻坚的卡点(不是已完成的成绩):这一段的目标是"秒级接客"——客户一回消息,像真人客服在线一样几秒内就回上。现在全链路跑通了,但端到端还要几分钟,离"秒级"还差一截,所以它是当前最该继续突破的瓶颈。
🪧 用大白话讲:客户回了私信,系统要立刻看到(靠"未读红点"),AI 立刻写好回复,自动发出去。已经把最坏情况从"等 12 小时"压到了几分钟——这是进步,但还没到"秒级"的目标
目前最快 · 但还没到秒级
~ 5 分钟
客户回复 → 自动发出
(目标:秒级)
2026-06-22 全链路真机验通(客户回「4 室 2 厅」) ⚠️ 跑通了,但未达秒级
全链路能自动跑(捕获 → AI 生成 → 危险词改写 → 自动发出 → 推 Lark),但端到端还要 ~5 分钟;时间主要耗在"每隔几分钟才去看一眼有没有新消息"这步(下图黄色段),不是真正"消息一来就触发"。
客户回复
T0
+≤3分 · 红点捕获
捕获
轮询节流
+秒级
AI 生成
webhook 触发
+秒级
危险词闸
自动改写
+~1-2分
发出
推 Lark 回执
来源:project_akke_dm_autoreply_cloudpc.md(黄色段"红点捕获"是目前离秒级目标最远的一步)
0 → 1 是怎么跑通的
1
💬
客户回消息
私信列表冒红点
2
🔴
只看红点行
有未读=真发了新消息
3
🤖
AI 写回复
秒级生成(webhook 触发)
4
🛡️
危险词改写
价格/微信自动改掉
5
📤
自动发出
回执推 Lark
现在批量跑起来是什么水平(离目标还差)
12h→3min
未读捕获已加快 240 倍
(但仍是分钟级,非秒级)
~3-4min
回复端到端
目标秒级 · 还没到
秒级
只有"写回复"这步秒级
捕获+发送仍是分钟级
踩过的坑 & 怎么修的
遇到的问题(现象)怎么修的进展
读不到未读数字:界面里未读徽标的坐标全是 0,靠坐标根本认不出哪个会话有新消息换思路:"有红点徽标 = 客户真发了",只处理带红点的会话行(PR #458)✅ 已修
正则漏了"前天"导致整批漏读:两天没回的会话时间显示"前天",正则没认,这一批全军覆没补全中文相对时间(刚刚/昨天/前天/X天前…)(PR #495)✅ 已修
系统消息被当客户回复刷库:"关闭会话""在线1小时前"被误当成客户消息,触发 AI 生成草稿红点门控天然排除(系统消息没红点)+ 正则黑名单前置过滤✅ 已修
短回复兜底假成功:客户回"4 房""L 型"这种短句,AI 识别不出意图就吐"网络卡了稍等"兜底词还自动发了硬拦:兜底串/空草稿/太短/决策阶段全部转人工,不自动发(PR #454)✅ 已修
AI 自己冒出价格/微信被限号:违规闸只扫客户问的,AI 草稿自己写的"每平 284 元"没堵草稿文本也扫红线词,命中自动改写去掉(PR #484)✅ 已修
🔴
目前还卡在哪(高优先级,要把几分钟干到秒级):
  • 没做到"客户一回就立刻接"(最主要的差距):目标是消息一来就秒级触发,现在却是每隔约 3 分钟才去"看一眼"有没有新消息,光这一步就吃掉几分钟——这是离秒级最远、最该先解决的一环。
  • 回复也只能一条条发:跟发私信一样,同一个号没法同时回多人,100 条回复排队串行要约 100 分钟。
  • "回复发出去没"还会偶尔误判:和发送是同一个问题——靠"输入框清空"判断已发,偶尔出错,还在收敛。

通道自驱化 — 让它无人值守、7×24 跑起来

🪧 用大白话讲:节点 ③ 讲的是"把一条私信可靠发出去";这一段讲怎么让云电脑无人值守地大规模、全天候跑——每分钟自动问"有单吗"、认领、发送(细节见③)、再回到挂机,人彻底走开。最大的卡点不是发得慢,而是"有没有人在发"。
第一个案例 · 最快速度
5 分钟
可控段中位
(派单→真发出)
2026-06-08 云电脑自动 DM 批量化验通(野荞账号)
全链「评论→采集→打分→派单→认领→GUI 发送→去重」自动闭环,可控段(派单到发出)中位 5 分钟
来源:cloudpc-auto-timeliness-10min.html / project_akke_cloud_pc_dm_poc.md
0 → 1 是怎么跑通的
1
🖥️
云电脑挂机
poll agent 常驻
2
🙋
每分钟问有单吗
cron 每分钟派单
3
🔒
认领一条
锁 4h 防重复发
4
🖱️
模拟人手发
GUI 视觉定位发送
5
✔️
解码验证
真发出了才标完成
按这套逻辑批量跑起来后
~3-5min
派单→发送中位
每分钟
派单频率
87s
单周期全部清空
(48 个热号)

⊕ 关键发现:时效最大的卡点是"云电脑深夜休眠"和"派单排序",不是发送本身——发送中位 5 分钟已经达标,压发送没意义,要先解决"有没有人在发"。

踩过的坑 & 怎么修的
遇到的问题(现象)怎么修的进展
本机国内访问全断:Mac 上 VPN 的 fake-IP 模式劫持了 DNS,抖音域名解析到占位 IP,看似走代理实际断批量操作搬到云电脑(国内 IP 无 VPN 干扰);本机调试时关 VPN 或加直连规则✅ 已绕过
派单机制突然裂开:代码合并了但数据库迁移没真跑,新字段不存在,cron 查报错、单子堆积铁律:高危迁移合并后立刻查字段是否真存在;高危路径必须走 PR(PR #499 阶梯降级保住安全列)✅ 已修
云电脑深夜休眠断供:个人版云电脑不是 24/7,会自动休眠,深夜没人唤醒就不发决策迁企业版 3 台(¥199/台/年),自带唤醒 API、脱离按时计费🔵 已决策·待落地
[潜在触达] 点开了错视频:固定坐标盲点"主页第一格",但主页头部高度会变,点到旧视频/同名号改 AI 视觉识别(VL)显式跳过置顶、点第一个真视频(PR #421)✅ 已修
[潜在触达] 连播害点赞落到下一条:视频自动连播,脚本点赞时播放器已翻到下一个关掉连播开关(一次性持久记住)✅ 已修
[潜在触达] 窗口标题"抖音"变"douyin"全天 0 发:重启后标题变了,脚本只认"抖音"二字两种标题都认(PR #380)✅ 已修
[潜在触达] 陌生人评论"评论自见"软封:贴评论本号能看见、别人看不见(平台软封),非话术问题单账号不适合常驻,风控比私信严 → 改作辅助渠道⚠️ 已知约束
🚧
目前还卡在哪:
  • 云电脑半夜会自动"睡着":现在用的是个人版云电脑,深夜会自动休眠,全天差不多 87% 的时间是黑屏、没人在发——这是目前最大的没解决的问题。已决定换成能 24 小时不睡的企业版 3 台,但还没买好、部署到位。
  • 一台机器上两个活会"抢":同一台云电脑想同时跑"发私信"和"潜在触达",会抢同一个抖音窗口,谁先谁后的协调机制还在试。
  • 潜在触达单号容易被"软封":一个号反复给陌生人留言,容易被抖音判成"这条评论只有你自己看得见"(别人看不到),所以这条路不适合靠单个号长期当主力。

下一步要做的优化

★ 重点 🔵 已决策·待落地 ⚪ 规划中/待做 ⚠️ 有前置阻塞
🔴
自动回复做到真·"秒级"接客 ★ 重点
这是节点 ④ 的核心目标,目前没达标:现在端到端还要几分钟(主要耗在"每隔约 3 分钟才看一眼有没有新消息")。要把"定时去看"改成消息一来就立刻触发(真·事件驱动),把几分钟干到秒级——客户体感等于"真人客服在线秒回"。
🔴
自动回复"稳定性"收敛 ★ 重点
目前自动回复整体还不够稳:GUI 自动化受坐标漂移 / 窗口标题变化 / 前台焦点竞争影响,偶发漏发"假成功"(以为发了其实没发出)。要做:① 发送验证从"输入框清空=已发"升级为读回对方气泡确认;② 坐标 / 窗口异常自愈 + 重启自检;③ 端到端成功率监控 + 掉点告警。
🔴
批量化操作上量 ★ 重点
当前一个号一个界面只能串行(100 条回复要 ~100 分钟),量上不去。方向:多账号 hash 分片 + 企业版多台云电脑并行,同批队列摊 N 路、单条等待 ÷N。前置:① 企业版 3 台落地 ② 分片函数进派单 RPC(同号不能并发是风控硬约束,只能靠多号横向扩)。
⏱️
采集再提频:热号每 1 分钟扫 + 节流 15 分钟 ⚪ 待证实
第 2 步加压,等当前频率连续 24-48h 零失败后推;预计把采集延迟从 45min 进一步压到 ~10-15min。(评论反爬边界不明,阶梯式不一步到位)
🖥️
企业版 3 台云电脑常驻 24/7 🔵 已决策·待落地
脱离按时计费、自带唤醒 API,真正 7×24 不依赖人工唤醒——这是"通道时效"最大的杠杆(深夜休眠占全天 87% 黑屏)。已发开通手册,待采购部署。
🔀
DM × 潜在触达 同机分时串行(窗口锁) ⚪ 代码已上·待验证
一台云电脑上让"私信"和"潜在触达"按优先级抢占式分时(DM > 反评 > 二触),当前只在小文那台开了开关,进程间通信待 PoC。
👥
潜在触达"关注流"覆盖扩容 ⚠️ 阻塞 route-B
当前监控池里一个号只关注了 12%,没关注≈监控无料;需批量补关注或换"直盯本人主页"策略(受 7 天墙限制)。
🔗
回复回执同步到 CRM ⚪ 可选增强
Webhook 端点已就绪,当前推 Lark;可扩展同步到企业 CRM。不阻塞,纯增强。