CreatorFlow 到 220 个 Star 后，我去申请了 OpenAI 的开源支持

我正在申请 OpenAI 的 Codex for Open Source 项目。

请基于我提供的 GitHub 仓库和 OpenAI 官方申请页，先核验事实，再协助填写申请表。

仓库地址：[GitHub 仓库 URL]
GitHub 用户名：[用户名]
真实角色：[主要维护者 / 核心维护者 / 创建者 / 唯一维护者]

请核对：
1. 官方页面当前的申请资格、支持内容和字符限制；
2. 仓库用途、许可证、Stars、Forks、Contributors、已合并 PR 和 Releases；
3. 项目已经存在的功能、目标用户和公开证据；
4. 命令执行、文件操作、网络请求、凭证、Prompt Injection、供应链和第三方贡献带来的真实攻击面；
5. API 额度能用于哪些持续维护工作，例如 Issue 分类、PR 审查、回归测试、文档检查和发布流程。

请分别生成：维护者角色、仓库为何符合要求、为何需要 Codex Security、API 额度用途、其他说明。每项提供英文版、中文翻译、英文字符数、引用事实和未采用表述。

约束：
- 不用二手帖子替代官方页面；
- 不虚构用户数、下载量、合作人员或长期采用情况；
- Stars 和 Forks 只写成公开指标、关注或复用信号；
- Contributor 身份与真实维护关系不一致时先指出，不自行推断；
- 不把计划写成现有能力，不把申请提交写成已经获批；
- 每个英文栏位不超过官方当前限制；
- 文风简洁、可信，不写营销文案。

最后做一次反向事实审计：逐句标注公开事实、合理推断和未知信息，删掉证据不足的句子，再读取一次仓库数据并重新计算字符数。

8 月 27 日，我又打开了一次 CreatorFlow 的 GitHub 仓库：220 个 Star，44 个 Fork。

说完全不激动，那是假话。

这个项目最初只是我给自己搭的一条自媒体视频生产线。我不想每次换个会话，都要重新解释选题怎么筛、脚本什么时候锁定、素材从哪里来、成片凭什么通过 QA。后来我把这些步骤整理成 Agent Skills，补上脚本、测试、安全边界和发布门禁，才把它开源出来。

仓库公开还不到两周。220 个 Star 不能算作 220 名真实用户，44 个 Fork 也不能证明有 44 个人完整跑通了流程。它们只说明，有人愿意停下来看看，其中一部分人还把代码拿走研究或修改。对一个刚起步的独立项目，这已经是一张值得认真对待的成绩单。

我也拿着这张成绩单，提交了 OpenAI 的 Codex for Open Source 申请。

先把结果说清楚：申请已经提交，正在等待审核，不是已经入选。OpenAI 官方申请页写的是滚动审核，由邮件通知入选者。入选维护者可获得 6 个月 ChatGPT Pro（含 Codex）、用于开源维护的 API 额度；符合条件的仓库还可能获得 Codex Security 的有条件访问。这里没有一个正式叫“Pro 20x”的固定礼包，我也不会把提交成功页面写成获批通知。

表面在写申请，实际在盘手里的牌

申请表的几个关键文本栏位最多 500 个字符。看上去，这很适合交给 AI：读一下仓库，写几段英文，再压缩字符数。

真正麻烦的不是写短，而是 AI 很容易在压缩时把确定性一起抬高。

比如 Star 是公开关注指标，不是用户数；Fork 更接近研究、复用或改造意愿，也不是安装成功记录。再比如 GitHub 的 Contributor 页面曾显示两个提交身份，其中一个 noreply 只是早期发布留下的作者身份，不是真实合作人员。CreatorFlow 是我独立创建并维护的。如果只让 AI 扫一眼页面，它很可能顺手写成“由两位贡献者共同维护”。

文字确实更漂亮了，事实却坏了。

这和小公司申请贷款很像。银行要看营收、流水、负债和还款能力。你可以请人把材料整理清楚，却不能把询价客户写成已付款客户，也不能把下个月计划签的合同算进今天的收入。申请表不是给愿景估值，而是在有限篇幅里说明：你是谁，已经做了什么，为什么需要这项资源，拿到以后准备用在哪里。

