wrong_user 完整分析先记住一句:这些"发不出去"的 没有一条发错人、也没有一条真发出去。
系统发之前会先核对"找到的是不是本人",对不上就主动跳过不发(记 wrong_user)——是安全拦截,不是发错。代价是 lead 当天没联系上 + 机器空跑。
24 小时内 97 条高意向里:只有 34% 在 10 分钟内采到(够得上发送时效),40% 抓到时已经过期 24h+。采集中位延迟 185 分钟(约 3 小时)。
结论:发送通道的 wrong_user 是小头;大头是"进料慢"——评论抓到时人早凉了。优化重心应放在"采集提速",不是死磕发送。
15 条跳过拆解:
| 7 条 | wrong_user — 核对不上本人(本报告重点) |
| 6 条 | 超时 — 超过 10 分钟时效窗口(对应进料端瓶颈) |
| 2 条 | 被拒 — 对方隐私设置/拒收 |
注:野荞报告聚焦这 7 条 wrong_user;下方第③节是全天累计 21 条的逐条人工验证(更大样本),两者口径不同,合看更全。
失败先看一个分叉:派单时缓存里有没有这人的抖音号。有号 → 用号搜(A/B/C);没号 → 退回昵称搜(D)。
A/B/C 来自全天 21 条逐条人工搜的样本(都有号);D 来自野荞报告的兮兮宝贝(冷缓存没号)。
本人在第一条、号也对,但拍照那刻没认出是主页(没加载好/残留)。→ 重试可救
用号搜返回另一个人(号段相近)。本人没出现。
号、昵称都搜不到本人,停在结果页/视频页。
新评论缓存还没号 → 按昵称搜 → 撞同名。本人其实搜得到,给它号(预热)就能救(兮兮宝贝)。
| 组 | 例子(抖音号) | 手搜结果 | 结论 |
|---|---|---|---|
| A 搜得到 | 833997494 69540571321a x.g.z.6688(私密)2026588128 187193079 58835709546 |
✅ 搜得到本人 | 系统误判,能救 |
| B+C 搜不到 | 41780494807 zhaoliang.666 13936266666l84554044 aassddffqqwwee 573733910 … |
❌ 搜不到本人 | 本通道够不到 |
| D 冷缓存 | 兮兮宝贝(派单时无号) | 昵称搜撞名(本人其实搜得到) | 缓存预热给号 → 能救 |
有号的 21 条里:能救(A)~6、够不到(B+C)~15;D 是另一条没号的路(兮兮宝贝),归"能救"。
全天 ~15/21 是本人根本搜不到(本通道结构天花板,救不了);只有 ~6 是"搜得到却误判"(已修)。
💡 活证据:heshufuderen97 上午搜不到被记 wrong_user,过几小时系统自己重试就发出去了——印证"重试能救"。
↑ 这就是第③节的 D 类 ——和 A/B/C(都有号、用号搜)不同,D 是压根没号、退回昵称搜才撞的,所以单列。
当天唯一"搜得到本人却仍失败"的特例 兮兮宝贝,暴露了一条结构性失败链:
| 新评论刚进(10min 窗口内) | → | 缓存里还没这人的抖音号(没被预查过) | → | 退回按昵称搜 | → | 撞同名 | → | wrong_user |
即:越是"新鲜、够时效"的评论,越可能因为缓存没预热到而没号、退化成撞名搜。这和"进料端"是同一根:都卡在"新料来不及处理"。
84554044),抖音按"包含"匹配 → 返回号里含这串的别人。24 小时 97 条高意向评论,按"从评论出现到被采集"的延迟分布:
| ≤10 分钟 | 33/97 (34%) | 够得上发送时效 |
| >24 小时 | 39/97 (40%) | 抓到就已过期 |
采集中位延迟 = 185 分钟(约 3 小时)。
缓存预热覆盖目前只有 7%(44/615) 有号 → 大量评论派单时无号 → 撞名 / wrong_user。
死磕发送通道(wrong_user)只能救个位数;真正的杠杆在"采集提速 + 缓存预热"——让评论在还新鲜、本人还在的时候就带号派出去。
本次两个脚本已合并到 main(PR #375 + #376),云电脑下载覆盖 + 重启即生效。默认即生效、不改派单/抑制行为、零风险。
| 脚本 | 本次改了什么(作用) | 应为字节 |
|---|---|---|
douyin_dm_grounded.py |
发私信主脚本。加「非主页重试」:点开结果落「非主页」(残留/没加载好)时重搜落稳再核对,把"本人已点到却被误判"捞回来发。不放宽核对标准、不会发错人。 | 58682 |
wuying_poll_agent.py |
派单 agent。让 wrong_user 把 _ocr_seen(搜到了谁)写进数据库,事后能按 A/B/C/D 量出各占多少。纯后台记录、不改任何派单/抑制行为。 |
35824 |
# 1) 先 Ctrl+C 停掉正在跑的 poll agent，然后： cd C:\akke-wuying\wuying-dm # 2) 下载两个新脚本（覆盖旧的）： Invoke-WebRequest -Uri "https://gist.githubusercontent.com/yeqiao356/23eae280eee68fafc4c80a53bdf345eb/raw/douyin_dm_grounded.py" -OutFile douyin_dm_grounded.py Invoke-WebRequest -Uri "https://gist.githubusercontent.com/yeqiao356/05e5a1f32378b6bb307f014c8ab7e8a5/raw/wuying_poll_agent.py" -OutFile wuying_poll_agent.py # 3) 校验字节数（必须一致，对不上就重下第2步）： (Get-Item douyin_dm_grounded.py).Length # 应 58682 (Get-Item wuying_poll_agent.py).Length # 应 35824 # 4) 重启 agent： py wuying_poll_agent.py
非主页重试默认就开,不用改 .env;非 2560×1600 机器同操作、不用重新量坐标(见下)。
本次两个改动都与分辨率无关,非标准分辨率机器和 2560 机器走法完全一样:
wuying_poll_agent.py 只往数据库多写一段文字,纯后台,跟屏幕坐标毫无关系。douyin_dm_grounded.py 的「非主页重试」是重走一遍搜索+点击,用的还是这台机器已有的坐标,不新增、不改动任何坐标。→ 非 2560 机器照样下两个文件 + 校验字节 + 重启即可,不用重新量坐标。
⚠️ 前提:这台机器坐标本来就得是准的(之前已用 measure-row-dy.py / measure_nav.py 量过)。重试能救"页面没加载好",救不了"坐标量错"——若坐标本就落空,重试只会重复落空的点击。非标准分辨率机器若还没量过坐标,先量坐标,本次更新才有意义。