零星（小星）云电脑 DM 通道抢修全记录
开场白发送 0 → 64% · DM 自动回复链路打通 · route-B 恢复运行
时间 2026-06-30 → 07-01 · 账号 8af08f10…（零星/夏夏）· 无影云电脑 2560×1600
通道运行状态
三条腿全跑 DM · route-B×2
一句话前因：零星的 DM 通道几乎发不出去（连续 wrong_user）、用户给账号发消息数据群不推送也不自动回复、云电脑还老自己跳到「创作者中心/投稿」。三个症状查到底，根因各不相同——坐标漂移、只读模式没开、页面状态误触——本页把每个问题的现象 → 试过的失败方案 → 成功根因 → 解法全列出，失败的弯路也留着，避免下次重走。
问题一 · 开场白发送 0 成功 / 53 连 wrong_user 已解决
| 现象 | 零星派单几乎全部 wrong_user/(非主页)，0 条 sent——搜到的名字落到非主页，身份闸不过。 |
|---|
| 失败方案 ① | 切英文输入法 → 用户试了，没用。 |
|---|
| 失败方案 ② | 单独重启 agent → 没用。 |
|---|
| 失败方案 ③ | 归咎 C_HOME 跳创作者中心 → 用户说「还是跳」，错误归因。 |
|---|
| 成功根因 | AKKE_C_SEARCH 坐标漂移（实测 527,19 vs 默认 432,25，X 偏约 250px）→ 搜索框点击落到了视频上 → 空搜索 → 根本搜不到人。默认坐标只在 2560×1620 有效，这台是 2560×1600。 |
|---|
| 解法 | 逐点重量 9 个坐标写进 .env 重启 → 发送 0 → 64%。 |
|---|
| 剩余 | 剩余 wrong_user 原以为是 short_id 天花板——72h 逐条深挖推翻了此说（100% sec_uid、0 短号）。真因是搜索/身份读取流程 bug，可修，见下「派单失败原因分布 · 深挖」。 |
|---|
派单失败原因分布 夏夏核对 · dispatch_queue 权威口径
夏夏问：日志里 skip 那几行写的是 wrong_user 还是 dm_panel_failed？有没有别的漏网原因？
答：取 dispatch_queue.error_message（比肉眼看黑窗全）归类如下——
| 原因 |
近24h |
近48h |
性质 |
| wrong_user（非主页·身份闸） | 25 · 66% | 70 · 74% | 搜到的名字落非主页，身份闸不过 |
| expired（评论>10min·新鲜闸） | 4 · 11% | 13 · 14% | 主动跳过，非失败 |
| sent 成功 | 8 · 21% | 9 · 9% | — |
| unverified（未验证） | 1 · 3% | 3 · 3% | 边角 |
回答夏夏两个点：
- 没有
dm_panel_failed，也没有任何没归类的漏网原因。所有 skip 干净落在 3 类：wrong_user / expired / unverified。
- wrong_user(非主页) 占 74% 偏高——我逐条深挖了 72h 的 70 条，推翻了 short_id 天花板说，真因是搜索/身份读取流程 bug（详见下方「深挖」专表）。真正「漏网」的不是缺原因类别，而是这个可修的 bug 在压制可达线索。
口径：dispatch_queue 按 completed_at 窗口、error_message 归类；expired 属新鲜闸主动跳过不计失败。sent 占比是跨窗口均值，低于修复瞬时的 64% 峰值（含修复前时段；且大部分 wrong_user 实为搜索流程 bug 而非不可达，见下方深挖）。
深挖 · wrong_user 真因（72h / 70 条逐条交叉分析）推翻天花板说
| 目标是否重投 | 70 条 = 70 个不同目标，无一重试 → 不是同几个号被反复投。 |
|---|
| 目标 ID 形态 | 100% sec_uid（MS4..），0 个纯数字短号 → 根本不是 short_id 不可搜天花板。 |
|---|
| 搜 A 落到谁 | 搜 A 落到别人 B 的主页 = 35 条（50%）；搜自己落到自己非主页 = 仅 1 条。 |
|---|
| 落地页高度集中 | SHUI×10、小读知新×9、鱼破冰×5、(空白页)×46——这几个「粘性页」本身都不在派单队列里（不是前一个目标），却跨 8 小时对不同目标反复出现。 |
|---|
| 定性结论 | 连「珩妈 带娃玩」这种不生僻的名字都落到 SHUI → 排除纯重名歧义，坐实搜索/身份读取流程 bug：搜索框没清干净 / 结果没刷新就读身份，反复停在少数粘性页。可修，不是不可达天花板。 |
|---|
| 建议（P1） | douyin_dm_grounded 搜索腿加：清空搜索框 → 等结果刷新 → 确认目标名匹配再读身份。修好能挽回一大块 74% 的 wrong_user。少量超生僻名（emoji/单字）确有重名歧义、半结构性挽不回。 |
|---|
代码级根因 · 已定位到具体函数 PR #690 已合并 · 代码侧已修
2026-07-03 状态更新：修法①（代码）已合并进 main（PR #690，2026-07-01），goto_home() 已真接进 process()（douyin_dm_grounded.py:817），不再是死代码。修法②（机器）需每台云电脑 .env 各自量 AKKE_C_HOME 才激活——部署 runbook 已给坐标（29,84@2560×1600），换机器/换分辨率要重量。另注：还有一个 #690 治不了的独立坑——同台云电脑若同时跑「图文自动发」会抢桌面焦点、照样 wrong_user，只能图文与 DM 分机/分时（见问题二）。
| 元凶 | goto_home()（douyin_dm_grounded.py，2026-06-12 专门写来治此 bug——点左侧「推荐」把搜索框钉回稳定位置，docstring 明写「每条搜人前调一次」）当时是死代码，整个文件从没被调用过（2026-07-01 PR #690 已接线，见修法①）。 |
|---|
| 触发链 | process() 每条只调 reset_to_home()（Esc+关聊天），不回首页。代码自己注释（C_SEARCH 处）就写「结果页时顶部搜索框会挪位」→ 上一条停在结果页 → 固定 C_SEARCH 坐标点空 → 打字/回车没执行 → 上一条残留结果还在 → 点第一条 = 残留人（SHUI/小读知新）。 |
|---|
| 双重坑 | ① goto_home() 在 process() 里没接线；② 就算接上，它 if not C_HOME: return —— 零星机没量 AKKE_C_HOME 也是 no-op。两个都得修。 |
|---|
| 顺带澄清 | 早先怀疑 C_HOME 导致跳创作者中心——不可能，因为 goto_home 根本没被调，设不设 C_HOME 都无效（这也解释了当时「删了还跳」）。 |
|---|
| 修法①（代码）已合并 | PR #690（2026-07-01 已合并 main）：process() 每条搜索前加 goto_home()，现已接线（douyin_dm_grounded.py:817）。guarded：没量 C_HOME 时 no-op、零风险。 |
|---|
| 修法②（机器） | 云电脑 .env 量 AKKE_C_HOME（左侧「推荐」按钮坐标）才激活。两个都到位后，搜索框每条钉回稳定位，残留页链断掉。 |
|---|
比补丁更深一层 · wrong_user 的真正分界是「自动化方式」，不是坐标 方法层根因（2026-07-03 增补）
PR #690（goto_home 回首页）是给「GUI 截图+坐标点击」这套方式打的补丁，能治「残留别人名字的粘性页」那一小块，治不了大头「空白页」——因为空白页是坐标点空、回首页也救不回会飘的坐标。换个视角：同期同代码同通道（cloud_pc）的四个号里，唯一 wrong_user=0 的「有大有小」用的根本是另一套方式——浏览器 DOM。
| 找人方式 | GUI 截图+坐标（零星/饭粒/小文用 douyin_dm_grounded.py） | 浏览器 DOM（有大有小用 douyin_dm_web_send_dom.py） |
|---|
| 认的是 | 屏幕上的像素位置（第 X 像素点搜索框、点第一条） | 页面里的元素（找到搜索框元素、点结果里那个人的节点） |
|---|
| 会不会点错人 | 会——坐标飘一点 / 分辨率不对 / 别的窗口（图文）抢焦点 → 点到空白处 → 落到空白页或残留页 = wrong_user | 不会——要么点到目标元素、要么干脆找不到直接失败，不会「点到别人」 |
|---|
近 120h 四号实测（同为 cloud_pc 通道、同代码）：
| 账号 | 方式 | wrong_user | 其中空白页(坐标点空) | 占比 |
|---|
| 有大有小 | 浏览器 DOM | 0 | 0 | 0% |
| 饭粒/一筑 | GUI 坐标 | 67 | 43 | 34% |
| 小文/野荞 | GUI 坐标 | 18 | 13 | ~37% |
| 零星 | GUI 坐标 | 104 | 78 | 61% |
零星每日 wrong_user 占比：6/29 94% → 6/30 79% → 7/1 36%（#690 合并当天回落）→ 7/2 66%（又反弹）。补丁按住一部分、脆弱的底子还在，正是「空白页大头治不了」的表现。
| 结论 | 零星高、有大有小 0，不是号池差、不是机器没校准，是两种方式本质不同：GUI 认像素位置（天生会点空/被抢焦点），DOM 认页面元素（天生不点错）。之前说的「坐标飘 / 图文抢焦点」都对，但只是 GUI 这套的具体翻车原因，DOM 压根不吃这一套。 |
|---|
| 正解（比继续调坐标更干净） | 零星/饭粒/小文要根治 wrong_user，最稳的路是切到有大有小已验证 0% 的浏览器 DOM 方式（douyin_dm_web_send_dom.py）。继续在 GUI 坐标上打补丁（量坐标、停图文）只能压不能除。 |
|---|
问题二 · DM 自动回复：不回复 + 数据群不推 + 老跳投稿
今天的主战场，拆成 4 个子问题。
B1 · 数据群不推 + 不自动回复 管道修好，待端到端绿卡
| 现象 | 用户给小星发消息，数据值班群没收到推送，也没有自动回复。 |
|---|
| 失败假设 | 怀疑 AKKE_C_DM_INBOX 坐标飘、点到创作者中心 → 重量发现 871,8 ≈ 旧 884,7，基本没飘，假设推翻。 |
|---|
| 成功根因 ① | AKKE_DM_AUTOREPLY_MODE=capture（只读模式）→ 发送腿从不跑 → 草稿永远到不了 sent；而数据群推送只在 sent 那一刻触发 → 永远空。
跨账号铁证：一筑 sent=5/推=5、有大有小 sent=4/推=8；零星 sent=0、1 条 approved 卡住、推=0。 |
|---|
| 解法 ① | 改 AKKE_DM_AUTOREPLY_MODE=both → 发送腿激活（跟一筑同款配置）。 |
|---|
| 成功根因 ② | 旧坐标 884,7 现场点到了投稿；亲手重量的 871,8 才是真「私信」。差 33px，在挤满按钮的顶角就是「私信 vs 投稿」的区别。 |
|---|
| 解法 ② | 写 AKKE_C_DM_INBOX=871,8 / AKKE_C_DM_FIRST=691,111。 |
|---|
| 验证 | 黑窗证明 mode=both、点私信不跳投稿、读到 26 行会话——管道全通。但此刻手头没有一条「全新真客户回复」能拉着走到绿卡，尚未亲眼见到端到端一次成功（靠等真客户回复验证）。 |
|---|
B2 · 云电脑老跳创作者中心/投稿 根因定位 正解待办
| 现象 | 云电脑经常自己跳到创作者中心；agent 启动第一下点到「投稿」。 |
|---|
| 失败假设 ① | 归咎 C_HOME → 用户说还跳，推翻。 |
|---|
| 失败假设 ② | 归咎图文 agent 抢焦点 → 查无 msedge 进程（图文在夏夏自己电脑跑），排除。 |
|---|
| 失败假设 ③ | 归咎 DM_INBOX 坐标漂移 → 重量发现没飘，部分推翻。 |
|---|
| 成功根因 | 用户自己查出：抖音首页点私信会误触首页正在播的视频；综合/视频页点才正常——首页沉浸式视频流盖掉了顶栏。
⚠️ 我之前「重启前回首页」的建议正好是反的，已纠正。 |
|---|
| 临时解法 | 重启前让抖音停在私信/综合页，别停首页。 |
|---|
| 正解（待办） | 改代码：捕获前强制切到稳定页，不靠人记得别停首页。 |
|---|
B3 · 小号测试为何测不通 已解释（非 bug）
| 现象 | 用小号冷发消息给零星，捕获腿不抓、不回。 |
|---|
| 根因 | 设计如此（douyin_dm_autoreply.py:156-158）：捕获只处理「零星先发过开场白、对方回复」的会话，靠 480 条已发记录匹配；冷私信不在记录里 → 直接 continue 跳过。自动回复 = 回应外呼客户，不接管陌生冷私信。 |
|---|
| 结论 | 小号这条路测不了（除非先让零星走完整流程给小号发过开场白）；真正的验证靠等真客户回复外呼后的对话。 |
|---|
B4 · 捕获把时间戳读成回复 附带发现·次要
| 现象 | [inbound] 春暖花开: 00:20 / 春夏秋冬: 00:54——预览是时间戳，不是回复内容。 |
|---|
| 根因 | 捕获把会话时间戳误读成消息预览（classify 漏判），record_dm_inbound 幂等 no-op，没产出新草稿。 |
|---|
| 状态 | 次要，先记着；真回复内容够长时不受影响。 |
|---|
问题三 · 环境/操作坑（过程中踩的） 都有解
| .bat 乱码炸 | start-dm-routeb.bat 一堆「不是内部命令」。根因：机器上是旧中文版 .bat，cmd 按 GBK 读 UTF-8 中文、把注释当命令跑。
解法：绕过 .bat 直接手动起 python；正解=换干净英文版 .bat（route-B 那个已从镜像 curl 修好；DM 那个走 PowerShell 内联写）。 |
|---|
| cmd 吞字符 | echo ...=871,8>> 里 8>> 被当成「重定向数据流 8」，871,8 没写进去。解法：重定向 >> 放最前 >>file echo ...。 |
|---|
| agent.log 陈旧 | 手动 cmd /k 起的日志进黑窗、不进 agent.log，别看它误判。 |
|---|
| 镜像同步盲点 | 干净英文版 start-dm-routeb.bat 早合 main，但没进镜像同步列表 → 镜像永远 stale → 机器 curl 只能拉到坏版本。已提 PR 补进 sync-wuying-scripts.yml，根治。 |
|---|
抢修时间线
起点
零星 DM 连续 wrong_user，0 sent；数据群无自动回复推送；云电脑老跳创作者中心。
诊断 · 发送
排除输入法/重启/C_HOME 三条弯路 → 定位
AKKE_C_SEARCH 坐标漂移。
✅ 修复 · 发送
重量 9 坐标写 .env 重启 → 发送 0 → 64%。
诊断 · 自动回复
跨账号对比锁定
MODE=capture 只读；现场看到启动点投稿定位坐标+页面状态。
✅ 修复 · 自动回复
改
MODE=both +
DM_INBOX=871,8 + 停综合页重启 → 黑窗读到 26 行会话、点私信不跳投稿。
✅ 恢复 · route-B
绕过坏 .bat 直接起 watch+consume（窗口锁串行），三条腿全跑。
进行中
长 watcher 盯真客户回复走到数据群绿卡，端到端最后一验。
当前运行状态
- DM + 自动回复（
wuying_poll_agent，mode=both，坐标已修）—— 每 5min 扫收件箱，读到 26 行会话，一次网络 read timeout 已自恢复。
- route-B watch ——
lead池 536 · 每60s拉3页，正常。
- route-B consume ——
队列 realtime-touch-queue.jsonl · 自动发，正常。
待办清单
- P0 端到端验证：等一条真客户回复走完到数据群绿卡（长 watcher 盯着）。
- P1 修
douyin_dm_grounded 搜索腿：清空搜索框→等结果刷新→确认目标名匹配再读身份。当前 74% wrong_user 大头是它（50% 搜 A 落 B、粘性页），修好挽回可达线索——比 short_id 天花板影响大得多。
- P1 DM 的
start-dm-routeb.bat 换干净英文版（PowerShell 内联，以后双击一键起）。
- P2 正解硬化：捕获前强制切稳定页，根治 B2 首页误触。
- P2（可选）治 B4 时间戳误读为回复。
方法论教训
- 三个症状 ≠ 一个根因。发送=坐标漂移、自动回复=只读模式、跳投稿=页面状态，三者独立，硬凑成一个原因会全错。
- 理性归因、别把弯路当结论。本轮推翻了 4 个失败假设（输入法/重启/C_HOME/DM_INBOX 坐标飘），靠跨账号数据对比 + 现场黑窗证据才锁定真因。
- 坐标必须按分辨率现量。默认坐标只在 2560×1620 有效；2560×1600 的机器全飘，是重复踩的坑。
- 用户的现场观察是金矿。「首页点私信会误触视频、综合页不会」是用户自己查出来的，直接纠正了我反了的建议。