云电脑 DM · wrong_user 分析与卡点
账号「小文（野荞）」2026-06-16 当日。严格 10min 时效通道（评论发表 ≤10min → 触达），无影云电脑 GUI 搜人发私信。本报告拆解今日 7 例 wrong_user（搜到/点到错人被身份门拦下、未发出）的根因与卡点。
账号 小文（野荞）
日期 2026-06-16
通道 无影云电脑 · 严格 10min
wrong_user 7 例
0当日大盘
skipped 15 例拆分：wrong_user 7（搜错人，本报告重点）+ 超10min过期 6（10min 时效闸正常过期老单，符合预期）+ 拒收 2（对方隐私拦截，平台机制）。
17 例 wrong_user 明细
| 北京时间 | 作者 | 地区 | 评论 | 抖音号 | 能否被搜到 |
|---|
| 21:36 | @做自己的太阳🌻 | 浙江 | 正准备装修，90平多少钱 | 914822202 | 纯数字默认ID·搜不了 |
| 21:23 | 兮兮宝贝 | 江苏 | 多少钱装好 | hankexin0925 | 能搜到本人·可救 |
| 17:36 | 🕊八方来财 | 江苏 | 麻烦给我一份 | lt93.12 | 关了按号搜·搜不到 |
| 15:38 | 大🐮 | 江苏 | 我想做一米的 | ying0177 | 关了按号搜·搜不到 |
| 12:42 | 🌞ㅤ | 上海 | 30w预算求优秀设计师 | 52936778392 | 纯数字默认ID·搜不了 |
| 12:21 | 花开四季 | 江苏 | 可以附加一份你的攻略不 | 975832114 | 纯数字默认ID·搜不了 |
| 09:39 | 一条小鲤鱼 | 广东 | 15层通铺木纹砖，全屋定制 | 2139675380 | 纯数字默认ID·搜不了 |
实时反查已验证：以上 7 个抖音号与共享缓存完全一致、没有过期——号是对的，问题不在号准不准。
2核心案例：兮兮宝贝（能搜到却 wrong_user）
7 例里只有兮兮宝贝是「抖音号能搜到本人」的，却依然 wrong_user。查时间戳拿到铁证：
缓存写入(fetched_at): 21:21
派单创建(created): 21:21 ← 同一分钟
派单时带的号: 无 ← 关键
完成: 21:23 wrong_user
结构性根因（一句话）：
1️⃣ 兮兮宝贝是 21:21 刚冒出来的新鲜评论——你要的严格 10min SLA 派的就是这种「刚发的」。
2️⃣ 这种新用户我们从没反查过 → 共享缓存是冷的（没号）→ 派单时 号:无。
→ 没号只能退回昵称搜「兮兮宝贝」→ 撞同名 → wrong_user。越追新鲜，派的越是没预热过的新用户，越容易冷缓存撞名——这是 10min SLA 与「号已就绪」的天然张力。
失败链条：
① 21:21 新鲜评论
刚发表、进 10min 窗口
→
② 缓存冷·无号
这新用户从没反查过，派单 号:无（号同一分钟才写入，太晚）
→
③ 退回昵称搜
没号 → 只能按「兮兮宝贝」搜，撞一堆同名
→
④ wrong_user
昵称搜无法按号锁定本人 → 身份门拦下
本机网格扫描已开（AKKE_SEARCH_SCAN_N）：若派单带了号，搜 hankexin0925 出 2 个结果（兮兮宝贝 0925 + 撞脸 Han.❤ 0529）时能按号精确挑本人。可惜这次根本没号，退回昵称搜，网格扫描也无号可比 → 仍撞名。所以兮兮宝贝的死因是冷缓存 / 派单无号，不是扫描没开。
3卡点（根因）
🔴 卡点一：7 例里 6 例「物理上按抖音号搜不到」（绝对主因）
运营手动实测：7 个抖音号有 6 个搜不到本人。其中 4 个只有纯数字默认 ID（用户没设自定义抖音号，搜索框天生搜不了），2 个（lt93.12 / ying0177）关掉了「允许通过抖音号搜索到我」。这 6 个无影的「搜人式发送」物理上够不到 —— 不是工具 bug，是这些用户自身搜不到。即使缓存预热好、把号带上，无影按号搜照样空。这是今日 wrong_user 的绝对大头。
🔴 卡点二：唯一可搜的兮兮宝贝 —— 冷缓存导致派单无号
10min 严格时效派的是刚冒头、从没反查过的新用户 → 共享缓存冷（无号）→ 派单 号:无（号同一分钟才写入、太晚）→ agent 退回昵称搜「兮兮宝贝」撞名。「时效」和「号已就绪」天然打架。这一类才是预热缓存能救的。
✅ 不是卡点：网格扫描已开
本机 AKKE_SEARCH_SCAN_N 已启用，撞脸号（0925 vs 0529）只要派单带了号就能按号精确挑本人。此项已具备，无需动作。
⚪ 旁注：本机重查的 SSL timeout 不算 agent 卡点
本报告在 mac 上重查时遇到 SSL handshake timeout，那是本机网络问题、重试即过，不代表无影 agent。况且对上面 6 个「搜不到」的用户，反查到号也没用（搜不到），所以反查稳定性不是本案重点。
4解法
FIX 1 · 最关键搜不到的用户（6/7）→ 给无影加「主页链接直达」路径（治卡点一）
今日 wrong_user 大头是搜不到的用户（纯数字号 / 关了按号搜），无影现有「搜人式发送」物理够不到。唯一可靠路径 = sec_uid 主页链接（永久有效）：https://www.douyin.com/user/<sec_uid>，打开主页 → 点私信。
短期：运营手动点链接触达；长期：给无影脚本加「按 sec_uid URL 跳主页 → 点私信」新路径，绕开搜索框（功能改造，待评估无影抖音端能否粘 URL 跳主页）。
FIX 2持续预热缓存（治卡点二）
针对「可搜但缓存冷」那类（如兮兮宝贝）：本机国内 IP 每几分钟跑一次，把「待派单池」新评论提前反查好号写进共享缓存；进 10min 窗口被派时缓存已热、派单直接带号 → 按号搜不撞名。全 org 受益。
python enrich-pending-pool.py --minutes 120 # 每 5 分钟一轮，只补号不发消息
已具备网格扫描 —— 本机已开，无需动作
AKKE_SEARCH_SCAN_N 已启用。只要派单带号，撞脸号能按号精确挑本人。FIX 2 把号补上后，此项自动发挥作用。
立即能救：仅兮兮宝贝（hankexin0925）1 个 —— 带号重派一次，agent 按号搜（网格扫描已开）即可正常发出。其余 6 个搜不到的无影端搜索式发送物理够不到（无影抖音客户端不支持粘链接跳主页，FIX 1 此路不通）。
本质结论：今日 wrong_user 七成以上不是工具能直接修的，而是用户搜不到 —— 提升整体「可达率」要靠扩大「有真抖音号且允许搜索」的号源占比。
5更大的瓶颈：进料端（采集延迟）
wrong_user 只是发送端的损耗。把视角拉到整条漏斗，真正限制产出的是进料端——大部分高意向抓到时就已经过期。
近 24h 97 条高意向的采集延迟（评论发表 → 入库）分布：
| 采集延迟 | 条数 | 占比 | 能否进 10min SLA |
|---|
| ≤10min | 33 | 34% | ✅ 唯一够格被派 |
| 10–60min | 13 | 13% | ❌ 已过窗 |
| 1–6h | 4 | 4% | ❌ |
| 6–24h | 8 | 8% | ❌ |
| >24h | 39 | 40% | ❌ 发表超 24h 才抓到 |
中位采集延迟 = 185 分钟（~3 小时）。只有 34% 的高意向在 10min 内被抓到，40% 是发表超 24h 才入库。也就是说：不是发不出去，是大部分料抓到时就已经过期——10min SLA 的产出天花板由采集速度决定，不是发送能力。
6优化空间（按杠杆排）
🥇 杠杆一：采集提频（最大空间）
把 ≤10min 那档从 34% 往上拉 = 唯一能在不破坏 SLA 前提下放大可发量的办法。对高产/活跃号源的视频提高采集频率，缩短"评论发表→入库"；对只产 >24h 老评论的源降权。
🥈 杠杆二：缓存预热覆盖率（进行中）
615 待派单只有 44 有号（覆盖率 7%）。常驻预热拉到近 100%，清掉"可搜部分"的冷缓存→撞名。已验证反查命中率 100%（见下）。
🥉 杠杆三：号源可达率（治本但慢）
今天 6/7 wrong_user 是用户本身搜不到（纯数字号/关搜索）。给每个号源算"可达率"（评论者里有真抖音号且允许搜索的占比），优先挖可达率高的号源，从源头少踩搜不到的人。
🏅 杠杆四：转化端（目前盲区）
今天发 25 条、用户回复 0。口径应从"发了几条"扩到"回复率/加微率"，否则发得多不转化也白搭。opener 文案 bug（如"昵称已重置"当称呼）属这一层。
小结：瓶颈不在发送端（agent/无影/配额都够），而在进料端——采集太慢（料过期）+ 缓存太冷（缺号）+ 号源人群搜不到。
7FIX 2 验证 + 常驻预热的代价/成本/影响
验证结果（2026-06-16 本机实跑一批 60）：
本批反查 60 → 命中号 60 / 确定无号 0 / 瞬时失败 0 （命中率 100%）
已写缓存 60 行（缓存 44 → 104）
说明：反查本身完全可靠，之前的 SSL timeout 是本机网络偶发，重试即过。
若设成「每 5 分钟常驻预热」，代价/成本/影响：
| 维度 | 评估 |
|---|
| LLM / Token 成本 | 零 纯反查，不调 LLM，不烧 OpenRouter 额度 |
| 本机资源 | 极低 每 5min 一个 python 批，CPU/内存可忽略 |
| 稳态调用量 | 自限 脚本跳过已缓存的，稳态只查新进的高/中意向（约每小时十几条）；初始 615 backlog 约 10 批清完后即低负载 |
| 抖音接口风险 | 低-中 · 主要是限流非封号 反查只读主页（读 ≠ 写，风险比发 DM 低一个量级），稳态量低+带 sleep、像正常浏览，账号几乎不会被封、顶多限流（接口返空 body） |
| cookie 该用谁 | 隐患 本次借的是饭粒（在用的发送号）cookie，等于让发送号同时背读+写足迹、略抬风控概率。应改用采集专用号（fanny / 小胡 / 采集号 这类只读不发的）的 cookie，把风险与发送号隔离 |
| 单机依赖 | 脆 必须本机国内 IP 跑（Fly 东京被封）。mac 休眠/关机 → 预热停 → 缓存重新变冷。不是高可用 |
| cookie 失效 | 需监控 cookie 15–30 天过期；过期后反查静默失败、缓存停更，需有告警 |
| 覆盖局限 | 治标有限 只救"可搜"那部分；对 6/7 那种用户本身搜不到的，预热到号也没用（搜不到） |
结论：常驻预热几乎零成本、值得开，但要配 ① 改用采集专用号的 cookie（别用在发的号，隔离风控）② 监控接口是否返空 body（=限流/cookie 失效）+ 到期换号 ③ 接受单机依赖（mac 关机即失效）④ 清楚它只解决"可搜但冷缓存"那部分，不解决"用户搜不到"的大头（那要靠杠杆一采集提频 + 杠杆三号源可达率）。
关于"监控 cookie 有没有风险"：监控本身没风险；真正的风险点是「用在发的号去反查」——换成采集号 cookie 就基本规避了。读操作低风险，账号不会因反查被封，顶多限流。