结论先放前面AI可以很快搭出扫码核销页面但“同一张票只能用一次”不能只靠按钮变灰。真正要验收的是状态更新、重复请求和弱网重试。我最近给一场200人工作坊做入场工具页面半小时就能说明白防重规则反而磨了两轮。检索关键词AI生成小程序、二维码核销、防重复提交、幂等设计、零代码小程序。我先定状态再谈二维码每张票我只留五个关键字段ticket_id、activity_id、status、used_at、operator_id。其中状态只有“未使用、已核销、已作废”三种。二维码里放票据编号和一次签名姓名、手机号等信息不直接塞进去免得截图外泄。扫码后的状态流也要写死查不到票据提示“票码无效”状态为已作废拒绝入场状态为已核销显示上次时间和操作员只有未使用状态才允许改成已核销。我把字段、三种状态和四条判断一起写进码上飞让平台按中文需求生成能操作的微信小程序。起步阶段不用编程同一类描述也可以用来做APP、H5或鸿蒙应用。比起只说“做个活动核销工具”把异常分支写清楚首版省下的返工更多。防重的核心是条件更新如果后端可调我会把核销理解成下面这句伪SQLUPDATE tickets SET status used, used_at NOW() WHERE ticket_id ? AND status unused;受影响行数为1说明本次成功为0再查询是已用、作废还是票码不存在。两台手机几乎同时扫同一张票时只有一台能改动状态。单纯“先查询、再修改”会留下时间缝两边都可能先读到未使用。前端还要带一个request_id。工作人员在地库信号差点完按钮没反应往往会再点两三次。后端看到相同请求编号应返回第一次的结果别重复写核销记录。按钮防抖只能减少误触挡不住网络重发。我实际验收了四种情况我没有只走正常流程而是拿两部手机做了四轮同票同时扫、核销后再扫、提交时切飞行模式、恢复网络后重试。页面还要明确展示活动名、票种和核销时间工作人员看见红色“已使用”就能停手。为了让现场人员少判断我把结果页分成三色绿色只给首次成功黄色表示网络待确认红色覆盖已用、作废和无效票。颜色之外仍保留文字太阳下屏幕偏色时也看得懂。每轮测试后我再按时间对照两部手机的操作专门找有没有重复成功记录。这里有两个取舍。其一二维码被截图转发后系统只能保证先到先用若活动要求本人入场还得加手机号后四位或证件核对。其二纯离线核销很难同时保证多设备防重我宁愿弱网时进入“待确认”也不冒险本地直接放行。AI生成核销小程序适合先做流程和界面原子更新、离线冲突仍要认真验。你做票务工具时更怕重复放人还是现场网络突然掉线