企微好友单聊 AI 自动回复 · 优化总结

方案B（GUI 截屏代回）· 2026-07-12 · 云电脑运行版本 v2026-07-12.1 · 代码 PR #817（commit 8cbb87d7）
10 + 7累计修复/优化项（07-09 批 + 07-10~12 实战批）
57单元测试（全绿）
2端到端全链路实测走通（读→生成→发→确认→落库）
1根本天花板（GUI）

一、这套是什么（背景）

企业微信好友单聊的 AI 自动代回。不走官方 API（官方客服 API 被 ICP / 可信 IP 卡住）， 而是在云电脑上跑一个常驻 Python loop，用「截屏 → 视觉模型认字读消息 → 固定坐标点击打字发送」的 GUI 方式代回。

数据链：云电脑 loop → Fly 中转 → Vercel /api/wecom/chat/reply → chatReply（小艳，模型 qwen3-235b-a22b-2507，07-10 起由 glm-4.6 切换、可独立回滚）→ 回传 → GUI 打字发出

先天特性：GUI 方式没有"送达回执"，靠截图认字，天生比 API 脆——两批优化都是在把这些脆点补硬。

二、07-09 批次：10 项加固（已上线，详见上一期报告）

项治什么问题状态
A 连发防抖客户连发多条时，读到半截就回、剩下的下轮又回一次（拆成多条）。改：读到待回消息后先确认聊天区 2.5s 不再变化（发完）才回。已上线
B 读取上限每次最多读 6 条 → 连发 >6 条漏前面。改为 10 条。已上线
C 红点不饿死某会话红点卡住不消时独占 3 个处理槽，饿死其他客户。改：本轮已点过的行跳过。已上线
系统消息过滤"XX撤回了一条消息""工作台统计（总客户N位/收款N元）"被当客户消息回。改：正则拦截，从源头跳过。已上线
F 红点检测修正截图含最左导航栏 → "消息"图标红角标被当成假未读。改：裁掉导航栏 + 顶部死区过滤。（07-11 已被像素扫描方案取代，见下批第 2 项）已迭代
G 发送前重抢前台"读→生成"隔数秒，其间焦点被抢 → 发送中止 / 打字中途丢焦。改：发前主动把企微顶到最前+最大化。已上线
VL 断连重试视觉模型（OpenRouter）偶发掐连接 → 整轮读取作废。改：失败重试 3 次 + 退避。已上线
★ 发送后回读确认治"假成功"——按发送键就记成功，但字没落进输入框/坐标偏/被窗口挡。改：发完截图回读，确认文案真出现在右侧才记成功。已上线
★ 定期全量扫会话客户在【无红点、又非当前打开】的会话里回消息，两条腿都够不着。改：定期把前 6 个会话逐个点开读一遍补漏。（07-11 起降频到每 20 轮：红点检测确定性后它只剩兜底作用）已上线
★ @微信 硬门系统通知/内部群被当客户回、污染台账。改：只代回标题带「@微信」的外部客户。已上线

三、07-10 ~ 07-12 实战批：三天连修 7 项（v2026-07-12.1）

07-09 批上线后连续三天实战（野荞机），把「消息发不出去 → 红点检测不到 → 真客户被拦 → 同一问题连回三遍」一整条故障链挖穿修完。每一项都有真机截图/DB 对账作为证据，不靠猜。

问题根因修法状态
消息发不进输入框（首触两天发不出）会话列表分隔条被拖宽 ~240px，固定坐标 x=391 落进列表空白区，字全打进虚空输入框坐标挪到聊天区深处（AKKE_WECOM_C_INPUT=445,913，列表怎么拖都够不着）已上线
红点挂着就是检测不到①检测带把头像列裁掉（红点长在头像上）②旧 y<60 死区把顶行会话红点全数误杀红点检测整个换成确定性像素扫描：企微红按真机截图标定，橙图标/任务栏红排除；VL 不再参与位置判断，死区废除已上线
真客户被 @微信 硬门拦死裁剪图读标题偶发丢「@微信」徽标；名字非空走不到"读空兜底"，硬门假阴性把红点白白点掉硬门前加徽标丢失救济：已知系统会话名单直接跳过，存疑名字整屏重读标题复核，读到徽标才放行已上线
会话在 VL 眼里是空的裁剪比例 0.25 是列表宽 620px 时配的，分隔条拖窄后裁剪切进聊天气泡 185px，客户消息全被裁掉按机标定 AKKE_WECOM_CROP_RATIO（分隔线像素+5 ÷ 屏宽，画图悬停即可量）已上线
★ 同一问题被连回三遍（门店地址 12:02/16:20/19:13 三连发）两层叠加：回读确认假阴性（消息其实已送达）→ 台账/落库全没记、系统失忆；VL 读气泡左右 ~1% 偶发误读 → 旧消息重新变待回 → 重新生成重新发①重验优先于重发：verify 失败登记待重验，下轮出手前先重读，在聊天里就补记账+补落库、不再发 ②出手前重复文案闸：拟发文案与近发缓冲相似度≥0.8 或前 16 字相同 → 不发、记台账止血 ③回读加长文案前缀命中，压假阴性火种已上线
VL 出口网络断连（Remote end closed）云电脑出口网络对大 POST 敏感（与抖音通道同款老毛病），连锁导致读盲 + 回读假阴处置=重启云电脑代理；诊断口径=本机打同 model 大 POST 几秒通则 API 侧健康、锅在云电脑网络运维口径
loop 冻死无人知晓心跳 ts 停在前一天没人看，黑窗版本号写死不可信运维纪律：开工先看 wecom_reply_status.json 心跳；07-12 起版本号随改动走（横幅看 v2026-07-12.1），不用再对字节数猜版本运维口径
这批修复的方法论：位置/布局类任务从视觉模型手里收回来，交给确定性代码（像素扫红点、真图标定坐标与裁剪、相似度闸），VL 只留在真正的语言任务上（认字、判内容）。每一处阈值都用真机截图离线校准后才上线。

四、目前的状况

五、还存在的 Bug / 局限

问题说明性质
无「转人工」边界决策门议价、退款、投诉、客户明显不满、要求转人工——目前一律照常自动回。抖音通道已有 needs_human + 滞留哨兵模式可照抄，企微通道还没接。待做·优先
生成侧编造记忆实测出现「您之前说在成都，是吧？」而客户从没说过成都——模型无中生有的记忆，服务端待查。待查
D 失焦发半条不记账发送中途失焦中止时只发了半条却不记账，下轮重生成整条 → 客户可能收到"半条+整条"。未修·下批
E 身份用显示名会话身份 = 销售号:显示名。客户改昵称 → 新建会话丢历史。GUI 拿不到稳定 userid，补不干净。结构性
布局标定是人肉的坐标/裁剪比例绑定分隔条位置，谁拖一下就要重标（已有画图量法，但仍是手工）。可自动化
🔒 根本天花板GUI 方案无官方送达回执，回读确认是补救不是根治。到不了"零故障、无人值守"。GUI 天花板

六、未来的优化（按性价比排序）

七、日常运维要点