让用户上瘾但别被刷爆：vibe 项目的游戏化实战

先把边界划清楚，免得你读完发现货不对板：本文不讲拉新奖励（那是《推荐计划指南》的地盘），不讲流失用户召回（见《留存与召回指南》），更不讲计费额度的账本（见《Credits 积分账本指南》）。最后这条最容易混淆，所以多说一句：Credits 那篇是"花钱的账"——用户充钱、扣费、对账，记账方向是向外花；本文是"赚分的账"——用户做行为、你发积分，记账方向是向内赚。两套账本长得像，方向相反，混用一张表是灾难的开始。

本文只回答一个问题：如何用积分、徽章、排行榜、连击这四件套，让用户主动回来，并且让刷分的人占不到便宜。目标读者是做 toC vibe 项目（社区、学习、工具、内容类）、想提升留存和活跃的独立开发者，一人团队，没有增长团队，没有数据分析师——所以本文所有方案都按"一个人能写完、一个人能运维"来设计。

先说结论，省你时间：游戏化不是给产品"加个好玩的东西"，而是给已经存在的核心行为加一套反馈放大器。如果你产品的核心行为本身用户就不想做，游戏化救不了它，只会让你多维护四套系统。这句话是全文的总开关，后面每一节都会回到它。

一、四件套与适用边界：先想清楚你在放大什么

积分、徽章、排行榜、连击，四个东西解决的是四个不同的行为问题，乱配等于乱吃药。

• 积分（Points）解决的是"行为可被计量"的问题。用户做了 A，你给 10 分；做了 B，你给 50 分。积分的本质是把离散的行为翻译成统一的货币，让用户直观感受到"我在积累"。它适合行为高频、单次价值小的场景：社区发帖、每日学习打卡、工具的高频小操作。
• 徽章（Badges）解决的是"身份需要被证明"的问题。积分是数量，徽章是里程碑。"连续打卡 30 天"这枚徽章，价值不在那 30 天的积分总和，而在用户愿意把它晒出来。徽章适合有身份认同的社区和学习类产品：开源社区的贡献者徽章、学习产品的课程完成徽章。
• 排行榜（Leaderboards）解决的是"人需要参照系"的问题。心理学上叫社会比较：用户不知道自己 500 分算多算少，但看到自己排第 37 名、前面那个只差 20 分，行为动机立刻就有了。排行榜适合有竞争氛围、用户之间可比的产品：学习打卡榜、创作榜、游戏化工具。
• 连击（Streaks）解决的是"习惯需要被保护"的问题。连击的魔力在于"损失厌恶"：断掉 47 天的连击比得到 47 天的奖励更让人心疼。它适合依赖每日习惯的产品：背单词、冥想、健身记录、写作。

四件套不是必须全上。一人团队的铁律是：先上一个，跑顺了再加第二个。选型看这张决策矩阵：

行为目标	首选件套	实现成本（一人团队）	作弊风险	备注
提高核心行为频次	积分	低（一张 ledger 表）	高（刷行为=刷分）	必须配反作弊，见第六节
建立身份认同、促进分享	徽章	中（规则引擎）	中（条件可被针对性刷）	隐藏款徽章防剧透式刷榜
制造竞争、拉高头部活跃	排行榜	中（Redis Sorted Set）	高（头部是刷分重灾区）	分段榜比全局榜更抗刷
培养每日习惯、保 D1/D7 留存	连击	低（一张 streak 表）	中（改时区、脚本签到）	时区坑见第五节

选型之前，必须先定义北极星行为：如果你的产品只能让用户多做一件事，那件事是什么？学习产品可能是"完成一节课"，社区可能是"发一条有回复的帖子"，工具可能是"完成一次导出/分享"。游戏化放大的必须是这个行为，不是"登录""浏览"这种边角料。给"登录"发积分是最常见的自我安慰——登录量涨了，北极星行为纹丝不动，还顺手教会用户每天来领低保。

然后是适用边界。以下三类产品，游戏化大概率是毒药，不是解药：

• 低频严肃工具。报税软件、合同签署、医疗记录——用户一年用三次，每次都希望快点结束。你给他搞个"报税达人"徽章，他只会觉得你不尊重他的时间。严肃工具的留存靠"下次还好用"，不靠"下次还好玩"。
• 行为本身带有负面情绪的产品。债务管理、戒烟、待办催收——用户打开你的产品时心情已经不好了，排行榜只会让他更不好。连击在这里尤其危险：断签一天等于公开处刑一次。
• 核心行为还不成立的产品。上线三个月、日活两位数，先别想游戏化。游戏化是放大器，0 乘以任何数都是 0。这时候你的工作是找到 Product-Market Fit，不是给没人用的功能发徽章。

一个自检问题，答不上来就别往下读了："如果没有任何积分徽章，用户做这件事本身快乐吗？"如果答案是"不快乐"，游戏化只是在给止痛药续费。

整体链路长这样，后面几节就是把这张图里的每个框拆开讲透：

二、积分账本设计：这是"赚分的账"，不是"花钱的账"

先跟《Credits 积分账本指南》做个了断。那篇讲的是用户花钱买额度、你扣费：账本的核心约束是钱不能多扣、不能少扣，对账是生命线。本文的积分账本约束完全不同：分可以多发（大不了通胀），但绝不能发重、发错、发丢。一个是财务系统，一个是激励系统；一个错一分钱要人命，一个错一次发放用户只会觉得"今天运气好"。所以两套账物理隔离，各记各的，这是铁律。

