AI科研 Skill 排行榜 Top10

这是第一次有人把这条赛道的格局摊开。之前大家只是零散地听说"某个科研 skill 库好像挺火"，具体谁在前面、差距多大、格局是散的还是已经分层了，没人说得清。

我读完的第一反应不是"该用哪个"，是"这排名能信吗"。

所以我花了一个下午，把 10 个仓库一个一个查了。查星数、查最后更新时间、查许可证、查仓库体积、查 README 里到底写了什么。

查出五件事，榜单上一个字都没提。

一、先把榜单摆出来

第一梯队三个，都在 5 万星以上：

然后掉下来：

最后三个：

榜单本身没毛病。它明确说了按星数排，也没假装这是质量评测。

但"按星数排"这句话，决定了你该怎么读它。

我去查的时候，距榜单发布隔了大约一天。结果是：10 个项目，无一例外，全在涨，合计又涨了 1,134 星。

平均下来，每个项目一天涨 113 星。

这不是某一个项目特别火。是整个品类同时在被看。

（图 1：10 个项目逐个复核。左侧条形是星数，右侧是各仓库最后一次 push 距今的天数｜数据：GitHub API，2026-11-04 15:50 实测）

二、断崖在第 3 名和第 4 名之间

5.2 万 → 1.9 万。跌掉 64%。

这一刀切得非常干净。前3名和第 4 名之间，不是"稍微差一点"，是差了整整一个量级。

前十名其实分了三层：

这个分层不是巧合。往下看就明白了。

三、177 个技能换 5.6 万星，23 个技能换 5.2 万星

这是我这次最想说的一个数。

榜首的 scientific-agent-skills，177 个技能，56,028 星。摊下来每个技能 317 星。

第三名的 nature-skills，23 个技能，52,103 星。每个技能 2,265 星。

星数只差 7.0%（3,925 颗），技能数差 7.7 倍。

（图 2：星数几乎相当，技能数差近 8 倍。下方方块是技能数量，每格代表 5 个｜数据：GitHub API 实测 + 各仓库 README）

这说明榜单排的不是"谁的能力强"。

它排的是"谁打中的痛点更普遍"。

写论文、画图、润色——这三件事，所有学科的所有硕博生都要干。所以 23 个技能就能撬动 5.2 万星。

而"跑单细胞测序"、"做分子对接"、"算材料能带"——每一个技术含量都更高，但只有一部分人需要。所以 177 个技能，换来几乎一样的星数。

再往下看两个极端：第 8 名只有 1 个技能包，8,078 星。第 9 名 3 个技能，5,639 星。

一个 skill 换来 8 千星。在开源世界里这意味着什么？

意味着这个痛点足够普遍，以至于"打包"这个动作本身就够值钱了。

四、第 8 名和第 9 名，已经不更新了

这是查的时候最意外的一部分。

第 9 名 codex-claude-academic-skills：5,639 星，3 个技能。建仓 2026-05-14，最后一次 push 也是 2026-05-14。

建仓当天推了一次，之后再没动过。到今天，174 天。

第 8 名 Research-Paper-Writing-Skills：8,078 星，最后更新 2026-06-23，134 天前。整个仓库 40KB。

我去读了第 8 名的 README，一共 2.3KB。开头有一段"Important Attribution"，作者自己写得很坦率：

“Most writing knowledge and methodology in this repository comes from Prof. Peng Sida (彭思达)'s open study notes. My contribution is organization, structured adaptation, and packaging as reusable Skills.”

我觉得这个作者值得尊敬。他把出处放在 README 最前面，没有一丝含糊，还附了原仓库链接。

但这件事同时暴露了榜单的一个盲区：

8,078 颗星，衡量的是"彭思达那套笔记有多值得学"，不是"这个仓库有多重"。

star 是收藏，不是使用。它记录"有多少人觉得这值得存下来"，不记录"这东西现在还能不能跑"。

这两件事，在你真正动手的时候，差得很远。

五、10 个项目里，4 个许可证不明

这个对科研用户是实际问题，不是法律洁癖。

GitHub 上显示的 NOASSERTION，意思不是"没有许可证"，是"认不出你用的是哪一种标准协议"。可能作者写了自定义条款，也可能压根没写。

为什么科研用户要在意？两个很具体的场景：

一是你在企业做研发，想把某个 skill 接进内部流程。没有明确许可证，法务不会放行。

