opencode STATS.md 深度解析GitHub / npm 双渠道下载统计的自动化流水线【免费下载链接】opencodeThe open source coding agent.项目地址: https://gitcode.com/GitHub_Trending/openc/opencodeSTATS.md是 opencode 仓库根目录下的下载量统计档案按天记录 GitHub Release 与 npm 两个分发渠道的累计下载量及日增量最新一行2026-01-29总下载量已达 10,190,453。本篇围绕这张统计表展开先讲清表格每一列的口径与读法再结合 统计脚本 和 定时工作流 还原数据从哪里来、差值怎么算、文件怎么写回仓库的完整链路最后基于表内真实数据解读增长拐点、渠道占比变化以及缺失/重复行背后的原因。STATS.md 的表格结构与读数口径统计表是一张四列的 Markdown 表格自 2025-06-29 起每天追加一行列含义口径说明Date统计日期脚本执行当天取new Date().toISOString().split(T)[0]的 UTC 日期GitHub DownloadsGitHub Release 资产累计下载量所有历史 release 全部 asset 的download_count之和npm Downloadsnpm 包opencode-ai累计下载量2020-01-01 至当前年份 5 年区间的逐日下载量求和Total两渠道之和GitHub npm每个数字后面括号里的增量如58,209 (0)、10,190,453 (386,234)是相对上一行的日环比变化。首日增量为0因为脚本在文件不存在或解析不到上一行时把基线记为 0。两个数字都不是当日新增而是累计值GitHub 侧遍历全部历史 release 求和npm 侧查询的也是全量历史区间因此两列天然单调递增日增量只反映当天采集时点上累计值比上一次采集时点多了多少。这一点在解读异常行下文时很关键。数据采集流水线从 API 到一行 MarkdownSTATS.md不是人工维护的由一条 GitHub Actions 工作流每天自动驱动。整条链路涉及三个文件工作流定义、采集脚本、以及被写入的 STATS.md。定时触发与提交机制工作流定义在 .github/workflows/stats.yml触发方式schedule使用 cron 表达式0 12 * * *即每天 12:00 UTC 运行一次同时开放workflow_dispatch允许手动触发。仓库守卫if: github.repository anomalyco/opencode只在主仓库生效fork 中不会执行。并发控制concurrency: ${{ github.workflow }}-${{ github.ref }}同一分支上上一次运行未完成时新运行会被去重避免同一天产生多笔重复统计下文会出现的重复日期行就与此类机制的边界情况有关。权限仅授予contents: write用于把新行提交回仓库。运行环境blacksmith-4vcpu-ubuntu-2404自建 runner。核心步骤只有两步执行bun script/stats.ts然后以GitHub Action身份提交git config --local user.email actiongithub.com git config --local user.name GitHub Action git add STATS.md git diff --staged --quiet || git commit -m ignore: update download stats $(date -I) git push注意提交信息前缀是ignore:这类消息通常会被 changelog 工具自动排除避免每日更新统计污染发布日志。另外POSTHOG_KEY以 secret 形式注入用于脚本末尾的指标上报。数据源一GitHub Releases API脚本 中fetchReleases()负责拉取 GitHub 侧数据分页请求https://api.github.com/repos/anomalyco/opencode/releases?pageNper_page100每页 100 条每页之间await new Promise((resolve) setTimeout(resolve, 1000))人为限速 1 秒规避 API 频率限制直到某一页返回空或不足 100 条为止把所有 release 汇总返回。随后calculate()遍历每个 release 的全部 assets累加asset.download_count得到该 release 的下载量再对全部 release 求和得到 GitHub 侧累计值。这里统计的是Release 资产下载各平台二进制安装包等不含npm渠道也不含源码压缩包以外的其他资产来源。数据源二npm Downloads APIfetchNpmDownloads(opencode-ai)调用 npm 官方统计接口https://api.npmjs.org/downloads/range/2020-01-01:{当前年份 5 年}-12-31/opencode-ai脚本注释明确写了这样设计的原因Use a range from 2020 to current year 5 years to ensure it works forever——把结束日期设为当前年份加 5 年保证日期范围永远是过去到未来脚本无需随年份维护。返回值是逐日downloads数组脚本用reduce求和得到opencode-ai包的全量累计下载量。失败时仅打印 warning 并返回 0不会中断整个流程。写回逻辑解析上一行、算差值、追加save(githubTotal, npmDownloads)是 STATS.md 表格逐行增长的直接来源逻辑值得逐段看见 script/stats.ts#L125-L189定位上一行读取现有STATS.md从文件末尾向前逐行扫描用正则匹配第一个数据行/\|\s*[\d-]\s*\|\s*([\d,])\s*(?:\([^)]*\))?\s*\|\s*([\d,])\s*(?:\([^)]*\))?\s*\|\s*([\d,])\s*(?:\([^)]*\))?\s*\|/正则把千分位逗号、可选的括号增量都做了容忍处理取出 GitHub / npm / Total 三个上一期累计值文件不存在或没有匹配时三者回退为 0。计算增量githubChange githubTotal - previousGithubnpm 与 total 同理。格式化累计值用toLocaleString()加千分位增量为正时写成(1,338)为负时写成(-x)为 0 时写成(0)。兜底建表若文件中找不到# Download Stats标题会先补上表头再追加新行最后跑bunx prettier --write统一表格对齐——这正是 STATS.md 里列宽整齐的原因。上报脚本末尾向 PostHog 发送两条download事件source: github与source: npmdistinct_id固定为download用于在分析平台侧观察下载趋势。没有POSTHOG_KEY时仅打印 warning 并跳过。这套末尾扫描 正则解析的设计是刻意的脆弱-鲁权它不依赖数据库或临时文件只依赖 STATS.md 自身作为状态存储即使 workflow 重跑、环境重建也能延续序列。数据解读增长曲线、渠道拐点与异常行基于 STATS.md 现有 200 余行数据2025-06-29 至 2026-01-29可以读出几个有依据的事实性结论。关键里程碑日期Total事件2025-10-191,005,287总下载量首次破 100 万2025-12-102,017,599首次破 200 万2026-01-145,214,290首次破 500 万2026-01-2910,190,453首次破 1000 万表内最后一行从 100 万到 200 万用了约 52 天而从 500 万到 1000 万只用了 15 天2026-01-14 到 2026-01-29增长显著加速。单渠道最大单日增量出现在 2026-01-16GitHub 单日 552,622Total 单日 661,678是表内最高峰。渠道结构GitHub 在 2026-01 反超 npm表内两列的相对位置随时间发生了一次明确翻转2026-01-05 及以前npm 列始终大于 GitHub 列如 2026-01-05GitHub 1,738,171 npm 1,353,043 不成立除外实际 2026-01-05 为 GitHub 1,738,171 / npm 1,353,043GitHub 已略高。以 2026-01-06 为表内首个明确反超日GitHub 1,960,988单日 222,817对比 npm 1,377,37724,334此后再未回落。到 2026-01-29GitHub 渠道累计 7,815,471占比约 77%npm 渠道 2,374,982占比约 23%。从渠道含义看这反映安装方式向直接下载 Release 二进制各平台原生安装包倾斜具体原因发布节奏、安装引导变化等仓库内没有直接记录此处不下结论。异常行缺失日期、重复行与 0统计表本身就是流水线运行日志几处异常恰好印证了上文机制缺失 2025-07-07表内从 07-06 直接跳到 07-08说明当天 12:00 UTC 的运行未产生提交当天未执行或被并发控制丢弃。缺失 2025-10-1310-12 到 10-14 之间无行且 10-14 的增量是 13,005/10,541接近两个日期的累计量符合补记特征。2025-08-27 / 08-28 npm 列 0GitHub 列照常增长而 npm 列纹丝不动可推断这两天 npm 统计接口返回的累计值与前一天相同npm 官方计数存在延迟或波动并非脚本故障——脚本对接口失败会返回 0 并打 warning而 0 与前一值相减不会出现 0 且总量仍在增长的情况。2025-10-30 出现两行同日两行分别为 (613,746 / 542,064) 与 (617,846 / 555,026)是当天两次执行例如手动workflow_dispatch叠加定时触发或重试各追加了一行由于脚本总是追加而非覆盖当天行重复执行会留下双行。这也解释了为什么第二行的增量是相对第一行算的。这些异常不影响累计值的单调可信性但提醒读者STATS.md 的每一行对应某次采集时点而非严格的自然日快照。延伸与 packages/stats 统计站点的区别仓库中另有一个同名易混的模块 packages/stats它是独立的统计站点SolidStart 前端 Effect/Drizzle 数据层 Lambda面向的是推理请求、token 用量、成本等运行指标数据由 infra/stats.ts 部署到stats.域名下与本文的下载量统计是两套互不相关的体系本文的 STATS.md 链路GitHub Releases API npm API →script/stats.ts→ 根目录 Markdown 表格packages/stats站点链路Iceberg 事件表inference.event→stat-sync守护进程每小时聚合 → PlanetScale 数据库 → SolidStart 站点。从 packages/stats/server 的同步守护进程 可以看到其每日一次全量刷新 每小时增量的策略但那属于运行指标域与下载统计无关读者如需运行统计站点可参考其 AGENTS.md在仓库根目录执行bun dev:stats即可本地启动。小结STATS.md 的四个数字口径GitHub 全 release 资产累计下载、npmopencode-ai全量累计下载2020 起、两者之和、以及相对上一采集时点的日增量。生成链路完全自动化.github/workflows/stats.yml每天 12:00 UTC 触发 →script/stats.ts分页拉取 GitHub Releases每页 100 条、间隔 1 秒并查询 npm range API → 从文件末尾正则解析上一行 → 追加新行 → prettier 格式化 → 以ignore:前缀提交并推送同时向 PostHog 上报两条download事件。数据本身可读性良好总下载量从 2025-10-19 破百万到 2026-01-29 破一千万2026 年 1 月中旬 GitHub 渠道日增量多次超过 npm 数个量级渠道占比翻转至约 77% / 23%缺失日、0 日与重复日都是流水线时点行为的直接记录可按上文机制逐条归因。复用这套模式时关键设计点是用被统计文件自身作为状态存储只解析最后一行即可恢复基线无需额外基础设施代价是异常行重复/缺失会留在文件中作为历史痕迹。【免费下载链接】opencodeThe open source coding agent.项目地址: https://gitcode.com/GitHub_Trending/openc/opencode创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
