SUBPROJECT SYNC · 2026-05-28 · WEEK 22
云电脑子项目进展同步
把抖音 PC 客户端跑在阿里无影 EDS 上、由 Akke 调度系统派单——这条新通路从 PoC 通过到批量化上路的本周进展全景。本页作为项目内部周例会项目分析回顾标准样板。
CHANNEL 云电脑 + 抖音 PC
ARCH Supabase 公告板 / pull-based
STAGE PoC 通过 · 生产首发待激活
PoC 首条投递
2/2
2026-05-21 14:09 · 9 分钟连发 2 条
PASS · 接收方 cross-check
基础设施就绪
7/8
cron / schema / env / RPC / 节奏门全绿
仅末段 Wuying poller 待启动
单账号设计上限
18
条 / 天 · 45–90 min jitter
OCR conf ≥ 0.95 才发送
已对外投递
0
Wuying poller 首次抢锁待启动
P0 阻塞 · 5/29 周末激活
云电脑通路的第一条 DM 投递发生在 2026 年 5 月 21 日 14:09，由登录在阿里无影 EDS 上的抖音 PC 客户端账号「有大有小」发出。9 分钟内连发 2 条，全部经接收方手机端 cross-check 确认从主收件箱正常接收，没有被折叠到消息请求。
POC 投递时刻线
9 MIN · 2 MESSAGES · 2 PASS
"你好，看到你主页内容很喜欢，请问做装修吗？— akke poc 5/21"
口径说明 上述 2 条属于 PoC 双账号内部自测——目的是验证「云电脑 + 抖音 PC + 自动化脚本」这条新通路的基础可行性，而非「对真实潜客发出的第一条生产 DM」。后者需要 Wuying 端的轮询脚本正式抢到调度公告板上的第一条任务后才算开始（详见 §03 / §04）。周例会口径必须严格区分这两条线。
这次 PoC 通过的最大意义，是推翻了 5 月 13 日团队基于推断给出的「云电脑通路不可行」结论——其中「阿里 IDC 出口 IP 必触发抖音风控」「Electron 套壳的抖音 PC 拿不到组件树」「抖音 PC 没有 DM 功能」三个核心假设被实测一一证伪。技术路径正式从「云电脑被否决」翻转为「云电脑是值得规模化的新通路」。
整套系统的核心洞察：云电脑藏在 NAT 后面、外部网络找不到它。因此把方向反过来——中央放一张「公告板」（Supabase 数据库表），云电脑每分钟自己来抢锁取任务，外部没有任何节点持有云电脑的直连。这是这条通路能在 NAT、IP 漂移、抖音风控下稳定运转的根因。
每个角色干什么
① 闹钟 / VERCEL CRON
每 5 分钟敲一次派单员的门。整套系统的心跳起点。
② 派单员
查每个抖音号的"小本本"：上次发了多久、今天发了多少。都通过才贴派单。
③ 公告板
公司中央一面墙，所有派单贴在上面。一张派单只能被一个人撕下。
④ 小助理 / POLLER
远程办公室里每 60 秒来公告板看一眼，有自己能干的就撕下来。
⑤ 动手的人 / 抖音 PC
桌上摆着一台云电脑。搜索 → 主页校验 → 关注 → 点赞 → 私信。
⑥ AI 视力 / OCR
发送前用 Vision 校验「这真是要找的人」，置信度 ≥ 0.95 才允许动手发，防止给错人。
三个关键不变量
- 1:1 绑定一台云电脑 = 一位同事 = 一个抖音号，严格不混用。这是去重和审计的基石。
- 反向 PULL-BASED云电脑藏在网络深处，外面不连它，让它自己来取活儿——避开 NAT / IP 漂移 / 风控连接限制三连。
- UI 文本作投递证据HTTP 200 历史上有过 silent drop（Web 通道 status_code 7911）。云电脑通道发完能直接看抖音 PC 自显的「· 刚刚」回显——比任何 API 状态码更可靠。
「PoC 单台跑通」≠「N 台并发跑稳」。下面先看本周追踪的主数据（部署台数）日变化曲线，再看辅助指标 dial，最后是按重要性分组的 bad case 全集（顶部 matrix 速览 + 详细 cards）。
主数据 · 部署台数本周趋势
已激活云电脑实例数 · POLLER 在线可被 CLAIM
1 → 1 → 2 预期
本周持平 · 下周拐点
05-22 周四
05-23 周五
05-24 周六
05-25 周日
05-26 周一
05-27 周二
05-28 周三
下周
每日关键事件
05-22 周四
PoC 第二天，8h = 95 灵豆教训 → "按需唤醒"纪律入档
05-23 周五
生产化方案设计：从临时 tunnel 直连改为公告板 pull-based
05-25 周日
公告板架构上线（dispatch_queue 表 + claim_dispatch RPC）
05-26 周一
节奏控制层落地 + PR #34 修 schema 缺字段 + 激活「零星」账号 cloud_pc
05-27 周二
基础设施 7 跳 verify 全绿（唯独末段 Wuying poller 未抢锁）
05-28 周三
同事 onboarding runbook 完工（commit a52074b）+ OCR 切 OpenRouter 与主线 LLM 路由对齐
下周预期
5/29 周末激活首个 poller（待同事云电脑唤醒）→ 5/29–6/15 内激活 2–3 台（含试点新同事）
本周观察 部署台数本周持平 1 台——这是设计内的：本周核心是把"PoC 单台"升级到"生产可调度单台"（架构 + 节奏 + 监控全套落地），而非急于横向扩台数。真正的规模化拐点在下周：P0 完成、第 2 位试点 onboarding 把曲线推到 2，并验证 runbook 是否真的可复制。
辅助指标 · KPI Dial 网格
Bad Case · 重要性 × 状态速览
重要性维度 = 影响范围 × 破坏度 × 发生频率。13 个已知 case 按以下矩阵分布：
BAD CASE STATUS MATRIX
关键Critical · 4 项
重要Important · 5 项
一般Minor · 4 项
Bad Case · 详细分组
关键组默认展开，重要 / 一般默认折叠，点击标题展开。
关键 · CRITICAL · 阻塞首发或可造成重大损失
4 项 · 1 待修 / 3 已缓解 ▶
掉线监控缺失 待修
现象云电脑掉线 / 同事忘开 → poller 死，但 cron 照常派单，pending 静坐超 30 min 无人接，整个通路"看上去在跑实际死了"。
影响P0 阻塞——首发上线后没人能第一时间发现 poller 死掉。
进展暂无自动告警，靠日常人工巡检。
下一步新增 Lark 告警规则 pending ≥ 5 AND oldest claimed_by IS NULL 超 30 min → 推 PM（§04 P0）。
死账号锁池 已缓解
现象云电脑长期不上线，cron 仍照常给该账号 claim leads，高意向池被反复锁住其他同事拿不到，整池子被一个死账号瘫掉。
影响多人协作时严重——一个忘开的云电脑能让其他人当天无 lead 可发。
进展SOP 已落地：请假 ≥ 1 天必须告诉 PM，PM 把 channel_pref 改回 manual 并释放现有 claim（runbook §5 完整 SQL）。
下一步把这个动作做成一键 CLI / dashboard 按钮，去掉人工 SQL 步骤（§04 P1）。
派单重复多发 已缓解
现象同一用户的派单可能被 claim TTL 过期后重新派单，dispatch_queue 缺底层去重守卫，曾观察到单用户堆 5 条 pending——一旦 poller 启动会向同一个人连发 5 条 DM，秒触风控。
影响客户体验灾难 + 账号风控触发，重要性 critical。
进展已发生时立即 abort 多余行（留最新 1 条）；完成第一次 send 后调 mark_lead_contacted 永久去重；修复代码 PR 在审。
下一步INSERT 前加 NOT EXISTS 子句做底层防护（§04 P1）。
灵豆耗费陷阱 已缓解
现象wuying Mac 客户端保持运行时云电脑不休眠，按 4 灵豆/小时全速扣。PoC 8h 实测烧掉 95 灵豆 vs 估算 28，差 3 倍。
影响成本预算直接被打爆；批量化后多台并发若失控将拖垮整个套餐预算。
进展SOP 已硬纪律：下班必须 Cmd+Q 完全关 Mac 客户端，10 分钟后云电脑自动休眠停扣。已写进新人 onboarding。
下一步日报加「当天灵豆消耗」维度，PM 每周二复盘超预期立即告警（§04 P0）。
重要 · IMPORTANT · 影响批量化稳定，需主动监控
5 项 · 3 监控中 / 2 已缓解 ▶
Cookie 过期 + IDC IP 风控 监控中
现象抖音 Cookie 15–30 天失效，重新扫码偶尔撞上阿里 IDC IP 风控验证码（概率较低但发生过）。
影响账号失活时间窗口若超 7 天，影响该账号产出。
进展定期每 3 周主动扫码刷新；如遇验证码及时人工处理。
下一步在 /health 接口返回当前登录态变化 → Lark 告警 PM（§04 P1）。
自启失败 + 双开抢锁 已缓解
现象开机自启偶尔失败导致 dispatch 无人消费；手动启动时与已自启的进程双开互相抢锁出现部分消费。
影响当天该台云电脑的产出可能归零。
进展唤醒后先看 dispatch_queue claimed_by 是否非空确认 agent 在跑；手动启动前先 taskkill /F /IM python.exe 杀残留。
下一步把"开机 60s 后心跳一次到公告板"做进 agent，超时即告警（§04 P1）。
多通道并发 race（ADB / WDA / 云电脑） 已缓解
现象现有 5 位 ADB+WDA 运营线 + 新增 1–2 位云电脑试点，两条链路并跑时同一 lead 可能被双 claim。
影响理论上可能导致接收方收到重复 DM，但目前未发生。
进展按账号绑定表物理隔离——同一 account 只绑一条通道；云电脑账号用独立 account.id。
下一步RPC 层加"已被另一通道 claim"软逻辑检测（§04 P1）。
风控验证码突袭 监控中
现象高频或陌生 IP 触发抖音验证码弹窗，焦点被对话框抢走，自动化脚本卡住。
影响当条 DM 失败 + 后续脚本死，需人工介入。
进展pyautogui FAILSAFE 鼠标甩左上角紧急停 → 人工处理 → PM 调降 daily_limit；cron 派单 45–90 min jitter 抖散，不轰炸同账号。
OCR 主页校验置信度门槛 监控中
现象OCR conf ≥ 0.95 防错发，但阈值过严会漏发（FN 把好 lead 错杀），过松会误发（FP 给错人）。
影响FN 损失获客效率；FP 损失客户信任。
进展当前 0.95 是 PoC 实测均衡点。
下一步采样 100 条被拦截截图人工复查 FP / FN 比例 → 调阈值或 prompt（§04 P1）。
一般 · MINOR · 已彻底修复或有可靠 workaround
4 项 · 全部已修 ▶
Electron 多窗口歧义 / 点击被吞 / 中文乱码 已修
三个原生坑同一进程派生多窗口 → 改用 Desktop.windows(visible_only=True) 选面积最大；click_input 被 React 吞 → 改 pyautogui doubleClick；type_keys 不支持中文 → 改剪贴板 Ctrl+V 粘贴。
进展三个全部已修，沉淀在 worker/scripts/wuying-dm/。
搜索结果同名撞车 已修
现象抖音搜索同名昵称会撞 25+ 个改名号，单因子匹配容易发错人。
进展双因子精度守卫：必须同时匹配「抖音号 AND 昵称片段」，缺一不放行。
DM 真投递验证 已修
现象HTTP 200 不能作为投递证据（Web 通道有过 status_code 7911 silent drop）。
进展云电脑通道改用 UI 文本回显「· 刚刚」作强证据，比 API 状态码可靠。
分辨率校准 已修
现象坐标硬编码 1456×819，云电脑分辨率改动后点击全部错位。
进展已提供 calibrate.py 一键重采样，新人 onboarding 默认跑一遍。
按优先级分三档 — P0（这周内必须，解锁生产首发）/ P1（2–4 周内，让批量化稳）/ P2（长期或可选）。每条列出现状 + 完成后解锁什么，方便周例会评估资源投入与排期。
P0 · 解锁生产首发
本周内
7 跳基础设施已绿，只差最后一跳的 Wuying 端 poller 起来——这一档完成，云电脑通道才算正式投入运营。
-
P0.5 · Wuying poller 5/29 周末激活验证 bootstrap.bat 已写完，需要同事在本周末唤醒云电脑实际触发自启，并在 60 秒内观察到 dispatch_queue 现存 2 条 pending 转 claimed。
解锁：从「设计完成」升级为「跑起来过」。
-
唤醒云电脑 + 确保 poller 首次抢锁 按 runbook §1–3 唤醒，bootstrap.bat 自启 / 否则手动启动。
解锁：dispatch_queue 现有 2 条 pending 被消化。
-
首条对外真实 lead DM cross-check 等 cron 下一轮派单 → dispatch_queue 转 sent → 接收方手机截图。
解锁：端到端链路证明可对外用。
-
灵豆按需唤醒纪律 SOP 化 下班 Cmd+Q 关客户端写进新人 onboarding；日报加「当天灵豆消耗」维度。
解锁：杜绝成本失控。
-
Lark 监控告警接入 新规则
pending ≥ 5 AND claimed_by IS NULL 超 30 min → 推 PM 告警卡片。
解锁：故障从人工巡检升级为分钟级告警。
P1 · 让批量化稳
2–4 周内
第一条对外 lead 跑通之后，下一步是让"N 台云电脑 × N 位同事"稳定 7×24 跑下来，而不是单台单跑。
- 1–2 位运营试点 onboarding 按 runbook §7 PM checklist 串完整流程（分配实例 → 配账号 → bootstrap → 验证派单）。解锁：流程可复现，分散单人依赖。
- "请假离场"流程 SOP 化 CLI 脚本一键切换账号
channel_pref 在 cloud_pc 与 manual 之间。解锁：避免值班空档锁池。
- 反馈回路三指标进日报 实发数 / OCR 失败率 / 风控痕迹推 Lark 日报卡片。解锁：后续灵豆升档 / OCR 阈值调整有数据基础。
- 多通道并发 race 防御 RPC 层加"已被另一通道 claim"检测或 unique constraint。解锁：no double-send 保证。
- Cookie 过期监控
/health 接口返回登录用户名 + 最后活跃时间，变化 → Lark 告警。解锁：账号掉线不再无人察觉。
- OCR 准确率采样 采样 100 条被 Vision 拦截截图人工复查 FP / FN 比例。解锁：若 FP > 5% → 调阈值或 prompt。
- 派单底层去重 INSERT
dispatch_queue 前加 NOT EXISTS 守卫排除同用户已 pending/claimed 行。解锁：彻底消除单用户被连发 N 条风险。
P2 · 长期 / 可选
长期
基础通路稳了之后才考虑——成本优化、横向扩展、架构整合。
- 灵豆套餐升档决策（6/15–6/18 复盘） 黄金 ¥9.90 / 40 灵豆 vs 铂金 ¥29.90 / 160 灵豆。按需唤醒下大概率维持黄金；如实测月耗 > 40 → 升档。
- 多账号并发支持 当前 Electron 单进程仅能登一个账号，多账号需多云电脑实例。如试点验证需放量 → N:1 映射改造。
- 云手机方案横评结论更新 5/13 矩阵"云电脑 = 负优化"基于推断，已被 PoC 部分推翻 → 采样 1–2 个备选方案稳定性后定通道战略。
- 与 message_queue 架构整合 当前 cloud_pc 完全绕开
message_queue 直走 dispatch_queue。长期可统一到单 RPC + dashboard 统一展示。
- 抖音 PC 版本升级监控 当前锁 v7.8.0，Electron / 抖音 PC 升级会失效坐标。把版本号写进
/health。
- ADB+WDA 既有 5 人线迁云电脑可行性评估 成本 / 稳定性 / 风控三维对标。
关键决策节点
本周内 P0 全部 4 条完成 → 云电脑通道正式投入运营。
6/15 – 6/18 灵豆消耗复盘，决定黄金套餐是否维持或升铂金。
P1 完成条件 ≥ 1 位新人 onboarding 走通 + dispatch_queue 日均成功率 ≥ 95% + lead 堆积 < 5 条。
"对外真实运营"启动标志 首条来自非 PoC 账号的对外 lead DM 被记录且接收方有回复——这一里程碑达成才算云电脑通道真正进入运营态。
相关文档