这是云电脑触达通道的长期专题页：前期（磨合阶段）记录问题、根因、SOP 修补；跑顺之后只在「① 最新快照」和「⑧ 更新日志」追加各周期的发送数量与效率。所有结论都标注统计口径，口径变了会在更新日志里声明。
wrong_user，这条没发出去、不占风控额度——它是防发错人的保险，不是发送失败。status=sent = UI 层确认（私信发送后输入框清空复核 / 评论发布后回显）。它不等于服务端送达回执——详见「③ 有效性」。| 日期 | 尝试 | 发出 | 其中重复 | 新触达 | OCR跳过 | 场次/时间窗 | 节奏 |
|---|---|---|---|---|---|---|---|
| 6/3 | 2 | 2 | 0 | 2 | 0 | 1 场 · 16:29-16:30 | — |
| 6/4 | 23 | 17 | 0 | 17 | 6 | 1 场 · 20:48-21:52 | 2.8min/条 |
| 6/5 | 47 | 21 | 8 | 13 | 26 | 3 场 · 02:20 / 20:05 / 21:01 | 1.1-2.3min/条 |
| 6/6（至上午） | 24 | 15 | 0 | 15 | 9 | 2 场 · 00:06 / 10:09 | 1.4min/条 |
| 合计 | 96 | 55 | 8 | 47 人 | 41 | 7 场 |
| 日期 | 尝试 | 发出 | OCR跳过 | no_works | 场次/时间窗 | 节奏 |
|---|---|---|---|---|---|---|
| 6/4 | 0 | 0 | — | — | 备了 10 条候选但没跑（机器上无当日 comment_log） | — |
| 6/5 | 48 | 23 | 22 | 3 | 3 场 · 02:44 / 22:14（空跑）/ 23:02 | 1.8-1.9min/条 |
| 合计 | 48 | 23 | 22 | 3 |
尝试→发出转化率：DM 57%（剔除两场事故场后为 64%）、RC 48%（剔除空跑场后为 70%）。损耗大头是 OCR 身份门，其中约一半来自"窗口卡死/旧文件重跑"两类事故而非名单本身（见 ⑦）。
| 层级 | 状态 | 说明 |
|---|---|---|
| UI 层确认 | 78/78 通过 | DM 发送后复核输入框已清空；RC 发布后评论回显。本页"发出"即此口径。 |
| 服务端送达回执 | 拿不到 | 抖音对陌生人私信有静默丢弃机制（API 通道实测过：表面返回成功、实际 status_code=7911 没送达）。云电脑走 GUI，无法读到这个回执，所以"发出 ≠ 必达"。 |
| 对方回复 | DB 视角 0 / 需人工核 | 云电脑 GUI 发的私信，对方回复不会自动回流数据库（轮询回复的 cron 不覆盖此通道）。真实回复要人工打开云电脑抖音客户端的消息列表看，有回复手动补账。RC 的互动同理，且公开评论可能被风控无声吞掉，建议抽查对方视频确认评论还在。 |
| 指标 | 6/4 DM (n=11) | 6/5 DM (n=21) | 6/5 RC (n=23) |
|---|---|---|---|
| 最快 | 10.3h | 10.6h | 10.2h |
| 中位 | 22.9h | 68h（≈2.8天） | 63h（≈2.6天） |
| 最慢 | 31.3h | 170.8h（7天） | 101.9h |
| <24h 占比 | 55% | 24% | 17% |
对照实测规律（评论后 6h 内触达命中/响应最好，24h 后腰斩，48h 后趋零），6/5 七成以上的触达发生在意向热度已经凉透的窗口。
证据就在 6/4 vs 6/5 的对比里：6/4 当天拉当天发（单场、13→23 条小批），时效中位 23h、<24h 占 55%；6/5 攒到三场 47 次尝试，中位飙到 68h、<24h 跌到 24%。同一台机器同一套脚本，差距全在节奏。
先讲清找人机制（常见误解）：名单里每个人都带 user id（sec_uid），但它只用于发送后回写数据库去重——抖音 PC 客户端没有"按 user id 直达主页"的入口（深链协议在 Windows 客户端实测不可用）。所以云电脑找人只能：把抖音号（反查不到号时回退昵称）敲进搜索框 → 用户 tab → 盲点第一条结果 → OCR 截图核对主页是不是本人。任何一环对不上 = wrong_user 跳过。手机通道则是从源视频评论区点头像直达，不走搜索（见 ⑥）。
定义：同一个候选连续两轮被 OCR 身份门拦下（wrong_user）。6/5 晚场（21:01-21:09）与深夜场（23:57-00:12）两轮实测出 6 人（青宝 / 自由人 / 微笑 / yan~~ / 小小小小小邓 / 冉冉柠檬雨）——其中 5 人用的是精准抖音号搜索、微笑是昵称回退；同两场里其他候选以同样方式通过，说明是这 6 个个体相关的失败，不是整场环境问题。
根因假说（均未实锤——日志只记了置信度，没记"OCR 实际看到了谁"，已列为脚本改进项）：① 搜索第一条结果不是本人（重名/仿号/数字号被模糊匹配排前，脚本盲点第一条）；② 昵称→抖音号的反查在重名时张冠李戴，号本身就是别人的；③ 对方近期改了昵称/头像，OCR 比对昵称对不上。
处置规则：二连跳 = 该用户在云电脑通道拉黑，不做第三次重试（每次重试白烧 1.5 分钟机时和一次搜索曝光）。转手机通道——手机走"视频→评论区→点头像→进主页"路径，完全不依赖搜索，云电脑的失败模式在手机上不存在；手机自己的失败模式是评论太旧时在评论区翻不到人（时效 >24h 命中率腰斩），所以二连跳名单要尽快转、别过夜。
| 批次大小 | 实测节奏 | 说明 |
|---|---|---|
| 25 条大批（6/5 凌晨） | 2.3min/条 | 窗口状态随批次变长劣化（残留弹窗/页面累积），后半段越跑越慢、误判变多 |
| 7-11 条小批（6/5 晚 / 6/6） | 1.1-1.4min/条 | 单条耗时低约 40%，且每批之间有人工复位客户端的机会 |
建议节奏：每批 8-10 条 · 批间人工复位（回首页、关残留窗口）· 白天每 2-3 小时一批。这样一天 3-4 批正好贴着风控额度（25-30），时效、效率、风控三头都顾到。拉名单时按"目标发出数 × 1.5"备缓冲（OCR 会筛掉一批），但锁号别贪多——锁了不发，4 小时后过期又回池，白占同事的可拉空间。
| 云电脑（无影 + PC 客户端） | 手机连电脑（ADB / WDA） | |
|---|---|---|
| 找人方式 | 昵称/抖音号搜索 + OCR 核身 | 源视频评论区点头像直达，无需搜索 |
| 主要失败模式 | 搜索撞名被 OCR 拦（本期 30-50%） | 评论太旧翻不到头像（6h 内≈0%，24h≈50%，48h≈100% 失败） |
| 对评论新鲜度 | 不敏感——几天前的评论也能搜到人 | 强依赖——超过一天基本废 |
| 节奏 | 1.1-2.3min/条，全自动 | 约 2-4min/条，需人在旁边盯 |
| 无人值守 | ✅ 可以（夜间/工作日白天挂机） | ❌ 不行 |
| 发错人风险 | 低（OCR 0.95 门槛，宁跳过不错发） | 低（头像直达本人） |
| 回复回流 | ❌ 不回流 DB，要人工核客户端 | 部分场景同样需人工，但操作人当场可见 |
| 边际成本 | 云电脑月费 + 灵豆，挂机不占人 | 占一台真机 + 一个人的注意力 |
分工结论：新鲜线索（≤24h）→ 手机（命中高、当场确认）；时效偏旧 / 大批量 / 夜间 → 云电脑（不吃头像时效、可挂机）；云电脑二连跳 → 转手机兜底；两通道共用同一本触达账本，同人绝不重复触达。
| 问题 | 后果 | 修补 |
|---|---|---|
| 新名单写入没生效，旧文件重跑（发生 3 次） | 8 条重复私信发给已触达用户 + 30 次空尝试，浪费约 40 分钟 | SOP 三道闸第 1 条：贴完写入块必须核对打印出的第一个昵称等于新名单第 1 行，对不上不许跑。发送脚本本身不去重，去重只在拉单侧 |
| 抖音窗口卡死在上一个人页面 / 「抖音挂件」小窗抢焦点 | 整批 OCR 连环误判（看谁都是同一个人），15 条空跑 | 三道闸第 2、3 条：跑前回首页关残留窗口和挂件；日志连续 2 条 OCR 看到同一名字立即停 |
| 运行中碰键鼠 / 开新窗口 | 点击落进错误窗口，文案可能贴错地方 | 跑批期间不操作云电脑；回传日志等批次结束 |
| 回复不回流 DB | 差点把"0 回复"当真实结论写进报告 | 报数口径声明 + 人工核客户端（见 ③） |
| 日期 | 更新内容 |
|---|---|
| 2026-06-06 | 专题页首发。覆盖 6/3-6/6 上午全部机器日志（DM 96 次尝试 / 55 发出 / 独立 47 人；RC 48 / 23）；确立口径与名词定义；时效根因五条；二连跳处置规则与批次建议（≤10）；云电脑 vs 手机分工结论。 |