为什么要把三种福利排成一条时间线
限时促销、节日活动、首发福利看起来都是「活动」，但它们的额度形态完全不同：
- 首发福利：窗口最短（通常 24–72 小时），给的是「早鸟折扣 + 邀请码 + 公测排队名额」，价值在于锁定低价档位和优先调用权。
- 节日活动：窗口较长（通常 1–4 周），常见形式是签到、任务、抽奖、节日礼包，给的是可累积的调用额度或折扣券。
- 限时促销 / 闪购：窗口居中（通常 3–7 天），给的是充值返赠、套餐折扣、按量计费抵扣券。
三者叠加时，最容易犯的错是「节日活动慢慢做，结果错过首发窗口」。正确顺序是：首发日先锁价格与资格 → 节日活动期间补长期额度 → 闪购窗口把返赠换成推理额度。
操作步骤
第一步：建一张「三窗口」日历（提前 1 周）
在日历里为每个目标平台建三条记录，字段固定为：
- 活动类型（首发 / 节日 / 闪购）
- 开始与结束时间（换算成本地时区，注意很多平台按 UTC 或美西时间截止）
- 领取条件（是否需绑卡、是否需企业认证、是否限新用户）
- 额度形态（现金抵扣券 / 模型调用额度 / 折扣档位 / 邀请码）
- 有效期与是否可叠加
把「结束时间」统一提前 12 小时设提醒——多数平台的截止是按服务器时间，卡点提交经常失败。
第二步：首发日只做三件事
- 抢早鸟档位：新品发布页通常有「前 N 名 / 首周」的折扣价或赠送额度，先注册并完成邮箱验证，再决定是否绑卡。
- 领邀请码：发布公告、官方 Discord / Slack、开发者社区里常有首发邀请码，通常一码一次、限新账号，先领后试。
- 进公测排队：排队本身不产生额度，但公测期往往附带免费调用配额，且公测用户在新版本转正式时更容易拿到续期券。
首发日不要花时间做节日任务，那些窗口长得多。
第三步：节日活动期做「可累积」的任务
节日活动的额度通常按天或按周发放，重点是连续性而不是单次强度：
- 优先做「签到 / 每日调用」类任务，成本最低、额度可叠加。
- 抽奖类活动只投入已有账号，不为抽奖注册新号（多数平台会合并风控）。
- 节日礼包码注意兑换截止时间，通常比活动结束早几天。
第四步：闪购窗口按「计费项」换算
促销给的是「充值返赠」或「抵扣券」，不要直接当成 Token 数。先看该平台账单里的计费项：输入 Token、输出 Token、缓存命中、图片/音频单位、Embedding 调用。返赠通常只能抵扣其中一部分，且常有「不可用于某类模型」的限制。
换算方法：用你过去一个月的实际账单结构，估算返赠能覆盖多少比例，再决定充值档位。
第五步：把三种额度记进同一张表
字段：来源、额度形态、到期日、适用范围（哪些模型/接口）、是否可转让。到期前两周统一复盘，优先消耗「快到期 + 适用范围窄」的额度。
注意事项
- 多数首发福利限新账号或限首次订阅，老账号重复注册通常触发风控，得不偿失。
- 节日活动的额度常有使用期限（约 30–90 天），不是永久余额。
- 闪购返赠多不可提现、不可转让，且部分平台规定退款时返赠部分作废。
- 地区限制：部分节日活动仅对特定国家/地区账号开放，注册前确认服务条款。
- 企业认证：面向企业的促销通常要求公司邮箱或营业执照，个人号无法领取。
- 不要为了凑活动额度而超量充值，返赠比例再高也不如按需付费划算。
适用场景
- 团队需要在某季度集中做模型评测或批量推理，想压低单位成本。
- 个人开发者刚接触某平台，希望在低价窗口内锁定一档长期套餐。
- 已有多个平台账号，想把分散的活动额度整理成一张可管理的额度表。
工具与渠道
关注各模型厂商与云平台的官方博客、发布公告页、官方 Discord / Slack 的 announcements 频道，以及开发者邮件列表——首发邀请码和闪购信息基本只在这些渠道首发。聚合网关类平台的活动通常在自己的控制台公告里发布。