去年Q3，某SaaS公司的CTO在复盘会上发现一个诡异现象：团队规模从12人扩到20人，代码提交量却跌了23%。没人请假，没搞重构，产品路线图也没变。三个月后，核心架构师离职，带走了一半的上下文知识——这时候他们才意识到，数据早就在报警。
代码仓库不会 burnout（职业倦怠），但它会记录 burnout 的所有前兆。提交频率、PR审查周期、贡献者分布，这些不是"工程卫生指标"，而是团队能量支出的流水账。人可能碍于面子不说，但 Git 日志不会撒谎。
信号一：连续四周提交下滑，工作变"重"了
单周波动是噪音。但连续四周 commit 频率下降，且排除假期、集中攻关等变量，这就值得拉会聊聊。
通常这意味着工程师把更多时间花在"对抗现有复杂度"上：调试模糊的代码所有权、在遗留系统里考古、或者单纯是动力衰减导致推进困难。表面看产出少了，实际是单位产出的能耗飙升。
某金融科技团队曾记录到，他们的核心服务库在两个月内人均提交从每周4.2次跌到2.1次。深入排查后发现，一个微服务的边界定义混乱，导致每次改动都要跨三个仓库协调。修复架构后，数据回升，工程师的 standup 时长也从平均23分钟缩到11分钟。
提交下滑往往是"工作变难"的滞后指标，而非"人变懒"的证据。
信号二：60%提交来自同一个人，"巴士系数"正在杀人
打开核心仓库的贡献者分布。如果最近30天超过60%的提交来自单个账号，你面对的不只是知识风险——那个人大概率正在过载。
高巴士系数（Bus Factor，指关键人员流失导致项目瘫痪的风险）意味着单一工程师扛着不成比例的认知负荷。他/她可能同时在回消息、解阻塞、当活文档。这种孤立感是 burnout 的高危土壤。
更隐蔽的是"影子贡献"：表面看提交分散，但某人的代码被频繁 revert 或覆盖，实际影响力远超统计。建议结合 git blame 和代码评审记录交叉验证。
某电商平台的移动端负责人曾独占70%的框架层提交。团队没当回事，直到他休了两周年假，期间三个需求延期，线上事故响应时间从15分钟拉到4小时。休假回来后他提了离职——"我以为你们不需要我，结果发现你们真的需要，这更可怕。"
信号三：PR成"坟场"，审查文化崩解
打开 Pull Request 列表，筛出 open 超过7天的。如果数量在累积，审查文化已经出问题了。
原因通常二选一：reviewer 被淹没，把审查工作无限期 deprioritize（降级处理）；或者代码库复杂到审查成本过高，打开 diff 需要心理建设。无论哪种，对提交者都是负反馈循环——"我的活没人看"，进而"那我干嘛还主动"。
观察个体层面的信号同样关键。某工程师的提交频率没跌，但突然停止主动 review 他人 PR、不再在 Slack 技术频道发言、commit message 从详细说明变成"fix"。这不是休假，这是"心理离职"（quiet quitting）的技术等价物。
健康仓库的贡献者分布像心电图，有波动但覆盖全员。当最近20个 commit 只出现两三个名字，且其他人持续淡出，需要追问：是技能断层？是领域边界不清？还是某些人已经被沉默地边缘化？
数据是起点，对话才是解法
所有这些指标的共同价值在于"客观"和"前置"。人在 burnout 临界点往往不愿承认，或已经失去承认的能量。仓库数据提供了不依赖自我报告的早期预警系统。
但数据本身不会修复任何东西。看到四周提交下滑，下一步是找当事人聊"最近哪个环节最卡手"，而非质问"为什么产出少了"。发现某人独占60%提交，该做的是拆分领域所有权、建立轮换机制，而不是简单表扬"辛苦了"。
GitPrime（现 Pluralsight Flow）在2019年分析过300个工程团队的数据，发现贡献者集中度与离职率的相关性达到0.47——不算因果，但足够让管理者多看一眼图表。
某开源项目的维护者分享过他们的实践：每月生成"仓库健康度"简报，包含提交趋势、PR 周转时间、新贡献者占比。不用于绩效考核，只作为团队 retro（复盘）的输入。两年内，他们的核心贡献者留存率从61%提升到89%。
你的团队上周有多少 PR 在 review 队列里躺了超过5天？核心仓库的 top 贡献者占比是多少？过去一个月，有没有人的提交模式从"主动推进"变成"被动响应"？
热门跟贴