如何对项目进行开源审查

周末我做了一件事：把自己 GitHub 上的 32 个私人项目，逐个过了一遍，判断哪些适合开源。结论是——一个都不能直接发。

不是项目做得不好。最高分的那个 daily-signal 拿了 83 分，有测试、有 CI、用户问题也清楚。但即便这样，它现在也不能把 visibility 改成 Public。

这件事让我意识到，“开源”这两个字被我严重低估了。

起因

我手上有 32 个私人项目，分布在 AI 工具、英语学习、可视化、个人工具几个方向。有些是认真做的产品，有些是周末随手写的脚本。时间一长，我自己都记不清哪个做了什么、里面有没有不该公开的东西。

我想整理一下，挑几个开源出去。一开始的想法很简单——挨个看看代码质量、有没有 README，差不多的就开。

后来发现这个判断方式完全不对。

“能不能开源”其实不是一个问题，是四个

审查之前，我把”能不能开源”当成一个问题。做完才发现，这其实是四个完全不同的问题，混在一起想，结论一定是错的：

1. 能不能安全地公开源码？（会不会泄密钥、泄露私人数据）
2. 别人能不能合法地用？（版权清不清晰、许可证在不在）
3. 值不值得投入开源运营成本？（有没有人需要、会不会有维护负担）
4. 发出去是加分还是减分？（工程声誉上是正资产还是负资产）

我以前的判断只看第 3 个——“这项目不错，应该有人需要”。但真正会出事的，是前两个。

这次我按六个门（gate）来审：权属版权、密钥隐私、合规滥用、第三方来源、最小可用性、维护边界。前四个里任何一个被确认阻断（BLOCKED），整个项目就不能公开，不管它分数多高。

几个让我后怕的发现

第一个：blog-critique 里疑似有真实密钥。

在 tracked 配置里发现了看起来像真实 provider credentials 的值。不是写在 .env（那个被 gitignore 了），是写进了会被 git 追踪的配置文件。这意味着它很可能已经进了完整 Git 历史。

这种事光加 .gitignore 是没用的——历史里的东西还在。正确的处理是：先去服务商后台轮换密钥（当作已经泄露），再清理当前树和完整历史。顺序不能反。

回头想想，这种”临时方便写进配置”的事我以前干过不止一次。这次只是审查才撞上。

第二个：好几个项目里有真实个人数据。

evolution-os 的种子数据里是真实履历，TPO-Writing 里有可识别的个人故事，monday-magic-bank 的 README 里写了真实未成年人的身份背景。这些东西对我自己有用，但一旦公开，就是不可逆的隐私泄露。

第三个：版权来源说不清。

vocabulary 里混了商业词书 PDF 的分块和派生列表，financial-chart 里有公司品牌和业务素材，ai-coding 是书籍、小说、词书、多来源实验混在一个仓里。这些项目即使代码是我写的，素材的授权我不一定能证明。

有个认知偏差特别值得说：自己写的代码 ≠ 自己有权开源。代码是你的，但如果里面嵌了别人的数据、模板、字体、模型，整体能不能开源取决于那个来源的授权，不是取决于你的代码占比。

最高分的项目，反而被一票否决

这是最反直觉的一条。

AgentInfra 的价值分是所有项目里最高的（49/55），长期看是我最想做的技术品牌旗舰。但它现在被判定阻止公开——因为第三方来源（G4）被 BLOCKED：历史里有第三方插件缓存，上游资产的逐项来源治理还没做完。

评分系统设计成这样是有意的：分数高只代表”值得投入”，不等于”现在能发”。G1-G4 的 blocker 是硬门槛，一票否决，覆盖数值分。

这个设计纠正了一个常见错觉——“打分高就能开源”。实际上，分数只帮你排序”先整理哪个”，不替你做发布决策。

收敛到三条公开主线

审查到一半我有个转变。

一开始我想的是”挑出高分的一批，都开了”。看到 32 个项目分布在好几个方向、互相重叠，我才发现这个思路有问题。个人开源的影响力，来自别人能记住你解决了什么具体问题，不是 Public 仓库的数量。开 10 个半成品，不如把 1 个做到别人愿意 star。

最后我收敛到不超过三条公开主线：

• 一个小而稳定的工具（首发，建立开源流程样板）—— daily-signal
• 一个能直接演示的产品旗舰 —— DeepListener 或 breather，二选一，不同时运营两个
• 一个长期的工程代表作 —— AgentInfra，先治理来源再开放

TOEFL/英语那 9 个项目，全部收到 sentence-builder 一个主品牌下，其他抽模块或归档，不分散经营 6-9 个仓库。

几条可以复用的判断

做完这一轮，我把能复用的部分整理出来：

1. 把”能不能开源”拆成四个问题分开判断：能不能安全公开、别人能不能合法用、值不值得运营、发出去加不加分。混在一起想一定出错。
2. 先查阻断项，再看分数。权属、隐私、合规、来源——任何一个说不清，分数再高也不能发。
3. .gitignore 挡不住已经进历史的东西。密钥和私人数据一旦进了 Git 历史，按”已泄露”处理：先轮换，再清历史，顺序不能反。
4. 自己写的代码 ≠ 自己有权开源。素材来源的授权决定整体能不能发，不看你的代码占比。
5. 个人开源要收敛。三条主线够了，不分散经营一堆仓库。

我把这套审查标准、评分规则和整改工作流，固化成了一个项目（open-source-incubator）和一个 skill。下次再攒一批项目要整理，直接跑流程，不用从头想判断维度。

最实际的一条：在把任何项目改成 Public 之前，先假设它不能发，然后让证据说服你它可以。 反过来做，大概率会漏掉真正会出事的东西。