2.1 表结构：只增不改

积分账本只有一条军规：ledger 表只 INSERT，不 UPDATE、不 DELETE。任何"修改积分"的操作，都是一条新的正负分录。原因很现实：一年后你要查"某用户某天为什么多了 500 分"，靠一条被 UPDATE 改掉的余额字段，你什么都查不出来；靠 append-only 的流水，你能精确还原。

CREATE TABLE points_ledger (
  id            BIGSERIAL PRIMARY KEY,
  user_id       BIGINT NOT NULL,
  -- 幂等键：同一行为事件只记一次账，见 2.2
  idempotency_key VARCHAR(128) NOT NULL UNIQUE,
  -- 正数=发放，负数=消耗/过期/扣减
  delta         INTEGER NOT NULL CHECK (delta != 0),
  balance_after INTEGER NOT NULL,
  -- 行为来源：comment_created / lesson_completed / checkin ...
  reason        VARCHAR(64) NOT NULL,
  ref_id        VARCHAR(128),
  -- 赛季归属：赛季清零时只清当季，历史可查
  season_id     INTEGER NOT NULL DEFAULT 0,
  expires_at    TIMESTAMPTZ,
  created_at    TIMESTAMPTZ NOT NULL DEFAULT now()
);
CREATE INDEX idx_points_ledger_user ON points_ledger (user_id, id DESC);

注意 balance_after 这个冗余字段：它是写时计算的快照，让"查余额"变成一次主键索引扫描，而不是全表 SUM。对一人团队来说，这是用一点点写放大换巨大的读简单。余额的权威来源永远是 SUM(delta)，balance_after 只是缓存——两者对不上时，以 SUM 为准，写个每周对账脚本就行（十分钟工作量）。

2.2 幂等发放：同一行为只发一次分

积分系统最常见的生产事故不是"分发错了"，而是"分发了两次"。用户点赞，请求重试了一次，后端又发了一次积分——用户不会投诉你多发了分，但你的经济系统从此有了窟窿。解法是发放时带幂等键：

-- 幂等键的构成：用户 + 行为类型 + 行为对象 + 日期（按需）
-- 例如：user:42:lesson_completed:lesson_101 / user:42:daily_checkin:2026-10-19
INSERT INTO points_ledger (user_id, idempotency_key, delta, balance_after, reason, ref_id)
VALUES (42, 'user:42:lesson_completed:lesson_101',
        50, (SELECT COALESCE(SUM(delta),0) FROM points_ledger WHERE user_id=42) + 50,
        'lesson_completed', 'lesson_101')
ON CONFLICT (idempotency_key) DO NOTHING;

三条硬规则：第一，幂等键必须在行为事件产生的地方就确定好，传进发放函数，而不是在发放函数里现编——现编的键两次调用长得不一样，等于没做幂等。第二，ON CONFLICT DO NOTHING 之后要检查 affected rows，0 行表示重复事件，直接返回成功（对调用方来说"已经发过了"和"刚发完"没有区别）。第三，幂等键要有业务语义，方便人肉排查：看到 user:42:daily_checkin:2026-10-19 就知道这条分录是哪来的。

一个容易踩的坑：把"每日上限"和"幂等"混为一谈。"每天发帖最多得 50 分"是业务规则，"同一篇帖子只加一次分"是幂等。前者用计数器实现，后者用幂等键实现。两个都要，但它们是两回事。

2.3 积分过期与通胀：贬值还是清零？

积分只发不收，长期看就是通胀：老用户手里几十万分，新用户永远追不上，积分体系名存实亡。两种解法：

	定期贬值（如每季度余额 ×0.8）	赛季清零（赛季结束清零重开）
用户体感	温和，"我的分缩水了"	剧烈但可预期，"新赛季开始了"
实现成本	中（批量 UPDATE 余额快照 + 记负分录）	低（season_id 一切，榜单天然分段）
适合场景	积分可兑换实物/权益，贬值=调价	排行榜驱动的产品，赛季=天然话题
风险	用户觉得被"偷钱"，需提前公示	赛季末活跃断崖，需结算奖励对冲
一人团队推荐度	★★★	★★★★★

我的判断很明确：一人团队无脑选赛季清零。理由有三：实现简单（season_id 字段天然支持，新赛季写新 season_id 就行）；和排行榜是绝配（每赛季一张新榜单，老用户没有历史包袱，新用户随时能进场）；清零本身就是运营事件（"S3 赛季开启"比"您的积分已贬值 20%"好听一百倍）。贬值方案唯一的适用场景是积分能兑换真实权益——那时候积分已经半只脚踏进"花钱的账"，请回去读《Credits 积分账本指南》。

赛季时长建议：4–8 周。太短（2 周）用户刚有感觉就清零，太长（半年）通胀先把你干掉。赛季结束前一周发"赛季结算预告"，给用户一个把分花掉/冲榜的理由——这是用规则设计行为，不是事后补救。

2.4 本节检查点

• ledger 表是 append-only 吗？有没有任何 UPDATE 余额的代码路径？
• 每次发放都有业务语义明确的 idempotency_key 吗？重复事件返回的是成功而不是报错吗？
• 余额读取走 balance_after 快照，SUM 对账脚本写了吗？
• 赛季制还是贬值制，定了吗？赛季时长和清零公告写进运营日历了吗？

