【框架设计】好友推荐：等级差与活跃度评分

实战应用：用在哪里

好友推荐解决新玩家没有社交对象的冷启动问题：按等级差、活跃时段、共同好友三个因子打分，每天推 5 个候选人。推荐质量直接影响组队率与留存，推得不准玩家第三次就永久关掉推荐面板，评分因子要持续用数据校准。

推荐评分

function Friend.score(candidate, plr)
    local lvDiff = math.abs(candidate.level - plr.level)
    local s = 100 - math.min(lvDiff * 2, 60)
    if candidate.lastLoginAt and os.time() - candidate.lastLoginAt < 86400 then
        s = s + 20
    end
    local common = Friend.commonCount(candidate.id, plr.id)
    s = s + math.min(common * 5, 20)
    return s
end

等级差每级扣 2 分，最多扣 60，昨日活跃加 20 分，共同好友每个加 5 分封顶 20 分。纯函数计算，候选池来自同服务器在线与 7 日活跃玩家，万级候选全量打分在 10 毫秒内完成，凌晨预计算白天直接读。

推荐与去重

function Friend.recommend(plr)
    local cands = {}
    for _, c in ipairs(Friend.candidatePool(plr)) do
        if not Friend.isFriend(plr.id, c.id) and not plr.rejected[c.id] then
            cands[#cands + 1] = { id = c.id, s = Friend.score(c, plr) }
        end
    end
    table.sort(cands, function(a, b) return a.s > b.s end)
    return { table.unpack(cands, 1, 5) }
end

已拒绝的候选人进黑名单不再出现，拒绝三次同一身份的玩家标记为推荐冷感用户，停止推送。玩家点接受直接发起好友申请，对方同意后互加，接受率按天统计反哺评分权重。推荐卡片用 GUI:Card 控件渲染头像与在线状态，附一句推荐理由让接受更有依据。

验证与监控

推荐接受率按因子分桶分析，等级差因子的权重每月校准一次。

踩坑记录

评分因子的第一次校准数据来自一个月的接受率日志，等级差因子的实际斜率比拍脑袋定的平缓得多，按数据重标后接受率提升了四成。拒绝黑名单的容量做过上限控制，拒绝记录只保留最近 200 条，冷感用户的标记独立存储不受容量影响。推荐时段的选择也有讲究，晚八点推送的接受率是下午三点的一倍，社交意愿跟着在线心情走，同样的候选人在不同的时间被推荐出去是两个结果。推荐系统的冷启动数据来自新服的观察，开服首日的社交关系几乎为零，候选池临时放开到全服活跃玩家，等级差因子的权重在首周减半。接受与拒绝的交互做了轻量化，右滑接受左滑拒绝的手势版在移动端测试时接受率提升明显。推荐结果的多样性约束避免榜单被单一行会包揽，同会候选人最多占三席，玩家要的是更大的世界而不是自己圈子的复制。推荐系统的冷启动数据来自新服的观察，开服首日的社交关系几乎为零，候选池临时放开到全服活跃玩家，等级差因子的权重在首周减半。接受与拒绝的交互做了轻量化，右滑接受左滑拒绝的手势版在移动端测试时接受率提升明显。推荐结果的多样性约束避免榜单被单一行会包揽，同会候选人最多占三席，玩家要的是更大的世界而不是自己圈子的复制。

本文由 996 技术组基于 996 引擎官方知识库与浮生梦老师课程体系整理。团队长期从事传奇类引擎 Lua 后端逻辑、客户端界面与商业版本交付，内容以官方知识库与真实项目为出处，按版本持续修订。