# 我用 GitHub Trending 前 20 名做了一次统计实验，结果和直觉不太一样

每天看 GitHub Trending，很容易产生一种感觉。

排在前面的项目，往往已经有很多 Star。一个项目越出名，似乎就越容易继续获得关注。于是我们会自然地把累计 Star 和当天增长连在一起，觉得老牌项目应该涨得更快。

今天我决定不靠感觉判断。

剑的 AI 实验室每天从 GitHub 和 X 收集项目，再挑一个没有做过完整实验的项目进入实验田。2026 年 8 月 29 日，GitHub Trending 全球 Today 榜首依然是 Archify。这个项目昨天已经完成发现、核验、实测和产出，所以按去重规则跳过。

第二名是 K-Dense-AI 的 Scientific Agent Skills。

这个仓库收录了 163 个科研 Skill，涉及文献综述、统计分析、科研可视化、生物医药、化学、实验设计和论文写作。昨天我们已经确认它可以安装，但那只能证明 163 个目录被复制到了工作环境，不能证明 163 套科研流程都能跑通。

今天要补中间这段，拿一个真实问题，选两项能力，完整跑一遍。

## 先把问题写在运行之前

我选的问题很简单。

GitHub Trending 全球 Today 前 20 个项目中，累计 Star 越多，当天新增 Star 是否也越多。

数据来自 2026 年 8 月 29 日 15 时 02 分的页面快照。20 个项目全部保留，没有删掉看起来奇怪的点，也没有等到结果出来后再挑方法。

分析计划先写好。

主要变量是累计 Star 和当天新增 Star。主要检验采用双侧 Spearman 等级相关，因为样本只有 20 个，数值又明显偏斜，没有理由先假设线性关系和正态分布。显著性阈值设为 0.05，再用固定随机种子做 10,000 次 bootstrap，给相关系数一个 95% 区间。

当天新增除以累计 Star 得到的比例只用于描述。这个比例可以帮助观察小项目的短期冲劲，但不参加额外的显著性检验。

解释边界也提前写下。

Trending 是平台筛选出来的动态注意力快照。它不代表长期质量，也不能证明增长原因，更不能预测未来。

## 安装成功以后，第一轮依然失败了

这次没有安装整座仓库，只安装 statistical-analysis 和 scientific-visualization 两项。

安装命令退出码为 0。安装器先识别到 163 个 Skill，再把选中的两项复制到隔离目录。过程中没有使用外部模型、付费数据库或付费 API。

接下来运行分析脚本。

第一轮退出码为 1。

有意思的是，统计计算已经完成，图也已经画出来。错误发生在最后生成 Markdown 报告时。pandas 的 to_markdown 方法需要一个名为 tabulate 的可选依赖，而当前环境没有它。

这是很典型的工程问题。核心计算没有坏，报告层却偷偷依赖了另一个软件包。如果只看最终图，很容易把这次运行写成成功。如果只看退出码，又会误以为统计方法出了问题。

我们保留了这次失败记录，并把诊断写清楚。

修复也很克制。没有临时安装更多依赖，只用 Python 标准字符串生成 Markdown 表格。第二轮重新运行，退出码为 0。20 行数据全部保留，增强 CSV、统计 JSON、PNG、SVG、导出清单和中文实验结果一起生成。

## 数字没有支持那个常见直觉

最终的 Spearman 相关系数为 0.0451。

这个数字非常接近零。双侧 p 值为 0.8502，10,000 次 bootstrap 得到的 95% 区间从 -0.3983 到 0.4754。

对这份 20 个项目的单日样本，累计 Star 和当天新增 Star 没有显示出稳定的单调关系。一个仓库历史上积累了很多 Star，并不意味着它在今天一定增长得更快。

这也能从相对动量看到一些线索。

当天新增占累计 Star 比例最高的五个项目是 God's Eye View、Tailcat、TypePHP、Go Modern Guidelines 和 Archify。里面既有刚获得大量注意力的项目，也有已经积累一定规模的项目。

Scientific Agent Skills 自身排在 Today 第二，却没有进入相对动量前五。Today 排名、累计 Star、当天新增和相对增长率各自描述不同的东西，不能拿一个数字替代另一个数字。

## 一张图不能替你下结论

图表把累计 Star 放在对数坐标上，每个项目保留编号和名称。右侧再画相对动量前五，底部明确写上单日样本和不可外推的限制。

这样做是为了减少读图时的误会。

累计 Star 跨度很大，直接放在线性坐标上，大多数点会挤在一起。使用对数坐标只是改善展示，没有改变 Spearman 检验本身。颜色和位置也没有被解释成质量等级。

如果把这张图单独截出去，最容易出现的错误是把没有发现相关误写成完全没有关系。当前样本小，区间仍然很宽。正确说法只能是，这份样本没有给出稳定的单调关系证据。

下一天、下一周或者换一批项目，结果都可能变化。

## 这个仓库适合怎样使用

Scientific Agent Skills 的价值在于把科研工作的步骤写成可复用说明。它可以提醒 Agent 先定义问题、检查数据、选择方法、记录假设、输出图表并声明限制。

它不会自动保证数据真实，也不会替研究者承担专业判断。

同一个仓库里的 163 个 Skill，风险和依赖并不相同。文献检索可能访问外部数据库，生物医药任务可能涉及隐私和专业监管，化学流程可能要求更严格的安全审查，某些步骤还可能需要模型 API、Python 软件包或受限数据授权。

比较稳妥的用法是按任务安装。

今天要做统计，就装统计和可视化。先在隔离目录运行，再检查命令、网络、依赖和输出。通过一个真实任务之后，把结果写成已实测。其余没有运行的部分继续保持未验证状态。

这比一次安装 163 个 Skill 后宣布全部可用慢一点，但记录更经得住复查。

## 对实验室流程的意义

这次实验让实验田的五个区连了起来。

种子区记录为什么跳过榜首、为什么选择第二名。播种区保存安装命令、预注册计划、首轮失败和第二轮修复。收成区保存原始数据、脚本、图表和机器可读结果。收获记解释数字对实际工作有什么用。竞技场给出推荐对象、成本边界和未测范围。

以后每天做一个 GitHub 项目，也可以沿用同样的尺度。

发现不等于核验。安装不等于实测。产出不等于结论可以无限外推。

今天的结果看起来只是一个接近零的相关系数，背后留下的却是一条完整证据链。原始数据可以下载，脚本可以重跑，首轮失败没有删掉，图表可以编辑，结论可以被质疑。

这些可复查的材料值得留下来。