一个开源项目怎么连续5天上GitHub Trending：阿里这篇复盘值得一看！

阿里内部的AI Code Review工具开源两个月，20k star，连续5天上GitHub Trending首页。团队写了篇复盘，讲的是具体做对了什么、踩过什么坑，值得拆开看看。
1. 开源前先想清楚定位，别为了开源而开源
这个工具在阿里内部已经跑了两年，20k月活、采纳率30%+、误报率不到5%。真正的转折点是26年之后越来越多人反馈"代码是AI写的，看不过来，不敢合"——这是个真实痛点，。
1）差异化很清楚：不是"用了大模型"就完事，是"确定性工程×Agent协同"的混合架构，规则该硬编码的地方硬编码，只在真正需要动态决策的地方用Agent。
2）主动在README里写清楚哪里做得还不够好。用户预期对了，用完不失望，留存反而更高；把话说满，用户一旦发现不符预期，"被骗了"的负面口碑传播比正面快得多。
本质上是可信度来自你敢暴露短板，不是来自你把优点吹到多满。
2. 先完成，再完美
首个版本只做了几件事：CLI工具、模型配置命令、评审框架内核、Claude Code的skill集成、GitHub Action、可观测能力。就这样发了。
1）窗口期有限，打磨三个月，用户心智可能已经被别人占了。
2）不完美反而给社区留了参与空间——两个月后100多个正式版本、一百多位贡献者、60%以上的feature commit来自外部PR，这些能力很多是团队一开始根本预见不到的场景里长出来的。
3）一个教训：早期太关注框架内核完备性，配模型这个"最入口"的环节做得太复杂，来的流量转化率很低。后来想明白：易用性就是转化率，这件事不能拖到后面做。
3. 谨慎增加用户的认知复杂度
README从1000行砍到200行，只留"你是谁、为什么选你、怎么快速开始"，其他全扔文档站。
1）判断新功能是否增加复杂度的标准：新增的东西是否让同一批用户面对更多选择。同时支持GitLab CI和GitHub Actions不算复杂度增加，因为这两类用户互相看不见对方的东西；但同时提供两个功能相近的参数让同一个用户纠结该用哪个，才是真正的负担。
2）判断路径：用户进来→5分钟理解核心价值并跑起来→有兴趣再看细节。凡是让这条路径变长的改动，都要三思。
4. 快速响应，是社区活不活的关键
小bug、小特性12小时内发版修复，PR提交后尽快review。两个月发了89个版本。
1）靠人力根本撑不住这个节奏，靠的是一整套AI Coding工作流：内部代码100%AI生成、100%AI评审；人只做审查AI输出和最终决策。团队专门配了一套Skill（读Issue、建PR、评审代码、发版、润色回复语气）。
2）一切皆代码是这套工作流能跑通的前提——CI/CD、评审规则、发版流程、文档全是代码化的，Agent才能读、能改、能跑。你的发版流程如果是"点三个按钮、填两个表单、等审批"，Agent根本插不进去。
3）一次事故换来的规矩：不能让AI自己选方案再执行，决策权必须在人手里。有次让AI自由决定怎么优化工具调用逻辑，单测过了就发了，结果在上HN头条前两天引入了bug，用户第一次用就踩坑。后来定死：核心链路改动必须跑完整评测集才能发版，AI写代码必须给明确方案约束。
5. Trending不是终点，是起点
第一次上Trending，第二天就掉了——原因很简单，新人进来没事可做。第二次上Trending前，团队提前准备了一批Good First Issue，PR来了就处理，结果连续5天首页。
本质上是流量来了没有承接，就像开了店门货架是空的。
6. 开源能不能成，看三层支撑
1）组织信任：代码公开意味着设计水平全透明，还需要持续投入人力，光靠业余时间撑不住这个发版节奏。
2）稳定的核心贡献者：不是招来的，是从社区里"长"出来的，转化率取决于响应速度——PR提了一周没人看，再热情的人也会走。
3）真实用户的持续反馈：开源的是框架，但壁垒是背后用户踩过的坑。内部用户验证"路走得通"，外部用户发现"还有哪些路要走"，这个顺序反了会很痛苦。
AI把Issue分类、代码评审、发版这些重复劳动自动化了，一个小团队就能撑起过去十人团队的节奏。门槛降低了，上限没降——省下来的时间，正好用在真正需要判断力的地方。
原文：mp.weixin.qq.com/s/EGd5iweuD8lOgf8HCN2m2A
#how i ai##程序员#