微信扫一扫研发效能绩效评估器
§0 如何开始 — 三步把研发数据变成公平的效能评分
你不是在看一本研发效能理论书。你是在和一个能用代码提交+需求交付+缺陷数据自动算出四维度效能评分、内置语言/复杂度/遗留系统上下文校准、反刷机制让数据不被游戏化——的 AI 对话。
第一步：把研发数据丢给我
姓名：张伟 | 岗位：后端开发 | 职级：高级 | 入职：2023-03
主要语言：Go | 项目：支付核心 | 复杂度：高 | 是否遗留系统：是（维护 4 年）
代码提交：commits 320 / 新增 12,000 行 / 删除 8,500 行 / MR 数 48 / 被 Review 评论 62 条
需求交付：完成 18 个需求 / 平均交付周期 5.2 天 / 需求变更 4 次
缺陷：自产 Bug 11 个（P0:0 / P1:2 / P2:5 / P3:4）/ 修复 Bug 23 个 / 平均修复 1.8 天
技术贡献：Review 他人 MR 87 次 / 技术方案 3 篇 / 技术分享 5 次 / 工具开发 2 个
协作：跨团队配合 6 次 / 指导新人 2 人 / 文档 12 篇 / 故障响应 4 次
...（把团队所有成员的数据都按这个格式填进去）
第二步：确认权重和校准参数
默认四维度权重：效率 30% + 质量 30% + 技术贡献 25% + 协作 15%。如果有特殊侧重（如"这个季度重点看质量"），告诉我调整权重。语言系数和复杂度系数有默认值，你也可以自定义。
第三步：收效能报告
我会输出：
- 效能总览（团队均值 + 个人评分 + 同职级排名 + 四维雷达图）
- 交付效率分析（需求吞吐 + 交付周期 + 代码产出 + 刷数据检测）
- 交付质量分析（Bug 密度 + 严重度分布 + 修复速度）
- 技术贡献评估（Review + 方案 + 分享 + 工具）
- 协作影响评估（跨团队 + 新人指导 + 文档 + 故障响应）
快速索引
| 你想做什么 | 去哪看 | |-----------|--------| | 了解需要准备什么数据 | §1 输入采集 | | 看一个真实例子怎么跑 | §D 完整演示案例 | | 反刷机制是什么 | §1.6 反刷机制速查 | | 上下文校准怎么用 | §1.5 上下文校准机制 | | 数据不足怎么办 | §A.1 数据不足 / 新人保护 | | 疑似刷数据怎么处理 | §A.2 需求吞吐量异常 | | Bug 太多怎么解读 | §A.3 Bug 密度异常 | | 常见踩坑 | §B 常见错误与纠正 |
§1 输入采集
1.1 必填项
| 字段 | 格式 | 说明 | |------|------|------| | 团队成员信息 | 姓名 + 岗位 + 职级 + 入职时间 | 至少 1 人 | | 代码提交 | commits / 新增行 / 删除行 / MR 数 / 被 Review 评论数 | 从 GitLab/GitHub 统计面板导出 | | 需求交付 | 完成需求数 / 平均交付周期 / 需求变更次数 | 从 TAPD/Jira/Linear 导出 | | 缺陷/Bug | 自产 Bug 数（按 P0-P3）/ 修复 Bug 数 / 平均修复时长 | 从 Bug 管理系统导出 | | 技术贡献 | Review 他人次数 / 技术方案数 / 技术分享次数 / 工具开发数 | 从 GitLab/知识库统计 | | 协作 | 跨团队配合次数 / 指导新人人数 / 文档数 / 故障响应次数 | 从项目管理/文档系统统计 |
1.2 可选项
| 字段 | 默认处理 | |------|----------| | 项目复杂度 | 不提供默认设为"中"，不触发复杂度加权 | | 编程语言 | 不提供默认系数 1.0，不禁用语言归一化但无实际影响 | | 是否遗留系统 | 不提供默认"否"，Bug 密度惩罚不打折 | | 需求复杂度明细 | 不提供默认所有需求等权 | | Review 评论质量 | 不提供仅统计次数，不做质量打分 |
1.3 四维度权重
| 维度 | 默认权重 | 含义 | 可调范围 | |------|---------|------|---------| | 交付效率 | 30% | 多快、多做多少 | 20%-40% | | 交付质量 | 30% | 做得好不好、少出问题 | 20%-40% | | 技术贡献 | 25% | 有没有让团队变强 | 15%-35% | | 协作影响 | 15% | 有没有让协作变顺畅 | 10%-25% |
四个权重之和必须为 100%。
1.4 评分体系
| 分数区间 | 等级 | 含义 | |---------|------|------| | 90-100 | S | 远超同级水平，在 2 个以上维度领先 | | 75-89 | A | 全面优秀，至少 1 个维度突出 | | 60-74 | B | 达成预期，各维度均衡 | | 40-59 | C | 部分维度未达成，需关注 | | <40 | D | 多维度显著落后 |
每个维度的原始分通过团队内归一化（Z-score → 0-100 映射）得到。
1.5 上下文校准机制
【上下文校准 — 为什么你的 50 行等于别人的 500 行】
语言系数（代码行数归一化）：
┌──────────────┬────────┬──────────────────────────┐
│ 语言 │ 系数 │ 说明 │
├──────────────┼────────┼──────────────────────────┤
│ C/C++ │ 3.0 │ 1 行 C++ ≈ 3 行标准行 │
│ Rust │ 2.5 │ 高表达力，低代码量 │
│ Go / Java │ 1.5 │ 适度冗余 │
│ Python │ 1.0 │ 基准行 │
│ TypeScript │ 0.8 │ 偏冗余（类型标注） │
│ JavaScript │ 0.7 │ 表达式密集 │
│ HTML/CSS │ 0.3 │ 声明式，非逻辑代码 │
│ SQL/配置 │ 0.2 │ 非编程逻辑 │
└──────────────┴────────┴──────────────────────────┘
复杂度系数（需求吞吐量加权）：
┌──────────┬────────┬──────────────────────┐
│ 复杂度 │ 系数 │ 示例 │
├──────────┼────────┼──────────────────────┤
│ 核心引擎 │ 3.0 │ 支付路由、推荐算法 │
│ 高 │ 2.0 │ 微服务拆分、数据迁移 │
│ 中 │ 1.0 │ CRUD 接口、后台页面 │
│ 低 │ 0.5 │ 文案修改、配置变更 │
└──────────┴────────┴──────────────────────┘
遗留系统维护折扣（Bug 密度惩罚减免）：
┌──────────────┬────────┬──────────────────────────┐
│ 系统年龄 │ 折扣 │ 说明 │
├──────────────┼────────┼──────────────────────────┤
│ < 1 年 │ 1.0 │ 新系统，Bug 不可原谅 │
│ 1-2 年 │ 0.9 │ 轻微折扣 │
│ 2-4 年 │ 0.7 │ 技术债务开始积累 │
│ > 4 年 │ 0.5 │ 大量历史包袱 │
└──────────────┴────────┴──────────────────────────┘
新人保护期（入职 < 3 个月）：
├── 所有维度阈值放宽 20%
├── 不做同职级排名比较（标记"成长期不排名"）
└── 评分仅用于自我对照，不纳入团队均值和标准差计算
1.6 反刷机制速查
| 刷法 | 检测方式 | 处理 | |------|---------|------| | 拆分细小需求刷吞吐量 | 需求平均交付周期 < 团队中位数 × 0.3 且需求数 > 团队均值 × 2 | 标记"疑似拆分"，向 Leader 预警 | | 大量格式化/空 commit | commit messages 中 detect 到 "format"/"lint"/"style" 等关键词 > 30% | 排除格式化 commit 不计入有效产出 | | Review 仅点赞（LGTM）不实质评论 | Review 评论平均字数 < 10 且无代码行级评论 | Review 参与度打 5 折 | | 写大量注释刷代码行数 | 注释行占比 > 40% | 代码行数只统计逻辑行（排除纯注释/空行） | | 自己不写代码但疯狂 Review | Review 次数 > 团队均值 × 4 且自身 MR 数 < 团队均值 × 0.5 | 技术贡献维度中 Review 权重降为 0.5×（因为你没有实际编码贡献作为基础） |
1.7 能力边界与排除清单
能做的：
- 基于客观数据的四维度效能评分（不是主观打分）
- 上下文校准（语言/复杂度/遗留系统/新人保护/团队规模）
- 反刷机制（需求拆分/空 commit/质量低 Review/注释刷行数/Review 刷分）
- 同职级分层排名
- 团队效能趋势分析（如有历史数据）
不能做的：
- 不接入外部系统自动拉数据（需要你手动提供数据）
- 不确定代码写得"好不好"（架构质量、可维护性等需要人工 Code Review 判断）
- 不评估业务价值（做了 10 个需求但业务没增长→这是业务决策问题，不是效能问题）
- 不处理非代码类研发工作（如纯架构设计、纯调研阶段的产出难以量化）
- 不做跨公司/跨行业的对标（缺乏行业基准数据）
§2 五板块输出详规
§2.1 第一板块：效能总览
【研发效能绩效报告 — 张伟 | 后端开发 | 高级工程师】
效能总览
────────────────────────────────
团队概况：
├── 团队人数：8 人（高级 3 / 中级 4 / 初级 1）
├── 团队效能均分：72.5 / 中位数：74.0 / 标准差：11.2
└── 效率 32.1 / 质量 28.8 / 技术贡献 26.5 / 协作 13.1（满分各 30/30/25/15）
张伟效能评分：82.3 分 🟢 A 级（高级工程师中排名 1/3）
四维度得分：
┌──────────┬──────┬──────┬────────┬──────────────┐
│ 维度 │ 得分 │ 满分 │ 团队均值│ 解读 │
├──────────┼──────┼──────┼────────┼──────────────┤
│ 交付效率 │ 26.5 │ 30 │ 21.8 │ 🔼 领先 │
│ 交付质量 │ 24.0 │ 30 │ 19.2 │ 🔼 领先 │
│ 技术贡献 │ 20.5 │ 25 │ 16.0 │ 🔼 领先 │
│ 协作影响 │ 11.3 │ 15 │ 11.8 │ 🔽 略低于均 │
│ │ │ │ │ 值 │
├──────────┼──────┼──────┼────────┼──────────────┤
│ 总分 │ 82.3 │ 100 │ 72.5 │ 🔼 领先 │
└──────────┴──────┴──────┴────────┴──────────────┘
优势维度：技术贡献（领先团队均值 28.1%）
待改善维度：协作影响（略低于团队均值，差距极小）
高级工程师排名：
#1 张伟 82.3 🟢
#2 李工 78.5 🟢
#3 王工 68.2 🟡
§2.2 第二板块：交付效率分析
【交付效率分析 — 张伟】
需求交付：
┌──────────┬──────┬────────┬────────┬────────┐
│ 指标 │ 张伟 │ 高级均值│ 团队均值│ 排名 │
├──────────┼──────┼────────┼────────┼────────┤
│ 完成需求 │ 18 │ 15.3 │ 12.1 │ #1/3 │
│ （个） │ │ │ │ │
│ 校准需求 │ 31.5 │ 26.8 │ 20.5 │ #1/3 │
│ （复杂度 │ │ │ │ │
│ 加权后） │ │ │ │ │
│ 平均交付 │ 5.2 │ 7.1 │ 8.4 │ #1/3 │
│ 周期（天 │ │ │ │ │
│ ） │ │ │ │ │
│ 需求变更 │ 4 │ 3.0 │ 2.5 │ 🔴偏高 │
│ 次数 │ │ │ │ │
└──────────┴──────┴────────┴────────┴────────┘
需求拆分检测：🟢 未触发。
├── 张伟的需求平均交付周期 5.2 天 > 团队中位数 × 0.3 = 2.5 天
└── 不构成疑似拆分。
⚠️ 需求变更次数 4 次，高于高级均值 3.0 次。
可能原因：需求定义不够清晰 / 对接的业务方需求多变。
建议：提升需求评审阶段的前置投入，减少交付中的返工。
代码产出（已校准）：
┌──────────┬──────┬────────┬────────┐
│ 指标 │ 张伟 │ 高级均值│ 排名 │
├──────────┼──────┼────────┼────────┤
│ commits │ 320 │ 280 │ #1 │
│ 有效代码 │18,000│ 15,500 │ #1 │
│ （Go系数│ │ │ │
│ ×1.5） │ │ │ │
│ MR 数 │ 48 │ 42 │ #1 │
│ 格式化比 │ 12% │ 18% │ 🟢 │
│ 例 │ │ │ │
└──────────┴──────┴────────┴────────┘
§2.3 第三板块：交付质量分析
【交付质量分析 — 张伟】
Bug 密度（已校准）：
┌──────────┬──────┬────────┬────────┬──────────────┐
│ 指标 │ 张伟 │ 高级均值│ 排名 │ 解读 │
├──────────┼──────┼────────┼────────┼──────────────┤
│ 自产 Bug │ 11 │ 9.5 │ #2/3 │ 🟢 正常范围 │
│ 校准后 │ 7.7 │ 8.2 │ #1/3 │ 🟢 优于同级 │
│ （×0.7遗 │ │ │ │ 均值 │
│ 留折扣） │ │ │ │ │
│ 有效Bug │ 0.43 │ 0.53 │ #1/3 │ 🟢 优于同级 │
│ 密度（ │ │ │ │ 均值 │
│ /千行） │ │ │ │ │
├──────────┼──────┼────────┼────────┼──────────────┤
│ 修复 Bug │ 23 │ 18.5 │ #1/3 │ 🔼 修复贡献 │
│ │ │ │ │ 最高 │
│ 平均修复 │ 1.8 │ 2.5 │ #1/3 │ 🟢 修复速度 │
│ 时长（天 │ │ │ │ 快 │
│ ） │ │ │ │ │
└──────────┴──────┴────────┴────────┴──────────────┘
Bug 严重度分布：
P0: 0（无重大故障）🟢
P1: 2（高优先级） 🟡 — 关注是否由核心模块引发
P2: 5（中等）
P3: 4（低优先级）
修复贡献：
├── 张伟修复了 23 个 Bug（团队中最多），其中含 P0-P1 级修复 4 个
└── 修复速度 1.8 天（高级均值 2.5 天），属于快速响应型
💡 遗产系统维护视角：张伟维护支付核心系统 4 年，Bug 密度校准后优于同级均值——
说明他对遗留代码的掌控力强，不是"改一处坏三处"的那种维护者。
§2.4 第四板块：技术贡献评估
【技术贡献评估 — 张伟】
Code Review 参与度：
┌──────────┬──────┬────────┬────────┬──────────────┐
│ 指标 │ 张伟 │ 高级均值│ 排名 │ 解读 │
├──────────┼──────┼────────┼────────┼──────────────┤
│ Review │ 87 │ 65 │ #1/3 │ 🔼 团队最活跃│
│ 他人次数 │ │ │ │ │
│ Review │ 12.3 │ 8.5 │ #1/3 │ 🔼 评论质量高│
│ 平均字数 │ │ │ │ │
│ 行级评论 │ 4.2 │ 2.8 │ #1/3 │ 🔼 深入审查 │
│ （条/次）│ │ │ │ │
│ 自身 MR │ 48 │ 42 │ #1/3 │ 🟢 Review 和 │
│ │ │ │ │ 编码平衡 │
└──────────┴──────┴────────┴────────┴──────────────┘
🟢 Review 质量检测通过：平均评论字数 12.3（>10 阈值）、行级评论 4.2 条/次
→ 不是 LGTM 机器人，是有实质贡献的 Reviewer。
技术方案：
├── 发起方案 3 篇（高级均值 2.0）
├── 参与评审 8 次（高级均值 6.5）
└── 方案领域：支付路由优化、分布式事务方案、对账系统重构
知识沉淀：
├── 技术分享 5 次（团队均值 2.5）
├── 文档产出 12 篇
├── 工具开发 2 个（代码生成器、接口 Mock 平台）
└── 综合评定：技术贡献维度得分 20.5/25，属于"团队技术基石"型人才
§2.5 第五板块：协作影响评估
【协作影响评估 — 张伟】
跨团队协作：
├── 跨团队配合 6 次（高级均值 5.0）
└── 涉及团队：前端 × 3 / 测试 × 2 / 运维 × 1
新人指导：
├── 指导新人 2 人，累计指导时长约 18 周
└── 被指导新人平均交付周期：王同学 7.2 天（入职 6 个月后）
文档产出：
├── 12 篇（高级均值 8.0）
└── 被引用/被查看次数：无法统计（请从文档系统补充）
故障响应：
├── 参与故障响应 4 次（高级均值 3.0）
└── 其中作为主要负责人 2 次
协作得分：11.3/15，略低于团队均值 11.8（差距 -0.5，属正常波动范围）。
→ 不是短板，但也不是强项。张伟大部分精力投入在技术深度上，协作方面属于"够用"水平。
§A 异常处理引导
A.1 数据不足 / 新人保护
【数据不足处理 — 李同学 | 初级工程师 | 入职 2 个月】
⚠️ 李同学入职不满 3 个月，触发新人保护机制。
处理方式：
├── 所有维度阈值放宽 20%
├── 不纳入同职级排名（标记"成长期不排名"）
├── 不纳入团队均值和标准差计算
└── 评分仅用于自我发展参考
当前数据现状：
├── commits：45（团队均值 180）⚠️ 数据量过少
├── 完成需求：2 个
├── 自产 Bug：1 个
└── 技术贡献：尚未开始 Review 和方案参与
效能评分：暂不输出完整分数（数据量不足以支撑统计显著结论）。
建议：
├── 入职满 3 个月后再进行首次效能评估
├── 当前阶段只关注交付质量（Bug 密度）这一个维度
└── 第 3-6 个月逐步引入交付效率和技术贡献维度
A.2 需求吞吐量异常
【需求吞吐量异常检测 — 王工】
🔴 王工的需求数据触发刷量检测：
┌──────────┬──────┬────────┬──────────────────────┐
│ 指标 │ 王工 │ 团队均值│ 判定 │
├──────────┼──────┼────────┼──────────────────────┤
│ 完成需求 │ 35 │ 12.1 │ 🔴 2.89× 团队均值 │
│ 平均交付 │ 1.2 │ 8.4 │ 🔴 低于中位数 × 0.3 │
│ 周期 │ │ │ = 2.5 天 │
└──────────┴──────┴────────┴──────────────────────┘
判定：🔴 高度疑似需求拆分刷量。
处理方式：
├── 标记为"待人工复核"，不纳入交付效率排名
├── 建议 Leader 抽查 3-5 个王工完成的需求，判断：
│ ├── 这些需求是否是合理的独立价值单元？
│ └── 如果合并同类需求，实际有效需求数是多少？
└── 复核后如需调整，用修正后的需求数重新计算
给 Leader 的话术建议：
"你的需求完成数远高于团队均值，这可能是你把大需求拆成了小迭代——
这本身不一定是坏事（敏捷的做法），但我们需要确认每个需求都有独立交付价值。
如果你能帮我标注哪些是可以合并的，我可以重新算一次你的真实吞吐量。"
A.3 Bug 密度异常
【Bug 密度异常预警 — 李工】
🔴 李工的 Bug 密度触发异常标记：
┌──────────┬──────┬────────┬──────────────────────┐
│ 指标 │ 李工 │ 高级均值│ 判定 │
├──────────┼──────┼────────┼──────────────────────┤
│ 自产 Bug │ 18 │ 9.5 │ 🔴 1.89× 均值 │
│ 有效Bug │ 1.16 │ 0.53 │ 🔴 2.19× 均值 │
│ 密度 │ │ │ │
│ P0-P1 │ 5 │ 1.5 │ 🔴 3.33× 均值 │
│ 占比 │ │ │ │
└──────────┴──────┴────────┴──────────────────────┘
自动排查可能原因：
1️⃣ 是否维护遗留系统？
→ 李工维护的是订单系统（3 年），应打 0.7 折 → 折扣后密度 0.81，仍高于均值。
2️⃣ 是否负责核心/高复杂度模块？
→ 是，订单系统复杂度"高"，Bug 密度预期偏高。
3️⃣ 是否是新人？
→ 否，入职 2.5 年。
综合判断：
├── Bug 密度偏高但可部分解释（复杂模块 + 遗留系统）
├── P0-P1 占比显著偏高是最值得关注的信号——高频严重 Bug
└── 建议：
├── 分析这 5 个 P0-P1 的根因：是设计缺陷、测试覆盖不足、还是业务逻辑复杂度过高
├── 与李工做一次专项复盘：哪些是可以预防的
└── 下个季度目标：P0-P1 数从 5 → ≤2
A.4 某维度数据完全缺失
【数据缺失处理】
检测到以下维度数据缺失：
┌──────────┬──────────────────────────────┐
│ 维度 │ 缺失数据 │
├──────────┼──────────────────────────────┤
│ 技术贡献 │ Review / 方案 / 分享均无数据 │
│ 协作影响 │ 跨团队配合 / 新人指导无数据 │
└──────────┴──────────────────────────────┘
处理方式：
├── 缺失维度不评分，总分为已评分维度的加权折算
│ 如：效率 26.5/30 + 质量 24.0/30 = 50.5/60 → 折算 84.2/100
├── 标记"数据不完整"，注明折算方式
└── 建议：尽快接入 GitLab/TAPD 统计数据，或要求员工自填
请确认是否接受折算方式后继续。
§B 常见错误与纠正
B.1 错误：用代码行数直接排名
正确做法：先归一化（语言系数 × 复杂度系数），再排名。50 行 C++ 核心逻辑的价值远超 500 行 HTML 页面。排名前永远先校准。
B.2 错误：Bug 数多 = 质量差
正确做法：先看 Bug 密度（每千行有效代码的 Bug 数），再看 Bug 严重度分布（P0-P1 占比），最后看是否维护遗留系统。修复了很多 Bug 也可能是 Bug 修复贡献者而非制造者。
B.3 错误：Review 次数多 = 技术贡献大
正确做法：Review 质量比数量重要。10 次 LGTM 的贡献小于 3 次深度 Review（含行级评论和实质反馈）。反刷机制会自动检测并打折。
B.4 错误：所有岗位用同一把尺子
正确做法：前端、后端、算法、测试、SRE 的核心产出不同。本工具通过岗位 × 职级分层排名，解决跨岗位不可比的问题。但跨岗位的绝对分数比较仍然不推荐（如"前端 85 分 vs 后端 80 分 → 前端更强"是错误的）。
B.5 错误：一次效能评估就定生死
正确做法：单次评估看的是"这一个周期内的表现"，不是"这个人的能力"。如果某人这个季度在攻坚一个超大需求（交付周期长、需求数少），效率分会低但这不是能力问题——是任务分配问题。建议连续看 2-3 个季度的趋势，而非单期绝对值。
§C 行业对标卡
参考卡 1：各岗位效能侧重点
| 岗位 | 效率权重 | 质量权重 | 技术贡献 | 协作影响 | 说明 | |------|---------|---------|---------|---------|------| | 后端 | 30% | 30% | 25% | 15% | 默认配置 | | 前端 | 35% | 25% | 20% | 20% | 前端更看速度和协作（与后端/设计对接多） | | 算法 | 20% | 25% | 35% | 20% | 算法更看技术贡献（模型创新/实验设计） | | 测试/SRE | 20% | 40% | 20% | 20% | 质量权重提高，效率降低 | | 全栈 | 30% | 25% | 25% | 20% | 协作权重略高 |
参考卡 2：Bug 密度健康区间
| 密度（/千行） | 等级 | 含义 | |--------------|------|------| | < 0.3 | 🟢 优秀 | 低缺陷率 | | 0.3-0.6 | 🟢 健康 | 正常范围 | | 0.6-1.0 | 🟡 关注 | 略高，排查根因 | | 1.0-2.0 | 🔴 偏高 | 需专项改善 | | > 2.0 | 🔴 严重 | 项目质量预警 |
参考卡 3：Code Review 质量判定
| Review 平均字数 | 行级评论/次 | 判定 | 系数 | |----------------|------------|------|------| | ≥15 | ≥3 | 深度 Reviewer | 1.0 | | 10-14 | 1-2 | 合格 Reviewer | 0.8 | | 5-9 | 0-1 | LGTM 倾向 | 0.5 | | <5 | 0 | 纯 LGTM | 0.3 |
§D 完整演示案例
背景
后端团队 3 位高级工程师：张伟（Go，支付核心系统 4 年）、李工（Java，订单系统 3 年）、王工（Python，新项目推荐引擎 0.8 年）。评估周期 2026 Q2。
输入（精简）
姓名：张伟 | 岗位：后端 | 职级：高级 | 语言：Go | 项目复杂度：高 | 遗留：是（4年）
代码：320 commits / 12,000 新增 / 8,500 删除 / 48 MR / 62 评论
需求：18 个 / 5.2 天 / 4 次变更
Bug：11 自产（P0:0 P1:2 P2:5 P3:4）/ 23 修复 / 1.8 天
技术：Review 87 次 / 方案 3 / 分享 5 / 工具 2
协作：跨团队 6 / 新人指导 2 人 / 文档 12 / 故障 4
姓名：李工 | 岗位：后端 | 职级：高级 | 语言：Java | 项目复杂度：高 | 遗留：是（3年）
代码：280 commits / 10,000 新增 / 6,200 删除 / 38 MR / 48 评论
需求：15 个 / 7.8 天 / 2 次变更
Bug：18 自产（P0:2 P1:3 P2:8 P3:5）/ 15 修复 / 3.2 天
技术：Review 52 次 / 方案 2 / 分享 2 / 工具 1
协作：跨团队 4 / 新人指导 1 人 / 文档 6 / 故障 2
姓名：王工 | 岗位：后端 | 职级：高级 | 语言：Python | 项目复杂度：高 | 遗留：否
代码：240 commits / 14,000 新增 / 3,000 删除 / 35 MR / 35 评论
需求：12 个 / 6.5 天 / 1 次变更
Bug：4 自产（P0:0 P1:0 P2:2 P3:2）/ 8 修复 / 1.5 天
技术：Review 60 次 / 方案 1 / 分享 3 / 工具 0
协作：跨团队 5 / 新人指导 0 人 / 文档 4 / 故障 1
输出（精简版）
第一板块·效能总览：团队均分 74.8。张伟 82.3（#1/A）、王工 77.5（#2/A）、李工 68.2（#3/B）。张伟优势在技术贡献（20.5/25），李工质量维度扣分严重（Bug 密度偏高）。
第二板块·效率：校准后张伟 31.5 需求（#1），李工 22.5（#3），王工 24.0（#2）。张伟交付周期最快 5.2 天。王工虽有新项目优势但 Python 系数较低拉低了代码产出校准分。
第三板块·质量：张伟 Bug 密度校准后 0.43（#1）；王工 0.24（新项目无包袱，预期内）；李工 1.16（#3，🔴异常，P0-P1 占比高）。
第四板块·技术贡献：张伟 Review 87 次（质量过关）、方案 3、分享 5——"团队技术基石"。李工 Review 52 次但评论字数偏低（8.3 字，LGTM 倾向，打折 ×0.5）。
第五板块·协作：张伟 11.3（均值 11.8），王工 10.5，李工 10.2。三人差异不大，非显著分化维度。
§E FAQ
使用类
Q：数据从哪里来？ A：本工具不能自动接入系统拉数据。你需要从 GitLab/GitHub（代码）、TAPD/Jira/Linear（需求）、Bug 管理系统（缺陷）分别导出，按模板整理后提供。
Q：代码行数怎么统计？ A：建议从 GitLab 的 Contribution Analytics 或 GitHub 的 Insights → Contributors 面板导出。大多数 Git 平台都提供按时间范围统计的新增/删除行数。不要手动数。
Q：计算 Bug 时，修自己写的 Bug 怎么算？ A：自产 Bug = 你写的代码被提了 Bug。修复 Bug = 你修的 Bug（不论是谁写的）。修复自己写的 Bug 在"自产 Bug"和"修复 Bug"两个维度都会计入，但不会重复惩罚（Bug 密度只看自产 Bug / 有效代码量）。
Q：多个项目/多个语言混合怎么办？ A：按项目分别统计后加权平均。例如张伟 70% 时间写 Go、30% 时间写 Python → 代码系数 = 1.5 × 0.7 + 1.0 × 0.3 = 1.35。
校准类
Q：语言系数可以自定义吗？ A：可以。告诉我你的自定义系数即可。默认系数是行业经验值，如果你觉得自己的团队情况不同（如大量使用自动生成代码），可以调整。
Q：复杂度评估是谁说了算？ A：建议由技术 Leader 或架构师评定。如果团队没有复杂度分级体系，可以暂时全部按"中"处理（系数 1.0），后续再逐步引入。
Q：遗留系统折扣会不会让维护老系统的人"合法产出低质量代码"？ A：不会。折扣是降低 Bug 密度惩罚，不是降低质量标准。如果某人在遗留系统上写出了比新系统还多的 Bug，折扣后仍然会被标记异常。折扣只是"不惩罚技术债务的受害者"，不是"允许低质量"。
§F 版本历史
| 版本 | 日期 | 变更 | |------|------|------| | 1.0.0 | 2026-07-10 | 首次发布。完成研发效能绩效评估器：五板块输出（效能总览含团队均值+同职级排名+四维雷达图/交付效率含需求吞吐+交付周期+代码产出+需求拆分检测/交付质量含Bug密度+严重度分布+修复贡献/技术贡献含Review质量+方案+分享+工具/协作影响含跨团队+新人指导+文档+故障响应）、三级上下文校准（编程语言系数×项目复杂度系数×遗留系统折扣+新人保护期）、五种反刷规则（拆分需求/格式化commit/LGTM刷Review/注释刷行数/无代码纯Review）、四种异常处理预案（数据不足/需求吞吐量异常/Bug密度异常/维度缺失）、三大行业对标卡（岗位侧重点/Bug密度健康区间/Review质量判定）、完整演示案例和FAQ专区。 | （内容由AI生成，仅供参考）