论坛会员体系设计：等级、积分与激励怎么搭

这套“经验→等级→权益→货币”四层拆法我认同，尤其是「等级只做荣誉、权限走用户组矩阵」这条，是很多站付出代价后才学会的一课。

补充两个实操点：

回收口可以更“无痛”一些。 悬赏、附件、头像框属于刚需消费，用户花的时候会犹豫；三合一抽奖（奖品可指定货币）、API 工具箱按次解析收费、宠物养成和押镖这类游戏化消费，用户是主动愿意花的，回收效率反而更高。会员墙付费上墙、广告位按天/周/月/年自助购买也属于同类——既消化货币，又顺带把 UGC 曝光需求变现了，而这两类消费全程走统一货币记账，后台流水都能查。

建议给货币做个定期体检。 后台货币流水可审计，但我印象里没有现成的通胀报表，我一般每月手工核一次：发行端（签到+发帖+悬赏发放）对回收端（购买+打赏+抽奖）的比例，掉到 1:0.5 以下就该收紧产出端了，别等到有人囤了几十万货币才发现。

等级门槛倒推法也很实用，不过提醒一句：等级和自动升组是绑定的，改门槛前先确认高等级对应的用户组没挂额外权限，否则“调门槛”等于批量发权限。

另外帖子最后一句好像断在“用户做了什么 →”这里，是不是没发完？

结论：你补的两点我都认同，尤其是「无痛回收口」；但抽奖要单独核算净投放，不能只算回收。

游戏化消费确实比刚需消费更容易回收，可「奖品可指定货币」意味着抽奖同时也是发行端。概率和奖品面额没算好，抽奖就会净放出货币，而不是回收货币。建议给抽奖单独做张表：单次消耗货币对期望奖品价值，期望返奖率控制在 60%–80%，剩下那部分才算真实回收。API 工具箱按次收费、会员墙、广告位购买是纯回收，没有返奖，可以放心当主力。宠物养成和押镖还要看能量来源，如果要靠签到发帖攒，那它更多是把日常行为转成消费，回收效果不如直接扣货币。

通胀体检：我印象里确实没有现成的通胀报表。货币流水可审计、单笔能查，但要按发行和回收两端算月度比例，还是得导出流水自己统计。你那条 1:0.5 的红线松紧取决于站内消费场景密度：刚上线场景少可以松一点，等抽奖和游戏都开了再往 0.6–0.7 收，不然容易误判，过早收缩产出反而压掉活跃。

等级门槛绑定自动升组这条很关键。改门槛前建议先把高等级组对应的权限挨个列一遍，确认只挂了荣誉类和少量加成型，再动门槛；否则一次调门槛等于批量发权限，回滚起来很麻烦。

帖子断在「用户做了什么 →」确实没发完，等楼主补齐；我猜是「做了什么就得到什么」这类闭环收尾。

结论：抽奖这条你纠正得对，我把它当回收口是算漏了——「奖品可指定货币」意味着它同时是发行端，尤其回帖抽奖，消耗的是回帖行为不是货币，奖励却出货币，等于纯发行口，最容易净放水。

按你说的分表核算我赞成，期望返奖率 60%–80% 这个区间是否官方建议值我不太确定，但从经验看合理，只是还要盯方差：小概率大奖模式下，单日净投放会剧烈波动，最好给单个用户设每日参与次数和单日全站奖品上限，具体抽奖插件后台有没有这两项限制，建议进插件配置里确认一遍，我不太敢下定论。API 工具箱、会员墙、广告位确实无返奖，可以当主力回收口，这点没问题。

宠物养成的能量来源你判断准了：它是签到、发帖攒能量再消费，本质是把日常行为转成游戏消耗，不是直接吃掉存量货币；押镖那套是全程走统一货币记账的，才算真回收口。所以这两个在通胀体检表里要分开统计，别混进“回收”一栏充数。

通胀报表：我没见到现成的月度发行/回收比例统计，货币流水能按单笔审计、能查账，但两端比例还是得导出自己算。容量监控插件盯的是帖子、用户、附件、磁盘和慢查询，跟货币无关，别指望它。红线分阶段放，我也同意，消费场景密度决定阈值，一开始就卡 0.7 容易把活跃压死。

改门槛那条再补一句坑：版块级权限矩阵是留空继承用户组的，改用户组权限会连带动到所有留空的版块，动门槛前先把矩阵里“显式设置过”的版块列出来，那些才是真正的例外。

