好友申请处理不是一个接口的事而是一条完整的自动化管线。从收到申请到完成处理分三个环节。一、感知环节——程序怎么知道有人申请靠好友事件回调。用户发起好友申请时Eyun 通过 Webhook 推送事件通知回调数据里带申请人标识、申请来源、验证消息。感知环节的关键是别漏——回调 5 秒内返回 1000超时会重试 3 次。程序收到后先把申请记录入库再异步处理不阻塞回调响应。二、判断环节——自动通过还是拒绝拿到申请后程序做判断。判断依据通常有三类来源渠道某个活动来的自动通过、验证消息关键词含代理加人等词拒绝、已有客户匹配CRM 里有记录的优先通过。判断结果分三种明确通过、明确拒绝、不确定转人工。规则不要太复杂覆盖 80% 的常见情况就够剩下的交人工。三、执行环节——通过后紧接着做什么判断为通过后程序执行一连串动作调通过接口接受申请改备注加来源标签方便后续分组发欢迎语引导用户进入下一步流程。执行环节要处理失败情况——通过成功但发欢迎语失败要有重试机制。每个动作独立执行一个失败不影响其他。三环节对照处理环节做什么关键机制感知收到申请通知好友事件回调、5 秒响应判断规则决定通过/拒绝/转人工来源匹配、关键词、CRM 关联执行通过 改备注 发欢迎语接口调用、失败重试自动处理示例app.post(/webhook) def webhook(): d request.json if d.get(eventType) friend_apply: apply_q.put({ # 入库异步处理 wxid: d[fromUser], source: d.get(source, ), verify: d.get(verifyMsg, ) }) return {code: 1000} def apply_worker(): while True: a apply_q.get() if a[source] in AUTO_PASS_CHANNELS: # 来源自动通过 accept_friend(WID, a[wxid]) set_remark(WID, a[wxid], f渠道-{a[source]}) sendText(WID, a[wxid], 欢迎回复1看菜单) else: notify_admin(a) # 转人工审核落地建议好友申请自动化能省大量人工但规则要保守。建议先用感知 转人工模式跑一段时间观察申请来源分布和验证消息特征再逐步开放自动通过。通过后的欢迎语和改备注动作要确保成功率好友加了但没欢迎到位等于白加。