为什么是「单账号归集」而不是多开或转让
2026 年主流 AI 平台的邀请返利机制基本定型：被邀请人完成注册/首充/首次调用后，邀请人获得额度奖励，且奖励通常按「累计成功邀请人数」分档递增。多数平台的服务条款明确禁止同一主体批量注册小号刷奖励，也普遍禁止额度转让或折现。因此真正可持续的做法只有一条：一个主账号，把阶梯爬满，把奖励沉淀在同一额度池里。
这条路线适合个人开发者和小团队：不需要额外身份，不需要企业资质，只需要持续的、真实的邀请来源。
操作步骤
第一步：筛出「有阶梯」的平台，而不是「有奖励」的平台
打开候选平台的邀请页（通常在控制台侧栏的 Referral / Invite / Affiliate 入口），只看三件事：
- 奖励是否分档（例如 3 人、10 人、25 人、50 人各有一档加成）；
- 奖励是「一次性额度」还是「被邀请人消费的百分比返佣」——前者适合做底仓，后者适合做长期流水；
- 阶梯是否有有效期（多数平台按自然月或季度清零进度，务必在页面上确认）。
只保留同时满足「有阶梯 + 进度可查 + 条款允许公开分享邀请链接」的平台，通常 3～5 家足够，不要贪多。
第二步：给每个平台建一张「阶梯进度卡」
用一个表格（Notion、飞书表格或纯文本都行）记录：平台名、当前档位、距下一档还差几人、本周期清零日期、已到账额度、到账延迟天数。每周更新一次。这张表是整个方案的核心，因为阶梯奖励的最大浪费不是「邀请不到人」，而是「差一个人就到下一档但周期结束了」。
第三步：把邀请链接放到「本来就会有人看」的地方
有效邀请来源通常只有三类，按转化率排序：
- 真实使用场景的产出物：你写的教程、开源项目的 README、脚本里的配置注释。读者因为用了你的东西而注册，转化最稳。
- 垂直社区的回答：在技术问答、开发者论坛里回答具体问题时，附带一句「我用的是 X，邀请链接在这里」。注意多数社区禁止纯广告，只在不违反版规时使用。
- 同事与协作者：小团队内部互相邀请，一人主账号、其他人作为被邀请方，双向都有奖励时收益最高。
第四步：奖励到账后立刻「归集」到主账号
若平台支持把奖励额度合并到同一 API Key 的计费池，直接在控制台确认；若不支持，则在主账号下建立独立的「奖励专用 Key」，并在代码里把它设为第一优先级，用完再切到付费 Key。这样做的目的是让奖励额度先被消耗，避免过期浪费。
第五步：月度对账，把「一次性」变成「可预期」
每月末做三件事：
- 统计本月实际到账额度与上一月对比，算出「月度平均补给量」；
- 把即将清零的阶梯进度标红，决定是否在本周期内补足；
- 若某平台连续两个月零到账，评估是否把它从清单里移除，换一家。
注意事项
- 条款优先：注册前读一遍 Referral 条款中的「禁止行为」段落。自邀请（同一人多账号互邀）、虚假信息注册、批量群发邀请，几乎都会被判定违规并回收额度甚至封号。
- 到账延迟：多数平台的奖励在被邀请人完成首次付费或首次成功调用后触发，且有 7～30 天不等的审核期，不要把奖励算进「本周可用额度」。
- 档位清零：部分平台按自然月清零阶梯进度，部分按滚动 90 天，务必在进度卡里写清楚，这是最容易踩的坑。
- 返佣类奖励的波动：百分比返佣依赖被邀请人的持续消费，不适合做底仓，只作为补充。
- 不要为了冲档而拉无效用户：平台通常会核验被邀请人的真实活跃度，无效注册不计入档位，反而浪费你的社交信用。
适用场景
- 个人开发者：每月有稳定的小额推理需求，希望通过邀请把成本压到接近零；
- 2～10 人小团队：由一人主账号归集奖励，团队共用同一额度池；
- 内容创作者：本身有教程、开源项目或技术社群，邀请链接有天然曝光位；
- 不适合：需要大额、确定性算力预算的生产业务，以及无法公开分享邀请链接的封闭场景。
与其他路线的搭配
这条路线适合作为「底仓」，与官方 Free Tier 的限速档位、聚合网关试用金轮换搭配使用：邀请返利负责提供额度增量，Free Tier 负责提供日常基础调用，两者叠加后基本可以覆盖个人开发者的月度用量。