影刀RPA店群自动化实战多店铺买家黑名单共享与协同防御系统设计店群最隐蔽的损失不是平台佣金不是广告费而是恶意买家。一个买家在你A店仅退款成功转头又去你B店下单同样的商品再次申请仅退款。由于店铺之间没有信息共享他屡试不爽。我们统计过一个职业“羊毛党”可以在半年内从同一个商家的不同店铺薅走价值上万元的商品。更别说那些给差评要挟退款的、寄回空包裹的、谎称未收到货的。单个店铺看这些买家占比不高但所有店铺加起来每月损失的数字相当可观。拼多多店群自动化上架方案我们早期每个店铺独立拉黑名单结果同一买家换个店铺继续作案。后来我们搭建了一套多店铺买家黑名单共享与协同防御系统所有店铺的黑名单实时同步新订单进来时自动拦截高风险买家并支持跨店铺的差评预警和退款限制。这篇文章不讲上架也不讲广告。专门聊聊店群场景下恶意买家协同防御的工程实践如何识别恶意行为如何跨店铺共享黑名单如何与订单系统联动以及如何通过数据分析发现批量攻击模式。适用场景多店铺运营、频繁遭遇恶意买家/职业打假/羊毛党的店群项目。技术栈影刀RPA Python Redis 规则引擎 订单拦截API。TEMU店群如何管理运营一、恶意买家的四种常见模式先总结我们遇到的真实案例。模式一高频仅退款买家下单后以“质量问题”申请仅退款上传模糊图片。平台倾向于保护买家往往同意退款。一个账号在多个店铺重复操作专门挑低价商品。模式二寄回空包裹/虚假单号申请退货退款填一个假物流单号或者寄空包。系统自动签收后触发退款商家货钱两空。模式三差评勒索下单后给差评然后联系客服要求退款或送优惠券否则不改评价。模式四批量注册账号用虚拟手机号注册多个账号在同一店铺或不同店铺大量下单然后批量退款测试商家的风控底线。单个店铺很难发现这些模式因为数据量不够。但把所有店铺的数据聚合起来就能看到清晰的恶意行为画像。二、整体架构系统分为五个模块。行为采集模块影刀RPA定时从各店铺后台抓取订单、退款、评价、客服消息等数据推送到Kafka。特征提取模块实时分析每条行为计算买家维度指标退款率、纠纷率、差评率、IP段、收货地址、下单频率等。风险评估模块规则引擎根据特征输出风险评分0-100超过阈值自动加入黑名单。黑名单共享模块黑名单存储在中心Redis所有店铺实时同步。订单创建时系统调用接口检查买家是否在黑名单中。拦截与处理模块高风险买家下单后系统通过订单API自动取消订单或标记为“需人工审核”并发送告警。下面重点讲解特征提取、风险评估和跨店铺同步。三、买家画像与风险特征提取从订单、退款、评价、客服对话中提取买家的行为特征。时间窗口为过去90天。# buyer_profiler.pyclassBuyerProfiler:def__init__(self,buyer_id):self.buyer_idbuyer_iddefload_features(self):# 从数据仓库查询该买家的所有店铺行为sql SELECT COUNT(DISTINCT order_id) as total_orders, SUM(CASE WHEN refund_status refunded THEN 1 ELSE 0 END) as refund_count, SUM(CASE WHEN refund_reason LIKE %假货% OR refund_reason LIKE %质量% THEN 1 ELSE 0 END) as quality_refund_count, AVG(order_amount) as avg_order_amount, COUNT(DISTINCT shop_id) as shops_visited, COUNT(DISTINCT DATE(order_time)) as active_days, SUM(CASE WHEN review_rating 2 THEN 1 ELSE 0 END) as bad_review_count FROM unified_events WHERE buyer_id %s AND order_time NOW() - INTERVAL 90 DAY returndb.query(sql,self.buyer_id) 计算衍生指标-退款率退款订单数/总订单数--仅退款率仅退款订单数/总退款数--差评率差评数/总评价数--平均客单价如果总是买低价商品可能是羊毛党--收货地址重复度同一地址关联多个买家账号 → 可疑--IP段聚集性同一IP段出现大量不同买家 → 可能为批量注册 这些指标存储在Redis的Hash结构中key为buyer_profile:{buyer_id}TTL为90天。---## 四、风险评估与黑名单规则规则引擎实时评估新订单的买家风险。规则示例-退款率60%且 总订单数5→ 高风险疑似恶意退款--仅退款占比80%且 客单价30元 → 中风险--差评率50%→ 高风险差评师--同一收货地址关联 ≥3个不同买家账号 → 高风险批量小号--30天内退款次数 ≥5→ 中风险--命中已知恶意买家名单从行业共享或手工添加→ 直接黑名单 规则使用JSON配置运营可调整阈值。 python# risk_scorer.pyclassRiskScorer:def__init__(self,rules):self.rulesrulesdefevaluate(self,profile):risk_score0risk_reasons[]forruleinself.rules:ifrule[condition](profile):risk_scorerule[score]risk_reasons.append(rule[reason])returnmin(risk_score,100),risk_reasons 风险等级-0-30正常--31-60关注订单标记“可疑”人工可放行--61-100高风险自动拒绝订单或强制人工审核 当买家的风险评分超过70时自动加入黑名单。---## 五、跨店铺黑名单共享与实时拦截黑名单存储在中心Redis集合blacklist:buyers中所有店铺的订单创建接口都会调用is_blacklisted(buyer_id)。 python# blacklist_service.pyclassBlacklistService:def__init__(self,redis_client):self.redisredis_clientdefadd(self,buyer_id,reason,expire_days180):self.redis.sadd(blacklist:buyers,buyer_id)self.redis.hset(fblacklist:reason:{buyer_id},reason,reason)self.redis.hset(fblacklist:reason:{buyer_id},expire,int(time.time()expire_days*86400))defis_blacklisted(self,buyer_id):ifnotself.redis.sismember(blacklist:buyers,buyer_id):returnFalse# 检查是否过期expireself.redis.hget(fblacklist:reason:{buyer_id},expire)ifexpireandint(expire)time.time():self.redis.srem(blacklist:buyers,buyer_id)returnFalsereturnTrue 在订单创建环节API或影刀脚本先调用is_blacklisted。如果命中则-调用平台订单取消API如果允许--或者标记订单为“风控拦截”不自动发货等待人工确认--发送告警给运营“黑名单买家XXX尝试下单已拦截” 对于已经支付但未发货的订单系统自动发起退款通过API避免损失。---## 六、跨店铺行为关联发现批量攻击单独的买家特征可能不明显但多个买家共享相同收货地址、手机号、IP段时可以判定为团伙攻击。 我们每天离线运行一次**关联分析**-按收货地址分组统计关联的买家账号数量。超过3个账号的地址标记为“异常”。--按IP前缀C段分组统计买家数量。超过10个买家来自同一C段且行为异常标记为可疑。--按支付账号脱敏后分组检测同一支付账号绑定多个买家号。 发现关联后自动将所有关联买家加入黑名单并追溯历史订单对未发货订单发起退款。 python# gang_detection.pydefdetect_gangs():gangs[]# 按地址聚合address_groupsdb.query(SELECT receiver_address, GROUP_CONCAT(buyer_id) FROM orders GROUP BY receiver_address HAVING COUNT(DISTINCT buyer_id) 3)foraddr,buyersinaddress_groups:forbuyerinbuyers.split(,):blacklist_service.add(buyer,f地址关联:{addr})gangs.append(addr)# 按IP段聚合ip_groupsdb.query(SELECT SUBSTRING_INDEX(client_ip, ., 3) as ip_segment, GROUP_CONCAT(DISTINCT buyer_id) FROM orders GROUP BY ip_segment HAVING COUNT(DISTINCT buyer_id) 5)forseg,buyersinip_groups:forbuyerinbuyers.split(,):blacklist_service.add(buyer,fIP段关联:{seg}.*)returngangs ---## 七、与订单系统的集成影刀RPA对于不支持API取消订单的平台影刀RPA脚本在订单同步环节进行拦截。 流程1.影刀脚本登录店铺后台拉取新订单2.2.调用黑名单服务查询买家ID3.3.如果是黑名单买家脚本自动点击“取消订单”按钮并填写原因“风控拦截”4.4.记录拦截日志 同时在订单备注中自动添加“黑名单买家”标签供客服后续参考。 python# 影刀脚本伪代码ordersrpa.get_new_orders()fororderinorders:buyer_idorder[buyer_id]ifblacklist_service.is_blacklisted(buyer_id):rpa.cancel_order(order[order_id],reason风控拦截)rpa.add_order_remark(order[order_id],黑名单买家已取消)send_alert(f黑名单买家{buyer_id}尝试下单已自动取消)---## 八、黑名单数据运营与申诉机制黑名单可能出现误判例如正常买家因纠纷被误伤。我们提供申诉入口-买家可以通过客服渠道申诉提供证据如商品完好照片--运营审核后可从黑名单中移除并记录移除原因--移除后该买家后续订单正常处理 同时黑名单设置**自动过期**大部分黑名单条目有效期为180天过期后自动移除除非有新的恶意行为。 运营可以在后台查看黑名单列表分析高频恶意买家画像如来自哪些地区、买什么品类商品用于针对性的风控策略。---## 九、真实踩坑与经验**坑1规则过于敏感误伤正常买家**初期将“退款率50%”直接拉黑结果有些买家只是退货频率高但每次都有正当理由如帮朋友代购。改进增加“纠纷率”和“差评率”联合判断且只有收到商家举证如空包、虚假物流才拉黑。**坑2黑名单跨店铺同步延迟**恶意买家先在A店作案加入黑名单后几分钟内又去B店下单由于同步延迟未被拦截。解决使用Redis集群和订阅发布黑名单变更立即通知所有节点。**坑3收货地址归一化困难**同一地址写法不同“XX路1号” vs “XX路1号101室”无法自动关联。我们使用地址清洗服务如调用地图API将地址标准化到行政区街道级别进行聚合。**坑4买家使用虚拟号码导致地址关联失效**有些恶意买家使用虚拟号段手机号无法关联。我们增加“支付账号”维度的关联脱敏后效果更好。---## 十、效果数据与收益系统运行半年后-累计识别并加入黑名单买家2300--拦截高风险订单4200单挽回损失约15万元--恶意退款率所有店铺平均从3.2%降到1.1%--运营人工审核黑名单时间从每周4小时降到30分钟 一个案例一个团伙使用50多个账号以“仅退款”模式在3个月内骗走200多件商品。系统通过收货地址和IP段关联一次性全部识别并拉黑后续所有订单被自动拦截。---## 十一、总结让恶意买家无处遁形多店铺协同防御的核心价值是把单个店铺的“碎片信息”聚合成全局的“行为画像”。恶意买家可能骗过一家店但骗不了所有店铺。 建议实施路径5.先实现单一店铺的黑名单手动添加6.2.收集订单和退款数据构建买家画像7.3.设计简单的风险规则如仅退款次数3自动加入黑名单8.4.扩展到跨店铺共享9.5.增加地址/IP关联分析发现团伙攻击 不需要100%准确宁可漏掉少数也不要误伤太多。随着数据积累规则会越来越精准。 记住**最好的防守是让攻击者知道在这里占不到便宜。**---作者林焱
影刀RPA店群自动化实战：多店铺买家黑名单共享与协同防御系统设计
影刀RPA店群自动化实战多店铺买家黑名单共享与协同防御系统设计店群最隐蔽的损失不是平台佣金不是广告费而是恶意买家。一个买家在你A店仅退款成功转头又去你B店下单同样的商品再次申请仅退款。由于店铺之间没有信息共享他屡试不爽。我们统计过一个职业“羊毛党”可以在半年内从同一个商家的不同店铺薅走价值上万元的商品。更别说那些给差评要挟退款的、寄回空包裹的、谎称未收到货的。单个店铺看这些买家占比不高但所有店铺加起来每月损失的数字相当可观。拼多多店群自动化上架方案我们早期每个店铺独立拉黑名单结果同一买家换个店铺继续作案。后来我们搭建了一套多店铺买家黑名单共享与协同防御系统所有店铺的黑名单实时同步新订单进来时自动拦截高风险买家并支持跨店铺的差评预警和退款限制。这篇文章不讲上架也不讲广告。专门聊聊店群场景下恶意买家协同防御的工程实践如何识别恶意行为如何跨店铺共享黑名单如何与订单系统联动以及如何通过数据分析发现批量攻击模式。适用场景多店铺运营、频繁遭遇恶意买家/职业打假/羊毛党的店群项目。技术栈影刀RPA Python Redis 规则引擎 订单拦截API。TEMU店群如何管理运营一、恶意买家的四种常见模式先总结我们遇到的真实案例。模式一高频仅退款买家下单后以“质量问题”申请仅退款上传模糊图片。平台倾向于保护买家往往同意退款。一个账号在多个店铺重复操作专门挑低价商品。模式二寄回空包裹/虚假单号申请退货退款填一个假物流单号或者寄空包。系统自动签收后触发退款商家货钱两空。模式三差评勒索下单后给差评然后联系客服要求退款或送优惠券否则不改评价。模式四批量注册账号用虚拟手机号注册多个账号在同一店铺或不同店铺大量下单然后批量退款测试商家的风控底线。单个店铺很难发现这些模式因为数据量不够。但把所有店铺的数据聚合起来就能看到清晰的恶意行为画像。二、整体架构系统分为五个模块。行为采集模块影刀RPA定时从各店铺后台抓取订单、退款、评价、客服消息等数据推送到Kafka。特征提取模块实时分析每条行为计算买家维度指标退款率、纠纷率、差评率、IP段、收货地址、下单频率等。风险评估模块规则引擎根据特征输出风险评分0-100超过阈值自动加入黑名单。黑名单共享模块黑名单存储在中心Redis所有店铺实时同步。订单创建时系统调用接口检查买家是否在黑名单中。拦截与处理模块高风险买家下单后系统通过订单API自动取消订单或标记为“需人工审核”并发送告警。下面重点讲解特征提取、风险评估和跨店铺同步。三、买家画像与风险特征提取从订单、退款、评价、客服对话中提取买家的行为特征。时间窗口为过去90天。# buyer_profiler.pyclassBuyerProfiler:def__init__(self,buyer_id):self.buyer_idbuyer_iddefload_features(self):# 从数据仓库查询该买家的所有店铺行为sql SELECT COUNT(DISTINCT order_id) as total_orders, SUM(CASE WHEN refund_status refunded THEN 1 ELSE 0 END) as refund_count, SUM(CASE WHEN refund_reason LIKE %假货% OR refund_reason LIKE %质量% THEN 1 ELSE 0 END) as quality_refund_count, AVG(order_amount) as avg_order_amount, COUNT(DISTINCT shop_id) as shops_visited, COUNT(DISTINCT DATE(order_time)) as active_days, SUM(CASE WHEN review_rating 2 THEN 1 ELSE 0 END) as bad_review_count FROM unified_events WHERE buyer_id %s AND order_time NOW() - INTERVAL 90 DAY returndb.query(sql,self.buyer_id) 计算衍生指标-退款率退款订单数/总订单数--仅退款率仅退款订单数/总退款数--差评率差评数/总评价数--平均客单价如果总是买低价商品可能是羊毛党--收货地址重复度同一地址关联多个买家账号 → 可疑--IP段聚集性同一IP段出现大量不同买家 → 可能为批量注册 这些指标存储在Redis的Hash结构中key为buyer_profile:{buyer_id}TTL为90天。---## 四、风险评估与黑名单规则规则引擎实时评估新订单的买家风险。规则示例-退款率60%且 总订单数5→ 高风险疑似恶意退款--仅退款占比80%且 客单价30元 → 中风险--差评率50%→ 高风险差评师--同一收货地址关联 ≥3个不同买家账号 → 高风险批量小号--30天内退款次数 ≥5→ 中风险--命中已知恶意买家名单从行业共享或手工添加→ 直接黑名单 规则使用JSON配置运营可调整阈值。 python# risk_scorer.pyclassRiskScorer:def__init__(self,rules):self.rulesrulesdefevaluate(self,profile):risk_score0risk_reasons[]forruleinself.rules:ifrule[condition](profile):risk_scorerule[score]risk_reasons.append(rule[reason])returnmin(risk_score,100),risk_reasons 风险等级-0-30正常--31-60关注订单标记“可疑”人工可放行--61-100高风险自动拒绝订单或强制人工审核 当买家的风险评分超过70时自动加入黑名单。---## 五、跨店铺黑名单共享与实时拦截黑名单存储在中心Redis集合blacklist:buyers中所有店铺的订单创建接口都会调用is_blacklisted(buyer_id)。 python# blacklist_service.pyclassBlacklistService:def__init__(self,redis_client):self.redisredis_clientdefadd(self,buyer_id,reason,expire_days180):self.redis.sadd(blacklist:buyers,buyer_id)self.redis.hset(fblacklist:reason:{buyer_id},reason,reason)self.redis.hset(fblacklist:reason:{buyer_id},expire,int(time.time()expire_days*86400))defis_blacklisted(self,buyer_id):ifnotself.redis.sismember(blacklist:buyers,buyer_id):returnFalse# 检查是否过期expireself.redis.hget(fblacklist:reason:{buyer_id},expire)ifexpireandint(expire)time.time():self.redis.srem(blacklist:buyers,buyer_id)returnFalsereturnTrue 在订单创建环节API或影刀脚本先调用is_blacklisted。如果命中则-调用平台订单取消API如果允许--或者标记订单为“风控拦截”不自动发货等待人工确认--发送告警给运营“黑名单买家XXX尝试下单已拦截” 对于已经支付但未发货的订单系统自动发起退款通过API避免损失。---## 六、跨店铺行为关联发现批量攻击单独的买家特征可能不明显但多个买家共享相同收货地址、手机号、IP段时可以判定为团伙攻击。 我们每天离线运行一次**关联分析**-按收货地址分组统计关联的买家账号数量。超过3个账号的地址标记为“异常”。--按IP前缀C段分组统计买家数量。超过10个买家来自同一C段且行为异常标记为可疑。--按支付账号脱敏后分组检测同一支付账号绑定多个买家号。 发现关联后自动将所有关联买家加入黑名单并追溯历史订单对未发货订单发起退款。 python# gang_detection.pydefdetect_gangs():gangs[]# 按地址聚合address_groupsdb.query(SELECT receiver_address, GROUP_CONCAT(buyer_id) FROM orders GROUP BY receiver_address HAVING COUNT(DISTINCT buyer_id) 3)foraddr,buyersinaddress_groups:forbuyerinbuyers.split(,):blacklist_service.add(buyer,f地址关联:{addr})gangs.append(addr)# 按IP段聚合ip_groupsdb.query(SELECT SUBSTRING_INDEX(client_ip, ., 3) as ip_segment, GROUP_CONCAT(DISTINCT buyer_id) FROM orders GROUP BY ip_segment HAVING COUNT(DISTINCT buyer_id) 5)forseg,buyersinip_groups:forbuyerinbuyers.split(,):blacklist_service.add(buyer,fIP段关联:{seg}.*)returngangs ---## 七、与订单系统的集成影刀RPA对于不支持API取消订单的平台影刀RPA脚本在订单同步环节进行拦截。 流程1.影刀脚本登录店铺后台拉取新订单2.2.调用黑名单服务查询买家ID3.3.如果是黑名单买家脚本自动点击“取消订单”按钮并填写原因“风控拦截”4.4.记录拦截日志 同时在订单备注中自动添加“黑名单买家”标签供客服后续参考。 python# 影刀脚本伪代码ordersrpa.get_new_orders()fororderinorders:buyer_idorder[buyer_id]ifblacklist_service.is_blacklisted(buyer_id):rpa.cancel_order(order[order_id],reason风控拦截)rpa.add_order_remark(order[order_id],黑名单买家已取消)send_alert(f黑名单买家{buyer_id}尝试下单已自动取消)---## 八、黑名单数据运营与申诉机制黑名单可能出现误判例如正常买家因纠纷被误伤。我们提供申诉入口-买家可以通过客服渠道申诉提供证据如商品完好照片--运营审核后可从黑名单中移除并记录移除原因--移除后该买家后续订单正常处理 同时黑名单设置**自动过期**大部分黑名单条目有效期为180天过期后自动移除除非有新的恶意行为。 运营可以在后台查看黑名单列表分析高频恶意买家画像如来自哪些地区、买什么品类商品用于针对性的风控策略。---## 九、真实踩坑与经验**坑1规则过于敏感误伤正常买家**初期将“退款率50%”直接拉黑结果有些买家只是退货频率高但每次都有正当理由如帮朋友代购。改进增加“纠纷率”和“差评率”联合判断且只有收到商家举证如空包、虚假物流才拉黑。**坑2黑名单跨店铺同步延迟**恶意买家先在A店作案加入黑名单后几分钟内又去B店下单由于同步延迟未被拦截。解决使用Redis集群和订阅发布黑名单变更立即通知所有节点。**坑3收货地址归一化困难**同一地址写法不同“XX路1号” vs “XX路1号101室”无法自动关联。我们使用地址清洗服务如调用地图API将地址标准化到行政区街道级别进行聚合。**坑4买家使用虚拟号码导致地址关联失效**有些恶意买家使用虚拟号段手机号无法关联。我们增加“支付账号”维度的关联脱敏后效果更好。---## 十、效果数据与收益系统运行半年后-累计识别并加入黑名单买家2300--拦截高风险订单4200单挽回损失约15万元--恶意退款率所有店铺平均从3.2%降到1.1%--运营人工审核黑名单时间从每周4小时降到30分钟 一个案例一个团伙使用50多个账号以“仅退款”模式在3个月内骗走200多件商品。系统通过收货地址和IP段关联一次性全部识别并拉黑后续所有订单被自动拦截。---## 十一、总结让恶意买家无处遁形多店铺协同防御的核心价值是把单个店铺的“碎片信息”聚合成全局的“行为画像”。恶意买家可能骗过一家店但骗不了所有店铺。 建议实施路径5.先实现单一店铺的黑名单手动添加6.2.收集订单和退款数据构建买家画像7.3.设计简单的风险规则如仅退款次数3自动加入黑名单8.4.扩展到跨店铺共享9.5.增加地址/IP关联分析发现团伙攻击 不需要100%准确宁可漏掉少数也不要误伤太多。随着数据积累规则会越来越精准。 记住**最好的防守是让攻击者知道在这里占不到便宜。**---作者林焱
