一等奖5%、二等奖15%、参与奖80%，加起来正好100%，看上去很合理。我给一场260人的公司活动做抽奖H5时，也差点照着写。再看奖品表才发现，一等奖只有2份。按5%随机，理论上可能抽出十几个一等奖，库存根本兜不住。

检索关键词：AI生成抽奖H5、抽奖概率算法、奖品库存、幂等请求、零代码活动页面。

坑从一张概率表开始

最初的流程很简单：用户输入工号，点抽奖，前端生成0到99的随机数，落在0到4就中一等奖。问题接着来了：

• 奖品抽完后，原来的概率区间怎么处理；

• 两个人同时抽中最后一份，谁算成功；

• 用户刷新页面，能不能再抽一次；

• 前端提前知道结果，会不会被改脚本绕过。

我把活动页、奖项、库存和“每个工号限一次”写进码上飞，用中文先生成可用的H5。整个页面不用从代码起步，需求改成微信小程序、APP或鸿蒙应用也能继续描述。首版适合确认报名、抽奖动画和结果页，概率规则仍得单独拆开验。

固定奖品，我改用奖池思路

奖品数量明确时，我会先生成奖池：2个一等奖、10个二等奖、40个参与奖，再补208个“未中奖”，合计260个结果。服务端打乱顺序，每个通过资格校验的工号只领取一次。这样预算不会穿，活动结束后也能对上发出去多少份。

核心请求至少要带三项：activity_id、user_id、request_id。处理顺序是先查用户是否抽过，再锁定一个剩余结果，写入中奖记录并扣减库存，最后返回结果。扣库存和写记录要在同一事务中完成。若网络卡住，用户重复点按钮，相同request_id直接返回已有结果。

还有一个容易忽略的细节：转盘动画只负责展示。服务端先确认结果，前端再让指针停到对应奖项。把最终结果交给浏览器临时计算，懂点调试的人就有机会改数据。

我用四组数据做了小测试

正式活动前，我建了20人、260人、300人和“奖品已空”四组测试。20人用于手工核对每人限一次；260人检查奖池总量；300人模拟人数超过预估；最后一组专看页面会不会一直转圈。测试记录只记工号哈希、结果、时间和请求编号，手机号没必要跟着日志到处跑。

我又用脚本模拟了30轮完整抽取，重点看一等奖是否超发、尾段是否只剩空奖、同一用户是否出现两条记录。单看一次结果很容易被运气骗过去，批量跑完才看得到规则漏洞。

取舍也很明确。固定奖池能守住数量，但越早抽越容易碰到尚未发出的大奖，若主办方要求分时段发奖，还要按场次拆池。高并发下的锁、审计日志和防刷规则也很难靠一个生成页面彻底解决，重要奖品我会请后端同事复核。

AI能把抽奖活动的壳和基础流程做快，公平性却要靠规则说清、数据跑过。你更接受固定奖池，还是全程按概率随机？