GitHub 打榜、冲 star，到底有没有正经做法？

投放窗口内，增速从 70/天 涨到 121/天

这场投放前后，项目的 star 增速长这样 —— 数据来自 Wayback Machine 的公开档案快照，任何人都能复核。两个地方值得盯着看。

1/ 窗口内增速接近翻倍。这一段里，v1.0.0 发布、官方内容、创作者爆发压在同一段时间 —— 发布节奏和投放对齐，本来就是这场的打法，后面 Trending 一节会讲为什么这么排。

2/ 平常的速度是什么样：窗口外的四个时段，日增都在 29 到 70 之间；窗口内是 121，对着 4 月基线看是 4 倍多。

这场投放是两场 campaign、两百多位创作者、合计 270 万有效曝光。达人内容集中爆发了十二天，7 月初的档案快照正好捕捉到峰值段。GitHub 那一侧我们没有做任何操作 —— 没买一颗 star、没配一个 fork，涨出来的量全部是内容带过去的自然转化。

X 联动为什么对 GitHub 有效

开发者不点广告，但开发者刷 X。

这一场里真正打穿的内容，全是一个类型：创作者拿这个项目重构自己的工作流，把过程写成实操长文。最高的一条保姆级教程 37 万次浏览，还有一条架构长文 24 万。

这类内容带来的 star 和广告带来的点击是两种东西。用户的真实路径往往是：刷到教程 —— 截图转发到群里 —— 几天后自己打开 repo 点了 star。中间隔着你追踪不到的转发，但落点是真实的开发者，star 后面跟着 fork、issue 和真实使用。

另一个规律：分发是头部游戏。两场加起来，曝光的一半以上来自前十条帖。所以我们配盘的时候，先留几个位置给能出头部帖的人，剩下的位置把基础盘的量铺够。这套配法我们在 另一篇里写过了。

GitHub Trending 的玩法规律

冲 star 绕不开 Trending。GitHub 不公开 Trending 算法，以下是从公开行为反推、加上我们实操的规律，当参考不当保证。

1/ Trending 看增速不看总量。榜单按日、周、月滚动，比的是这个窗口里新增的 star，几万 star 的老项目增速平了照样上不去，几百 star 的新项目一天爆几百就能上。这对新项目是好事。

2/ 分语言榜比总榜好上。总榜要跟全平台卷，Python、TypeScript 这种大语言的分榜也很卷，但你的项目如果主语言相对小众，分榜的门槛低得多。上了分榜同样有展示位。业内同行给过我们两个数据点：有客户增量不大，上了自己语言的日榜；也有项目 launch week 连着三四天单日 500 多 star，总榜照样没上。

3/ 集中打比平摊打有效。同样一千个 star，摊在一个月里什么都不是，压在两三天里就是一次 Trending。所以发布节奏和内容爆发要对齐：版本发布、创作者集中发帖、官方转发，挤在同一个窗口里。我们那场的爆发期就是十二天，不是把预算摊满整个合同期。

4/ 上榜本身有复利。Trending 是 GitHub 站内最大的自然分发位，而且不止站内：各内容平台的聚合号和 bot 会自动抓榜转发。上榜带来第二波 star，第二波又延长在榜时间。我们冲榜冲的就是这第二波，榜单截图本身没什么用。

5/ 流量承接的重要性。流量到 repo 那一刻，README 有没有 30 秒讲清楚这是什么、quickstart 能不能跑通、issue 有没有人回 —— 决定 star 转不转化成用户。冲榜前先把 repo 收拾好，这是成本最低的一步。

买假 star 呢？

市面上确实有直接卖 star 的。问题有三个。

假 star 的特征太好认：同一天注册的小号、零活动记录、star 了你还同一天 star 了另外两百个仓。开发者圈看 star 曲线有的是工具，一根笔直的竖线配上零 fork 零 issue，等于当众承认造假。还有个粗糙但好用的体检：健康仓库的 fork 通常在 star 的一成上下 —— star 上万、fork 只有十几个的仓，不用看曲线也知道怎么回事。

GitHub 也在清理，而且是按周期扫的，一周到一个月不等。更麻烦的是，清扫的警戒线按仓库各算各的：买量买多了，这个仓库的阈值会被拉高，之后连真实用户都容易被误伤 —— 同一个刚注册、还没什么活动记录的账号星了两个仓库，干净的那个留得住，买过量的那个直接被清掉。

最实际的一条：假 star 不带任何下游。没有 fork、没有 issue、没有人在 X 上聊你。而上面那条真实曲线里，star 的旁边是同窗起量的关联仓库和 X 上的实操讨论。投资人和用户去核的就是这些。

怎么跟老板和投资人说这个数

star 的增长几乎都发生在内容平台之外，中间隔着大量群聊转发，精确到单条内容的归因做不到，硬做就是编数字。

诚实又有说服力的说法是：以投放窗口为界，报「窗口内 star 从 X 涨到 Y，增速是窗口前的多少倍，窗口后回落到多少」，把同期的产品发布和官方动作如实列上。数字全部可以用 Wayback Machine 这类第三方档案复核 —— 我们给客户的报告就是这么写的。

自己留档有个趁手的工具：repo 的 Insights 里有个 Traffic 面板，访问量按渠道拆开（X 来了多少、Reddit 来了多少），只有仓库管理员能看，而且只显示最近 14 天 —— 投放期间记得定期截图。也要说清它的边界：它监控的是谁来看了，从看到点 star 这一步没有任何工具能监控；所以它适合内部留档，对外举证还是靠 Wayback 这类第三方档案。