同样 30 万星，一个 1 天一版一个 13 天一版：AI 编程项目怎么筛健康度

GitHub 上带 ai 话题的仓库已经多到不能靠 star 排序直接挑了。用官方搜索接口按 star 排序，抓取于 2026-10-31，返回的总数是 约 19.4 万 个（查询链接）。排在最前面的是 morluto/rea，41.5 万 颗星；紧随其后的 openclaw 有 39.4 万 颗星、约 8.3 万 个 fork，license 字段是常见的 MIT，open issues 是 约 7900（注意：搜索接口的这个计数含 PR，与仓库页 Issues 标签页的数字不是一回事，口径差异后面会提），项目创建于 2025-11-24，最近一次 push 在 2026-10-31。这个组合会让人犹豫：它增长很快、也有人大量 fork，但未关闭问题不少、许可证是常见的 MIT。这说明一件事——用 star 数筛 AI 项目，筛出来的是热度，不是健康度。这份榜想把三个更难看的指标固定下来：release 节奏、issue 首响中位数、维护者集中度。

为什么 star 数会骗人

star 数反映的是路人好感，不是维护状态。一个项目可能因为某次演示、某个教程或首页推荐被大量 star，但 issue 区长期没人回复，release 停留在半年前，代码集中在一个人手上。使用者真正开始集成时，这些细节才会变成成本。于是我们不用 star 做最终排序，只把它当作入围条件。先取 topic:ai 里 star 前 30 的仓库，再对每个仓库计算三个健康度指标。这样做的好处是，标准可以写进脚本，下个月同一时间再跑一次，排名变化就能说明哪些项目在变好、哪些在变差。

⚠️ 这份榜的数据全部来自 GitHub 公开 API，全部是 2026-10-31 的快照，没有用爬虫、没有用第三方统计平台。star/fork/issue/total_count 这类数字每次查询都会微调（同一天内重查也可能差几个），所以下面一律用约数 —— 精确到个位的数字写进文章，几天后就是错的。要核实时点开文末链接看当前返回。搜索接口返回的结果带 incomplete_results: false，意思是这次查询没有因为超时或分页截断而返回不完整；这个字段很重要，它让我们知道「约 19.4 万」这个数字是完整计数的官方数据，不是估算值。之后每个月跑榜时，只要这个字段保持 false，就能继续放心使用。

三个指标怎么定

第一是 release 频率。看一个项目最近 90 天发了多少个 GitHub Release，或者最近一次 release 距今天数。这里需要调用 /repos/{owner}/{repo}/releases 端点，按 published_at 排序。有个坑是，有些项目习惯用 tag 而不是 GitHub Releases 发版，如果只统计 release 会低估它的活跃度。所以实践中更适合把 releases 和 tags 两个端点都拉一遍，取并集。这是本文的工程做法，不是 GitHub 官方给出的健康度口径。

第二是 issue 首响中位数。从 /repos/{owner}/{repo}/issues 拉 issue 列表时，先排除掉 pull_request 字段不为空的条目，剩下的才是真 issue。然后对每个 issue 找到第一条非作者产生的评论或事件，计算从创建到首次响应的时间。取中位数，而不是平均数，因为偶尔会有 issue 被冷落三个月，平均会失真。这个指标能反映维护者是不是真的在接用户反馈。它也没有现成字段，需要自己用 events 或 comments 二次计算。

第三是维护者集中度，也就是 bus factor 的近似。用 /repos/{owner}/{repo}/contributors 拉贡献者列表，按 commit 数排序，看前两名或前三名贡献者的提交占比。如果前两名把绝大部分提交都包了，那这个项目很依赖极少数人。严格 bus factor 要算“损失多少人会导致项目停摆”，远比这复杂；所以我们只把它写成“前两名贡献者提交占比”这个近似值，不直接叫 bus factor。

从 API 抓到的两个样本

榜单第一项 morluto/rea 是 2026 年 4 月才建的新项目，热度高但历史太短，不适合当”健康度”的样本。这里改看 openclaw/openclaw —— 它排在第二，创建已近一年，既有规模也有足够的维护历史："stargazers_count": 39.4 万、"forks_count": 约 8.3 万、"open_issues_count": 约 7900、"language": "TypeScript"、"created_at": "2025-11-24"、"pushed_at": "2026-10-31"。这些是 GitHub API 返回的官方数据。它的 license.key 是 mit，也就是最常见的 MIT 协议，许可证这一项它没有拖后腿。