所以我没有让 AI 直接写一篇夸项目的文案，而是先做证据盘点。

截至当天，仓库可公开核对的数据是：220 Stars、44 Forks、10 个已合并 PR、1 个 Release，最新版本为 v0.2.0，许可证是 MIT。Apple Silicon 和 Intel macOS runner 的 Core 冒烟测试与公开包审计已经通过，但这不等于所有可选工具都完成了全量 Mac 适配。项目有早期关注，也已经产生维护动作；至于活跃用户数、长期采用率和包下载量，目前没有可靠数据，就不写。

规则、手牌和结果必须分开。官方规则决定表格要回答什么；仓库证据是我已经有的手牌；是否入选是审核结果。提示词只能帮我整理前两项，不能替我制造第三项。

五个栏位，不要反复讲同一句话

申请时，我把几个栏位拆成了不同任务。

角色栏只回答谁负责结果。我选的是 Primary maintainer，因为项目由我独立创建，我负责工作流、Skill 契约、自动化脚本、测试、PR、Release 和后续维护。这里不需要再讲一遍宏大愿景。

“为什么仓库符合要求”放项目用途、许可证和公开指标。我写的是明显的早期兴趣，没有把 Stars、Forks 偷换成用户规模。

Codex Security 的理由则要对应真实攻击面。CreatorFlow 会让 Agent 操作文件、执行命令、安装依赖、访问用户提供的 HTTPS 地址，也会处理网页和第三方素材。命令与路径注入、不安全删除、SSRF、凭证泄漏、Prompt Injection 和供应链风险，都是具体问题。“为了提高安全性”这句话放进任何项目都成立，反而说明不了为什么是你。

API 额度也一样。比“提升开发效率”更可信的，是说明它会被用于 Issue 与 PR 分类、工作流 Diff 审查、根据 Bug 生成回归测试候选、检查文档里的过期命令和私人配置，以及根据合并记录起草 Release Notes。最后的合并、安装和发布仍由维护者确认。

最后一栏专门交代限制：项目年轻，没有长期采用数据；公开数字来自 GitHub；仓库不包含私人资料、登录凭据、声音样本和未公开项目。把短板主动写清楚，不会削弱申请，反而让其他句子更可信。

我真正复用的是“反向事实审计”

我把完整提示词放在本文的资源卡里。它的重点不是让 AI 写得更像申请，而是强迫它先完成三件事：读官方规则，查仓库证据，区分事实、推断和未知信息。

第一版写完以后，再让它站到反方做一次审计：哪句话把关注度写成用户数，哪句话把提交身份写成合作人员，哪句话把计划写成现有能力，哪句话把“已提交”写成“已获批”。删完这些，再计算字符数。

这套方法不只适用于 OpenAI。申请云资源、孵化器、开发者计划，甚至给客户写项目案例，都可以先列五张表：

1. 官方规则：谁能申请，对方看什么，字段和期限是什么；
2. 身份关系：谁创建、谁维护、谁贡献，页面身份是否等于真实人员；
3. 已有证据：代码、Release、PR、测试、文档和可核对数据；
4. 实际成本：安全、维护、审核、发布分别消耗什么；
5. 结果边界：已提交、审核中、已入选，不能混成一个状态。

如果一条判断没有证据，就降级措辞；如果一个数字会变化，提交前再读取一次；如果一个优势只存在于路线图里，就先别写进现在时。

220 个 Star 以后，责任比数字更具体

我以前容易把 Star 当成一个结果。做到 220 的时候，反而更清楚它不是什么。

它不是收入，不是活跃用户数，也不能证明项目已经成熟。它更像陌生人交来的一点早期信任。有人点 Star，有人 Fork，有人跑不通以后回来问一句 Mac 能不能用。每多一个真实问题，维护者手里就多一项要回答、要修、要留下证据的责任。

OpenAI 的申请也是这样。6 个月 Pro 和 API 额度当然有吸引力，我确实想要。但审核者最后看到的，仍然是仓库里已经存在的代码、文档、测试、Release、安全边界，以及维护者是否持续把这些事情接住。

提示词能把牌摆整齐，不能替你凭空发牌。我的申请已经提交，接下来就是继续维护，然后等邮件。