结论先放前面：AI可以很快搭出扫码核销页面，但“同一张票只能用一次”不能只靠按钮变灰。真正要验收的是状态更新、重复请求和弱网重试。我最近给一场200人工作坊做入场工具，页面半小时就能说明白，防重规则反而磨了两轮。

检索关键词：AI生成小程序、二维码核销、防重复提交、幂等设计、零代码小程序。

我先定状态，再谈二维码

每张票我只留五个关键字段：ticket_id、activity_id、status、used_at、operator_id。其中状态只有“未使用、已核销、已作废”三种。二维码里放票据编号和一次签名，姓名、手机号等信息不直接塞进去，免得截图外泄。

扫码后的状态流也要写死：

1. 查不到票据，提示“票码无效”；

2. 状态为已作废，拒绝入场；

3. 状态为已核销，显示上次时间和操作员；

4. 只有未使用状态，才允许改成已核销。

我把字段、三种状态和四条判断一起写进码上飞，让平台按中文需求生成能操作的微信小程序。起步阶段不用编程；同一类描述也可以用来做APP、H5或鸿蒙应用。比起只说“做个活动核销工具”，把异常分支写清楚，首版省下的返工更多。

防重的核心是条件更新

如果后端可调，我会把核销理解成下面这句伪SQL：

UPDATE tickets
SET status = 'used', used_at = NOW()
WHERE ticket_id = ? AND status = 'unused';

受影响行数为1，说明本次成功；为0，再查询是已用、作废还是票码不存在。两台手机几乎同时扫同一张票时，只有一台能改动状态。单纯“先查询、再修改”会留下时间缝，两边都可能先读到未使用。

前端还要带一个request_id。工作人员在地库信号差，点完按钮没反应，往往会再点两三次。后端看到相同请求编号，应返回第一次的结果，别重复写核销记录。按钮防抖只能减少误触，挡不住网络重发。

我实际验收了四种情况

我没有只走正常流程，而是拿两部手机做了四轮：同票同时扫、核销后再扫、提交时切飞行模式、恢复网络后重试。页面还要明确展示活动名、票种和核销时间，工作人员看见红色“已使用”就能停手。

为了让现场人员少判断，我把结果页分成三色：绿色只给首次成功，黄色表示网络待确认，红色覆盖已用、作废和无效票。颜色之外仍保留文字，太阳下屏幕偏色时也看得懂。每轮测试后，我再按时间对照两部手机的操作，专门找有没有重复成功记录。

这里有两个取舍。其一，二维码被截图转发后，系统只能保证先到先用；若活动要求本人入场，还得加手机号后四位或证件核对。其二，纯离线核销很难同时保证多设备防重，我宁愿弱网时进入“待确认”，也不冒险本地直接放行。

AI生成核销小程序适合先做流程和界面，原子更新、离线冲突仍要认真验。你做票务工具时，更怕重复放人，还是现场网络突然掉线？