面向开源维护者的 ChatGPT Pro / Codex 权益申请看似零门槛，任何项目的维护者都能提交，但官方审核更看重真实使用量、采用广度和生态重要性。本文梳理申请条件、审核维度、填表前的准备清单与常见误区，并给出未通过时的可持续替代方案。
OpenAI 面向开源项目维护者开放了一项权益申请：通过表单提交自己的项目，有机会获得一段时间的 ChatGPT Pro（含 Codex 相关能力）使用权。消息传开后，最吸引人的一点是门槛写得非常宽松——不设硬性 star 数要求，只要你是某个开源项目的维护者，哪怕项目只有你一个人在维护，也可以提交申请。
于是讨论很快分成两派。一派觉得填表只要几分钟，先交上去再说，中了是运气；另一派则翻出官方说明里那句关于「显著使用量、广泛采用度、对生态有明确重要性」的描述，认为 star 少、下载量低的小项目基本没有机会。两种态度都不算错，关键在于搞清楚这个计划在筛选什么，以及你该投入多少精力。
这个计划在找什么样的项目
从公开说明看，它更像一个面向开源生态的支持计划，而不是普惠福利。申请是表单制，由官方团队审核，分批滚动处理，不是先到先得，也不是填了就自动通过。具体的权益时长、覆盖范围、名额和截止时间都可能调整，请以官方申请页面当时写明的条款为准，不要拿别人的截图当依据。
值得注意的是，它没有把 star 数设为硬性门槛，这并不等于不看项目影响力。官方强调的是「meaningful usage、broad adoption、clear importance」这一组词——真实使用量、采用广度、生态重要性。star 只是这三件事的一个粗糙代理指标，审核方完全可以绕开它去看别的证据。
审核可能关注的几个维度
| 维度 | 官方口径 | 你能提供的证据 |
|---|---|---|
| 真实使用量 | 有实际用户在用 | 包管理器下载统计、依赖它的仓库数、issue 与讨论来源 |
| 采用广度 | 被较多人或组织采用 | 下游项目、企业用户、教程与文档引用 |
| 生态重要性 | 填补空白或属于关键一环 | 协议/标准的实现、被其他项目当作基础设施 |
| 维护者身份 | 你确实是维护者 | 提交历史、合并的 PR、release 记录、仓库权限 |
对绝大多数个人项目来说，前两项很难做强，但第三项和第四项是可以讲清楚的：你的项目解决了什么别人没解决的问题，谁在依赖它，你最近三个月做了哪些维护工作。审核看的是可信度，而不是数字大小。
通过率高不高：没人能给准数
公开渠道没有可靠的通过率数据，任何「很高」或「极低」的说法都是个人感受。比较务实的判断是：
- 提交成本极低（几分钟填表），所以值得一试，尤其是刚好在维护项目的人；
- 但不要把它当成规划前提，别因为「可能免费」就推迟自建工具链；
- 只有两三个 star 的项目提交没有坏处，只是期望值要放低；
- 审核是滚动的，等待时间不确定，不要反复催问或重复提交。
提交前的准备清单
如果决定申请，花半小时把材料整理好，比反复提交十次有用。
- 确认身份可验证：使用与仓库提交记录关联的账号或邮箱，确保你能在个人主页上看出对该仓库的维护权限。
- 让主仓库三十秒能看懂：README 写清项目是什么、解决什么问题、如何安装、有没有最小示例，LICENSE 不要缺。
- 补齐活跃度证据：最近的 release、CHANGELOG、对 issue 的回复记录，这些比 star 更能说明项目还活着。
- 准备一句具体用途：说明拿到权益后打算做什么，例如代码审查辅助、issue 分类、测试用例补全、文档翻译。越具体越可信，空泛地写「提升开发效率」没有信息量。
- 只填 1–3 个代表仓库：挑最能说明问题的，不要把 fork 和个人练习项目全列上。
- 有下游依赖就写出来：谁在用、用在哪，这是「采用广度」最直接的证据。
填表时的几个细节
- 项目描述用英文写，一句话讲清定位，避免机翻腔；
- 链接指向主仓库，而不是个人主页或 fork；
- 不要夸大使用量，审核方看得到提交记录和 issue 区；
- 如果项目有过安全修复、兼容性维护等「脏活累活」，可以提一句，这类工作往往比新功能更能体现维护者角色。
几个需要避开的误区
刷 star 或买 star。 违反平台规则，而且审核看的是采用度而非数字，短期涨上去的 star 与下载量、依赖数对不上，反而更可疑。风险远大于收益。
共享或转卖权益。 订阅类权益与账号绑定，转卖、拼车、出借都可能触发风控，导致账号受限。申请的权益自己用，别碰这类交易。
临时建空仓库凑数。 没有提交历史、没有 release、没有使用者，很难通过任何一项审核，还会浪费一次提交机会。
把免费额度当长期基础设施。 权益有期限，到期后工具链要能平滑回退，别把团队流程建在随时会消失的额度和模型版本上。
没通过怎么办
大部分申请者大概率收不到通过通知，这不代表项目没价值，只是名额和筛选标准的问题。可行的替代路径有三条：
- 继续维护，等下一批：把 README、release 节奏、issue 响应补起来，下次申请时材料会强很多。
- 用付费档位或按量计费：多数 AI 编码工具都提供个人订阅或 API 计费，成本可控，适合作为稳定方案。
- 自建长期在线的运行环境：如果瓶颈不是额度而是机器——本地笔记本一合盖、一断网，挂在后台跑的 agent 就中断了，长时间任务很难跑完。这种情况下可以考虑把工作负载放到一台常驻在线的远程机器上，例如整台 Mac mini 托管在机房、按月租用的独享远程 Mac，通过网络远程连接使用，网络环境相对稳定，适合长时间挂着跑 Claude Code 这类命令行工具。它解决的是设备和在线时长问题，不能替代订阅本身，按需评估即可。
小结
这个计划的真实门槛不在 star 数，而在于你能否用材料证明项目「有人在用、有人在依赖、你在认真维护」。行动建议很简单：
- 值得提交，但只花半小时，不投入更多情绪；
- 提交前把 README、release、用途说明三件事补齐；
- 不刷数据、不碰账号交易，避免为了小便宜损失主账号；
- 同时准备好不依赖免费额度的长期方案，工具链才不会被一次审核结果左右。
最后提醒一句：此类计划的资格要求、权益内容和时长都可能调整，动手前请以官方页面最新说明为准。