好友申请处理的核心不在通过这个动作而在判断要不要通过这条决策链。按判断逻辑分三层从粗到细。一、来源判断——这个申请从哪来第一层判断看申请来源。好友事件回调里带来源信息搜索微信号加的、手机通讯录加的、群聊加的、扫二维码加的。不同来源对应不同策略。比如从付费活动群加来的——高价值用户自动通过并打 VIP 标签从随机群加来的——不确定走内容审核搜索微信号加的——主动找上门优先通过。来源判断是最粗的过滤层能挡掉一部分明显不该通过的申请。二、内容判断——验证消息说了什么通过来源过滤后第二层看验证消息内容。提取关键词做匹配含业务相关词产品名、服务名的优先通过含推广词代理、兼职、引流的拒绝验证消息为空的标记待确认。内容判断不是万能的——验证消息可以伪造所以这层只是辅助参考不能作为唯一依据。但批量申请里验证消息有明显特征的靠这层能快速分流。三、风险判断——这个号有没有问题最后一层做风险评估申请人的 wxid 是否在黑名单库、是否短时间内大量加人批量加人信号、历史是否被拒通过过。风险判断依赖积累的数据——黑名单库、行为历史都需要长期维护。新项目没有历史数据时这层几乎不起作用跑一段时间后价值才显现。三层判断对照判断层看什么典型规则准确度来源判断申请来源渠道活动群→通过、随机群→审核高内容判断验证消息关键词业务词→优先、推广词→拒绝中风险判断黑名单、行为模式黑名单→拒绝、批量加人→拒绝需数据积累三层判断示例def judge_apply(apply): # 第一层来源 if apply[source] in VIP_CHANNELS: return pass, vip if apply[source] not in KNOWN_CHANNELS: return manual, unknown_source # 第二层内容 msg apply.get(verify, ) if any(w in msg for w in SPAM_WORDS): return reject, spam_keywords if not msg: return manual, empty_verify # 第三层风险 if blacklist.has(apply[wxid]): return reject, blacklisted if rate_limiter.is_burst(apply[wxid]): return manual, burst_apply return pass, normal app.post(/webhook) def webhook(): d request.json if d.get(eventType) friend_apply: decision, reason judge_apply(d) if decision pass: accept_friend(WID, d[fromUser]) sendText(WID, d[fromUser], WELCOME_MSG) elif decision reject: pass # 不通过 else: notify_admin(d, reason) return {code: 1000}落地建议三层判断从粗到细顺序不能反——先做来源最快最准再做内容中速最后做风险最慢但最稳。初期只做前两层就够了风险层等数据积累后再加。所有不确定的申请统一走人工宁可慢审也不要误通过。接口回调字段说明参考 Eyun 开发文档。
好友申请处理的核心不在通过这个动作而在判断要不要通过这条决策链。按判断逻辑分三层从粗到细。一、来源判断——这个申请从哪来第一层判断看申请来源。好友事件回调里带来源信息搜索微信号加的、手机通讯录加的、群聊加的、扫二维码加的。不同来源对应不同策略。比如从付费活动群加来的——高价值用户自动通过并打 VIP 标签从随机群加来的——不确定走内容审核搜索微信号加的——主动找上门优先通过。来源判断是最粗的过滤层能挡掉一部分明显不该通过的申请。二、内容判断——验证消息说了什么通过来源过滤后第二层看验证消息内容。提取关键词做匹配含业务相关词产品名、服务名的优先通过含推广词代理、兼职、引流的拒绝验证消息为空的标记待确认。内容判断不是万能的——验证消息可以伪造所以这层只是辅助参考不能作为唯一依据。但批量申请里验证消息有明显特征的靠这层能快速分流。三、风险判断——这个号有没有问题最后一层做风险评估申请人的 wxid 是否在黑名单库、是否短时间内大量加人批量加人信号、历史是否被拒通过过。风险判断依赖积累的数据——黑名单库、行为历史都需要长期维护。新项目没有历史数据时这层几乎不起作用跑一段时间后价值才显现。三层判断对照判断层看什么典型规则准确度来源判断申请来源渠道活动群→通过、随机群→审核高内容判断验证消息关键词业务词→优先、推广词→拒绝中风险判断黑名单、行为模式黑名单→拒绝、批量加人→拒绝需数据积累三层判断示例def judge_apply(apply): # 第一层来源 if apply[source] in VIP_CHANNELS: return pass, vip if apply[source] not in KNOWN_CHANNELS: return manual, unknown_source # 第二层内容 msg apply.get(verify, ) if any(w in msg for w in SPAM_WORDS): return reject, spam_keywords if not msg: return manual, empty_verify # 第三层风险 if blacklist.has(apply[wxid]): return reject, blacklisted if rate_limiter.is_burst(apply[wxid]): return manual, burst_apply return pass, normal app.post(/webhook) def webhook(): d request.json if d.get(eventType) friend_apply: decision, reason judge_apply(d) if decision pass: accept_friend(WID, d[fromUser]) sendText(WID, d[fromUser], WELCOME_MSG) elif decision reject: pass # 不通过 else: notify_admin(d, reason) return {code: 1000}落地建议三层判断从粗到细顺序不能反——先做来源最快最准再做内容中速最后做风险最慢但最稳。初期只做前两层就够了风险层等数据积累后再加。所有不确定的申请统一走人工宁可慢审也不要误通过。接口回调字段说明参考 Eyun 开发文档。