三、徽章/成就系统：事件 → 条件 → 授予

如果说积分是"工资"，徽章就是"奖杯"。工资按月发、大家都有；奖杯只发给做到特定事情的人，而且要摆在看得见的地方。徽章系统的技术本质是一个规则引擎：监听行为事件，按配置好的条件判定，满足就授予。听起来简单，坑全在"规则怎么配"和"并发下别重发"。

3.1 最小规则引擎：JSON 配置 vs 硬编码

一人团队最常见的错误是两个极端：要么把所有徽章条件硬编码在业务代码里（加一枚徽章要改代码、重新部署），要么一上来就做可视化规则编辑器（三个月做不完）。中间路线是 JSON 规则配置：规则写成配置文件，引擎只负责解析和执行。

// badges.json：加徽章只改配置，不改代码
[
  {
    "id": "first_post",
    "name": "初露锋芒",
    "tier": "common",
    "trigger": { "event": "post_created" },
    "condition": { "count": 1, "window": "all_time" }
  },
  {
    "id": "streak_30",
    "name": "三十而立",
    "tier": "rare",
    "trigger": { "event": "checkin" },
    "condition": { "streak_days": 30 }
  },
  {
    "id": "night_owl",
    "name": "夜猫子",
    "tier": "hidden",
    "trigger": { "event": "post_created" },
    "condition": { "hour_range": [0, 5], "count": 10, "window": "30d" },
    "hint": "据说有人在深夜出没……"
  }
]

引擎的执行逻辑只有三步，伪代码：

def on_event(event):
    for rule in load_rules():                      # 规则很少，全量加载放内存
        if rule.trigger.event != event.type: continue
        if evaluate(rule.condition, event.user_id):
            grant_badge(event.user_id, rule.id)    # 幂等授予，见 3.3

def evaluate(cond, user_id):
    # count / streak_days / hour_range 等条件类型按需扩展
    # 所有计数都走只读查询，不在这里写库
    ...

取舍很清楚：

	硬编码	JSON 规则配置（推荐）	可视化规则编辑器
新增一枚徽章的成本	改代码 + 部署	改配置文件 + 热加载	点点鼠标
条件表达能力	无限（图灵完备）	受限于已实现的 condition 类型	受限于产品经理的想象力
实现成本	0（顺手写）	1–2 天	数周起步
适用阶段	徽章 < 5 枚的验证期	徽章 5–50 枚的成长期	你有增长团队那天

实操建议：从硬编码起步，超过 5 枚徽章当天重构成 JSON 配置。5 枚是个经验阈值——以下硬编码的可读性尚可，以上散落在业务代码里的 if 条件会变成无人敢动的地雷。JSON 配置的 condition 类型一开始只实现三种就够：count（累计次数）、streak_days（连击天数）、hour_range（时段行为）。别为"未来可能需要的条件"提前做抽象，那是给自己加班。

3.2 徽章分级与展示面

徽章分三级，这是经过无数游戏验证的配比：

• 普通（common）：人人可得，教学性质。"完成新手任务""发第一条动态"。作用是让用户在注册 10 分钟内就拿到第一枚徽章——第一枚徽章的获得时间，决定了用户是否理解你的徽章系统。如果用户三天都没解锁任何东西，他会默认这个系统与他无关。
• 稀有（rare）：需要持续投入。"连续打卡 30 天""获得 100 个赞"。这是徽章体系的主力，数量控制在普通徽章的 1/3 左右。稀有徽章必须配进度条："再打卡 7 天即可解锁"比"???"有效得多——看得见的进度是行为燃料。
• 隐藏款（hidden）：不告诉用户存在，触发时给惊喜。"凌晨 3 点发帖 10 次"解锁"夜猫子"。隐藏款有两个作用：防刷（用户不知道条件就没法针对性刷，见第六节），以及制造社交传播（"卧槽我解锁了个隐藏徽章"是最好的 UGC 素材）。但隐藏款不能多，占总数的 10% 以内，多了用户会觉得规则不透明。

展示面设计只有一条原则：徽章墙是用户的"客厅"，不是"仓库"。用户主页 prominently 展示最近解锁的 3–5 枚，全部徽章收进二级页面。每枚徽章要有获得时间（"2026-09-12 解锁"），稀有徽章要有全站解锁人数（"全站 128 人拥有"）——稀缺性需要数字来背书。千万别学某些产品把徽章藏在三级菜单里：用户为之努力的东西，你却不好意思展示，行为动机直接腰斩。

3.3 并发授予的幂等：user_id + badge_id 唯一键

用户一次发帖可能同时满足三枚徽章的条件，三个 worker 并发执行授予——没有幂等保护，用户会收到三条"恭喜解锁"的通知，或者更糟，同一枚徽章被记了两次。解法和积分账本异曲同工：

CREATE TABLE user_badges (
  user_id    BIGINT NOT NULL,
  badge_id   VARCHAR(64) NOT NULL,
  granted_at TIMESTAMPTZ NOT NULL DEFAULT now(),
  -- 复合唯一键：同一用户同一徽章只授予一次
  PRIMARY KEY (user_id, badge_id)
);

