为什么是「兑换码」这条线
大多数「开源换 Token」的写法都停在 PR 数量、赏金任务和维护者津贴上。但实际发到你手里的东西往往是另一种形态：Hacktoberfest 完成后的奖励通知、项目 Swag Store 结算时附带的厂商优惠码、GitHub Sponsors 某些档位里塞的 sponsor perk、以及社区 Discord 抽奖发出的兑换码。这些东西本身不是现金，但其中相当一部分可以在 AI 厂商的 credits 兑换入口直接兑换成 API 额度。
关键判断：能兑换成额度的码，通常来自「厂商赞助开源活动」这一条链路，而不是来自项目自己。项目只是渠道，厂商才是发额度的一方。所以你要做的是顺着活动页找到赞助商名单，再去赞助商的开发者页面找兑换入口。
操作步骤
第一步：把「活动—赞助商」对应关系列出来
打开你参与过的开源活动页面（Hacktoberfest 官网、各语言社区的季节性活动、项目自己的贡献者日），翻到 Sponsors / Partners 区块，把赞助商中的 AI 厂商单独摘出来。这一步的价值在于：这些厂商在活动期间通常会上线一个专属兑换页，且这个页面往往不在官网导航里，只能从活动页跳进去。
同时检查你的 GitHub Sponsors 后台。部分项目的 sponsor tier 描述里会写明「含 XX 平台 credits」，这类 perk 一般以邮件形式发送，容易被当成垃圾邮件漏掉。
第二步：确认兑换码的形态与归属
常见形态有三种：
- 一次性兑换码：一码一账号，兑换后绑定，不可转让。
- 活动专属注册链接：点进去注册即自动发放额度，本质是带 UTM 的邀请链接，但额度通常比公开注册高。
- Sponsor perk 邮件里的表单：需要填 GitHub 用户名做校验，厂商后台核对赞助关系后手动发放。
先分清是哪一种，再决定用哪个账号去兑。一次性码不要浪费在小号上，绑定后无法迁移。
第三步：按「先兑快过期的、再兑长期的」排序
兑换码几乎都有有效期，通常以活动结束日为起点计算，窗口约 30–90 天。把手上所有码按到期时间排序，先兑窗口最短的。长期有效的（例如 sponsor perk 这类按年发放的）留到后面，因为额度本身也有过期时间，早兑等于早开始倒计时。
第四步：兑换后立刻确认三件事
- 额度到账的账户与你实际调用的账户是否一致（有的厂商 credits 只对组织账户生效，个人 key 扣不到）。
- 额度的适用范围（是否只限特定模型、是否排除某些高成本模型）。
- 是否触发速率限制——赠送额度常常配一套独立的低速率限制，和付费层不同。
第五步：把兑换结果记进一张表
字段至少包括：来源活动、赞助厂商、兑换码、兑换日期、到期日、适用模型、是否已用完。开源活动的兑换码是零散发放的，不记账基本等于白扔。
注意事项
- 不要买卖兑换码。 厂商条款普遍禁止转让，被查到会连带封号，且这类码通常绑定 GitHub 身份，转手后双方都用不了。
- 一个身份只兑一次。 用多个账号重复兑同一活动的码，是最容易被风控识别的行为，得不偿失。
- Sponsor perk 需要赞助关系处于有效状态。 取消赞助后，部分厂商会在下个结算周期停发，已发放的额度一般不受影响，但续期会断。
- 额度数字不要当成承诺。 各活动每期的额度不同，通常按厂商当期预算浮动，写死在文章里的数字没有参考价值。
- 注意税务与合规。 部分地区把这类实物/虚拟奖励视为应税所得，团队报销场景下尤其要留凭证。
适用场景
- 你每年稳定参与 Hacktoberfest 等季节性开源活动，手上有若干未兑换的奖励通知。
- 你在 GitHub Sponsors 上赞助了开源项目，但从未检查过 tier 里的厂商 perk。
- 你在做原型验证，需要一小笔额度跑通链路，但不打算为它单独走采购流程。
- 团队希望把成员零散拿到的兑换码集中登记，避免重复兑换和过期浪费。
不适合的场景
- 需要稳定、可预测的月度额度：兑换码是一次性的，无法作为长期供给层。
- 需要高并发或生产级 SLA：赠送额度普遍带低速率限制。
- 需要把额度转给他人使用：绝大多数兑换码绑定身份，不可转移。