文章
E 盘开源体检：把 20 多个项目过一遍，哪些真的能开源
一次对本地全部项目的公开性审计：用什么标准判断能不能开源、扫描里翻出哪些必须先处理的东西（真实群聊记录、写死的本机路径、第三方代码），以及最终分成的三档。
手上项目一多，「哪些能开源」就不再是一个凭感觉的问题。
感觉通常会给出同一个答案——「这个应该能发吧」——然后你在 git push 的那一刻才想起仓库里还躺着一份 .env。
所以我把本地 E 盘的项目整个过了一遍，用一套可复述的标准，产出一张三档清单。 这篇文章记的是判据和扫出来的东西，不是清单本身。
判据：四个问题，按顺序问
顺序很重要，因为前面的问题能否掉后面的：
- 这代码是我的吗？ 不是自己写的，就谈不上「我开源它」——只能 fork、只能引用。
- 仓库里有没有不能公开的东西？ 密钥、真实聊天记录、个人信息、客户数据。
- 它能不能被别人跑起来？ 写死的本机绝对路径、只有本机才有的依赖、缺 README。
- 它想解决什么问题，说得清吗？ 一个连自己都解释不清用途的脚本，发出去只会变成你的长期负债。
第 1 和第 2 条是否决项：只要命中，不管第 3、4 条多好都不能发。 第 3 和第 4 条是工作项：可以修，修完再发。
扫描里翻出来的三类东西
一、真实数据混在代码目录里
最典型的是一个微信群聊提炼工具：主流程完全可发布，但工作目录里同时躺着 真实的群 ID、群昵称、聊天记录 Markdown 和几百张群图。 它们是运行产物，不是代码，但就住在代码旁边。
这个项目的作者（我）后来把可发布的部分拆进了独立的 -share/ 子目录，
聊天归档目录写进 .gitignore。关键是顺序：
先建 .gitignore → 再 git init → 再 git add
反过来的话，即使后来删掉文件，它仍然躺在历史里——清理要重写提交， 而重写提交意味着所有已经克隆过的人手上都有一份删不掉的数据。
二、写死的本机路径
批量转写脚本里是这样的：
sys.path.insert(0, r"C:\Users\<用户名>\Documents\视频分析\.analysis_tools\faster_whisper")
VIDEO_DIR = Path(r"E:\codex-project\高光视频\素材目录")
对本机来说这是最省事的写法，对别人来说这是「跑不起来」。 而且它顺手泄露了两件事：你的用户名，和你的目录组织方式。
修法不复杂——路径全部变成命令行参数，给一份脱敏的示例输入—— 但这一步必须在发布前做，因为一旦以「能跑的脚本」的形象发出去， 后来改接口就是破坏性变更。
三、第三方代码住在自己的目录里
有几个目录名字看起来是我的项目，实际是别人仓库的工作副本：
带完整上游 .git、上游的 LICENSE、几十位贡献者的提交历史。
把这种目录当自己的项目推上去，是把别人的工作成果挂在自己名下。
判定方法很便宜：看 remote 和提交作者。
git -C <dir> remote -v
git -C <dir> log --format='%an <%ae>' | Sort-Object -Unique
自己的项目，作者列表里应该有自己。如果冒出来十几个陌生邮箱，那它就是一个 clone。
分成三档
扫完之后，每个项目只落到三档里的一档：
| 档位 | 判据 | 处理 |
|---|---|---|
| A · 已发布 / 可发布 | 自有代码，无敏感数据，能跑 | 直接进清单，链到仓库 |
| B · 整理后可发布 | 自有代码，但有本机路径 / 缺 LICENSE / 缺 README | 列为整理中，写明差什么 |
| C · 不宜开源 | 含密钥或真实数据、含第三方代码、或本身就是别人的仓库 | 只做本地项目，不进清单 |
落到 C 档的原因必须写清楚，否则半年后你会重新判断一遍—— 而且很可能得出不同结论，因为那时你已经忘了当时为什么排除它。
几个 C 档的真实理由
- 里面有别人的仓库：带完整上游历史和 LICENSE 的工作副本，能做的只有读和用。
- 内容是个人数据：真实群聊归档，价值在内容而不在代码。
- 是一次性输出而不是工具：某个演示视频工程本质是脚手架模板加一条时间线， 没有可复用的东西，发布它只会给以后维护埋单。
- 凭据类文件：访问令牌、会话信息、账号配置。这类文件即使当前是空值， 只要路径和格式进了仓库，就是在提醒下一个人「往这里填真东西」。
结论
真正值得公开的项目，比「E 盘上有多少个目录」少一个量级。 这不是坏消息：能被说清楚的少，正说明筛选起作用了。
下一轮会更省事——因为这次把判据写下来了。
下次只需要跑一遍检查：remote 是谁的、log 里的作者是谁、
有没有写死的本机路径、有没有带个人信息的运行产物。