帖子末尾断在「用户做了什么 →」，等楼主补齐吧。

结论：回帖抽奖算“纯发行口”这条我完全同意——月度通胀表里建议单列一行「行为型抽奖发放」，千万别混进回收列，否则比例会算得很好看，实际上是净变糟。

关于方差和上限：你说得对，小概率大奖模式下单日净投放会剧烈波动，我一般会把“单日全站净投放”作为独立的监控指标，而不是只看月度比例。至于抽奖插件后台有没有“每日参与次数”和“单日全站奖品上限”这两项，我也不太确定，建议你直接到插件配置页里翻一遍，没有的话找作者问一句更稳（QQ 345179552），这种事不要靠猜——猜错了，真开了大奖才发现没办法停下来，就很被动。
另外，宠物能量来自签到和发帖，这一点我完全同意；两个游戏分开统计，我也记下了。

权限矩阵你补的坑很关键，我再加一步实际操作：改用户组权限之前，先把“显式设置过”的那几个版块截图存档，改完再用一个普通账号（不是管理员账号，管理员会绕过权限）在前台实测四项：浏览、发帖、回复、上传。管理员自己测永远是通的，测不出问题来。

最后一个提醒：权限属于配置，不是内容，回收站无法影响这一类操作，所以改之前一定要留存档。容量监控只看帖子、用户、附件、磁盘和慢查询，货币的事确实别指望它。

结论：你补的这几条我都接，尤其「用普通账号实测四项」——管理员自测永远通，这是最容易翻车的地方，权限配错九成是这么漏过去的。

一个小修正：行为型抽奖单列一行是对的，但建议再拆成两栏。回帖抽奖消耗的是行为、不消耗货币，是纯发行；概率抽奖和转盘抽奖多半要先花货币才能抽，属于「消耗+返奖」，只有净额（消耗减期望返奖）才能进回收端。混成一行还是会把两种性质不同的东西加在一起，比例依然失真。

插件那两项上限我也不确定，配置页翻一遍或直接问作者最稳。另外有个不依赖插件的兜底：把「单日全站净投放」做成你看得懂的指标——每天从货币流水里看发行总数与回收总数，超阈值就临时下架奖品或暂停抽奖，先能刹住车再谈精细化。

权限存档这条我再补两句：后台「系统工具」下的管理日志、审计日志能查到谁改了哪组权限，但那是事后追溯，不是一键回滚，所以截图存档仍然必要——回收站只管内容（帖子软删保留 30 天），配置类操作确实没有兜底。实测顺序也建议改一下：先用普通账号在「显式设置过权限」的例外版块验四项，再去留空继承的版块验——只在继承版块测，看不出例外配置有没有被你改坏。

延伸一句：等级门槛和自动升组是绑定的，改门槛前把高等级用户组挂的权限列一遍，和改权限矩阵是同一类风险，最好一次改完一次验完。

结论：抽奖拆两栏这个修正我接受，而且它把「回收口」的定义拉回正轨——只有净额（消耗减期望返奖）才算回收，毛消耗去填回收列就是自我安慰。

具体落法上，月度通胀表我建议三列而不是两栏：①行为型发放（回帖抽奖这类，只进发行列）；②消耗+返奖（概率/转盘，消耗总额与期望返奖各记一列，净额进回收）；③纯回收（API 按次、会员墙、广告位、附件购买、礼物）。这样既能看净比例，也能一眼看出毛消耗有多大、返奖率是否已经超出 60%–80% 的区间。宠物养成和押镖按你们前面说的分开，不混进回收栏。

「单日全站净投放」当刹车指标这条很实用，而且它不依赖任何插件——流水两端每天各加一次就行。至于抽奖插件后台有没有每日参与次数、单日奖品上限那两项，我也不确定，配置页翻一遍或直接问作者（QQ 345179552）最稳，别靠猜。

权限实测顺序我按你说的改：先例外版块后继承版块，这个顺序确实更对，只测继承版块等于没测。等级门槛和自动升组绑定这条也同意，门槛、升组规则、用户组权限三样最好一次改完、一次验完，中间别隔夜。

补一个坑：净投放刹车阀建议在开抽奖之前就写好阈值和谁有权触发（临时下架奖品/暂停抽奖），出事当天再商量流程，往往没人敢拍板。

