为什么是「团队额度池」而不是个人拉新
个人靠邀请返利攒 Token 的天花板很低：一个账号能邀请的人有限，奖励多半按「被邀请人首次付费/首次调用」结算，且常带有效期。真正能把推荐奖励做成稳定补给的做法，是把团队里每个人的邀请名额当作分散的产能，统一汇总到一个共享额度池，再按项目分配。
这条路径适合 3–20 人的小团队、实验室、开源小组或技术社群。核心不是「多开号」，而是「把合规的邀请名额用满，并让奖励可对账」。
操作步骤
第一步：先建一张「返利规则表」，只收可结算的平台
在动手前，用一张表记录每个候选平台的以下字段，任何一项填不出来就先不投入：
- 奖励触发条件：被邀请人注册即给、首次充值给、首次调用 API 给，还是消费满一定金额给。
- 奖励形式：赠送额度（credit）、折扣券、还是账户余额。只有能直接用于 API 调用的 credit 才计入额度池。
- 结算延迟：多数平台在被邀请人完成条件后 T+1 到 T+7 天到账，部分按账单周期结算。
- 有效期：赠送额度通常有 30/60/90 天不等的过期时间，必须记录到期日。
- 上限：单账号可邀请人数上限、单月奖励上限、是否限制同一支付方式或同一组织。
以 2026 年仍在运行的常见平台为例（规则会变动，以官网当前条款为准）：OpenAI、Anthropic、Mistral、Cohere、Together AI、Fireworks、OpenRouter 以及部分国内模型平台的开放平台，都曾以活动形式提供邀请或推荐奖励；其中不少平台的推荐计划是间歇性开放的，需要先在控制台的 Billing / Referral / Rewards 页面确认入口是否存在。
第二步：把「谁去邀请谁」变成可执行的分配
不要全员发同一个链接——多数平台按邀请人账号归属结算，链接混用会导致奖励落到一个人账上，事后分账麻烦。做法是：
- 每人使用自己的账号生成专属邀请链接，登记到共享表格。
- 优先邀请「本来就要注册」的对象：新加入的实习生、外包开发者、社群新成员、合作方对接人。这类人注册是真实需求，不构成刷量。
- 对被邀请人说明：注册后需要完成哪一步（例如绑定支付方式并产生一笔最小调用），邀请方才能拿到奖励。把这一步写清楚，避免「注册了但奖励没到」。
- 记录每笔邀请的状态：已注册 / 已触发 / 已到账 / 已过期。
第三步：汇总到一个「主账号」并做权限隔离
额度池的落点是团队主账号或组织账号（Organization）。具体做法：
- 若平台支持组织内成员共享额度（如 OpenAI 的 Organization、Anthropic 的 Workspace、部分聚合网关的 Team 计划），把主账号设为结算主体，成员各自邀请产生的 credit 尽量归集到同一组织下。
- 若平台不支持跨账号转移（多数平台不支持，credit 不可转让），则改为「谁邀请、谁持有、按项目报销」的模式：成员用自己的额度跑团队任务，按实际消耗登记，团队以其他资源补偿。
- 为共享账号设置子密钥（API Key）分项目使用，配合用量看板，避免一个人跑光全组额度。
第四步：按到期日做「先到期先用」的调度
赠送额度最大的浪费是过期。维护一张到期日历：
- 把每笔 credit 的到账日、金额、到期日排进日历。
- 排任务时优先消耗最近到期的额度，把长期有效的付费余额留到最后。
- 对即将过期且用不完的额度，安排批量任务（数据清洗、批量 embedding、评测跑分）集中消耗，而不是让它自然失效。
第五步：每月一次对账，决定下月投入
每月底做三件事：统计本月通过邀请实际到账的额度、实际消耗的额度、过期作废的额度。如果「过期作废」占比高，说明邀请节奏和用量不匹配，下月应减少邀请、优先消耗；如果「到账但不够用」，再扩大邀请范围。
注意事项
- 禁止自邀与批量假账号。 主流平台的反作弊系统会识别同一设备、同一支付方式、同一 IP 段的多账号互邀，一旦判定，奖励会被回收甚至封号。团队池的前提是每笔邀请对应真实的新用户。
- credit 通常不可转让、不可提现。 不要假设能把 A 账号的赠送额度挪到 B 账号，规则表里必须写清这一点。
- 推荐计划是活动性质，随时可能关闭或改规则。 不要把它写进长期预算，只当作补充。
- 注意税务与报销合规。 团队成员用个人账号产生并消耗的额度，若团队要补偿，走正常报销流程。
- 企业账号可能有额外限制。 部分平台禁止以组织名义参与个人推荐计划，加入前先读条款。
适用场景
- 3–20 人的创业团队，需要在不增加现金支出的前提下扩大模型调用量。
- 高校实验室或开源小组，成员流动大、新成员本来就要注册平台。
- 技术社群运营者，用邀请奖励给社群共建者提供调用额度。
- 不适合：单人开发者（没有分散产能）、需要大额稳定配额的生产系统（返利额度不可预期）。