wrong_user 排查与修复方案worker/scripts/wuying-dm/douyin_dm_grounded.py本质上 没有一条发错人、也没一条真发出去——全是身份门（OCR 核身）正确拦截。但代价是大量派单空转 + lead 丢失。10 条里 组 A 能救 3 条 组 B 够不到 ~7 条。
人工核验 本结论非自动推断——这 10 条已在云电脑端逐个手搜抖音号、一条条人工审核确认（搜得到/搜不到、本人排第几条、是否私密），见下方第 2 节证据表。
一句话定调：修复只能捞回少数（组 A 是会被误杀的真 lead）；多数（组 B）是本发送通道结构上够不到的 lead，只能止损 + 往上游/换通道想。
云电脑发私信前，process() 走这条链路寻址 + 核身，任一步不过即判 wrong_user 并跳过、根本不发：
核身两道门（ocr_verify()）：① 当前页是不是个人主页（有关注/私信按钮+粉丝数+作品宫格）；② 昵称匹配 或 抖音号精确一致（号唯一，比昵称稳）。已开 AKKE_SEARCH_SCAN_N=5 深扫前 5 条结果。
云电脑端逐个手搜 10 个号验证后，干净劈成两组：
本人就在搜索第 1 条、号精确命中，却被记 (非主页)。问题 100% 不在搜索，在「点第一条 → 落主页」那一步。发生在不同时间（00:37 / 08:49 / 09:02），是间歇性。
| 抖音号 | 用户名称 | 手搜结果 | 失败原因 |
|---|---|---|---|
833997494 | 来地球玩的 | 第 1 条精确命中 | 点完没进主页（加载竞速/tab 没切） |
69540571321a | 泥彩哪 | 第 1 条精确命中 | 同上，间歇性 |
x.g.z.6688 | 许公子 | 第 1 条命中 · 私密账号 | 私密号无作品宫格 → is_profile=False 误判 |
关键证据：大量 sent 成功条目走同一条 C_FIRST 点击路径 → 第一条结果坐标本身是准的（否则全军覆没）→ 组 A 的失败是间歇性，重试正是对的工具（不是坐标问题）。
号搜出号段相近的别人，用昵称也搜不到。根因：账号改了号 / 注销 / 私密，或存的是不可搜的 short_id。深扫 5 条也救不了——本人不在结果里。
| 抖音号 | 用户名称 | OCR 实际搜到 |
|---|---|---|
41780494807 | 疯人院尼克 | 王灿讲系统 ｜号:41780494791 |
54457438150 | 咩咩的土豆子 | 用户9832… ｜号:38310000030 |
1077767305 | 如人饮水，冷暖自知 | 愿你遇良人 ｜号:1077767335 |
zhaoliang.666 | @陪读爸爸·带俩娃 | 纵横四海 ｜号:zhaoliang6666（昵称也搜不到） |
13936266666l | 战武66666 | 荷包陈甸甸 ｜号:13730761452L |
1214949699 | 董家有女 | (非主页) |
| …等 | ||
resolve_douyin_numbers.py:112：number = unique_id || short_id。没设自定义号的用户退回 short_id（内部数字 ID，搜索框按设计不可搜），合并后丢失了「是否可搜」信息。process() 扫描循环：ocr_verify 不匹配就 i++ 跳下一条。本人在第 1 条只是瞬时没进主页 → 跳到第 2–5 条全是别人 → wrong_user。ocr_verify() 的 VL prompt 要求「有作品宫格」才算主页 → 私密号没宫格 → 判非主页。complete_dispatch v2（migration 20260609195201）：wrong_user→skipped，同一 comment 累计失败 ≥3 次 → comment.status='skipped' 永久排除。所以组 B 不是无限重派，是每条烧 ≤3 次后停。| 失败组 | 本质 | 修复价值 |
|---|---|---|
| 组 A | 本来能联系上的 lead 被误杀丢了（可恢复） | 真增量 · 捞回 lead |
| 组 B | lead 反正够不到，3 次后 suppress | 仅省算力 · lead 仍丢 |
| 顺序 | 改动 | 性质 | 风险 / 路径 |
|---|---|---|---|
| 1 | A1 · (非主页) 重试同一条结果 | 捞回真 lead（组 A） | 低 · worker 脚本失败分支 |
| 2 | 主动跳过 short_id-only（enrich:unique_id 空就不派） | 0 成本灭掉组 B 可预判子集 | 低 · 先验证 |
| 3 | B2 · 给组 B 打 unreachable_search tag 量真实规模 | 看清 33% 里多少不可救 | 低 · 纯标记 |
| 4 | B1 · 反应式 1-shot suppress（改名/注销的） | 省算力（3 次→1 次） | 中 · 含 migration 走 PR |
| 放弃 | A2 · 私密账号放宽 is_profile | 1 条 · 私密大概率不可私信 | — |
(非主页) 重试同一条结果 救组 Adouyin_dm_grounded.py → process() 扫描循环（~734–758）i++ 跳下一条结果。seen 以 (非主页) 开头时（= 没落到主页，不是「认错人」）→ 重点同一条 + 加长等待 + 重新截图核身，重试 K 次（如 2）后才跳下一条；on-profile 但号不符才 i++。顺带把点完第一条到截图的 settle 等待（现 wait=2.0）调大。833997494 / 69540571321aenrich 调的 profile 接口里 unique_id 与 short_id 是分开返回的（line 112 合并才丢了信息）。unique_id 为空、只有 short_id 的 lead = 可证明搜索框永远够不到 → 在 enrich 阶段 0 成本、零误杀地跳过，比 B1「烧 1 次再 suppress」更早更省。
改名/注销的自定义号（如 zhaoliang.666）预判不了 → 留给反应层。即主动层（short_id）+ 反应层（strikes）互补，不是二选一。
unique_id 空 ⇒ 真搜不到」，再依赖它改派单。wuying_poll_agent.py 把组 B 这类失败的 p_error_message 落成 unreachable_search（区别于组 A 瞬时失败），就能 COUNT 出组 B 多大、33% 是否代表性。纯标记、不改行为。
当 process() 扫完全部 5 条、看到的全是 on-profile 的别人（号都不符 = 确定本人不在结果里）→ poll agent 打 unreachable_search → 新 migration 让 complete_dispatch 对该 error 1 次即抑制（类比现有 rejected 的 1-shot）。组 B 从烧 3 次降到 1 次。
(非主页)」可能瞬时，别 1-shot；「全是别人的真主页」才确定搜不到、可 1-shot。需 process() 回传细分原因。supabase/migrations/** → 必须开分支 gh pr create、CI 绿 + claude-review 过再合，不直推 main。douyin.com/user/<sec_uid>）—— PC 客户端没地址栏，已排除。zhaoliang.666 是自定义号样式却也搜不到（注销/改名）。只跳可证明的 short_id 子集，其余反应式处理。unique_id 空 ⇒ 真搜不到（云电脑验几个已知 short_id 号）→ 决定主动跳过②能不能依赖。worker/scripts/wuying-dm/更新到最新版-同步同事.md 流程同步到云电脑，先小批 dry-run 观察再放量。supabase/migrations/** 走 PR，其余 worker 脚本小 fix 可直推。本通道有结构天花板。组 B 的 lead 不是坏 lead——人家在视频下评论过，我们有 sec_uid 和 comment。够不到只是因为 PC 客户端只能靠搜索框按号寻址。
真正能覆盖全部的是 从评论/视频里点进 TA 的主页（iPhone / ADB 通道能做），而不是搜号。这是本通道的上限，要彻底解决 wrong_user 得换寻址方式，属于另案。