GitHub 移动端看不到 commits 总数。

这不是大故障，甚至不像一个产品问题。但 Simon Willison 专门为它做了一个小工具：GitHub Repo Stats。发布时间是 2026 年 5 月 7 日。

输入一个 GitHub 仓库 URL，或者 owner/repo 这样的标识，它就在浏览器里调用 GitHub REST API，把仓库统计拉出来。

这事不大，但很准。一个成熟平台少放了一个数字，开发者就用 AI 补了一个自己的界面。

小痛点，撞上的是开源评估的硬需求

Willison 的动机很直接：他评估一个新 GitHub 仓库时，总会先看 commit 数。但 GitHub 移动端布局里没有这个数字。

commit 数不能等同于项目质量。提交多，可能只是改得碎；提交少，也可能是项目稳定。

但它仍然是第一眼信号。项目还活着吗？维护节奏怎样？历史沉淀有多长？这些问题，commit 数给不了答案，但能先给一个方向。

GitHub Repo Stats 拉取的统计项大致是这些：

统计项读者真正拿它看什么
commits、contributors活跃度、参与规模
branches、tags、releases版本管理是否成形
open PR、top contributors维护压力、核心贡献者集中度
language breakdown、license技术栈、使用边界
latest release、key dates最近是否还在维护

这对开源项目使用者很实用。尤其是在手机上临时看一个依赖时，不必等回到桌面端再判断。先看这些信号，再决定要不要继续读 README、issue 和源码。

对维护者也有提醒。用户不会只听项目自我介绍。很多时候，他们先看的是冷冰冰的维护痕迹。

“观其行”，比“听其言”可靠。开源世界尤其如此。

做法很轻，但工程判断不算粗

这个工具不是爬虫，也不是平台级产品。

它的路径很简单：用户输入仓库地址，前端用 fetch() 直连 GitHub REST API。统计总数时，不是逐页拉完再数，而是用 ?per_page=1 请求返回的 Link header 推导总页数。

这个细节重要。小工具也有笨做法和巧做法。逐页拉取是蛮力；读分页头是利用规则。

Willison 还贴出了生成提示词。大意是：给定 GitHub repo URL 或 foo/bar repo ID，通过 REST 或 GraphQL、CORS fetch() 获取仓库信息，包括 commit 数和其他有用统计。

这只能说明它是一次典型的 prompt-to-tool 实践。不能据此断言工具完全由 AI 自动完成，也没必要夸成“AI 替代开发”。材料只证明一件事：一个边界清楚的小需求，现在很容易被描述成工具。

限制也要摆出来：

现实约束意味着什么
它不是 GitHub 官方功能稳定性、维护节奏取决于个人工具作者
材料未说明工具本身是否开源不能默认它可审计、可自托管、可二次开发
浏览器端直连 GitHub API仓库请求主要发生在用户浏览器与 GitHub 之间，但仍受 API 限额、CORS 和接口变化影响
commit 数只是粗信号不能替代代码审查、社区治理判断和安全评估

如果只是偶尔查一个仓库，这些限制问题不大。若团队想把它放进正式选型流程，就不能只靠网页小工具。更现实的做法是：用它做快速筛选，再用 GitHub API、CLI、依赖扫描和人工审查做第二层判断。

这就是它的位置。轻，不等于万能。

AI 小工具的价值，是降低“不顺手”的容忍度

我更在意的不是 GitHub Repo Stats 功能有多新，而是它暴露了一个变化：开发者对小摩擦的忍耐阈值正在下降。

过去这种问题大多会被放过去。移动端看不到 commits？那就回桌面端，或者点进 API，或者算了。

现在不一样。一个需求边界足够清楚，就可以当天变成工具。

这对经常用 AI 写脚本、写小网页、写内部工具的开发者很具体：别只拿 AI 去复刻大产品。更有效的用法，是把每天重复三次的小麻烦写下来。

比如：

  • 查仓库活跃度；
  • 批量整理 issue；
  • 把 API 返回转成表格；
  • 给内部依赖生成一页健康度摘要。

这些都不宏大，但能省时间。省下来的不是一次惊天动地的开发成本，而是反复被打断的注意力。

平台当然有自己的界面取舍。移动端空间有限，不可能把所有统计都铺出来。GitHub 不是没有数据，只是没有把这个数字放在那个位置。

但平台不展示，不代表用户不需要。

这类工具会越来越多，不是因为每个都重要，而是因为做出来太便宜。它们更像早年的浏览器用户脚本、命令行小工具、Excel 宏，只是生成门槛更低。

历史上很多工具革命都从边角开始。PC 早期杀进办公室，不是靠宏大叙事，而是靠表格、排版、账目这些具体活。今天的 AI 小工具也类似。不完全一样，但重复的是同一种人性：人会为省掉一个烦人的步骤而改变工作流。

接下来真正该看两个变量。

一是这类个人工具会不会补上缓存、导出、token 管理和团队共享。补不上，它就是个人便签；补上了，才可能进入团队流程。

二是 GitHub 这类平台会不会把被频繁外部补洞的信号重新放回界面。平台界面不是中立陈列，它决定用户第一眼看什么，也决定哪些判断被鼓励。

GitHub Repo Stats 很小。小到不值得神化。

但它提醒了一件事：AI 编程的锋利处，往往不在发布会上，而在一个开发者突然决定“不再忍这个破步骤”的那一刻。