手机震了一下GitHub 的 Follower 列表里多了一个新头像下角显示的数字刚好跨过 2w 这条线。说实话盯着这个数字看了好一会儿心里挺复杂。我从 2017 年开始认真做开源头三年最火的仓库也就几百个 StarFollower 更是常年停留在三位数。后来陆续做出几个被大家记住的工具才慢慢摸清楚涨星、涨粉到底是怎么一回事。先说一个可能不那么顺耳但很真实的结论涨 Star 这件事跟你代码写得好不好关系远没有你以为的那么大。真正起作用的是传播和信任这两件事——让目标用户知道你、看懂你、信你。这篇文章我不打算讲什么大道理就把我这些年踩过的坑、验证过有效的方法整理成 10 个技巧拆开讲。适合谁看仓库里躺着几个项目但 Star 和 Follower 一直涨不动的开发者正准备开源自己的工具或库想让更多人用起来的人想靠 GitHub 建立技术影响力反哺求职或接单的人1. 先把为什么别人会点Star这件事想明白1.1 Star不是点赞是收藏背书的组合动作很多人对 Star 有个误解觉得它像微博点赞用户看完觉得牛就点一下。实际完全不是。一个访客从打开你的仓库到点下 Star中间经历了一次非常脆弱的心理决策这次决策大概是这样的这项目能解决我的问题吗好像能。我以后会用到吗也许。作者看起来靠谱吗README 挺完整还有动图靠谱。那点个 Star 收藏一下也当是鼓励作者。注意收藏这个属性远比点赞重要。用户点 Star 的深层动机是这个项目我现在用不上但以后可能用得上先存着。所以你可以粗略地把 Star 理解为零成本收藏夹 对作者的微薄鼓励它不需要用户付出任何实际成本但也正因为如此用户对值不值得收藏的判断非常苛刻。我统计过自己几个仓库的访问转化率100 个访客里通常只有 1 到 3 个人会点 Star。那些看起来很火的仓库实际上都经历了大量访客的看完就走。想清楚这个逻辑之后你不会再纠结为什么我项目不错就是没人给星而是会去思考另一个问题访客打开仓库的头 30 秒里我有没有让他收藏的想法冒出来1.2 Follower涨的是信任不是流量Star 和 Follower 是两个完全不同的增长逻辑。Star 是一次性投票用户为某个瞬间的认可付费Follower 则是持续关注用户愿意关注你本质上是在说我相信你以后还会产出有意思的东西我不想错过。我自己的 Follower 曲线很有意思。前几年几个仓库加起来几千 Star 的时候Follower 只有一千不到。后来有一段时间我集中写了系列技术文章把项目背后的设计思路和踩坑过程全讲了一遍那一年 Follower 涨得比 Star 还快。原因很简单文章带来的访客不是冲着某一个仓库来的而是冲着这个人的思考方式来的认可你这个人自然就关注了账号。所以请记住这句话Star 是项目的资产Follower 是账号的资产。如果你只想要 Star把项目做好就够了如果你想要 Follower你得让自己成为持续被关注的理由。这也是我下面 10 个技巧里后半段内容更偏向运营和个人品牌的原因。2. 10个涨星技巧速览先拿目录再听我细讲为了让你有个整体框架我先把 10 个技巧列成表格。这些技巧不是按重要性排序而是按一个开源项目的生命周期排序从动工写代码之前、到发布、再到后续长期运营每个阶段有每个阶段该做的事。序号技巧一句话说明性价比1做工具别做玩具解决真实痛点的小工具远比炫技 demo 更受欢迎极高2README 首屏放动图用一段 gif 让用户 3 秒看懂项目价值极高3命名与一句话定位让人搜得到、记得住、转得出去高4文档和示例跟着第一版一起发第一版就能上手不给用户增加任何摸索成本高5把握首发 72 小时在目标用户聚集的地方集中曝光争取种子用户高6生态位打法给成熟生态做插件/周边借势而不是造势中高7技术社区内容反哺把踩坑和解决思路写成文章反向引流到仓库中高8认真经营 issue 与 PR用贡献者体验换长期口碑这是 Follower 增长的暗线中9经营个人主页门面profile README 就是你的开源简历放大每次曝光中10长期主义持续迭代稳定版本节奏让关注者觉得关注你不亏长期下面前三个技巧我会把重点放在写代码之前和打开仓库的前 3 秒上。原因很简单项目还没被看见时谈引流没有意义用户已经点进来时谈代码质量也来不及了。3. 技巧1-3项目的火体质是在写代码之前就决定的3.1 技巧1做工具别做玩具我自己就走过弯路。早期特别喜欢写一些炫技的东西为了展示对某个新框架的理解我写过一整套用那个框架实现的某某管理系统 demo还精心写了动画和炫酷的 UI。结果呢发出去两个月总共 40 多个 Star还有 10 个是朋友捧场。原因很扎心因为我自己都不会把它用在真实项目里。后来我转变思路专门做我自己每天都在用的东西。那会儿我天天要在命令行里处理一批格式乱七八糟的日志手动清洗特别烦就顺手写了个小工具把读取-清洗-统计-输出做成一条命令。写的时候完全没想过要火纯粹是自己用着爽。结果发到 GitHub 后Star 涨得比之前所有炫技项目加起来都快。为什么因为一个工具只要是你自己真实痛点催生出来的它就天然具备三个火体质它解决的是真实问题不是想象出来的问题——用户拿过去就能用而不是这玩意看起来挺酷但跟我有什么关系它不会过度设计——你只写了你需要的功能使用路径短上手成本低你愿意持续维护——因为你自己在用掉了坑会修需求变了会迭代用户看到的是一个活着的项目怎么找到这种工具型项目我给一个特别笨但特别有效的办法记录你一个月内重复做过 3 次以上的手工操作。解析日志、批量改文件名、生成格式化的接口文档、把一种格式转成另一种……任何一个让你觉得这破事怎么又要做一遍的场景都是潜在的开源机会。3.2 技巧2README首屏动图3秒讲清这项目有什么用GitHub 上 90% 的访客是通过 README 了解一个项目的。你的 README 首屏本质上是一块广告牌而大部分人的广告牌上写的是这是一个用于某某场景的某某工具再加上几段冷冰冰的功能描述。用户扫一眼看不懂走了。我实测下来在 README 顶部放一段 15 秒以内的操作动图是对 Star 转化率提升最明显的一个改动。人的视觉系统对动态画面的敏感度远高于静态文字一段在终端里敲一条命令、几秒后看到漂亮输出的 gif比一千字描述都管用。访客根本不用读文字看一眼就知道这项目是干嘛的、用了之后是什么效果、我能不能用。做动图这事门槛不高我分享下我的操作流程先在一个干净环境里装好自己的工具想好一个完整的 demo 场景用录屏工具开始录制终端字号调大一点关键输入操作可以稍微放慢把录制好的视频压缩成 gif控制在 10-15 秒重点展示输入命令→看到效果的过程放在 README 的第一张图上下面紧跟快速开始命令这里有个细节要注意动图里的环境和命令必须和 README 里的快速开始完全一致。如果动图里跑的是my-tool run demo但快速开始写的是my-tool start用户照着敲完发现不一样信任感当场崩盘。我自己就犯过这种低级错误后来专门加了个流程每次更新 README 动图必须照着快速开始的命令完整跑一遍。3.3 技巧3命名和一句话定位决定了搜索流量曾经在 GitHub 上搜过关键词的人都有经验搜索结果里仓库名和描述带有关键词的更可能被点进来。所以你的项目名和 README 开头那句话不应该拍脑袋而应该当成 SEO 来做。命名方面有几个方向可以参考描述性命名convert-json-to-csv这种一看就知道干嘛的搜索匹配度极高短词品牌化命名比如pandoc、yargs这种好记好念适合想长期做大的项目前缀式命名vue-router、react-query这种借生态关键词搭索引但无论哪种命名你都得在 README 的第一行H1 标题写清楚一句话定位。我自己有个公式一句话定位 一个动词 目标对象 核心价值举例来说一个用来解析 xxx 并自动生成 yyy 的命令行工具支持 zzz 格式——这比你写一个优雅高效的现代化工具强一百倍。优雅高效是形容词用户无感解析 xxx 生成 yyy是画面感用户瞬间就懂。还有个小技巧README 的 Title 和 Description 里最好把用户搜索时会用的关键词覆盖到。比如你做的是一个 Node.js 的模板引擎Description 里至少要包含Node.js、template engine这类词而不是只写个花哨的标语。这些关键词决定了你在 GitHub 搜索、Google 搜索里的自然流量这部分的访客质量极高——他们是带着明确需求来的。4. 技巧4-6发布冷启动把项目从做出来推向被看见4.1 技巧4文档和示例跟着第一版一起发太多人犯这个毛病代码写完了往 GitHub 一推README 就写了两行字然后跑去各大社区发帖我写了个 XX求 Star。这就像你想请人吃饭结果厨房做好了菜餐厅门口连路牌都没立客人进门后连菜单都看不清。第一印象决定用户留下来还是关掉页面而第一印象的核心就是文档的完整度。我不是说第一版就要写出几十页的正式文档但以下几个东西必须有快速开始三条命令以内能跑起来直接复制粘贴可执行不要让人去翻文档查依赖一个完整示例在 example 目录里放一个可以直接跑的最小案例环境要求写明 Node 版本、Python 版本、操作系统兼容性省去一半的 issueFAQ 或常见问题哪怕只有两三条也能极大降低用户的试错成本我印象很深的一件事有个用户后来给某个项目提了 PR他说自己就是照着 example 目录跑通之后才决定深入研究并提交代码的。你看示例目录不只是给用户用的它还是贡献者的入门通道。一个连示例都没有的项目别人想给你贡献代码都不知道从哪下手。4.2 技巧5首发72小时渠道和时机的组合拳发布是所有环节里最有杠杆效应的一步。一个项目发布后的 72 小时基本决定了它的初始势能被多少人看到、被多少人试用、有没有人帮你传播。这一步如果做得好项目能在几天内积累起第一批种子用户做不好项目就可能永远躺在仓库列表里沉底。我用的首发组合是这样的按时间排序发布前准备好一切README 最终检查、动图、示例、LICENSE、release 发布说明一个都不能少挑选目标社区海外项目发 Hacker News、Reddit 的相关板块、X/Twitter中文项目发掘金、知乎、V2EX、公众号视受众而定发布文案要点不要把标题写成我写了一个 XX 框架要写成我用 XX 解决了 XX 问题附工具。前者是自嗨后者是在给读者提供信息增量前 3 小时的反馈要盯紧有人提 issue 或者评论第一时间回复这种主人随时在线的感觉会极大影响围观者对这个项目的判断时机方面如果目标是海外用户我一般在北京时间晚上 10 点到次日凌晨 1 点之间发正好对应欧美早上那边一醒来就能看到如果目标是中文用户选工作日上午 10 点或者晚上 8-10 点避开午休和通勤时间。这个看着是小细节实际影响很大内容再好发在错误的时间段也可能淹没在信息流里。4.3 技巧6生态位打法借势而不是造势很多开发者有个执念一定要从零做一个颠覆性的新框架。但现实是无情的——生态成熟领域里一个新框架想从零起步难度不亚于在已经挤满人的赛道里再开一条路。我自己后来特别推荐的思路是生态位打法。什么意思就是当一个主流的框架、语言或平台已经聚集了大量用户时你不要试图做一个更好的它而是去做它生态里缺失的那块拼图。比如主流 CLI 工具缺一个可视化配置界面你做一个热门框架缺某个中间件或插件你写一个某个数据格式缺一个好用的转换器你补上这类项目的天然优势是目标用户已经存在且极度精准你不需要教育市场只需要被他们发现。我做过一个某主流框架的配置面板上线后几乎没有主动推广就靠挂在相关 Awesome 列表和官方文档里被引用了两次之后很长一段时间里每天都有自然流量进来。当然生态位打法也有风险你做的功能很可能被官方收编。所以选方向的时候尽量挑那些官方大概率不会做、但生态用户又真实需要的小工具、适配层、增强插件。这类项目可能没办法让你一夜之间获得几万 Star但它的 Star 和 Follower 转化率通常很高因为用户是被精准需求吸引来的。5. 技巧7-9从项目热度到个人影响力Follower增长的真正引擎5.1 技巧7技术社区的内容反哺如果只能挑一个从项目 Star 到账号 Follower的关键转折点我会选技术社区的内容输出。项目本身不会说话但文章会替你说话而且文章说的不是我这个项目多好而是我是怎么思考和解决问题的。我的做法很简单每做完一个稍有点技术含量的项目或者项目里遇到一个值得写的坑我都会写一篇技术文章发布到对应的开发者社区。文章内容围绕遇到的问题→排查过程→解决思路→最终工具化方案展开文末再自然带一句这个思路我已经做成工具开源了仓库在这里。注意是自然带一句不是硬广。如果文章真的有价值读者会对工具产生好奇心自己就会点过去。这种方式的奇妙之处在于它带来的访客质量远高于社区里刷到帖子的人。这些人是带着这个作者思考问题的方式不错的印象来的他们看完仓库之后很大概率会点 Follow 而不是只点 Star。我统计过来自技术文章访问的页面Follow 转化率差不多是直接浏览仓库的 3 到 4 倍。5.2 技巧8把issue和PR当成产品来做很多维护者把 issue 区当成客服区能不理就不理能拖就拖。但我想换个角度issue 区是你这个项目最真实的产品演示区。一个潜在用户点开 issue 列表看到的是你如何对待用户、如何解决问题。如果每一条 issue 都有人认真回复他会觉得这个项目有人管值得用如果 issue 列表里全是过期无人认领的问题他会转身就走。新手提的 issue 质量可能很差甚至明显是用户自己的环境问题。这种情况也值得认真回复。我记得有一次一个用户提了个报错我陪他排查了一个晚上最后发现是他本机环境变量没配对根本不是代码的锅。但正是这次交流让这个人成了项目最积极的传播者后来他在好几个平台主动帮我说了不少好话。PR 这边也一样。有人提 PR尽量在 24 小时内给反馈。哪怕不能立刻合并也要明确告诉对方预计什么时候看、还需要什么补充。合并之后记得在 release notes 里谢一句贡献者的名字。每一个 PR 贡献者都是你潜在的忠实 Follower因为他已经为项目付出了实际时间。这里我可以给你一个非常具体的建议把 issue 模板写好环境、复现步骤、期望行为、实际行为四段式。好的 issue 模板能筛掉大量无意义的问题维护者省心项目页也更专业。5.3 技巧9GitHub主页的门面工程用户因为某个项目点进你的账号主页这是每一次曝光的必经之路。如果你的主页看起来像一个半废弃的空账号用户大概率直接划走如果你的主页让人一眼看到这人是谁、做开源多久了、还有哪些值得看的东西Follow 的意愿会高很多。GitHub 个人主页支持通过创建一个和用户名同名的仓库来自定义 README这个区域我建议认真设计至少包含四个信息你是谁一句话自我介绍别整花活儿你做过什么挑 3-4 个最有代表性的项目用 pinned 固定在主页你的技术方向可以放几个技术栈标签但建议克制别搞成徽章墙你的其他输出阵地个人博客、公众号、X 账号愿意公开就放上去我改完主页之后有一个很直观的感受Follower 增长速度明显快了。因为用户看完你某个项目之后会在主页上看到你还有别的项目、别的方向那种这个人还会继续产出的预期会让他做出 Follow 的决定。我把主页理解为一个人形简历每一次别人点进你的头像都是一次面试机会。6. 技巧10长期主义以及两个我劝你务必避开的坑6.1 技巧10用稳定的版本节奏维持细水长流的关注最后一条技巧它不产生爆炸性的增长但它是前面所有技巧的地基。说实话我的 2w Follower 里绝大多数不是某一个爆款项目带来的而是几年下来这个人一直在做东西这个印象积累出来的。长期主义不是要你热血上头天天憋大招而是建立一个低成本的持续产出节奏。比如每个主力项目保证至少一个月有一次 release哪怕只修一个小 bug每次 release 写清楚 changelog让用户感觉到项目活着如果有两个以上项目主次分明不要每个都做一版就扔如果一个项目确实决定不再维护在 README 里写明 archived 状态并推荐替代方案别让仓库无声无息地死掉为什么持续在场这么重要因为 Follower 本质上是一种预期管理。用户关注你是期待你下一次产出。每一次 release、每一篇技术文章、每一条认真的 issue 回复都是在兑现这种期待。久而久之你的账号在用户心里就成了一个稳定产出高质量内容的标签。到这时候你再发新项目天然就有一批观众等着看冷启动的难度会小一个量级这就是我在标题里说的关注突破 2w的真正价值所在——它不是一个数字而是一个放大器。6.2 避坑1千万别刷Star这个话题我必须专门拿出来说因为它太容易被诱惑了。某个项目刚发布数据惨淡这时候有人跟你说几百块可以刷几百个 Star先帮你把面子撑起来——我劝你放弃这个念头原因有三点刷出来的 Star 是死的不会转化为 Follower、issue、PR、真实用户。你会陷入数字焦虑而不是把精力放在真正重要的事情上GitHub 的风控机制会清理异常增长一旦被识别轻则删除 Star重则封号这是一票否决的污点。开源社区很小这种事传出去你的技术信誉基本归零。一个靠刷量起家的账号根本无法获得社区真正的尊重还是那句老话真正的增长没有捷径。访问量、Star、Follower、PR、issue这些指标会以它自己的节奏增长你要做的是把项目做好然后把每一件该做的事做扎实。6.3 避坑2改名、删库和License变更请三思而后行这是几个看起来是自由、实际会伤害信任的操作。我见过不止一个项目本来 Star 还不错作者一冲动改了仓库名结果旧链接全部 404搜索引擎里的流量全部作废还有项目作者直接把仓库删了评论区一片为什么啊我存着还没用呢的哀嚎更有一些 License 说改就改的项目直接引发了社区的强烈反弹。我给的建议是改名早期没用户时随便改有 Star 有用户后尽量保留一个旧名字的 redirect并在 README 里加一句本仓库已迁移到 xxx删库与其删库不如 Archive。存档的仓库依然能访问代码依然能看但状态一目了然。这是对所有点过 Star 的用户的基本尊重License 变更如果从宽松协议改成严格协议至少要说明原因并给旧版本预留过渡期不要在 release 里直接替换这些操作的共同本质是你仓库里每一个 Star、每一个 Follower都是一个人对你付出的时间。你可以不维护了但你不该让这些人觉得自己的一键支持是一个错误决定。最后说点掏心窝的。回头看这条从三位数到 2w 关注的路我最大的体会是涨星和涨粉本质上都不是技术题而是信任题。你写代码解决自己的问题顺手帮别人省了时间这是 Star 的来源你持续地把做事的过程、踩坑的经验、思考的方式摊开来给别人看别人信你这个人这是 Follower 的来源。如果你现在正盯着一个只有几个 Star 的仓库发愁别焦虑也别想着走捷径。先去把一个工具做到自己每天都想用把 README 第一屏的视频和文字改清楚再去认真回复第一个提 issue 的人。这些东西看着不大但几年之后回看你会发现全部增长都长在这些不起眼的功夫上。