-- 授予时
INSERT INTO user_badges (user_id, badge_id) VALUES (42, 'streak_30')
ON CONFLICT DO NOTHING;
-- affected rows = 1 → 新解锁，发通知；= 0 → 已拥有，静默跳过

注意这个设计隐含了一个产品决策：徽章是终身制还是赛季制？上面的表结构是终身制——解锁了就永远拥有。如果你的徽章和赛季强绑定（"S3 赛季王者"），那需要 (user_id, badge_id, season_id) 三元唯一键。我的建议：普通/稀有徽章终身制（身份资产，越老越值钱），赛季限定徽章单独成体系（赛季通行证那套玩法）。混在一起会让用户困惑"我这徽章下赛季还有吗"。

3.4 本节检查点

• 新用户 10 分钟内能解锁第一枚徽章吗？路径实测过吗？
• 徽章规则是配置化的吗？加一枚徽章需要改代码吗？
• 授予路径有 (user_id, badge_id) 幂等保护吗？并发测试过吗？
• 稀有徽章有进度条吗？隐藏款占比超过 10% 了吗？

四、排行榜实战：Redis Sorted Set 是标准答案

排行榜的技术选型没什么悬念：Redis Sorted Set。这不是"推荐"，是行业标准答案——成员按分数排序，插入和取 Top N 都是 O(log N)，百万级用户毫秒响应。用关系数据库 ORDER BY score DESC LIMIT 100 也不是不行，但数据量上十万后，每次榜单查询都是一次全表排序，你的慢查询日志会先替你罢工。

4.1 核心命令与最小实现

你只需要四个命令（均为 Redis 官方文档标准命令，无版本强依赖）：

# 用户得分变更：ZADD key score member（分数存在则更新）
ZADD leaderboard:season:3 1250 "user:42"

# 取前 100 名（分数从高到低）：ZREVRANGE key start stop
ZREVRANGE leaderboard:season:3 0 99 WITHSCORES

# 查某用户的排名（从 0 开始计数）和分数
ZREVRANK leaderboard:season:3 "user:42"
ZSCORE leaderboard:season:3 "user:42"