二是你基于它改了点东西，想写进论文的方法部分，或者再发布出去。授权边界不清，就是个隐患。

对比一下：前 3 名里，K-Dense 是 MIT，nature-skills 是 Apache-2.0，都清清楚楚。反倒是排第 2 的那个模糊。

顺带一个细节：第 2 名和第 6 名是同一个作者（Imbad0202）的两个仓库。如果合并算，加起来 69,285 星，比榜首还高。

榜单把它们拆成两个名次，严格说没问题——按仓库排就是按仓库排。但你读的时候得知道，这不是两个独立团队在做同一件事。

六、这条赛道是今年春天才起来的

我把 10 个仓库的建仓日期都拉出来排了一下。

10 个项目里，8 个是 2026 年建的仓。而且不是分散在各月——从 2 月底到 5 月中，三个月里连续冒出来 8 个。

只有两个是去年秋天的：K-Dense（2025-10-19）和 Orchestra-Research（2025-11-03）。

再看涨星速度：nature-skills 建仓 6.4 个月，5.2 万星，月均 8,166。K-Dense 建仓 12.5 个月，5.6 万星，月均 4,472。

晚建仓的，跑得比早建仓的快 1.8 倍。

（图 3：10 个项目的月均涨星速度与建仓时间。越晚建仓的项目，涨得越快｜数据：GitHub API 实测，created_at 换算）

这个信号很明确：窗口是今年春天打开的。

之前不是没人做，是没人看。一旦 Claude Code、Codex 这类工具把"skill"这个概念铺开，需求就集中爆发了。

如果你正在做类似的东西，这个时间点值得记一下：现在进场，还在第一梯队的时间范围内。再晚一年，头部该固化了。

七、那这份榜单到底怎么用

三个用法，按重要性排。

第一，把它当地图，不是购物清单。

它最大的价值是把赛道的形状画出来了：头部是平台，中部是全流程流水线，尾部是单点写作。

这个形状比任何一个项目的功能列表都有用。因为你要判断"我该做什么"，看的是形状，不是功能。

第二，选工具时，先看最后更新时间，再看星数。

这是我这期查出来最实用的一条：

一个 174 天没更新的仓库，你 clone 下来大概率还能跑——skill 本质是 Markdown 加脚本，不像框架那样容易腐烂。但你要是卡住了，issue 里可能没人回。

反过来，第 5 名 AI-Research-SKILLs（24 天前更新）、第 7 名 Supervisor-Skills（19 天前更新），这个频率在活跃项目里算慢的，但在"一次性交付的 skill 库"里完全正常。

关键是：你得知道自己买的是持续维护的产品，还是一次交付的笔记。这两类东西的评价标准不一样。

第三，新入场的机会，不在"再做一套技能"。

看榜单尾部的天花板就清楚了：单点写作类已经卷到 5k–8k 星。再做一个"论文润色 skill"，上限就在那儿。

真正的空缺在验证环节。

这 10 个项目，没有一个在解决"我怎么知道它跑出来的结果对不对"。

我写这期的时候一直卡在这个问题上：如果我拿 K-Dense 里某个分析 skill 跑自己的数据，出结果了，我凭什么相信这个结果？谁来告诉我它在什么情况下会错、错多少？

没人管这件事。

而这件事，恰恰是科研里最贵的一环——前几期写 CopilotJ 的时候，那个把 1,609 个数成 266 的案例，就是这一环缺席的代价。

结语

回到标题里那两个名字。

56,028 星的那个：一天后又涨 185 星，仓库 460MB，177 个技能，有 CI、有安全扫描脚本、有版本号、README 里挂着 arXiv 编号。

174 天没更新的那个：5,639 星，3 个技能，建仓当天推了一次。

它们现在在同一份榜单上。因为你只能用一把尺子量它们，那把尺子叫 star。

star 是个好指标。它诚实、公开、删不掉。但它只量一件事：有多少人觉得这值得存下来。

至于这东西还能不能用、谁在维护、许可证允不允许你商用、跑出来的结果对不对——它一个字都不说。

所以这份榜单最好的用法，是把它当目录，然后自己往下翻。

（榜单发布于 2026-11-03。文中星数、更新时间、许可证均为 2026-11-04 15:50 通过 GitHub API 实测，与榜单发布时约有 24 小时差。技能数为各仓库 README 标注或目录统计，口径不完全一致。）