新成员进群，最好立刻看到规则和对接方式。靠人盯通知，高峰必漏，也难审计「到底欢不欢迎过」。个人微信客户群挂不了官方机器人；个人微信API二次开发用事件驱动欢迎——人来了系统才动。

能力说明见 GeWe API 开放文档。欢迎自动化难在「别刷屏、别漏、别从错号发」，不在多写几句文案。

欢迎要解决的真实问题

• 漏：回调超时或没入队，人进了群什么也没有

• 重：同一进群事件补推，欢迎说两遍，很像机器人广告

• 错：多号托管时从非主责号发出，客户不知道该回谁

• 烦：一分钟进五个人就发五条长文，群被刷爆

所以设计目标是：及时、至多一次、主责号、可合并。

落地时怎么决策

模板优先于模型。 进群是突发高峰，同步调大模型最容易拖死回调。短模板足够；个性化用「群类型 / 来源渠道」换模板，不必句句生成。

幂等先于文案。 没有事件级占坑，文案写得再好也会双发。重复到达应直接吞掉，不要再回失败码把补推拉得更猛。

主责号先于群发。 映射里写清「这个群由哪个设备负责欢迎」。两个托管号都在群里时，双欢迎几乎必然。

合并窗口。 短时间多人进群，合成一条「欢迎 A、B 等 N 人」比连发体验好，也更像真人运营。

和「群通知」别搅在一起

欢迎是进群事件驱动；工单进度是业务单据驱动。两套触发、两套占用键、两套监控。搅在一起会出现：工单重试把欢迎又打一遍，或欢迎失败把工单队列堵住。

主责号确认在群后，欢迎可以落成一条短文本（需要 @ 时按文档补 ats）：

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": "群ID@chatroom",
    "content": "欢迎加入本群，请先看置顶群规；急事请@值班。"
  }'

上线前重点验收

测试群进一人：欢迎 ≤ 1，CRM 有「已欢迎」记录。同一事件重放三次仍一次。故意让主责号掉线：应告警且不从备用号乱发（除非你明确设计了降级主责）。多人连进：合并策略符合预期，而不是刷屏。

群欢迎自动化，干货在事件纪律，不在接口清单。细节对照开放文档，产品决策按上面几条定。