一句话定义：Bus Factor（巴士系数，也叫关键人依赖）指的是——项目里有几个人"同时被一辆巴士撞了"，项目还能继续运转。这个数是 1，就意味着只要那一个人出事，项目就停摆。
为什么这么叫？想象一个团队一起过马路，一辆巴士冲过来。走掉 1 个人项目就瘫，Bus Factor 就是 1；走掉 3 个人才瘫，就是 3。它不是精密指标，而是一种提问方式：谁不能请假？
在开源 AI 领域，这个数字经常低得吓人。一个被无数公司塞进生产环境的推理库、一个被反复引用的评测工具、一个下载量极高的数据清洗脚本，背后可能就是一两个人业余时间在维护。他们写下了训练流程、调参经验、踩坑记录，而这些知识大量停留在脑子里、私聊里和没写完的 TODO 里。
打个比方：小区门口那家面馆，只有老板会调那锅汤。老板休假一周，店就关门；老板不干了，招牌菜就没了。食谱写在纸上叫"文档"，只存在脑子里叫"部落知识"（tribal knowledge）。
它和相邻概念的区别：
| 概念 | 关注对象 | 一句话理解 |
|---|---|---|
| Bus Factor | 人 | 少了几个人，项目会死 |
| 单点故障（SPOF） | 系统组件 | 一个零件坏了，全链路挂 |
| CODEOWNERS | 协作流程 | 谁被 @ 去审代码 |
| 部落知识 | 知识载体 | 关键信息只存在于个别人脑中 |
Bus Factor 本质上是"人"这一层的单点故障。有意思的是，CODEOWNERS 这类分工文件看着像明确了多人职责，实际上常常是把所有路径都指向同一个人。
对从业者的实际意义，可以拆成"评估"和"缓解"两步。
评估时问自己三个问题：
1. 核心维护者明天失联，多久能发出一个安全补丁？
2. 除他之外，还有谁能独立跑通完整的训练或评测流程？
3. 关键决策（为什么用这个超参、为什么过滤掉这批数据）记在哪里——代码注释、提交信息，还是私聊？
缓解手段也很朴素：
- 让至少两个人能跑通全流程，并轮值发布，别把发布权锁在一个人手里；
- 决策留痕，重要改动写一段"为什么这么做"，比写"做了什么"更值钱；
- 把隐性知识变成测试和 CI，能跑通测试的人自然掌握了一部分知识；
- 降低贡献门槛，写好 issue 模板和入门任务，让新人能上手；
- 使用方也要做功课：评估这个依赖有没有替代方案、能不能自己维护一个分支，以及是否值得通过赞助或雇佣支持维护者。具体项目的维护者规模、治理结构和资助渠道，以官方仓库和所属基金会的页面为准。
Bus Factor 不是要你怀疑某个具体的人，而是承认一件事：一个项目的健康度，不只写在代码和 star 数里，还写在"有多少人真的能接手"上。