夜雨聆风传统开源软件的分类主轴是"领域"——数据库、大数据、网络、操作系统。原因在于这些领域的主流项目大多成熟、可直接用于生产，"能不能用"并非首要问题。AI 领域则不同：项目成熟度方差极大，从基金会托管的工业级框架，到论文配套的一次性实验代码，外观上往往难以区分。因此判断一个 AI 项目，需要在"领域"之外叠加两条轴——形态（应用 / 框架 / 库 / 标准）与来源（基金会 / 公司 / 社区 / 论文）。其中来源轴的末端（个人实验、论文代码）无论形态如何，默认不可用于生产环境。
一、传统开源软件：以"领域"为主轴
传统 OSS 的第一刀几乎总是按应用领域 / 技术栈层次切。
领域分法在传统软件中够用的根本原因：这些领域的"头部项目"已经过十余年生产检验，成熟度普遍较高。“它是个数据库"基本就隐含了"它能用”。成熟度不是首要变量，因此不需要额外的轴来筛选。但要注意——这只对"头部"成立，机制见第二节末。
二、AI 项目：领域分法为什么失效
同样一句"它是个 AI Agent 框架"，可能指向工业级产品，也可能指向一份毕业 demo。领域标签在 AI 中丧失了筛选能力，原因有三：
2.1 边界模糊
一个"项目"可能同时是模型权重、训练框架、推理服务和演示界面，难以归入单一领域格子。
2.2 成熟度方差极大
传统领域的头部项目成熟度趋同；AI 项目的成熟度从"基金会毕业级"到"跑一次就崩"全谱系分布，且外观相似。
2.3 迭代过快
项目寿命短，归档率高，今年的明星可能明年停更。"领域"是慢变量，无法反映这种快速更替。
结论：AI 项目必须在领域之外叠加两条轴——形态 × 来源。前者决定"上手成本"，后者决定"存活风险 / 持续性"。
2.4 统一定位：一个模型，两个切片
退一步看，前两节并非"传统一套规则、AI 另一套规则"，而是同一个模型的两个切片。任何开源项目都由三个量定位：形态（应用 / 框架 / 库 / 标准）、来源（基金会 / 公司 / 社区 / 论文）、成熟度（本质上是时间的函数）。
- 传统软件
是"来源已饱和、成熟度已收敛"的极限情形：头部项目历经十余年，来源轴几乎全部上行到顶端、成熟度方差被时间抹平，三个量里只剩"领域"还在变。于是领域分法够用——不是因为另两条轴不存在，而是它们退化成了背景常量。随便找一个 2009 年某篇论文配套的数据库、或某个单人维护的数据库，它和一个 AI demo 一样不可生产；"它是个数据库≈它能用"成立，只是因为你下意识只点名了那些已经赢了的项目。换句话说，做筛选的从来不是"领域"这把刀，而是时间。 - AI 软件
是三个量同时剧烈变动的情形：成熟度未收敛、来源仍在迁移、形态彼此交叠。所以领域标签失去筛选力，必须把形态与来源显式拎出来。
更要紧的是这套定位只预测两件事：形态决定"上手成本"，来源决定"存活风险"。它不预测第三件事——“这套东西现在到底好不好、适不适配你的场景”。
可生产 = 存活 + 质量 + 适配，而两条轴只覆盖"存活"。质量与适配无法从出身推断，只能上手验证。明确承认模型不决定什么，比假装它替你决定了更有用。
三、两条轴
3.1 形态轴：决定"上手成本"
| 应用 / 平台 | docker compose up | |||
| 框架 / SDK | ||||
| 库 / 组件 | import | |||
| 标准 / 规范 |
3.2 来源轴：决定"持续性 / 存活风险"
判断存活风险的核心指标是 巴士因子（Bus Factor）——多少核心维护者一旦离开，项目即停摆；数值为 1 表示项目完全依赖单一个人。
一个关键的反直觉点：这条来源轴（含"基金会 > 公司 > 社区 > 论文"的排序）是存活风险排序，不是好用程度排序——别读反了。基金会背书是"存活信号"（会不会突然没人维护），而非"可用信号"（能不能拿来就用）：最易用的应用层（RAGFlow、Dify、Ollama）反而由公司主导、不挂基金会；挂基金会的多为底层库与标准（Milvus、ONNX）。两轴正交，且都与"好不好用"那第三件事正交——三者不可互相替代。
四、重点类别：论文 / 个人项目为什么默认不可生产
这是与传统软件差异最大、也最容易踩坑的一类。它在形态上可能自称"框架"或"应用"，但来源轴决定了它本质上是参考实现（reference implementation），不是产品。
4.1 四个结构性缺陷
- 目的错位
：为复现论文实验或演示效果而写，不为长期运行。 - 工程缺失
：常缺测试、错误处理、文档；依赖版本写死，环境脆弱。 - 维护断点
：作者毕业、换工作或论文发表后即停更。 - 协议限制
：部分明确标注"仅供研究 / 非商用"，无法合法进入生产。
4.2 识别信号
README 以 benchmark 数字为主，缺少部署与运维说明 最近一次 commit 在半年以上之前 issue 长期无人响应 单一作者，版本号长期停留在 0.x安装步骤依赖特定旧版本 CUDA / 库，且无版本约束说明
核心区分：论文代码证明的是"这个方法行得通"，而非"这套代码扛得住生产"。两者之间隔着工程化、测试、监控与长期维护的全部成本。合理用法是读它、移植其算法思路；误用是直接塞进生产环境。
五、合起来：交叉判断顺序
判断任意一个开源项目，按以下顺序收敛：
- 传统软件
→ 按领域定位，头部项目默认可用，可跳过后续轴（其来源轴与成熟度已饱和成常量）。 - AI 软件 → 先看来源
：是基金会 / 活跃公司，还是论文 / 个人？后者直接降级为"参考实现"。 - 再看形态
：应用（拿来用）/ 框架（自己搭）/ 库（当零件）/ 标准（对齐）。 - 最后看协议
：仅当遇到 AGPL / SSPL / 限商用 等传染性或商用受限协议时，才进入决策；其余情况协议为噪声。
提醒：以上顺序解决的是"会不会死 + 上手多贵"。即便全部走通，"它好不好用、适不适配我的场景"仍需上手验证——这一步任何分类轴都替代不了。
六、AI 开源实景：按"来源"铺开（GitHub 视角）
AI 开源项目按来源大致分四类，来源直接决定维护动力与存活风险。以下每类给出代表项目、形态与可用性判断，覆盖 GitHub 上的主流项目。
6.1 基金会托管（治理中立，存活风险低）
PyTorch Foundation（已扩展为伞形基金会，可托管 PyTorch 之外的独立项目）
LF AI & Data Foundation（AI + 数据托管最全，采用 沙箱→孵化→毕业→荣誉退休 四级）
OpenClaw 的特殊性：它最初是个人项目（Peter Steinberger），爆红后才新设 OpenClaw Foundation（治理模型仿 Ghostty 基金会）来"护住开源"。这是"应用层默认不在基金会、爆红后才补设治理"的典型路径——与 LF AI 那种"一开始就交给基金会的底层项目"方向相反。不过这里的"中立"要打个折扣：该基金会由 OpenAI 赞助、作者本人也已加入 OpenAI，治理上更接近"有大厂背书的基金会"而非纯中立——恰好是个比 LF AI 更"灰"的真实案例：来源轴上行了，但上行到的不是教科书式的中立顶端。
6.2 公司主导（有商业维护动力，多数存活风险低；重点防"协议陷阱"）
开放权重模型（公司 / 机构发布，“可下载"不等于"完全开源”）：Llama（Meta）、Qwen（阿里）、DeepSeek、Mistral、Gemma（Google）、Phi（微软）、GLM（智谱）、Hermes 3/4（Nous Research）。
协议陷阱 / 伪开源：部分"开源模型"只放权重、不放训练数据与代码，且 license 限制商用规模或场景。判断开放程度可参考 LF AI 的 Model Openness Framework（MOF，模型开放度框架）——它对"代码 / 权重 / 数据"三者分别分级，避免把"可下载"误当成"可自由生产使用"。
6.3 社区 / 个人（巴士因子低，进生产前先评估）
这一类的判断不看名气，看活跃度与维护者数量。llama.cpp 与 ComfyUI 之所以可用，是因为它们已从"个人"过渡到"公司 / 组织"——这印证来源轴是动态的，会随项目演化而移动。
6.4 论文 / 学术（参考实现，默认不可生产）
GitHub 上大量 “official implementation of [论文名]” 属于此类。它们证明方法可行，但不具备生产工程。识别信号与处理方式见第四节。
演化提示：少数论文 / 个人项目会沿"个人 → 社区 → 公司 / 基金会"上行（RWKV 即从研究项目进入 LF AI 孵化）。一旦完成上行，可用性才随之提升。判断时认准它"现在处在哪一级"，而非它"出身哪里"。
七、速记（带走四点）
- 传统看领域；AI 看"形态 × 来源"。
领域分法在 AI 中因成熟度方差过大而失效——更准确地说，三个量（形态 × 来源 × 成熟度）一直都在，传统只是"来源与成熟度已饱和成常量"的极限情形。 - 来源轴四级：基金会 > 活跃公司 > 社区 / 个人 > 论文。
越靠右，巴士因子越低、存活风险越高；论文 / 个人默认是参考实现，不是产品。但这是存活风险排序，不是好用程度排序——可生产 = 存活 + 质量 + 适配，来源只管"存活"，后两者仍需上手验证。 - 来源是动态的。
项目会沿"个人 → 公司 / 基金会"上行（OpenClaw、llama.cpp、RWKV）；认准它"现在在哪一级"。 - 协议只在边缘情况进入决策；基金会背书是"存活信号"而非"可用信号"。
开放权重模型尤其要用 MOF 之类框架辨别"可下载"与"可自由生产使用"。
