潜在触达 · 三天复盘
06-15 → 06-17 ｜ 路B 实时潜在触达 ｜ 检测 vs 真发 / 问题 / 根因 / 能否解 / 会否再犯
一句话：检测端三天一直有货（每天 15–18 条 ≤20min 新鲜视频），瓶颈从来不是供给、是执行层。三天在"逐个拆墙"——卡死→focus→搜索坐标，每修一堵露下一堵；06-17 傍晚把 focus+搜索两堵拆通（搜索实测 match=True），是最接近破冰的状态。
一 · 硬数据（真发按 comment_log 计，日期准）
| 日期 | 检测≤20min | 尝试发送 | 真发成功 | 完整三连 | 净结果 |
|---|
| 06-15 前天 | ~18 | 10 | 6 | 5 | 唯一有真发的一天 |
| 06-16 昨天 | 15 | 1 | 0 | 0 | 执行器卡死 10h |
| 06-17 今天 | 十几条 | 8 | 0 | 0 | 连撞 2 堵墙、傍晚拆通（待验完整三连） |
注：「检测≤20min」是监控逮到的新鲜视频数（每天稳定有货）；「尝试发送」「真发」来自 comment_log，是执行层实况。
二 · 问题清单（为何 / 能否解 / 现状 / 会否再犯）
| # | 问题 | 为何出现 | 能解? | 现状 | 再犯? |
|---|
| 1 | 06-16 卡死 10h、全天 0 | consume 调执行器无超时，一次 GUI 卡住冻全程 | 能 | 加 300s 硬超时+落盘，已部署 | 不会（超时硬护栏） |
| 2 | 06-17 focus_fail 全失败 | 重启后窗口标题 抖音→douyin，执行器只认抖音 | 能 | 改两个都认，实测生效 | 不会（认两种标题） |
| 3 | 06-17 wrong_user/@xiexie | 重启后搜索框坐标 y=13 点空、昵称没输进框→搜空 | 能 | 坐标改 400,25，实测 match=True | 会（每次重启坐标可能再挪） |
| 4 | 06-15 部分失败（3+1） | 3 send_unverified=VL截图验证过严、把已发的评论冤判没发（假阴）；1 focus_fail=焦点偶失真没打字 | 部分 | LENIENT 已开(治假阴) + focus 已根治 | 减少，但 GUI 本质脆 |
| 5 | wrong_user 另一种：未知客户 | 抓评论那刻没拿到作者抖音昵称(抖音对某些号返回空显示名)，库里只存占位「未知客户」；按昵称搜"未知客户"搜不到本人 | 待做 | 改用抖音号搜(未做)，这类跳过 | 会（没改搜号前） |
| 6 | 深夜/重启平台挂起 | 无影平台层空闲挂起，powercfg 管不到 | 个人版无解 | 接受白天档 | 会(每晚)，但深夜本无货(1.8%) |
三 · 为什么三天 0 破冰、今天才接近
检测端一直有货，但执行端一堵墙接一堵墙：卡死(16) → focus_fail(17早) → 搜索坐标(17午)，每修一堵就露下一堵。06-17 傍晚 focus+搜索两堵都拆了、搜索关实测通了（match=True 搜到真人），就差点赞/评论坐标（重启可能也挪了，待下一条真触达验）。
四 · 根本特性 + 会不会再犯
检测走 API（可靠）、执行走 GUI（脆）
这是结构性的：GUI 对
重启 / 版本 / 焦点 / 分辨率敏感。
- 永久不再犯：卡死（超时护栏）、focus_fail（认两标题）——上了硬护栏。
- 会再犯、靠纪律防：坐标类（搜索/点赞/返回），每次重启/换机可能挪 → 靠「重启后
_capture_pos.py 重测 + --confirm 主动验」这套流程兜。这是 GUI 自动化的固有维护成本，消不掉、只能流程化。
- 接受的：平台深夜挂起（无解，但深夜无货不亏）；未知客户 wrong_user（待做抖音号搜）。
五 · 现状一句话
焦点、搜索两堵墙今天拆通（搜索实测 match=True），三天来最接近破冰；只剩点赞/评论坐标待下一条真触达验。检测从不是问题，执行层的坐标维护是长期成本。