电竞服务平台打手评价打分模块

电竞陪玩、代练类服务平台里，打手评价分数是用户选择大神、派单算法筛选打手的核心指标。很多平台只做简单的五星打分，缺少评价时效控制、防刷分机制、评分加权计算、评价申诉和差评过滤逻辑，很容易出现刷好评、恶意差评、分数虚高，最终导致派单匹配不准、用户参考价值低。本文围绕评价流程、分数计算、风控、数据联动，分享一套稳定落地的评价打分模块设计方案。

后端采用SpringBoot + MyBatis-Plus开发，Redis缓存打手综合评分，MQ异步处理评价事件、更新统计指标，MySQL存储评价主记录、评价标签、打分日志。模块和订单、派单、售后模块联动，只有满足条件的订单才允许发起评价，评价结果会同步影响打手在派单算法中的履约分。

业务基础规则：订单状态为已完成、且在评价有效期内，用户才可以评价；一单只能评价一次，不支持重复打分；如果订单发起售后申诉，售后未结案前锁定评价入口，防止双方在纠纷阶段恶意打分。同时支持双向评价，用户可以评价打手，打手也可以对用户进行评价。

评价维度不只是总分，拆分为服务态度、技术水平、准时度三个分项打分，配套预设标签选择，比如沟通顺畅、效率高、发挥不稳、超时等，同时支持文字备注。评价标签方便后续做统计分析，也供其他用户快速参考。

下面是评价实体和评价类型枚举Java代码示例：

@Data@TableName("t_player_evaluate")publicclassPlayerEvaluate{privateLongid;privateLongorderId;privateLonguserId;privateLongplayerId;// 分项打分privateIntegertechScore;privateIntegerattitudeScore;privateIntegeronTimeScore;// 综合得分privateBigDecimaltotalScore;privateStringtagCodes;privateStringcontent;// 0正常评价 1申诉待复核 2判定恶意差评privateIntegerevaluateStatus;privateLocalDateTimecreateTime;}publicenumEvaluateSideEnum{USER_TO_PLAYER(1,"用户评价打手"),PLAYER_TO_USER(2,"打手评价用户");privateIntegercode;privateStringdesc;EvaluateSideEnum(Integercode,Stringdesc){this.code=code;this.desc=desc;}// getter省略}

综合分数采用加权计算，后台可配置权重，示例：技术分0.5、服务态度0.3、准时度0.2。同时综合评分不是简单累加，平台支持滑动窗口计算，只统计最近N条有效评价，而不是全部历史评价，保证分数可以反映打手近期真实服务水平，很久之前的历史评价慢慢衰减，不会一直影响分数。

分数计算工具示例：

@ServicepublicclassEvaluateScoreService{// 权重配置，可存入配置表动态修改privatestaticfinalBigDecimalWEIGHT_TECH=newBigDecimal("0.5");privatestaticfinalBigDecimalWEIGHT_ATTITUDE=newBigDecimal("0.3");privatestaticfinalBigDecimalWEIGHT_ONTIME=newBigDecimal("0.2");publicBigDecimalcalcTotalScore(Integertech,Integerattitude,IntegeronTime){BigDecimaltechScore=newBigDecimal(tech);BigDecimalattScore=newBigDecimal(attitude);BigDecimalotScore=newBigDecimal(onTime);BigDecimaltotal=techScore.multiply(WEIGHT_TECH).add(attScore.multiply(WEIGHT_ATTITUDE)).add(otScore.multiply(WEIGHT_ONTIME));returntotal.setScale(1,RoundingMode.HALF_UP);}}

评价提交成功后，发送MQ消息异步更新打手的统计指标，包括好评数量、差评数量、综合平均分。更新完成后刷新Redis中的缓存分数，派单算法读取缓存里的履约分，不需要每次派单都统计数据库评价记录。

差评申诉是必不可少的功能。打手收到差评之后，可以在限定时间内发起评价申诉，上传订单履约凭证，由平台审核员复核。核实属于恶意差评的，标记评价记录为无效，不计入分数统计，并且重新计算打手平均分；正常差评则保留，作为服务质量参考。

防刷分风控机制：系统监控同一用户短时间连续给同一个打手高分、多个账号集中给同一打手好评、订单成交立刻满分评价等异常行为，触发风控标记。风控标记的评价需要人工复核，复核前不计入分数。同时，退款订单、取消订单自动关闭评价入口。

权限控制：评价提交后，普通用户不能修改或删除评价；只有审核人员在申诉复核流程中，才可以标记评价是否有效，所有复核操作留痕，记录操作人和修改原因。

落地开发需要注意几个细节：评价快照和订单绑定，订单归档后评价记录同步归档；分数计算统一使用BigDecimal，避免精度丢失；缓存增加失效策略，当评价被申诉复核、状态变更时主动刷新缓存。另外展示给前端的分数做区间限制，最低0分，满分5分，避免极端异常值展示。

这套评价模块的核心设计思路是多维度分项打分、滑动窗口动态评分、差评可申诉复核、风控拦截刷分。评价数据不只是展示给C端用户，还要输出给派单算法、后台数据看板，作为打手服务质量量化指标。后续可以继续扩展评价AI内容审核、好评自动发放优惠券等增值能力。