邀请奖励的设计：防刷、冻结与抵扣上限

邀请返利是最容易失控的营销功能，也是最容易产生资损的功能。三个约束定好了，它就是一个很安全的增长工具。

奖励要冻结再释放

按下单时间冻结 7 天，期间如果发生退款就先撤销，再释放。这堵住了「下单退款反复循环薅羊毛」的路子。

奖励金额要冻结一段时间再释放，避免刷单。

已经发生但后来被撤销的奖励，要能优先抵扣欠额——否则会出现「撤销了但优惠已经用掉」的资损。

按整单实付计算，不按下单额

用券后的实付金额才是计算基数。这让「先下单再全额退款」不再有价值。

所有金额和额度的计算都要有溢出检查。

正确做法是下单那一刻把套餐内容（价格、每日额度、并发数、有效期）快照进订单。

抵扣比例要有上限

单笔最多抵扣原价的固定比例（比如 20%），并要求只能使用已生效的奖励金。这限制了奖励对毛利的侵蚀。

抵扣比例要有上限（比如单笔最多抵扣原价的固定比例），否则会侵蚀毛利。

撤销后的欠额要优先抵扣

如果一笔奖励后来被撤销但已被抵扣，不能凭空产生负余额——后续奖励要优先抵扣欠额。这条是资损防护的最后一道。

实操：用查询凭证查用量，不必把完整 Key 交给前端。

奖励金在控制台里的展示也要和抵扣规则一致，否则用户会看不懂。

# 查询凭证是一段 10 位字符串，权限远低于完整 API Key。
curl "https://aiminis.info/api/v1/query-key/quota?key=QRY1234567"

# 返回里包含：今日剩余额度、每日额度、有效期、状态，
# 以及最近 100 条调用明细（默认每页 10 条）。
# 浏览器端还会把最近用过的查询凭证存在 Cookie 里，方便下次直接看。

几个容易踩的坑

• 价格用浮点数存储，累加后账目对不上。
• 套餐改了之后已创建的订单也跟着变，用户看到的和付的不一样。
• 续费时没保留今日已用量，等于凭空多给了一份额度。
• 奖励金被撤销但已经被抵扣，产生了资损。

小结

网关这层看不见，但它的每一次选择都在影响你的延迟、成本和成功率，值得花点时间打磨。

如果你也碰到上面这些问题，可以看看 https://aiminis.info/ —— 一个把协议适配、渠道调度、用量与额度都收敛在一起的 AI API 网关，OpenAI 与 Anthropic 两套协议都能直接接。