为什么是 PR 赏金，而不是 Issue 认领

Issue 认领靠的是「抢标签」，供给方是项目维护者的注意力，兑现不稳定。PR 赏金不一样：钱（或额度）已经在项目的赏金池里，规则写死在结算页面上，你交付的是可被合并的代码，验收标准是 CI 与人工 Review 都通过。对想稳定拿到 AI Token 的开发者来说，这条路径的确定性来自「预算已存在」，而不是「活动方心情好」。

2026 年的现实是：越来越多的开源项目把赏金直接以「AI 推理额度」形式发放——项目从模型厂商拿到赞助额度，再分给贡献者；也有项目走现金赏金，再由你自己换成 Token。两条都算，本文都写。

操作步骤

第一步：筛出「有预算」的项目，而不是「有 Issue」的项目

判断一个项目值不值得投入，看四个信号：

  1. 仓库根目录或 .github/ 下有 FUNDING.yml，且 Sponsors 页面显示有活跃赞助方。
  2. 项目 README 或 CONTRIBUTING.md 里出现「bounty」「reward」「stipend」「credits」字样，并链接到结算页面。
  3. 有公开的赏金看板（常见形态：项目自建页面、Algora 类赏金平台、项目 Discord 里的 bounty 频道）。
  4. 近 90 天有合并记录，且合并者不是同一人——说明维护活跃、Review 不会石沉大海。

四个信号里至少满足三个再动手。只满足第一个的项目，通常只有赞助入口、没有分配机制。

第二步：逐字读结算规则，先确认「发什么」

赏金结算的坑几乎全在规则页。重点确认：

  • 发放形态：现金、平台余额、还是模型厂商的推理额度/兑换码。若是额度，确认是哪个厂商、有效期多久、能否转移给团队账号。
  • 触发条件：是「PR 合并即结算」，还是「合并后进入下一个 release 才结算」，还是「需被至少一位非提交者 Review 通过」。
  • 拆分规则：多人协作的 PR 如何分账；被维护者改写后合并的 PR 是否仍全额结算。
  • 税务与身份：现金赏金通常需要填写收款信息，部分平台要求实名或企业主体；额度类奖励一般只需邮箱或账号 ID。
  • 上限：单人单项目的结算频次上限，很多项目写明「每人每月最多 N 笔」。

规则里没写的，去项目 Discord/Matrix 的 bounty 频道问一句再开工，别做完才发现不符合条件。

第三步：选「小而确定」的 PR，别选「大而光荣」的

赏金 PR 的最优形态是：改动范围清晰、可被自动化测试覆盖、不涉及架构决策。典型高性价比类型：

  • 修复有复现步骤的 bug（Issue 里已给出最小复现）。
  • 补齐测试覆盖率缺口（项目有覆盖率门槛时尤其受欢迎）。
  • 类型注解、文档字符串、依赖版本升级等机械性改动。
  • 为已有功能补 CLI 参数、配置项或错误信息。

避开：重构核心模块、改公共 API、跨多个子包的大改动——这类 PR Review 周期长，且容易被维护者接手改写，结算归属不清。

第四步：提交时把「可验收性」写进 PR 描述

维护者每天处理大量 PR，能快速判断「这个可以合」的 PR 优先被处理。PR 描述里固定包含：

  1. 关联的 Issue 编号或赏金条目链接。
  2. 复现步骤与修复前后对比（截图或测试输出）。
  3. 你跑过的测试命令与结果。
  4. 变更影响面说明（是否影响公开 API、是否需要迁移说明）。

CI 全绿是底线。CI 红的 PR 基本不会被 Review，更不会被结算。

第五步：合并后按规则发起结算，并留档

PR 合并不等于额度到账。多数项目需要你主动发起：

  • 在赏金看板上把条目状态改为「已交付」，附上 PR 链接。
  • 或在项目指定渠道（通常是 Discord 工单或表单）提交合并记录。
  • 若奖励是模型厂商额度，通常会在数个工作日内收到兑换码或账号加额通知，按提示在对应厂商控制台兑换。

务必留档：PR 链接、合并 commit、结算申请记录、到账截图。额度类奖励偶有漏发，留档是唯一能追溯的凭据。

第六步：把额度接进实际工作流

拿到的是 API Key 就写进密钥管理工具，配一条主备 Key 的降级路由；拿到的是兑换码就尽快在有效期内兑换，别囤。额度通常有到期日，闲置即浪费。

注意事项

  • 别刷量。同一项目短时间内提交大量低质量 PR，会被维护者标记，赏金资格直接取消，且这类记录在开源社区是公开的。
  • 别接「已有人在做」的赏金。动手前在看板或 Issue 里确认没有他人认领，重复劳动不结算。
  • 现金赏金与额度奖励的税务处理不同，跨境收款尤其注意平台要求。
  • 额度不等于可商用授权。厂商赠送的推理额度通常附带使用条款限制，用于生产环境前读一遍。
  • 不要虚构贡献。本文所有路径的前提都是真实合并的代码。

适用场景

  • 有一定代码能力、希望把业余时间换成稳定推理额度的独立开发者。
  • 团队内部需要补充 AI Token 预算，且成员本身在参与开源项目的工程团队。
  • 正在维护自己项目、想反过来用赞助池给协作者发额度的维护者（同一套机制的另一端）。