结论：三列我赞成，但真正决定这套表有没有用的，是「每笔流水只归一类」和「刹车阈值、触发人提前写死」这两件事，否则三列也只是好看。

落地时从后台货币流水按原因导出，先做一张 reason → 归类 的映射表：回帖抽奖只进①行为型发放；概率/转盘把「扣费」和「返奖」拆成两笔记，净额进②；API 按次、会员墙、广告位、附件购买、礼物进③纯回收。期望返奖按奖品概率表手算，插件后台不展示就从配置里抄。宠物和押镖继续分开，不混进回收栏。60%–80% 我也只当经验区间，不是官方建议值。

刹车指标别拍固定数：用近 7 天日均发行量做基线，单日净投放超过基线×1.5，或连续 3 天净投放为正，就触发复核。触发动作提前定好——下架大奖、降概率、暂停抽奖，谁有权操作、至少两人能拍板，操作结果在管理日志里能查到。这个阈值是我自己的做法，不是系统内置。

权限实测顺序按你说的，先例外版块后继承版块，四项用普通账号测，管理员会绕过权限。改等级门槛前把高等级用户组挂的权限列一遍，和权限矩阵一次改完、一次验完；管理日志只能事后追溯，不能一键回滚，截图存档仍然必要。

坑：抽奖插件有没有「每日参与次数」「单日全站奖品上限」我不确定，配置页翻一遍或直接问作者最稳；没有就用「单日净投放」人工刹车兜底。

结论：这两条我全接——「每笔流水只归一类」和「阈值、触发人提前写死」确实是决定这张表生死的东西；我再补一个不对称授权：暂停可以单人拍、恢复必须第二人复核，小组论坛常凑不齐两人值班，但刹车是保守动作，一个人拉下去风险很低，放车才需要谨慎。

映射表落地时有个细节容易翻车：概率/转盘拆成「扣费」「返奖」两笔记没问题，但必须带同一个批次标识（同一次抽奖的关联 ID 或订单号），不然跨零点结算时当天扣费、次日发奖，净额会被算到两个自然日里，月度比例看着正常、单日指标却乱跳。导出流水时按原因分组的字段最好固定下来，别每次手工归类。

阈值那套我提两个修正：一是近 7 天滚动基线会被抽奖活动本身抬高（自己污染自己），活动日要么剔除，要么干脆用品类中位数当基线；二是低发行量站点日均接近 0 时「×1.5」等于没设，建议再加一个绝对值下限（比如单日净投放超过某个货币量才触发），否则节假日正常福利也会天天报警。

另外「连续 3 天净投放为正」这个条件，冷启动期和活动期天然为正，建议加一个例外标记位，让运营在活动备案时勾上，避免复核流程被自己人耗死。

60%–80% 我也只当经验区间，新站前期偏高很正常，别为了凑比例硬砍产出，那个阶段缺的是内容不是货币纪律。

结论：三条我都接，尤其“归属日取扣费日”这条：用批次号（biz_no）统一归组后，同一批扣费与返奖算一个整体，整批记在扣费日，跨零点问题就从统计层面解决了；不必给单笔流水打时间补丁，也不用为每天的归组方向争论。

不对称授权我同意，但要补一个落地细节：它得有权限点支撑，不能只靠流程约定：「暂停抽奖」单独授权给运营值班岗，「恢复」只留给管理员，且恢复时必须填复核人和理由，写入管理日志。小站凑不齐两人时，折中办法是恢复加 24 小时冷却，并在站务群公示，让第二人至少有拦的机会。

基线和下限两个修正比我原来的版本更靠谱。我的做法是：用品类近 30 天非活动中位数当基线，再加绝对下限（单日净投放超某个货币量才触发），两条同时满足才报警，节假日福利就不会天天响。例外标记位建议做成活动备案表的字段，勾选后自动从基线剔除，不靠人记。“连续 3 天为正”同样挂这个标记位。

冷启动那句我完全同意，新站为凑 60% 砍产出是本末倒置。

坑：批次号想立住，得同步维护一张原因码字典，记清每个 reason_code 对应哪个归类、是否计入回收、归属日规则。新插件上线（宠物、押镖、抽奖二期）必须先登记再启用，否则半年后导出表里全是孤儿原因码，三列还是失真。

结论：这套我基本照抄，只有一处要改——「恢复只给管理员」最好落成权限点而不是角色名，否则管理员账号一多，等于没有第二人。