第二个仓库是 obra/superpowers，由用户账号 obra 维护，属于个人维护类型。它的 owner type 是 User，而 openclaw 是 Organization。这个差异本身就会影响维护者集中度：个人项目天然更接近 bus factor 等于 1。obra/superpowers 的公开元数据在 GitHub 的 repository API 里是完整的：stars 31.0 万、forks 约 2.8 万、open issues 约 380、主语言 Shell、创建于 2025-10-09，最近一次推送 2026-10-29。这些数字与它的仓库页展示一致（取自 2026-10-31 的 API 快照）。本文不讲完整榜单，只用排序最前的两个仓库把三个指标怎么算讲清楚 —— 榜单本身每月都会变，写死反而误导：

这个表里两个仓库的数字都来自同一次搜索接口调用 —— search API 返回的每个 item 里就带着 stargazers_count、forks_count、open_issues_count、language、created_at 这些字段，不需要再单独调仓库详情接口。要补的是分页：一次搜索默认只回 30 条，要拿完整榜得跟 Link 头翻页。

三个指标算出来是什么数

方法说完得看数。下面这三个仓库的指标是我用同一套 API 算出来的（GitHub API 快照，2026-10-31）：

算完了才能看出这三项为什么比 star 有用：

release 节奏差了一个量级。openclaw 最近 10 个 release 挤在 10 天里（2026-10-21 到 10-30，平均约 1 天一版），是持续迭代的节奏；superpowers 的 10 个 release 摊在约 4 个月里（2026-06-17 到 10-21，平均约 13 天一版，最大的一次间隔约 38 天）。同样的 star 数（39.4 万 vs 31.0 万），前者平均约 1 天一版，后者平均约 13 天一版 —— 对要跟着它走的使用者来说，这是完全不同的风险。

贡献者集中度是更刺眼的一项。openclaw 前两名贡献者占了约 75% 的提交，superpowers 是约 92%。后者只有 37 位贡献者（GitHub contributors 接口单页最多 100，这里远没到上限，所以是全量），前两名就占了九成以上 —— 这就是 bus factor 接近 1 的具体数字，而不是一句形容词。

issue 首响是三项里最直观的。openclaw 抽到的 6 个有评论 issue，首条回复全部在 7 分钟内（最快 2 分钟）；superpowers 同样抽 6 个，跨度从 1 分钟到 35 小时，中位数在 12 小时量级。openclaw 每天发版、issue 几小时内就有人接，是”有值班”的形态；superpowers 是”有空看一眼”的形态。

需要说明口径：GitHub 的 issues 接口把 PR 和 issue 混在一起返回（这里 100 条里 openclaw 有 87 条是 PR（真 issue 13 条）、superpowers 有 62 条是 PR（真 issue 38 条）），我按有没有 pull_request 字段把两者分开，只对真 issue 统计；样本只取最近 100 条里有评论的前 6 个，没评论的 issue 不算首响（否则会把”无人回复”当成慢响应）。所以这个数字是”有人回复的 issue 的首响速度”，不是”全体 issue 的响应中位数”—— 后者需要遍历更多页，成本高得多。

样本只有 6 个，为什么就报中位数？ 因为这 6 个不是挑出来的：脚本对最近 100 条里所有有评论的 issue 逐个取首条评论，按 issue 编号顺序取前 6 个（与表格口径一致），全部有效就全部报出来（两个仓库这次都是 6 个全过，没有中途丢弃）。样本小，区间就宽 —— 所以表格里给的是区间（0.1~35 小时）而不是一个精确到小时的数，中位数只用来判断”量级”（分钟级 vs 小时级），不当作精确统计量。

owner 类型差异在两者之间是反向的：openclaw 是 Organization（背后有公司投入，人员流动有交接），superpowers 是 User（个人维护，账号出问题项目就停）。star 数上后者只少两成，但稳定性上的差距远不止两成。

