「自动推送」常被理解成一种功能实际要先分清触发源否则联调时账永远对不齐业务一有结果就推到微信发货、审批、告警、到期提醒——主动调发送接口不依赖对方先说话对方说了再自动回——依赖 Webhook个人微信API二次开发两条都做但幂等、监控、代码路径建议拆开。很多人把两套搅在一个函数里表现就是偶发双发、补发补错、监控里分不清是回调丢了还是业务 MQ 没消费。主动推事件到了就发链路很短但也正因为短容易漏掉映射和熔断订单状态变更 → 查 toWxid、appId → 单号占坑 → postTextcurl -X POST http://api.geweapi.com/gewe/v2/api/message/postText \ -H X-GEWE-TOKEN: YOUR_TOKEN \ -H Content-Type: application/json \ -d { appId: 设备ID, toWxid: 好友wxid或群IDchatroom, content: 您的订单已发货运单号请以系统通知为准。 }前提要硬好友须已添加群须账号已在。toWxid填错形态群填成个人人在群里却看不到推送业务侧却以为「接口成功了」。文件用postFile链接卡片用postLink图片走postImage别把所有东西都塞进文本接口。接口发出去的内容通常不回调成败看当次ret别干等事件证明「对方收到了」。超时先查本地是否已记成功再决定补发——否则网络抖动一次客户连收三条「已发货」。和自动回的边界自动回要配回调、3 秒返回、入队处理主动推没有「入站事件」队列消费的是业务 MQ。两套触发可以共用postText不要共用同一把幂等键。短时间状态连跳待发货 → 已发货 → 运输中合并成一条再推客户体验会好很多。多顾问多号时推送必须带该客户主责appId禁止全局写死默认设备——发错号比发失败更难查。推送时最容易翻的车当群发器。个人号观感就是真人在说话。单号驱动、可停、可审计比「每分钟打满」重要。掉线还在狂重试。appId掉线应熔断推送队列并告警恢复原设备后再放行而不是一路重试把号打热。映射表脏。客户换了主责顾问、群 ID 变了、好友删了又加旧toWxid还在推失败率会突然飙升。推送前做一次轻量校验比事后对账便宜。主动推和自动回抢答。客户刚收到「已发货」又因为说了「好的」触发自动回「已收到」体验很怪。业务事件推送可以带静默窗口或和会话状态联动。先只打通「指定测试好友推一条文本」再接到工单/审批再扩文件和群通知。推送稳了再叠自动回和 AI。API 文档GeWe API - GeWe API微信 API 开发文档