# 按分数区间取（游标分页用，见 4.3）
ZRANGEBYSCORE leaderboard:season:3 (1250 -inf LIMIT 0 20

应用层的更新策略：行为事件发生后，同步更新 Redis 榜单，异步落库。为什么？榜单是"可丢、可重建"的派生数据——即使 Redis 挂了，你也能从 points_ledger 的 SUM 重建。把榜单更新做成同步，是为了用户"做完行为立刻看到排名变化"的即时反馈；落库做成异步（消息队列或后台任务），是因为 ledger 是权威账本，不能丢，但可以等几秒。顺序反过来（同步落库、异步更新榜单）也行，但用户体验差一档：一人团队做 toC 产品，用户体验的即时性值得这点架构复杂度。

分数相同怎么办？Sorted Set 里 score 相同的成员按 member 的字典序排——这会导致"同分不同命"的诡异排名。标准解法是把时间戳编码进分数：score = 行为分 × 10^10 + (9999999999 - unix_time)，先达到者排前面。或者更简单：业务上允许并列，展示"并列第 3"——对大多数 vibe 项目，并列展示比时间戳 hack 更易懂。

4.2 三档榜单：全局 / 好友 / 分段

只做一张全局榜，是排行榜最常见的偷懒。问题很直观：新用户进来一看，第一名 50 万分，自己 30 分，直接关掉页面。心理学上这叫"习得性无助"在榜单上的翻版。解法是三档榜单：

• 全局榜：全站排名。给头部用户荣誉感，给运营提供"大神"素材。但它只服务 Top 1% 的用户，剩下 99% 是观众。
• 好友榜 / 关注榜：只排用户关注的人。邓巴数字决定了这里的竞争是真实的——你真的在乎那十几个人的排名。实现上是一个 key per user：leaderboard:friends:{user_id}，关注关系变更时重建。数据量小，随便折腾。
• 分段榜（青铜→王者）：按分数把用户切成段位，每人在自己的段位里排名。这是留住腰部和尾部用户的关键：青铜组第一名的快乐，不比王者组第一名少。段位阈值按赛季动态调整（取上赛季分数的 P20/P40/P60/P80 做切分），避免"青铜组第一比白银组垫底还高"的笑话。

三档榜的默认展示顺序应该是：分段榜 → 好友榜 → 全局榜。让用户第一眼看到的是"我有机会赢"的榜，而不是"我永远赢不了"的榜。这个细节决定了排行榜是留存工具还是劝退工具。

4.3 分页必须用游标，不用 offset

榜单分页有个致命坑：ZREVRANGE key 100 120 这种 offset 分页，在榜单实时变动时会跳页、重页。用户在看第 5 页时，有人冲上了榜首，第 5 页的内容整体下移一位——用户翻到第 6 页，会发现第 5 页最后一条又出现了一次。体验灾难。

正确姿势是游标分页：记住上一页最后一条的分数，用 ZRANGEBYSCORE 按分数区间取下一页：

# 上一页最后一条：score=1250, member=user:42
# 下一页：分数 < 1250 的前 20 条（注意开区间，排除已展示的 user:42）
ZRANGEBYSCORE leaderboard:season:3 (1250 -inf LIMIT 0 20
# 边界情况：与 user:42 同分 1250 但排在他后面的成员会被漏掉
# 解法：游标带上 (score, member) 二元组，应用层过滤 score=1250 且 member 字典序 > user:42 的

诚实地说，二元组游标的实现要多写二十行代码。但榜单是高频访问页面，跳页重页的用户投诉会让你花更多时间。这是"现在多写二十行，还是以后多回五十封客服邮件"的选择题。

4.4 赛季制：结算 cron + 奖励 + 清零仪式感

赛季制的排行榜才有"赛季"的样子。赛季结束时要做三件事，按顺序：

1. 结算（cron）：赛季结束时刻，cron 任务把最终榜单快照写进关系数据库（season_results 表：season_id, user_id, rank, score）。快照是历史荣誉的凭证，也是发奖的依据。从这一刻起，旧赛季的 Redis key 设置 TTL（如 30 天）后自然过期——不要 DEL 掉，留给用户回味和截图。
2. 发奖：按名次发赛季奖励（徽章、头衔、积分加成）。发奖走幂等发放（idempotency_key 带 season_id），发奖失败可重试——这是钱/荣誉，丢了用户会记仇。
3. 清零仪式感：新赛季开启不是静默的。要做三件事：全站公告（"S4 赛季开启，所有人回到同一起跑线"）、上赛季荣誉展示（用户主页挂" S3 钻石段位"徽章，终身制）、新赛季首周双倍积分（给所有人一个"我要冲"的理由）。

赛季时长和积分赛季保持一致（4–8 周，见 2.3），两套赛季各过各的等于运营灾难。

4.5 本节检查点

• 榜单读走 Redis Sorted Set，而不是数据库 ORDER BY 吗？
• 三档榜单都有吗？默认展示的是分段榜吗？
• 分页用的是 (score, member) 游标，而不是 offset 吗？
• 赛季结算 cron 写了吗？旧赛季 key 是 TTL 自然过期而不是 DEL 吗？发奖幂等吗？

五、连击/签到：时区是大坑，补签是门生意

连击（streak）是四件套里实现最简单、坑最隐蔽的一个。一张表、两个字段就能跑，但时区问题能让你的客服邮箱爆炸。

5.1 时区大坑：必须按用户时区算"天"

场景：用户在洛杉矶，10 月 18 日 23:30 打卡，10 月 19 日 00:30 又打卡——按他的本地时间，这是连续两天的打卡，连击应该 +1。但如果你的服务器按 UTC 算"天"，00:30 PDT = 07:30 UTC，和前一次（06:30 UTC）是同一天，连击不断但也不涨——用户看到"我明明打了两天卡，连击数没动"，信任直接清零。更糟的是反过来的吞连击：用户按本地时间每天都打卡了，但某次打卡落在 UTC 的同一天里，系统判定"今天已打卡"，第二天按本地时间打卡时，UTC 已经跨了两天，连击断了。

铁律："天"的边界按用户时区算，绝不按服务器时区、绝不按 UTC 一刀切。实现：

CREATE TABLE streaks (
  user_id       BIGINT PRIMARY KEY,
  timezone      VARCHAR(64) NOT NULL DEFAULT 'UTC',  -- IANA 时区，用户可改
  current_streak INTEGER NOT NULL DEFAULT 0,
  longest_streak INTEGER NOT NULL DEFAULT 0,
  -- 按用户时区算的"最后打卡日期"，存日期不存时间戳
  last_checkin_date DATE NOT NULL
);

-- 伪代码：打卡判定（server_time 必须用服务端时间，见 5.3）
def checkin(user_id):
    s = get_streak(user_id)
    today = server_now().astimezone(s.timezone).date()
    if s.last_checkin_date == today:
        return {"streak": s.current_streak, "already": True}
    elif s.last_checkin_date == today - timedelta(days=1):
        s.current_streak += 1
    else:
        # 断签：先看有没有补签卡，见 5.2
        s.current_streak = 1
    s.last_checkin_date = today
    s.longest_streak = max(s.longest_streak, s.current_streak)
    save(s)

三个细节：第一，timezone 字段允许用户修改——留学生从北京搬到纽约，时区不变的话他的"天"永远是错的。第二，夏令时切换那周，astimezone 会自动处理，别自己写 +8 这种偏移量——写死偏移量的代码会在每年三月和十一月各爆炸一次。第三，last_checkin_date 存的是"用户时区的日期"，这个日期只有在该用户时区下有意义，跨用户比较毫无意义——报表查询时注意。

5.2 断签挽回的经济学：补签卡

连击断了，用户有两种反应：一种是"算了，从头再来"（你的理想用户），另一种是"47 天白干了，卸载"（你的大多数用户）。补签卡就是给第二种用户一个台阶：花一点点代价（看个广告、付 1 元、消耗 100 积分），把昨天的断签补上，连击续上。

补签卡的定价是门经济学，核心公式：补签价格 < 用户重建连击的心理成本，但 > 0。定价为 0 等于没有惩罚，连击贬值；定价太高用户直接放弃。参考锚点：

补签方式	建议定价	适用阶段	注意
消耗积分	约为用户 3–5 天的积分收入	有积分体系的产品	别定成 1 天收入，否则等于没惩罚
看激励视频	1 次 / 天	有广告变现的产品	补签顺手贡献 eCPM，一举两得
直接付费	1–3 元 / 次，每月限 2 次	付费意愿强的工具/学习产品	限次！不限次等于卖连击，连击体系崩盘
好友助力	邀请 1 位好友帮忙补签	社交属性强的产品	本质是拉新，计入推荐计划口径，别重复计算

关键规则只有一条：补签只能补昨天，不能补上周。允许补 7 天前的签，等于告诉用户"连击无所谓，反正能补"——连击的损失厌恶一旦被补签稀释，它就从习惯引擎退化成付费道具了。产品上，断签超过 1 天，补签入口直接消失，文案从"补签续上"变成"新的开始"——给用户台阶，但只给一级。

5.3 防"改系统时区刷连击"：服务端时间戳为准

连击作弊最廉价的一招：把手机系统时间调到明天，打开 App 打卡，再调回来——一天之内刷出 30 天连击。防御只有一句话：打卡时间以服务端收到请求的时间为准，客户端传的时间只做展示参考。

具体做两层：第一层，签到接口完全忽略客户端时间参数，用 now() 落库——这是底线，没有这层，其他都是空谈。第二层，检测到同一用户 24 小时内签到次数异常（如 >3 次），标记可疑（不封号，只标记，进第六节的人工复核队列）。为什么不断然封号？因为误伤成本太高：用户跨时区飞行、手机时间同步 glitch，都可能触发。连击作弊的收益只是"数字好看"，不值得用封号这种重武器——标记 + 限制补签资格就够了。

5.4 连击奖励曲线：递增，但封顶

连击的奖励（积分/徽章进度）应该随天数递增——第 30 天的奖励必须比第 3 天丰厚，否则用户没有"坚持下去更赚"的感觉。但必须封顶：建议在 30 天或 60 天封顶，之后保持恒定。不封顶的后果是老用户的单日收益越滚越大，新用户永远追不上——和积分通胀是同一个病，见 2.3。

一个经过验证的曲线（每日签到积分）：1–7 天每天 10 分，8–30 天每天 20 分，31 天起每天 30 分封顶。简单、好记、客服能解释清楚。"客服能解释清楚"是检验奖励规则的黄金标准——如果你的规则需要三段话才能讲明白，用户是不会去算的，他只会觉得"这分怎么这么少"。

5.5 本节检查点

• "天"按用户 IANA 时区算吗？代码里还有没有写死的 +8？
• 签到接口用服务端时间吗？客户端时间参数被忽略了吗？
• 补签只能补昨天吗？补签限次了吗？
• 连击奖励封顶了吗？规则一句话能讲清吗？

六、反作弊：刷分的人永远比你想象的勤奋

先摆正心态：只要积分有价值，就一定有人刷。这不是"会不会"的问题，是"什么时候"的问题。一人团队做反作弊的目标不是"零作弊"（那是大厂安全团队的 KPI），而是"让作弊的成本高于作弊的收益"。刷 100 分要花 2 小时写脚本，而 100 分只值 1 毛钱——这仗你就赢了。

6.1 刷分三板斧

你未来一年遇到的作弊，99% 是这三种：

• 多账号（Sybil）：注册 50 个小号，互相点赞、互相评论，积分倒进大号。这是社区/内容类产品的头号敌人。特征：同一设备/同一 IP 下多个账号、账号行为高度同步（同一分钟内批量操作）、小号只给大号点赞。
• 脚本刷行为：用自动化脚本模拟"发帖—点赞—签到"一条龙。特征：行为间隔呈现机器规律（如精确每 60 秒一次）、7×24 小时无休（人类要睡觉）、User-Agent 或行为指纹异常。
• 改包重放：抓包拿到"完成课程"的 API 请求，重放 100 次。特征：同一幂等键之外的重复请求模式（注意：幂等键防的是"意外重试"，防不住"故意换键重放"——攻击者每次换个 ref_id，你的幂等键就失效了）。

诚实标注：以上三类是行业公开讨论的常见作弊模式，具体到你的产品，作弊手法取决于你的积分规则——你的规则就是攻击者的说明书。"发帖得 10 分"这条规则写出来的那一刻，就有人在想怎么批量发帖了。规则设计时就要做"攻击者视角"的推演，这是本节最重要的习惯。

6.2 三层防线

按成本从低到高部署，一人团队按顺序做：

第一层：速率限制（今天就能上）。每个积分行为设"人均合理上限"：发帖每天最多 10 次计分、点赞每天最多 50 次计分、签到每天 1 次。超限的行为照常允许（别拦用户正常使用），但不再计分。实现就是 Redis 计数器 + TTL，连代码都不用多写几行。这一层能挡掉 80% 的脚本小白——脚本不停跑，但分一分都拿不到，攻击者自己就走了。

-- 发帖计分的速率限制：每天前 10 次计分
INCR points_limit:post:user:42
EXPIRE points_limit:post:user:42 86400
-- 返回值 > 10 → 本次行为不计分（行为本身照常成功）

第二层：行为基线（上线后第二周上）。记录每个用户行为的统计基线：日均发帖数、活跃时段分布、行为间隔。当某个用户的行为偏离他自己的基线 3 个标准差以上，标记可疑。注意是"偏离他自己的基线"，不是全站统一阈值——大 V 一天发 20 条帖子是正常的，新号一天发 20 条就是刷。一人团队不用搞机器学习，简单的 z-score 规则 + 每周人工看一眼标记列表就够了。

第三层：设备指纹（作弊出现后再上）。多账号作弊的本质是"一个人操作 N 个号"，设备指纹（同一设备 ID / 同一 IP 段 / 同一浏览器指纹登录多个账号）是抓现行的最直接证据。但这一层有隐私合规成本（指纹采集要写进隐私政策），而且误伤真实用户（全家共用一台 iPad 的场景）。所以它是"作弊出现后再上"的 reactive 措施，不是提前部署的标配。

三层的关系：速率限制是城墙（挡住大多数），行为基线是巡逻队（发现异常），设备指纹是锦衣卫（精准抓人）。别一上来就建锦衣卫——你的产品可能还没值得被刷的价值。

6.3 一人团队每周 10 分钟 SOP

自动化防线之外，留一个人工复核队列。每周花 10 分钟做这四件事：

1. 打开"可疑用户"列表（行为基线标记 + 速率限制频繁触发的用户），按可疑度排序。
2. 看 Top 5：点进用户主页，30 秒判断——是真大 V 还是刷子，人眼比规则准。
3. 确认作弊：先扣分（记负分录，reason 写 anti_cheat），再封禁计分资格 7 天，最后才是封号。三级处罚，逐级升级。直接封号是核武器，误伤一个真用户，损失远大于放过十个刷子。
4. 把这次作弊的手法记下来，更新速率限制阈值或行为基线规则——反作弊是军备竞赛，你的规则库应该是活的。

处罚公示要不要做？要，但只公示"行为"，不公示"姓名"："本周清理刷分账号 12 个，追回积分 3400"——既震慑，又不引发"公开处刑"的争议。具体的用户 ID 只在申诉通道里处理。

6.4 与《支付欺诈指南》的分工

本文讲的是游戏作弊（刷积分、刷榜、刷徽章），《vibe-project-fraud-prevention-guide》讲的是支付欺诈（盗刷、黑卡、退款欺诈）。分工线划在"钱"上：作弊者图的是账面数字和荣誉，欺诈者图的是真金白银。一旦你的积分可以兑换现金/实物，两类问题会合流——那一刻起，游戏作弊就是支付欺诈，反作弊预算要按欺诈标准来配。判断题：你的积分能换钱吗？能，就去读那篇；不能，留在本节就够了。

6.5 本节检查点

• 每个积分行为都有"每日计分上限"吗？超限是静默不计分而不是报错吗？
• 新规则上线前，做过"攻击者视角"推演吗？（如果我是刷子，这条规则怎么刷？）
• 可疑用户复核队列有吗？每周 10 分钟的 SOP 写进日历了吗？
• 处罚是三级逐级升级吗？有申诉通道吗？

文案公式（直接抄）：成就名称 + 具体行为 + 稀缺性背书。好例子："解锁——连续打卡 30 天，全站仅 3% 用户达成"。坏例子："恭喜您获得成就！"——获得什么成就？为什么是我？一概不知，等于没说。稀缺性数字（3%、128 人）是关键：它把"我做到了"翻译成"我比大多数人强"，而后者才是分享的动力。

7.2 榜单页性能：缓存 60 秒 + 前 100 预热

榜单页是游戏化体系里访问量最高的页面，也是最容易被打爆的。两个手段：

• 榜单结果缓存 60 秒。用户看到的榜单允许 60 秒延迟——没有人会因为榜单晚了 40 秒而投诉，但你的 Redis 会因为每秒上千次 ZREVRANGE 而先走一步。实现：榜单查询结果按 key 缓存（如 cache:leaderboard:season:3:global），TTL 60 秒。60 秒是个经验值：短于 30 秒缓存命中率上不去，长于 5 分钟用户会觉得"我的分涨了排名没动"。
• 前 100 名预热。榜单 90% 的流量集中在第一页。cron 每分钟（或每次赛季关键节点）主动查询 Top 100 写入缓存，而不是等用户请求来了再查。这叫"把计算从请求路径上挪开"，一人团队能做的最便宜的性能优化。

个人排名查询（"我是第几名"）不要走榜单缓存：ZREVRANK 是 O(log N)，直接查，实时、便宜。但注意长尾用户的排名展示策略：第 108,642 名这个数字，展示出来是羞辱不是激励。对 1000 名开外的用户，展示分段榜排名（"青铜组第 12 名"）或好友榜排名，而不是全局排名——展示策略本身就是游戏化设计的一部分。

7.3 成就海报与社交分享

徽章解锁、赛季结算、连击里程碑——这些时刻用户有分享欲，你要把分享做成"一键"，而不是"截屏"。标准做法是成就海报：服务端生成一张图（用户昵称 + 成就名称 + 稀缺性数字 + 产品 logo + 二维码），用户一点分享，直接调起系统分享。海报生成可以用服务端 canvas（如 node-canvas）或预制模板 + 文字叠加，一人团队选后者：做 5–10 张模板图，动态文字按坐标打上去，十分钟量级的工作量。

海报上的二维码/链接，跳转目标要是专属落地页（"lee 解锁了，全站 3% 达成——你也来试试"），而不是首页。落地页的转化率和首页差一个数量级。分享链接的防刷、参数设计见《分享链接指南》，这里只强调：游戏化负责制造"值得分享的时刻"，分享链路负责把时刻变成新用户——两篇指南在"海报落地页"这个点上交汇。

7.4 本节检查点

• 每种触达事件都分好"即时 / 批量"了吗？"会想截图吗"是判断标准吗？
• 榜单页有 60 秒缓存 + Top 100 预热吗？个人排名走实时查询吗？
• 长尾用户看到的是分段排名而不是"第 108642 名"吗？
• 成就海报一键分享做了吗？二维码落到专属落地页而不是首页吗？

八、效果衡量与上线清单：以及，下线预案

8.1 A/B 测试：对照组是"无游戏化"

游戏化上线必须做 A/B 测试，而且对照组的设计有个常见错误：对照组必须是"完全没有游戏化"，而不是"另一种游戏化"。"A 组看旧版积分规则、B 组看新版积分规则"测的是规则优劣，不是游戏化本身的价值。正确的实验设计：实验组看到完整的积分+徽章+榜单，对照组什么都看不到（积分照常在后台计算，只是不展示——这样未来全量上线时，对照组用户的历史数据还在）。

分流单位用 user_id 哈希，别用"新用户 / 老用户"这种业务划分——新老用户本身行为差异巨大，会污染实验结果。实验周期至少 2 周，覆盖至少一个完整的"周行为周期"（工作日和周末的用户行为模式完全不同，跑 3 天就下结论等于算命）。

8.2 核心指标：三个就够

一人团队看三个指标，多了看不过来，少了会跑偏：

• D1 / D7 留存：游戏化的终极目标。实验组 D7 留存比对照组高 2–5 个百分点，就是成功。别指望翻倍——留存是复利游戏，5 个点的提升一年后是天文数字。
• 北极星行为频次：回到第一节：游戏化放大的必须是核心行为。所以直接看"人均每周完成课程数 / 发帖数"有没有涨。积分领取量涨了但北极星行为没涨——说明用户在刷边角料，规则要改。
• 人均积分消耗比（如果积分可消耗）：发放总量 vs 消耗总量。只发不花=通胀前兆；发 100 花 90 是健康；发 100 花 5，说明你的积分商城没人要，先别加新玩法，先修商城。

虚荣指标黑名单：注册转化率（游戏化不负责拉新）、页面 PV（榜单页 PV 高可能是用户在反复刷新看排名，不代表健康）、徽章总数（发 100 枚人人有的徽章，数字好看，毫无意义）。

8.3 上线前 12 项检查清单

1. 北极星行为定义了，且游戏化奖励只与它及它的前置行为挂钩。
2. points_ledger 是 append-only，没有 UPDATE 余额的代码路径。
3. 每次发放都有 idempotency_key，重复事件返回成功而非报错。
4. 余额读取走 balance_after 快照，SUM 对账脚本已写并加入 cron。
5. 赛季制已定：赛季时长、清零公告、赛季结算 cron 三件套齐了。
6. 徽章规则配置化，加徽章不改代码；(user_id, badge_id) 幂等已测并发。
7. 榜单走 Redis Sorted Set，三档榜单齐了，默认展示分段榜。
8. 榜单分页用 (score, member) 游标，无 offset 分页。
9. 连击按用户时区算天，签到用服务端时间，补签只补昨天且限次。
10. 每个积分行为有每日计分上限；可疑用户复核队列 + 每周 10 分钟 SOP 已排进日历。
11. 触达事件分好即时/批量；榜单页 60 秒缓存 + Top 100 预热。
12. 下线预案已写（见 8.4），feature flag 已埋，关掉游戏化核心流程不受影响——这一条上线前实测一遍。

8.4 下线预案：游戏化是插件，不是地基

最后一条，也是最重要的架构观：游戏化永远是插件，不是地基。什么意思？如果有一天你发现游戏化带来了刷分、客服压力、运维负担，收益覆盖不了成本，你要能在一小时内把它关掉，而产品的核心流程（发帖、学习、购买）毫发无损。

做到这一点需要三个设计：

• Feature flag 总开关。GAMIFICATION_ENABLED=false 时，所有积分发放、徽章授予、榜单展示、连击计算全部跳过——注意是"跳过"，不是"删除"。行为事件本身（发帖、打卡）不受任何影响。开关的粒度至少到四件套级别（能单独关排行榜、单独关连击），最好到单条规则级别。
• 展示层与核心流程解耦。前端渲染帖子详情页时，徽章墙、积分余额是独立组件，数据走独立接口。关掉游戏化，这些组件不渲染，页面其他部分正常。反模式：在发帖接口里同步调用"发帖得 10 分"，游戏化服务一挂，发帖也挂——这是把插件焊死在了地基上。
• 数据归档不删除。下线时，ledger、徽章、榜单快照全部归档保留（改个表名、设为只读都行），不删。原因有二：用户未来问"我当年的徽章呢"，你有据可查；万一半年后你想重启游戏化，历史数据是冷启动的燃料。删数据的下线不是下线，是自杀。

写在最后：游戏化最难的部分从来不是技术。Redis 命令、SQL 表结构、cron 任务，这些一个周末就能写完。难的是克制——克制住给每个边角行为发分的冲动，克制住一次上四件套的冲动，克制住看到刷子就想写完美防御系统的冲动。一人团队的游戏化，MVP 是"积分 + 连击"，跑三个月，数据说了算，再决定加不加徽章和榜单。让用户上瘾靠的是"我的努力被看见"，不是"我的屏幕上有多少数字"。