需求表述成 RPA 时实现容易滑向找控件、点发送。客户端改版后坐标失效双方会争论定义。甲方要的是无人值守执行乙方交付的是视觉上像人在点。演示都能成功所以不能用演示代替生产判据。工位后面一台挂着微信都能演示跟进也都能在一次更新或锁屏后集体停。个人号还绑在单机上。电脑休眠出站链路就停。这比很多内部系统更依赖「别靠桌面」。点击链路在三个维度上不可审计执行依赖前台。锁屏、分辨率、远程桌面抢焦点、主机休眠都会静默失败。失败无法按单重试点过即成功点空无法枚举未完成项。超时与已发送无法分离弹层挡住时「按下」是假成功。迁到按会话投递后失败率短期上升往往是假成功被揭开。不把这句话说清楚业务会要求退回脚本。可调度单元应是号实例、接收方类型、已渲染内容、计划时间、回执三态。像素坐标不属于接口契约。三个月后改的应是规则和间隔不是选择器。登录保活若仍需客户端交互可以留在边角业务发送走投递。夜间任务不应绑桌面会话。杀毒弹窗也是执行面故障。点击脚本记的是「点到了」。任务模型记的是可对账字段。对比一下就清楚差在哪# 不要click(x1024, y680) 坐标不是契约task{app_id:设备ID,to_type:friend,# 或 groupto_id:wxid_...,content:已渲染文本,biz_key:welcome:app:wxid:20260824,receipt:pending,# ok / fail / uncertain}receipt才能进审核和补发。click成功对不上聊天里有没有那句话。迁到任务之后第一周失败率升高先核对这些历史点击是不是假成功。无间隔、无审核的高速点击会把号打脏。接口的价值在于可暂停、可审核、可只补失败集合。偶尔改一次备注人手点也行。高频跟进、通过即问候、夜间任务绑在桌面上人力会耗在「今天脚本又漂了」。前期点击便宜贵在每周修。总账看三个月不看演示那天。内部演示或一次性迁移可以保留点击。生产会话与夜间跟进不应以点击为主通道。抽历史点击「成功」记录去聊天里核对对不上的记成欠账。假成功被揭开的那一周失败率看起来变差这是还账不是通道变差。查看个人微信 API 文档https://doc.geweapi.com/