开源 AI 选型方法论

① 准入：什么项目能进目录

准入关注「是否与开源 AI 实际应用相关」，而不仅是「当下是否最火」。最低 Stars 要求主要用于划定收录比较范围。

必须满足

• ✓ 开源许可证可识别，OSI 认可许可证优先
• ✓ 与 AI / ML 相关：模型、推理、RAG、Agent、多模态、MLOps 等
• ✓ 开源核心可自托管、集成，或作为基础设施 / SDK / 框架使用
• ✓ GitHub 公开仓库，可访问代码与基础元数据
• ✓ 达到最低 Stars 要求（例如 5000+，随收录范围调整）

优先考虑

• + 近 12 个月内有实质更新或社区活动
• + README、许可证与基本使用说明清晰完整
• + 可独立使用的工具 / 框架 / 产品

通常排除

• ✗ 已归档仓库
• ✗ 纯索引 / 清单类
• ✗ 纯题单 / 笔记 / 路线图（无可运行产品）
• ✗ 无独立价值的 Fork
• ✗ 与 AI 实际应用无关
• ✗ 长期废弃、无维护
• ✗ 闭源或纯 SaaS

以仓库实质用途为准，不单凭名称判断。

② 分类：按应用场景归档

每个项目仅分配一个主分类（如 LLM 推理、RAG、Agent 框架、MCP 工具、AI 教育等），对应「你在选什么能力」，而不是堆叠 GitHub Topics。分类由 AI 辅助、编辑团队确认；现有分类均不合适时可提案新类。项目详情页展示「收录理由」，说明场景匹配依据。

③ 评估与审核

新进入评估流程的项目，会结合仓库描述、Topics 与公开信息做场景匹配。评估结果决定直接公开、编辑复核或暂不收录。

AI 辅助筛选，编辑团队对收录与分类拥有最终决定权；信息变化时可更正或下架。

④ 应用落地：我们关注什么

「能进目录」不等于「开箱即用」。以下维度在项目详情页展示，供选型时阅读参考：

• • 许可证与合规：是否便于企业评估与部署
• • 维护活跃度：更新频率与社区响应情况
• • 社区采用：Stars、Forks、Contributors 等公开指标
• • 可部署性：安装、部署或集成说明是否清晰可用
• • 场景匹配：是否解决该分类下的实际问题（见收录理由）

供详情页落地选型参考；榜单排序见第五节。

⑥ 信任与治理

选型指南的价值在于可解释、可纠错、可更新。

• • 已公开项目展示「收录理由」，说明场景匹配与收录依据
• • 边界案例与新场景分类由编辑团队复核
• • 仓库指标按固定周期从 GitHub 更新
• • 任何人可通过联系我们页面提交纠错、分类建议、收录申请、对方法论的意见与异议，或应用落地相关疑问
• • 许可证变更、长期废弃、场景不符或重复镜像的项目可被移除
• • 重大方法论变更将更新本页并标注版本日期