AI 找开源工具最危险的一步：把 Star 当信用分

你以为 AI 在替你找工具，它可能只是在给批量仓库做搬运。

2026 年 8 月 10 日早上 6 点 07 分，我用 GitHub Search API 做了一次快照：查询 8 月 8 日以后创建、与 MCP、Agent Skill 或自动化相关的仓库，并按 Star 排序。返回的前 30 个样本里，有 22 个仓库名称带有高度相似的 script-hub、script-loader 一类模式；这 30 个样本都显示在 8 月 9 日创建，Star 落在 15 到 96 之间。

先把边界讲清楚：这只是一次特定查询的时间截面，不代表整个 GitHub，更不能据此认定某个仓库恶意或刷星。

但它足够说明一件事：Star 可以帮你发现线索，不能替你做信任决策。

AI 把“排序信号”误当成了“信用证明”

现在很多人找开源工具，已经不是自己一页页看，而是直接对 AI 说：

> 帮我去 GitHub 找一个能完成这件事的项目，选最好的，下载到本地并运行。

这句话听起来很省事，实际上把三个不同任务挤在了一起：发现候选、判断可信、获得执行许可。

AI 最擅长的是第一件事。它能搜索、比较 README、归纳功能、列出 Star 和更新时间。可一旦你让它“选最好的”，它很容易把能量化的字段当成答案：Star 多、描述完整、更新近、名字像专业产品，于是排名靠前。

问题是，排序靠前只代表“被这套查询和排序规则优先看见”。它不自动等于：

• 维护者身份可靠；
• 代码与 README 一致；
• 安装脚本没有额外动作；
• 依赖来源清楚；
• 项目经过真实用户使用；
• 适合在你的电脑、账号和数据环境里运行。

如果 AI 接下来还能开终端、下载仓库、执行安装命令，这个误判就不再是一条不准确的推荐，而会变成一次真实动作。

我看到的不是“坏仓库”，而是一组需要停下来检查的信号

这次快照里，最值得注意的不是某一个仓库，而是样本之间的相似性：名称结构接近、描述模板接近、创建和更新时间集中、Star 区间也较集中。

这些现象本身不是判决书。新项目可能因为发布活动、社区传播或作者已有受众，在短时间内获得关注；同类项目也可能自然采用相似命名。

但当多个信号叠在一起时，正确动作不应该是“立刻安装”，而应该是“提高核验等级”。

我把它叫作来源卫生：不是看到任何陌生仓库都害怕，而是在代码进入本机之前，知道它是谁、从哪来、做了什么、留下了什么证据。

普通人最容易踩的坑，是让 AI 从推荐直接跳到执行

一个很常见的场景是：你想批量整理文件、自动发布内容、连接社媒后台，或者给 Agent 加一个 Skill。AI 找到一个仓库，README 写得很完整，安装命令只有一行。

你看到“开源”“几十个 Star”“刚刚更新”，心理上已经完成了第一轮放行。AI 又补一句“这个项目最符合需求”，第二轮放行也完成了。

最后只剩一个回车键。

可真正需要判断的，是那一行安装命令之后会发生什么：它会下载哪些依赖？是否执行远程脚本？是否读取浏览器、SSH、云服务或社媒凭据？是否打开本地端口？有没有把数据发往外部服务？

给 AI 加四道验货门

以后让 AI 找 GitHub 项目，我建议不要只给它“搜索任务”，还要同时给它“验收任务”。四道门按顺序走，不要因为 Star 多就跳关。

第一门：看身份

先看维护者，而不是先看宣传语。

检查账号注册时间、历史仓库、持续贡献、组织关系、Issue 回复和 Release 记录。一个新账号不等于不可信，但“新账号、新仓库、没有历史互动”意味着证据少，执行权限就应该更小。

如果仓库声称来自某家公司或组织，要从官方主页反向进入仓库，而不是只相信仓库名称和头像。

第二门：看时间线

把创建时间、提交记录、Star 增长、Issue、PR 和 Release 放在一条线上看。

真实项目通常会留下开发过程：早期提交、功能迭代、问题讨论、修复记录。短时间集中创建并不一定有问题，但如果“热度很快、开发痕迹很薄、描述高度模板化”同时出现，就应该暂停自动安装。

这里不要问“Star 多不多”，要问“这些信号能不能互相解释”。

第三门：开代码

README 是销售页，代码才是交付物。

至少检查入口文件、依赖清单、安装脚本、网络请求、文件读写、环境变量和权限范围。特别留意远程脚本、预编译二进制、混淆代码、自动提权、浏览器数据目录和凭据读取。

看不懂全部代码没关系，可以让 AI 生成风险摘要，但必须要求它逐条给出文件路径和代码证据，不能只给一句“看起来安全”。

第四门：看证据

最后看仓库有没有可交叉验证的运行证据：CI 是否通过，Release 是否可追溯，Issue 是否有真实问题，PR 是否有讨论，许可证是否明确，安全策略是否存在。

首次运行放在隔离环境里，用测试账号、测试数据和最小权限。先让它完成一个可观察的小任务，再决定是否扩大权限。

一段可以直接派给 AI 的验货任务

以后不要只说“帮我找一个 Star 最多的项目”。可以把下面这段活直接交给 AI：

> 为这个需求寻找 5 个 GitHub 候选。Star 只作为发现信号，不作为可信结论。对每个候选检查：维护者与组织身份、仓库创建和提交时间线、依赖与安装脚本、网络和文件权限、Issue/PR/CI/Release 证据、许可证与安全策略。所有判断必须附仓库 URL、文件路径或公开记录。先给风险分级和最小化试运行方案，不得下载、安装、登录或读取凭据，等待我确认后再执行。

这段话做了两个关键拆分：搜索可以自动，执行需要授权；推荐可以基于信号，信任必须基于证据。

Star 仍然有用，只是它应该待在正确的位置

我不是说 Star 没用。它仍然能帮助我们发现社区关注、判断项目是否有传播基础、快速缩小候选范围。

问题只在于，Star 属于“发现层”，不属于“许可层”。

一个 Star 很少但代码透明、维护历史清楚、权限克制的新项目，可能值得在沙箱里小范围试用；一个 Star 很多但安装动作不透明、维护证据断裂的项目，也不应该直接进入生产环境。

最后给这套方法收个口：

先用热度找线索，再用身份、时间线、代码和证据做验货；没有通过验货，AI 就只有推荐权，没有安装权。

这才是把 Agent 真正放进工作流之后，我们该补上的那道门。