所以同一张 star 榜上，两个仓库看起来是同一量级的”热门 AI 项目”，实际的发版节奏和单点依赖风险差了不止一个数量级。这就是为什么本文说 star 筛不出健康度 —— 它筛的是注意力，而这三个指标筛的是项目还能不能靠得住。

可复跑的月榜脚本

下面是月榜的 Python 骨架，核心逻辑是：从官方搜索接口拿前 30，再逐个仓库拉 releases、issues、contributors，按前面定义的三个指标计算。代码只写关键路径，分页和限流逻辑用注释标出。

import requests

SEARCH_URL = "https://api.github.com/search/repositories"
HEADERS = {"Accept": "application/vnd.github+json"}

def top_repos(topic="ai", n=30):
    r = requests.get(
        SEARCH_URL,
        params={"q": f"topic:{topic}", "sort": "stars", "per_page": n},
        headers=HEADERS,
    )
    r.raise_for_status()
    return r.json()["items"]

# 对每个 repo，再调用 /repos/{owner}/{repo}/releases、
# /repos/{owner}/{repo}/issues（过滤 pull_request）、
# /repos/{owner}/{repo}/contributors 三个端点。
# 注意：未认证搜索 API 每分钟 10 次，核心 API 每小时 60 次；
# 完整榜单（几十个仓库）需要带 token，并按 response.headers["Link"] 处理分页；本文只演示前两项。

这个脚本每月固定时间跑一次，就能生成一张可比较的月榜。比如把 8 月和 9 月的 release 数、issue 首响中位数、前两名贡献者占比放在同一张表里，读者能直接看出一个项目是进入维护期、衰退期，还是还在高速迭代。它不是一次性分析，而是一个可以长期用的流量池。

这个口径不适合什么

这三个指标也会误判。新项目可能没有 release，但 main 分支每天都有提交，单看 release 会以为它不活跃。有些项目用 monorepo 结构，release 频率和具体子包的健康不一定一致。issue 首响中位数也受项目类型影响，库和应用的用户提问密度不同。贡献者提交占比只是 bus factor 的近似，如果两个人分工清晰、一个人休假另一个能顶上，占比高并不一定代表风险高。所以这张月榜更适合做筛查，不是审计。正式选型时，还是要进去看 issue 讨论质量、PR 合并速度、文档维护情况。

反方：这三个指标会被绕开

这三个指标可以被有意优化。比如，release 节奏可以通过”每两周打一个无变更的版本号”拉快；issue 首响中位数可以靠机器人自动回帖压低时间；贡献者提交占比可以通过拆分账户或合并 PR 时加注 co-authored-by 稀释。所以这张月榜不应该被当作安全审计，而应该被当作一个”看起来不像在演戏”的初筛——可疑的项目还是要进去看代码提交记录、PR 讨论质量、文档是不是三个月没更新。

如果做选型，建议把这三个指标的月榜当作”先排除再人工”，而不是”先信任再人工”。反之，如果是做榜单或推荐位，要把”指标可被绕过”这件事在说明页写清楚，否则读者会高估这份数据的判断力。

FAQ

Q：为什么不用 awesome-ai 这种精选清单？
精选清单是编辑过滤过的，覆盖广但缺乏时效性。本文这份月榜强调”按月重跑、口径不变”，读者可以把它和上个月的数据纵向比，看趋势；精选清单做不到这一点。

Q：issue 首响中位数 24 小时算好还是不好？
看项目类型。库类项目 24 小时内首响通常可以视为”有人盯着”；应用类项目 4 小时内首响才能说”维护活跃”。这张月榜先用 24 小时做统一基准，等读者用熟之后再按类型分层。

Q：贡献者提交占比超过 70% 就要警惕吗？
警惕比”超过阈值就 reject”更合适。如果一个项目 80% 提交来自同一个人，关键路径上的决定权就集中在那个人手上；如果他休假、生病或转项目，这个仓库的发版节奏可能立刻断掉。

参考来源

• GitHub Search API，topic:ai 按 stars 排序：api.github.com/search/repositories?q=topic:ai&sort=stars
• openclaw/openclaw 仓库主页：github.com/openclaw/openclaw
• openclaw 官网：openclaw.ai