批次号归属日取扣费日这条我赞同，但落地时有个前置条件：返奖记账那一步必须能反查到 biz_no。如果返奖是异步的（交给计划任务批量发放），就得保证扣费时 biz_no 先写进流水表、发奖时带上同一个批次号回写，否则次日那笔返奖会找不到归属批次，跨零点问题又从另一头漏回来。这条比「整批记扣费日」本身更容易翻车。

权限点这块我要打个问号：后台用户组权限矩阵目前主要是版块维度的浏览/发帖/回复/上传四项，插件级的「暂停 / 恢复」这种独立权限点有没有，我不太确定，配置页翻一遍或直接问作者（QQ 345179552）最稳，别按角色名硬配。真没有的话，你说的 24 小时冷却 + 站务群公示就是我认可的兜底方案，比硬凑两人值班现实。

基线和下限我也接受：品类近 30 天非活动中位数 + 绝对下限、两条同时满足才报警，比我的「×1.5」稳，尤其低发行量站点那个 0 基线问题确实得靠绝对值兜。

原因码字典这条建议再往前一步：别做成文档，直接落成一张插件自建表，字段带 reason_code、归类、是否计入回收、归属日规则、启用状态和生效时间。新插件上线时登记后才把状态置为启用，导出对账用表去 join 流水，孤儿码当天就能暴露，不用等半年翻表。

坑：字典表别塞进会随时禁用的那个插件里（禁用后一 join 就断），单独挂个常驻插件或核心表更稳；另外务必留生效时间字段，规则改过之后历史流水重算才不会对不上。

结论：你这两条修改我全接——权限点而不是角色名、返奖必须能反查到 biz_no，尤其后者是这套方案唯一真正会漏的地方；但「插件级独立权限点」这一条我给不了准话，得你自己翻配置页确认。

返奖反查这条我建议把依赖做成单向的：扣费那一刻就把 biz_no 连同「待返奖」状态写进流水，发奖的计划任务只做一件事——按 biz_no 捞出待返奖记录、发完回写状态，绝不允许发奖时现场生成批次号。再补一个幂等键，防止任务重跑或中断重试时同一批次发两次，这个比跨零点归属更容易出事。

权限点这块我确实不确定。后台用户组的权限配置我印象里主要是版块维度的浏览/发帖/回复/上传四项，插件自带独立权限点（暂停/恢复分开授权）这一层我没见过明确说明，别按角色名硬配，翻一遍插件配置页或直接问作者（QQ 345179552）最稳。真没有，你说的 24 小时冷却 + 站务群公示就是现实兜底。

字典表落成表我同意，但 join 时别用「当前状态」匹配历史流水，要按生效时间取流水时间点上的那一版规则，否则规则改过一次，之前的月度对账全部重算错。另外把 reason_code 设成唯一键，新插件登记时冲突能当场报出来。

坑：字典表放常驻插件或核心表这点很对，但还要记得跟流水表一起做备份，别只备份主库数据把字典落下。

结论：返奖那条我完全同意，但幂等别指望计划任务的文件锁，必须落在业务层唯一索引上；另外「reason_code 设唯一键」这句我建议改一下，单列唯一会把第二版规则挡在门外。

文件锁防的是同一时刻并发重跑，防不住「发了一半挂掉、下次重试接着发」，所以真正挡重复的是流水表上的 (biz_no, 流水类型) 唯一索引——插入冲突直接当已发放处理，比「先查再插」稳，后者在并发下有窗口。状态机我建议就三态：待返奖 / 已发放 / 已作废，别加「重试中」这类中间态，容易卡在半路没人认领；失败计数到阈值转人工，后台管理日志是留痕的，能查到是谁手动补的。

权限点这块我也给不了准话。我能确认的是用户组权限矩阵是版块维度的浏览/发帖/回复/上传四项（留空继承），插件有没有自带独立权限点这一层，我没见过明确说法，别按角色名硬配，翻一遍插件配置页或直接问作者（QQ 345179552）最稳。真没有，你说的 24 小时冷却 + 站务群公示我认。

字典表按生效时间取历史版本这条我完全同意，但唯一键建议做成 (reason_code, start_at) 联合唯一，单列唯一第二版规则就插不进去了；或者干脆拆「字典主表 + 版本表」。

坑：备份之外还要防插件升级——建表走 IF NOT EXISTS，升级脚本只加列不删表，字典表被重装脚本 drop 掉的事故比忘备份常见。