企业官网建设流程全解析

「自动推送」常被理解成一种功能，实际要先分清触发源，否则联调时账永远对不齐：

• 业务一有结果就推到微信（发货、审批、告警、到期提醒）——主动调发送接口，不依赖对方先说话

• 对方说了再自动回——依赖 Webhook

个人微信API二次开发两条都做，但幂等、监控、代码路径建议拆开。很多人把两套搅在一个函数里，表现就是：偶发双发、补发补错、监控里分不清是回调丢了还是业务 MQ 没消费。

主动推：事件到了就发

链路很短，但也正因为短，容易漏掉映射和熔断：

订单状态变更 → 查 toWxid、appId → 单号占坑 → postText

curl -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或群ID@chatroom", "content": "您的订单已发货，运单号请以系统通知为准。" }'

前提要硬：好友须已添加，群须账号已在。toWxid填错形态（群填成个人），人在群里却看不到推送，业务侧却以为「接口成功了」。文件用postFile，链接卡片用postLink，图片走postImage，别把所有东西都塞进文本接口。

接口发出去的内容通常不回调，成败看当次ret，别干等事件证明「对方收到了」。超时先查本地是否已记成功，再决定补发——否则网络抖动一次，客户连收三条「已发货」。

和自动回的边界

自动回要配回调、3 秒返回、入队处理；主动推没有「入站事件」，队列消费的是业务 MQ。两套触发可以共用postText，不要共用同一把幂等键。

短时间状态连跳（待发货 → 已发货 → 运输中），合并成一条再推，客户体验会好很多。多顾问多号时，推送必须带该客户主责appId，禁止全局写死默认设备——发错号比发失败更难查。

推送时最容易翻的车

当群发器。个人号观感就是真人在说话。单号驱动、可停、可审计，比「每分钟打满」重要。

掉线还在狂重试。appId掉线应熔断推送队列并告警，恢复原设备后再放行，而不是一路重试把号打热。

映射表脏。客户换了主责顾问、群 ID 变了、好友删了又加，旧toWxid还在推，失败率会突然飙升。推送前做一次轻量校验，比事后对账便宜。

主动推和自动回抢答。客户刚收到「已发货」，又因为说了「好的」触发自动回「已收到」，体验很怪。业务事件推送可以带静默窗口，或和会话状态联动。

先只打通「指定测试好友推一条文本」，再接到工单/审批，再扩文件和群通知。推送稳了，再叠自动回和 AI。

API 文档：GeWe API - GeWe API｜微信 API 开发文档