研发效能绩效评估器

要解决什么问题

研发绩效如果只盯「代码行数」或「需求个数」，很快会被拆分需求、格式化 commit、LGTM 式 Review 把数据玩坏；同一个人写 Go 核心支付和写 Python 新项目，产出也不该用同一套尺子量。团队 Leader 需要的是：在可解释的规则下，把 Git、需求系统、Bug 系统里已有的数字，变成四维度评分和同职级对比，而不是再开一场各说各话的对齐会。

技能如何工作

你把按模板整理好的数据交给对话（成员职级、commits/MR、需求交付周期、P0–P3 缺陷、Review/方案/分享、跨团队协作等）。默认权重为效率 30% + 质量 30% + 技术贡献 25% + 协作 15%，可按季度侧重调整，且四维之和须为 100%。

计算时会做上下文校准：编程语言系数、项目复杂度、遗留系统对 Bug 密度的折扣，以及新人保护期。同时内置反刷规则，例如需求完成数相对团队均值异常偏高会标记「疑似拆分」、格式化 commit 占比过高会从有效产出中剔除、Review 仅 LGTM 会按评论字数与行级评论打折。

输出通常分五块：效能总览（团队均值、个人分、同职级排名、四维雷达）、交付效率（吞吐、周期、代码产出）、交付质量（Bug 密度与严重度、修复速度）、技术贡献与协作影响，并附带异常解读（如 Bug 密度超标、数据不足时的处理思路）。

适用边界

本技能不会自动拉取 GitLab、Jira、TAPD 等系统数据，导出与清洗仍需你完成。语言系数、复杂度、遗留系统标记需要团队有基本共识；没有复杂度分级时，文档建议先全部按「中」处理。评分是辅助决策的量化视图，不能替代对业务上下文和人的当面沟通。