用 AI 做开源项目选型评估：维护活跃度怎么看

商业软件出问题有客服和合同兜底，开源项目没有：没有人对你承诺维护。今天好用，不代表明年还有人管；选型时看错活跃度，代价是半年后接手一个没人管的依赖。这篇讲活跃度该怎么看、许可证要核什么、长期风险怎么估，以及怎么让 AI 帮你把评估做全。

只看 star 数会误判

star 数是历史积累，可能是某次热度带来的，代表不了当下状态。更可靠的信号有五项。最近一次提交时间：主分支半年以上没动静要警惕，除非项目明确宣布进入维护模式。提交者人数：只有一两个人维护，风险集中在个人身上，人家换个工作、兴趣转移，项目就停摆。问题响应：随机抽几个近期 issue，看有没有人回、多久回。发布节奏：是持续小步迭代，还是一年憋一个大版本。文档质量：文档含糊的项目，用起来的时间成本会翻倍，而且文档差通常意味着维护投入低。五项合起来看，比单看 star 数靠谱得多。

许可证要核对的三件事

这一步常被跳过，后果可能很严重。重点确认三项：能不能商用；修改之后要不要开源，有些许可证要求衍生作品同样开源；有没有附加限制，比如禁用场景、须保留的声明。有些项目挂的是"开源但有限制"的许可证，商用场景需要额外授权，拿不准就找法务确认，别凭印象判断。可以把候选项目的许可证原文发给 AI，请它逐条解释条款含义和常见使用场景的边界，但最终结论要由专业人士确认。

让 AI 补全评估清单

把项目信息和你的用途交给 AI，让它生成评估框架，比让它直接给结论可靠。可以照抄这样一句：我在评估开源项目{项目名}，用途是{用途}，是否商用{是/否}。请列出评估活跃度该看的具体指标、核对许可证的要点、一份引入前的风险清单（维护中断、安全更新、依赖冲突），并说明什么情况应考虑自研替代。请不要编造该项目的具体数据。

末一句很重要。AI 不掌握该项目的实时状态，逼它给结论只会得到编造；让它出框架和清单，数据自己查、结论自己下，这是它在这件事上的正确用法。

长期维护风险怎么估

核心问题是：如果这个项目停止维护，我们怎么办。三条退路提前想清：能不能自己接手维护，看代码量和团队技能；能不能换到同类替代品，看有没有活跃的竞争项目；切换代价多大，看耦合深度。三条路都难走，这个依赖的风险就偏高，要么换掉，要么把关键部分隔离封装，把影响圈住。

评估维度对照

评估时按行打勾，一半以上落在危险信号一列，就别再往下走了。

引入前的两个动作

锁定版本号：避免自动升级带来意外变更，升级走人工确认。做外围封装：业务代码不直接调用它的接口，而是调用你自己的包装层，将来替换时只改这一层。这两步花不了多少时间，但显著降低将来的迁移成本。选型结论本身也值得沉淀成文档：评估依据、放弃的候选、风险清单，写法可参考给合伙人的总结写法；团队性的长期项目需要定期回看，整理方式见复盘总结的方法。

还有一点容易被忽略：选型逻辑是通用的，无论挑技术组件还是挑合作品类，判断依据都要落在可核验的数据上，思路可对照选品与内容的结合——用数据代替印象做决定，这一点在哪个领域都成立。

选型速查

• star 是历史，近期提交和 issue 响应才是现状
• 许可证核对：商用、修改开源义务、附加限制
• 让 AI 出评估框架，数据和结论自己定
• 想好停止维护的三条退路再引入
• 锁版本、做封装，降低将来的迁移成本

三个常被问到的问题

• 新项目没有历史数据，活跃度怎么估？：看维护者其他项目的履历、发布计划声明和社区讨论密度。实在没有数据，就按高风险处理，先封装好备用方案再引入。
• 依赖的项目突然宣布停维护怎么办？：先评估有没有未修复的安全漏洞，锁定当前版本可用的时限，同时启动替代调研。封装层做得好，切换周期是可控的。
• 评估报告能让 AI 直接写吗？：框架和清单可以，涉及具体项目的数据部分必须人工填、人工核。AI 不掌握仓库的实时状态，替你填数据就是在编。