2025QECon全球软件质量效能大会：数据能对话治理有AI：大模型破解效能度量深水区

王欢｜东方证券研发效能负责人

效能度量进入深水区的痛点度量指标反而导致团队氛围紧张，

甚至出现

“

为指标而工作

”

的异化行为—古哈的定律。03度量与改进脱节初期

，管理层往往对数据驱动决策抱有很高期望

，但随着时间推移

，关注度显著下降。数据停留在统计层面

，缺乏有效的跟踪机制和推动力量，难以转化为实际的效能提升。01关注度降温02副作用明显目录CONTENTS03

最后“一公里”：从度量到改进01

效能度量基石：指标设计实战02

效能度量跃升：度量数据分析04

LLM赋能：AI驱动代码治理PART

01效能度量基石：

指标设计与实战解析

度量：

开启效能的钥匙管理学之父彼得·德鲁克曾说过：“如果你不能衡量它

，你就不能改进它。”通过改进实现提质增效

，所以第一步是进行量化Ifyouwant

it,

measure

it.

lfyoucan't

measureit,forget

it.--PeterDrucher如果你无法度量它

，你就无法改进它!

什么是研发效能？流速与效率流派实现高质量产品/功能从概念到交付的流动效率

，它关注的是工作项在价值流中移动的速度、顺畅度和稳定性。能力与开发者体验流派通过优化工程师的工作环境、工具和心理状态

，最大化其创造力和生产力的水平。关注如何减少开发者的摩擦、挫败感和认知负荷

，让他们能够专注、流畅地进行创造。工程卓越流派构建和维护高质量、可维护、可持续的技术资产的能力。

它认为

，卓越的工程实践是长期、高效、低成本交付业务价值的基础。

六纵四横数字化效能体系

效能度量如同眼睛与大脑

，提供洞察以识别问题；工程效能则如同骨骼和肌肉

，提供核心能力支

撑；流程效能优化运作路径

，如同血管和神经确保高效流转；而标准规范则如同皮肤与屏障

，筑牢合规

底线。这四大维度协同作用

，最终合力驱动“以数字化手段为驱动，持续快速交付高质量、高价值业务价值的能力”这一核心价值的实现，确保体系有效承接战略并驱动业务目标达成。

数字化效能：

持续·快速交付·高质量——业务价值的能力图

：该图片引用FinEU

效能度量体系03

系统分层设计采用分层架构（如数据层、模型层、应用层）来构建可扩展、可维护的度量系统03

基于不同层级依据不同管理层级的职责视角，定制差异化的度量指标与数据呈现粒度。03

AI因素影响将人工智能技术对研发效能的正负向影响作为关键变量纳入评估模型。03

考虑主观因素在客观数据基础上

，引入定性评估以弥补纯量化分析的局限性

，形成综合判断02

涵盖全生命周期度量范围应覆盖从需求到交付的完整价值流

，实现端到端的效能洞察。03

时间维度分析通过时间序列分析监测效能变化趋势

，进行周期性的对比以评估改进效果。01

以业务目标为导向度量体系的设计必须与组织战略及业务目标对齐

，确保评估的有效性效能度量本质上是基于客观数据进行量化分析与决策的管理

方法。通过为不同指标配置差异化权

重

，以科学反映其在整个评估

体系中的相对重要性。数据驱动图：该图片引用FinEU权重分配0303为了采集到可靠的数据

，推进研发全生命周期管理流程的标准化

，它涵盖两个核心关键点：构建统一的研发流程体系

，研发管理工具全面推行

，度量系统对接相关工具平台

，进行自动化数据采集。效能理念组织、文化、流程组织宣导培训流程制度从组织宣导、员工培训以及流程制度层面灌输效能文化

，效能目的是指导改进

，而不是武器测试上线

itdm、需求平台、jira、git、ALM数据集成数据去噪研发工作流统一

立项需求设计开发基准规则建立项目基础数据需求绑定

jira绑定git绑定标准化及数据采集数据标准化

数据完整性数据驱动研发效能提升理念深化数据统一

数据质量控制数据铺开数据不是武器

，

是持构建统一的研发流程体系保证数据一致性和可靠性研发工具全面推广保证数据齐全不遗漏改

驱标准化全面推研发主航道建设文化广ci绑定

cd绑定

建立效能系统——数据去噪度量是用来做决策辅助的，其准确性直接关乎决策成败。而异常数据可致分析失真，导致分析的结果是错误的。因此，数据去噪确保数据质量、避免决策失误的关键原则之一。异常点异常点

异常点

异常点数据去噪常用方法3σ箱线图P85

代码量交付趋势图

故事交付时长分布图

指标建模——层级根据效能系统建设经验

，不同职级人员对研发效能诉求不同。

中高管理者需全局性数据洞察

，简洁易懂

，揭示整体情况和改进方向。基层管理者关注细致效能数据

，用于发现问题和推动改进。

一线员工虽不愿被量化考核

，但其实数据就是照镜子

，可以促进自我提升。组织指标

团队指标项目指标

管理层

团队负责人整体情况，辅助决策资源调配，发现问题

项目经理排查问题，改进行动镜子个人指标

员工人、

项目、

组织、

团队质量、成本

天/月/季度/年时间input

output效能工具个人/项目/团队/组织持续改进

指标建模——框架以效率、

质量、

成本等维度作为建模核心

，将数据进行建模

，确定相关效能因子以及占比。

在空间维度

，能够输出从组织、

项目到团队

，再到个人不停下钻的效能展示；

在空间维度

，可以出具天、

月、

季度、

年等进行跟踪

，可满足不不同管理人员的数据诉求。空间

效率、能力、价值

效能系统整体结构图数据底座提供数据支持、

数据建模及分析引擎提供分析结果

，支撑用户场景分析展示

，做到同一套数据针对不同层级的人员出具不同的效能展示数据

底座组织管理信

息

人力信息项目信息

组织信息数据建模指标建模团队模型缺陷模型分析

引数据分析三方因子健康度第三

方赋能代码当量代码检测研发管理工

具

JIRA系统

G

IT系统

ALM系统组织级团队/项目级个人级台

devopsci/cd

部门负责人效能分析改进模型设计辅助决策复盘、行动

领域专家用户

场景效能改进推动者持续交付平项目模型趋势分析个人模型对比分析健康度增减维度参数调优下钻分析一线员工模型调优指标因子代码缺陷用例需求人力构建经理擎标准名称标准类型与编号主要内容和特点相关度《软件研发效能度量规范》团体标准

(T/IQA

15—

2022)由中关村智联软件服务业质量创新联盟发布。

提出了以效率（Efficiency）

、效果（Effectiveness）

、卓越（Excellence）

为核心的E³CI模型

，提供了覆盖需求、

设计、

开发、

测试、

发布、

运营全流程的度量框架和具体指标。高

，指标较多《云上软件研发效能度量能

力模型》团体标准

(T/CCSA694—2025)由信通院发布。

覆盖了通用效能度量能力、

域建模能力、

效能度量模型

三大维度

，

旨在对软件开发的过程及结果进行合理有效的度量。未公开《研发运营一体化（DevOps能力成熟度模型》

系列)行业标准

(YD/T

3763系列)由信通院发布。

一个由多个部分组成的行业标准体系

，涵盖了总体架构、持续交付、

安全及风险管理等多个方面

，

由工业和信息化部发布。低

，指标较少《系统与软件工程开发运维一体化能力成熟度模型》国家标准

(GB/T42560-2023)该领域的首个国家标准

，建立了统一的能力成熟度框架

，

围绕项目管理、产品研发、

服务管理等6大能力域提出要求。低

，一些概念

指标工具箱——国标、

行标、

团标效能度量国标预计2026年发布

，敬请期待方向目标（G）Goal回答问题（Q）指标（M）说明我们想达成的改进目标

是什么？为了判断目标是否达成

，

我们需要回答哪些具体问

题？为了回答问题

，我们需要追踪哪些可量化的数据指标？效率团队人员的资源分配均

衡

，产出高团队人员工作饱和度如何？产品迭代速度如何？代码量、

帕累托需求交付周期趋势、

对比、

同

比、

环比质量系统软件质量高生产bug少？代码内建质量？测试缺陷、

故障数量单元测试覆盖度、

圈复杂度、

代码缺陷密度技术债务趋势、测试及生产缺陷

趋势

指标建模——GQM模型指标研发生命周期需求待办

入池分析

设计及评审

开发

测试

上线

验收

效率

GQM质量

指标有生命周期敲打找钉子观察213维度定义典型指标案例应用目标战略方向对齐度OKR完成率、

战略需求占比某AI公司用

"创新项目PV占比

"衡量转型进度过程价值流动效率需求等待耗时、

跨团队协作次数保险团队通过优化审批流程缩短周期37%产出交付物数量与规模需求吞吐量、

用户故事完成数工具类产品用MVP交付速度衡量产出效能能力团队核心素质技术栈更新率、

T型人才比例某云计算团队建立技能矩阵提升多云能力价值业务成果转化率需求ROI、

用户留存提升系数社交App用

"功能使用渗透率

"淘汰低效需求效率资源投入产出比人天交付需求数、

CI/CD流水线耗时自动化工具使部署效率提升20倍质量交付物可靠性缺陷逃逸率、

平均故障恢复时间(MTTR)金融系统通过混沌工程将MTTR从4h降至15m敏态和稳态的

度量响应变化能力、

维持稳

定需求变更率、

迭代目标达成度。

系统可用

率指标游戏团队用看板WIP限制减少需求堆积。

各种成功率DevOps持续交付成熟度部署频率、

变更失败回滚率某零售企业实现每日千次安全部署创新突破性价值创造专利产出量、

新技术采纳周期智能驾驶团队用A/B测试验证算法创新

基于不同度量目标典型案例

建立指标的原则度量是用一组数据或者多组数据反馈研发效能现状

，是一种抽象表示

，效能度量本质上是一种降维认知工具

，所以度量的反馈一定是片面的。度量不是考核——效能度量

是帮你改进的

“导航仪”

，而不是评判对错的

“成绩单”。

它的核心价值在于发现问题、持续优化

，而不是给你打分定性。引导出好的行为——优秀的效能度量

，其本质是设计一个

系统性的引导信号

，这个信号必

须与组织的最终价值目标强对齐

，从而自发地激发出协作、创新与

对整体负责的有效行为。度量指标自动化采集——度量指标必须通过自动化方式采

集

，

因为手工统计不仅效率低下

，更会因人为干预导致数据失真，从而使指标失去客观性和指导意

义。指标不在多

，而在精——指标的

“精”

，在于每一个都能精准揭示核心问题

，并驱动关键行动。

度量指标的价值

，不在于监测了多少现象

，而在于催生了多少有效行动。结合定性分析——度量体系的最终目的

，是驱动正确决策而非单纯考核绩效

，

因此必须将客观数据与主观洞察结合

，才能由表及里

，定位真因

，

引导持续改进。指标应该是动态的——指标的本质是解决当前最紧要问题的工具

，必须随项目阶段、

团队能力和业务目标的变化而实时调整

，确保始终聚焦在当下最关键的改进点上。不要盲目跟从大厂——拒

绝照搬大厂的

“标准答案”

，

因

为他们要解决的

“考题”和你的

截然不同；

真正要学习的

，是他

们设计指标背后的

“解题思路”。关注整体而非局部最优—

—通过衡量和优化系统的最终产出

，而非单个环节的效率

，来确保所有局部决策共同服务于整体目标的最大化。关注趋势而非绝对值——衡量改进的方向与速率比评判单一的数值结果更为重要

，

因为趋势能揭示系统的真实走向与团队行为的长期影响。维度平衡指标——优秀的指标设计

，

旨在通过内在的相互制约

，迫使团队进行必要的权衡

，从而引导其走向系统整体的健康与平衡。原则7

原则6原则10原则5原则4原则3原则1原则2原则8原则9史诗：中长期规划故事：角色、活动、价值故事故事子任务：具体工作内容子任务子任务子任务粗

细分层颗粒度【用户故事】作为一个<角色>,我想要<活动>,

以便于<商业价值>写好需求——分层、拆分、标准

最佳实践-从拆好需求开始EPIC【验收条件】

【技术方案】故事子任务故事故事子任务迭代1.N子任务验收用户故事的规格描述或用例，如何实现，实现到什么程度技术方案如何实现，方案如何设计，指导开发需求模版：在制品数量明显下降拆分标准需求待办需求分析排期开发测试发布验收可视化让每个人专注工作

绑定关系让全流程可追溯OneID全流程可视化、可追溯

、

最佳实践-OneIDOneID全流程可视化

，打通业务、需求、开发、测试、上线、运维、运营全流程

，全流程可追溯

，为价值后评估等建立血缘图谱分析打下基础需求id与Jira任务绑定devops

id与Jira绑定Jira

id与缺陷绑定Jiraid与代码绑定排期开发导持续改进测试发布引基于价值的流动

、

最佳实践|客户价值、

全局流动一切工作都是围绕客户价值展开的

，流动效率—优于资源使用效率：1）加快流动

，提高交付效率

，缩短交付周期。2）在整体或局部工作流程上建立一个拉动系统

，服务于业务价值。可视化过程问题

业务价值需求待办

需求分析

拉动

拉动

拉动

拉动

拉动验收

效能度量最佳实践|质量内建在开发过程中

，尽早发现问题并解决掉

，不要让质量问题流入下一个环节

，让质量正真内建。在开发过程中

，尽早发现问题并解决掉

，不要让质量问题流入下一个环节

，让质量正真内建。注：此图来源于国君分享效能体系——质量内建

效能度量最佳实践|建立多维度平衡指标不好的度量（单一化）只看“需求完成数”或“代码提交量”——结果可能是代码质量下降，

bug频发交付质量35302520151050如果

“需求吞吐量”和

“前置时间”都很好

，但“线上缺陷率”飙升

，

“技术债”恶化真实故事：

团队在以牺牲质量和长远健康为代价

，进行野蛮的加班冲刺。

不可持续。如果所有指标都表现平平或下降

，但

“技术债”指标在改善真实故事：

团队可能正集中精力在偿还历史债务

，

为未来的提速打下基础。

此时的

“慢”是为了将来的

“快”交付速度

用户满意度系统健康度交付效率PART

02效能度量跃升：数据可视化分析驱动决策加强度量结果可视化分析：加强数据度量可视化

，构建多层次、强对比、指向性明确可视化体系

，让数据成为决策点。从

“效率”转向效果和价值：将工程效能与业务关联起来。例如需求前置时间缩短了

，是否提升“该功能用户活跃度，进而是否对核心业务指标（OKR）的贡献度关注端到端价值流而非

“局部优化”：单个团队的指标最优

，不能以牺牲整体流程为代价

，设置整体度量指标

，减少部门内耗。数据泛滥却缺乏洞察：度量指标堆砌

，如何将数据转换成洞察、决策点？度量与业务价值脱节：我们不断持续改进

，是否对我们的核心业务指标产生了真正价值提升？内卷式的局部优化：团队为了迎合指标是否造成内耗？技术债是否得到有效管理？团队已经具备了基本的度量意识和工具链

，但随之而来的是更复杂的挑战：

数据泛滥却无洞见、

度量目标冲突、

团队为指标而优化、

以及度量与业务价值脱节

当效能度量进入深水区问题度量深水区面临的挑战问题：深水区度量问题点？解决：抓住核心关注点解决抓住核心关注点

破案的关键不是你找到了多少枚指纹

，

而是你知道那一枚指纹是凶手的的目的

，不是指标

，而是一眼就对于企业来讲

，效能度量的呈现能看到的决策点

效能度量分析让效能数据学会说话（效能度量可视化）

的四大心法找贴标签Development

planning对比Improve

performance有结论Senseofteamwork模块化improvement公司中位数14天头部平均水准7天需求总量需求交付周期管理能力需求完成率11个44.5天7人天0.3636当量质量提交频率缺陷修复时长25.09k0.07%510次0.5天——是英雄还是路人甲

，得看和谁同台竞技员工质效画像错误示范：正确示范：证券投资交易管理系统O45项目交付周期

20.1天给数据一个‘擂台’

，让它和对手同台PK，胜负高低才能一目了然证券投资交易管理系统O45找对比

心法一头部平均水准7天公司中位数14天员工质效画像公司中位数15.32天头部平均水准7天18.36%0.05

%

66.98%贴标签

心法二做数据的‘翻译官’

，直接把数据的‘方言’翻译成领导能听懂的‘管理普通话’代码当量代码提交频率开发交付周期153.62k2078次16.02天测试覆盖率重要问题密度代码不重复率——不要给原始食材

，要端上装好盘的菜项目质效画像错误示范：正确示范：证券投资交易管5项目交付周期公司中位数14天头部平均水准7天证券投资交易管理系统O4520.1天

研发周期较长项目质效画像数据区间标签解读负责人动作大于

Q3+

1.5

*

IQR認优秀属于正面极端值，表现异常突出，可能存在最佳实践或特殊增长点。复盘并寻求推广：分析成功原因，总结经验，并评估是否可复制到其他业务环节。(Q2,

Q3+

1.5

*

IQR]✅健康业务运行状态良好，稳定且优于

平均水平。保持现状，维持稳定：继续当前策略，持续监控以确保向好趋势。[Q1,

Q2]✅健康业务运行平稳正常，是构成业务

基本盘的重要部分。保持关注，防范风险：关注数据趋势，预防可能的下滑风险。[Q1-

1.5

*

IQR,

Q1)⚠预警表现有下滑趋势，虽未构成异常，但需高度警惕潜在风险。分析原因并监控：立即调查数据波动原因，增加监控频率，准备应对预案。小于

Q1-

1.5

*

IQR×异常属于负面极端值，通常表明存在确凿的问题或故障，亟待处理。立即介入，优先解决：最高优先级处理，迅速定位问题根源并修复，同时向上汇报。

怎么打标签？——建立一套标签体系×异常：就是传统意义上的“负面异常值”認优秀：则是“正面异常值”✅健康：正常的数据范围⚠预警：在正常和异常之间的缓冲地带

，起到提前警示的作用我们采用箱线图的中位数和四分位数作为划分数据健康状态的统计基础;这种方法能有效排除极端值的干扰

，真实反映数据的分布情况领导一眼扫过去

，红色×的地方就是需要他重点关注的地方有结论

心法三结论

，就是图表的‘新闻发言人’

，要主动、清晰、大声地把最重要的信息‘喊’出来’错误示范：

正确示范：——每一个图表

，都得有一个‘中心思想洞察数据显示

，供应商在运营效率上有所提升

，但效率优化所带来的轻微质量波动和用户满意度下降也值得关注。整体合作基本面保持稳定

，属于可控范围内的波动。风险点：人员精简带来质量和满意度波动。问题密度从0.19上升至0.22

，表明在代码质量、测试深度或细节关注度上有所松懈

，可能与团队工作负荷增加有关。从而引发满意度下降。建议：可友好地建议供应商关注人员优化后团队的经验结构搭配

，或推荐引入更高效的自动化测试工具

，以弥补人力减少可能带来的质量保障缺口

，从而实现真正的“提质增效”

同样

，

每一个模块都应该有一个结论——建立一套结论体系（或基于AI生成）供应商基本情况向量数据库3向量化3333数据源2：历史数据-公司近5年历史效能数据数据源3：打标数据-行业及公司效能指标打标数据数据集任务：从向量数据库搜索任务：从效能历史数据检索任务：从效能打标数据检索任务

：

+模型+算力结合专家模型构建提示词2统一调度数据源1：知识库-效能基础知识如：效能领域基础信息等-行业效能文档如：行业效能报告、白皮书等专家经验模型化提出问题收到答案数据源4：1用

6户1结构化

结构化数据召回排序42内容分割知识中心/CMS4格式转换大模型5模块化

心法四模块化

，是数据的‘导购’

，是直接把他带到最需要关注的‘货架’前。——不要摆地摊

，要开精品店四大心法：

找对比、

贴标签、

有结论、

模块化公司中位数32个头部平均水准35个产出适中

2314产出适中产出较高PART

03度量的最后“一公里”：

如何从度量到驱动改进指标应付文化

研发精力透支

0

精力之战1

CognitiveOverload0

资源之困2

The

HangingArchitecture0

人性之悖3

The

Resistance0

指标之伪4

TheVanity

Metric0

价值之惑5

TheObscure

ROI研发人员的全部时间与精力已被持续的业务需求耗尽

，

改进工作因缺乏最基础的资源投入

（时间与精力）而无法被排上日程

，形成恶性循环。当度量指标与改进目标脱节

，团队会倾向于采取

“

刷数据

”

等应付行为

（如测试用例不写断言）

，

这背离了改进的初衷

，

并制造出改进成功的虚假繁荣。改进是否真的产生了业务价值？改进工作所带来的实际价值难以被清晰衡量和呈现

，

导致其成果无法被有效评估

，也难以证明自身投入的合理性

，从而在争取资源时缺乏说服力。例子

：我们花了这么多时间

，这么多精力去做改进

，看到指标编号

，

但是到底对我们实际的业务有没有产生正向的影响？

怎么去自证？

核心困境：

我们为何卡在“最后一公里”？度量引发抵触

度量因其常被用于

“

挑

毛病

”

和归咎

，

本质上

与人性中渴望被信任和

认可的需求相悖

，

这种

反人性设计必然引发挑

战与排斥

，

从而扼杀改

进的意愿。驱动改进人手不足效能团队多为非传统的兼

职角色

，

人手不足

，

这种

先天的组织架构缺陷导致

其缺乏专职的驱动力量和

权责归属

，

难以持续推进

任何实质性改进。破局一利他思维从“寻找罪证”到“交付良药”

核心心法：数据的价值不在

于证明

“谁错了”

，而在于揭

示

“如何更好”

关键路径：运用

“4Keys”

利他设计法利他思维破局二关键少数从

“面面俱到”到

“关键少数”

核心心法

：在指标的世界里

，

“少即是多

，聚焦即是力量”

关键路径

：采用

GQM（目标

-问题-指标）法则

，

与业务方共同锁定3-5个北极星指标关键少数破局三借力打力从“孤军奋战”到“战略协盟”借力打力核心心法

：效能团队不能自成一派

，

必须将改进工作嵌入组织的流程中关键路径

：

与EPG（工程过程组）

结成“改进命运共同体”，实现双赢从“数据监工”到“价值伙伴”的五重破局要打通度量的“最后一公里”

，我们首先必须完成一场认知与理念的深层革命。这不仅是方法的转变，更是角色、价值和关系的重塑

在理念上实现关键转变最顶级的推进

，

是让改进成为组织无需思考的肌肉记忆和文化自觉。激活先锋从

“行政命令”到

“激活先锋”核心心法

：从

"要你改进

"变为

"我要改进

"

，

找到团队中的效

能先锋

，让他们成为改进的天

然推动者关键路径

：

识别并赋能团队内的效能极客

，

通过特权通道与绩效激励

，

将个人成就与改进成果深度绑定文化建设从

“短期项目

”

到

“

长期价值”关键路径

：打造

“价值可见

”

的效能改进长廊。在公司内部发布平台讲述

“成功故事”案例破局四破局五激活先锋文化建设0405020103为谁服务？这份数据是给开发者、项目经理还是产品经理看的？角色不同

，关心的核心完全不同是否在10秒内

，无需我们

额外解释

，他就能抓住核心信息？可视化做得够不够直观？他看到这份数据后

，知不知道下一步该做什么？洞察必须能直接导向一个明确的行动他是想争取资源？证明团队价值？还是规避线上风险？数据必须直击他的痛点帮他解决什么核心问题？他能否立即行动？他能否轻松看懂？04020103

破局之法一——利他思维

从“寻找罪证”到“交付良药”：数据的价值不在于证明“谁错了”

，而在于揭示“如何更好”运用“4Keys”利他设计法做效能报告以后我们呈现任何数据前

，都必须先通过这个

‘安检’

，

回答四个关键问题：

破局之法二——关键少数

从“面面俱到”到“关键少数”

：在指标的世界里，“少即是多

，聚焦即是力量”北极星指标产出通过这个漏斗

，我们就能与项目组共同锁定3-5个北极星指标。Q-问题接着

，我们问：“

为了实现这个目标

，我们必须回答的最关键的问题是什么？”例如：“我们的交付速度是快是慢？

”“我们的变更是否安全可靠？”GQM使用GQM法则寻找北极星指标以后我们呈现任何数据前

，都必须先通过这个‘安检’

，回答四个关键问题：G-目标首先

，我们必须回答：“我们最核心的业务目标是什么？”是提升客户满意度？是加快迭代速度？还是保障系统稳如磐石？M-指标最后

，我们才定义：“

哪个数据指标能最好地回答这个问题？”Goal

-

目标Metric

-指标Question-问题行动：

在复盘会上

，

由EPG担任会议主持和流程引导者

，负责推动讨论和决策；

我们效能团队担任

“数据解读顾问”

，负责呈现数据和解答疑问。输出：

共同产出一份由EPG官方背书的《过程改进项

清单》01效能团队：提供‘问题洞察’（数据

弹药）EPG团队：提供‘流程权威’（推进

引擎）

破局之法三——借力打力

从“孤军奋战”到“战略协盟”：效能团队不能自成一派

，联合EPG将改进工作嵌入组织的流程中由EPG将《改进项清单》

录入正式的项目管理工具（如Jira）

，并负责跟踪闭环；

我们效能团队负责定期提供

改进项的成效数据

，用于验证效果。输出

：一个在系统中被正式跟踪、有负责人和截止日

的

“改进问题单”。

行动：

在季度/月度复盘会前

，与EPG共同确定会议核心议题

，并由我们提供支撑议题的数据洞察报告

输出：

一份双方认可的、

以数据驱动的《效能复盘会议程》与EPG结成“改进命运共同体”

，实现双赢：可复制、可落地的战略协盟三步法：03第三步：共同跟踪双赢协同联合议程共同主持共同跟踪共建议程共同主持第一步：第二步：02 EPG是什么？在CMMI中EPG（Engineering

ProcessGroup）指的是过程改进小组，

EPG成员是几个或者一些骨干兼职人员，

由于存在改进需求而走到了一起

，聚焦于组织的过程改进

，负责和过程改进有关的活动。EPG—过程改进小组EPG的主要职责是根据公司的商业目标和当前现状

，制定并不断优化研发管理流程

，通过这些流程的落地

，实现提高开发质量、减少开发成本、缩短开发周期和提升开发效率等具体过程改进子目标

，最终保证公司商业目标的达成。开发骨干规划QA

管理架构

合规风控运维持续改进 EPG与效能关系？效能系统识别问题并输出给EPG小组。

EPG针对相关问题进行讨论并制定方案

，跟踪改进。效能系统反向对执行过程及结果进行监控

，确保解决方案的有效性并实现既定的改进目标。效能与EPG相互促成持续改进目标实现。效能—数据洞察EPG—过程改进小组洞察问题检验改进规划管理合规风控QA架构

运维持续改进开发骨干实现了“数据洞察”与“过程

推行”的专业分工

，确保了度量发现的改进措施能得到专职

团队的专业跟进。

破局之法三——借力打力为EPG提供了源自数据的精准改进议题

，直接赋能其过程改进工作

，实现了目标对齐与双向

赋能。改进过程由数据驱动发起

，并以关键指标恢复正常为闭环标准

，构建了客观、可衡量的改进生命周期。建立行动方案效能问题清单借助EPG的组织权威与跨部门协调能力

，有效保障了改进措施在各部门的顺畅推行与落地。持续监控效能观察正常质量门禁效能分析异常效能团队EPG团队PDCA借力打力闭环管理价值共赢数据驱动双向赋能质控团队度量输入

MSG/EPGQA/PM开始过程改进及总结质量效能评估及及激励结束输出分析记录结果专项改进收集改进过程记录改进成果日常改进目标管理专项改进策划效能度量问题改进点识别

破局之法三——借力打力EPG过程改进小组将效能度量问题进行手里

，负责推动和实施组织内的过程改进活动

，以提高研发效率和产品质量。

破局之法四、

五——激活先锋、

文化建设从“行政命令”到“激活先锋”

：从"要你改进"变为"我要改进"

从“短期项目”到“长期文化”

：项目有终点

，而流程没有。激活先锋：从“要你改进”到“我要改进”变

“行政指派

”为

“

内驱招募

”

，

通过数据

+

口碑

精准发掘有热情、有想法的

“对的人

”

，让改进成

为自我实现的舞台。彰显价值：从“埋头改进”到“抬头可见”为每个改进建立清晰的价值叙事

，

如

“部署从2小

时→

10分钟

，节省200人/天”

，让成效可感知、信

任可积累。激励赋能：从“执行者”到“所有者”赋予决策权与提案直通车

，提供推动变革的硬支撑；结合荣誉与绩效

，让先锋被看见、被认可

，激发持续动力。传播故事：从“个案成果”到“文化信号”将成功案例包装为

“英雄故事

”广泛传播

，

既提供

可复用的方法模板

，也塑造

“人人追求卓越

”

的文

化场域。彰

显

价

值BRAND

DECISION传

播

故

事BRAND

DECISION激

励

赋

能BRAND

DECISION激

活

先

锋BRAND

DECISION我们面临的最终挑战

，是让改进超越对任何个人的

依赖。

结论很明确：

破局的终点

，是从依赖

‘英雄’的推动

，转向培育能让改进自动发生的

‘土壤

’—

—这本身就是一项根本性的文化建设。找到团队中的效能先锋

，让他们成为改进的天然推动者

：

改进的杠杆点

，不是对全员发号施令

，

而是精准找到并激活团队中那5%的

“种子选手”激活先锋文化建设01030402PART

04LLM赋能：

AI驱动效能治理

研发现状导致代码重复度暴增02代码纳入效能指标度量指标反而导致团队氛围紧张，

甚至出现

“

为指标而工作

”

的异化行为—古哈的定律。03追求速度响应01AI写代码AI写出的代码很多时候

，都是冗余过分追求速度，

多数程序员习惯copy

粘贴我司2023年代码重复度情况

现状数据来源：研发效能基准报告信通院、思码逸时间：2023年对标行业水平VS.AI写代码

，让代码质量不断下降中国软件代码重复率很高5行及以上代码块重复频率增加了9

倍46%

的代码变更是新增行复制粘贴的行数超过了移动行数数据来源：

GitClear调查报告2019《中国软件和信息服务业发展报告》2024《人工智能生成的代码如何加剧技术债务》调查报告

代码重复度现状行业内存在大量代码复用的现象缺乏创新性和高

质量的原创性开

发加重开发者的运营负担中国的软件代码重复率超过50%数据来源：

中国软件协会代码重复率上升增加缺陷及安全漏洞一处有漏洞缺陷则多处风险

，干扰安全审查

，威胁系统安全。隐性风险：维护成本激增、缺

陷引入概率提升3-

5倍

代码重复度高的危害安全隐患、研发效率低下、技术债务堆积：“代码重复是研发效能的隐形杀手”代码重复度高会带来维护、

可读性、

性能及安全多方面的问题变更需多处同步，易出错

，且代码库复杂

，阻碍维护升级干扰业务逻辑理解，破坏代码结构

，影

响团队协作增加内存占用

，拖慢程序

，降低响应速度影响系统性能增加维护成本可读性差

代码重复度检测：

技术路线演进传统静态分析/人工审查→传统机器学习模型→code

bert/codeT5深度学习模型→codeT5+融合大语言模型

CodeBERT：

纯编码器架构（encoder-only），专注于代码理解任务

CodeT5

：编码器-解码器架构（encoder-decoder）

，统一支持代码的理解和生成任务

需要对代码进行特征提取

，将其转换为特征向量

使用决策树、

支持向量机等算法训练模型，自动学习特征

依赖人工经验

，逐行检查代码

，效率低

传统静态分析工具基于规则匹配和语法分析

，能识别简单重复模式文本→结构→

语义

→

意图

模型融合

：将CodeT5和大语言模型参数或特征融合

，构建更强模型深度学习模型自动学习深层特征

，

有效识别复杂

克隆-黑箱、资源消耗大通过深度神经网络自动从代码结构

中提取高级特征

，

能有效识别复杂

和深层的逻辑重复

，

但模型训练成

本高且像一个

“黑箱”。全面深度基于强大代码语义理解的检测技术利用在海量代码上预训练的大模型作为基石

，深度融合下游任务

，实现了对代码语义和功能级别的深度理解与重复识别

，代表了该领域的最高技术水平和发展方向。CodeT5+融合大模型代码重复度治理实践基于特征工程的机器学习模型依赖专家经验构建代码特征

，

并利用传统机器学习模型进行决策

，

在准确性和可解释性上取得了平衡

，但性能上限受限于特征质量。codebert每个代码片段生成向量

-

>

计算所有向量对的相似度（如余弦相似度）

-

>设定一个阈值

，高于该阈值的判定为重复似度

。

特征选择和权重设计依赖专家经验基于预定义规则进行快速

、

轻量的代码结构匹配

，

擅长发现表面相似的代码克隆

，

但缺乏深层次的语义理解。基于规则和模式

（结构）的快速表面克隆检测依靠专家特征和传统模型的智能平衡方案-依赖专家经验CodeT5codebertGraphCodeB

ERTUniXcoder向量相似度阈值对比语义理解可迁移性迁移性差语法层面静态代码扫码工具从字符匹配到数值比较的初步转变数据处理数

构

code

bert（代码库）

语

量代码变更行特征行为、时间特征生成义向造据集通过预训练代码模型生成特征向量

，结合多种相似性算法、代码变更行和提交时间相关等信息构建多维特征空间

，并深入评估多种机器学习模型的性能。分类模型14分类模型2分类模型3代码克隆类型（如精确克隆、近似克隆等）持续标注路线图：代码库

→code

bert生成语义向量

→计算相似度

→分类机器学习模型

→效果评估

模型架构模型指标评价模型指标评价模型指标评价分类机器学习模型计算语义相似度特征特征工程5321基于我的实际业务情况：u

追求一定速度u

资源有限u

打标量有限受限于高昂的计算资源需求和大量标注数据的依赖性

为什么选择code

bert？构造征工程-相似度特征从公司代码库提取两次代码提交内容→加载CodeBERT模型→对提取的代码进行分词器处理→通过CodeBERT输出CLS

向量→输出平均池化向量→计算两次提交代码对应的向量相似度。欧式距离相似度、曼哈顿距离相似度、余弦距离相似度、编辑距离相似度、文件名编辑距离输入

分词器codebert模型特征类型特征名commit

1commit2生成语义向量相似度特征两组向量计算相似度CodeBER

T模型平均池化向量各类

相

似

度

结果公司Git代码库信息提取CLS向量...|行数|差时间戳时间月/天

天数差特征距离月底天数代码变更特征变更行新增删除特征类型特征名代码变更行特征代码提交新增/删除行数、

代码提交变更行数、

代码提交变更行数差的绝对值、

代码提交新增/删除行数差的绝对值时间特征提交时间戳、

提交月份、

提交天

，提交天数差

，提交日期距离月底的天数

构造征工程-代码变更行、

时间特征痛点

1：高质量标注数据获取成本极高痛点2：人工标注耗时耗力

，效率低下痛点3：标注数据规模小

，难以支撑复杂模型训练

关键实践1如何高效打标

计算代码相似度→

设定阈值筛选候选克隆对→

开发者人工审查→

按克隆类型标注→

形成4237对高质量样本基于相似度阈值标注基于相似度阈值与人工审查的高效标注实践

关键实践特征工程的经验分享特征选择：在选择机器学习算法时的经验教训，如何根据数据特点和业务需求选择特征工程。基于代码克隆场景l

分析实际业务场景中的关键影响因素l

结合领域专家经验辅助决策l优先选择可解释性强、业务逻辑明确的

特征基于SHAPl通过SHAP值量化特征全局/局部重要性l可视化特征与目标变量的非线性关系l发现隐藏的数据模式（如交互效应）•领域知识驱动

：异常时间模式挖掘优于通用时序特征•模型限制补偿

：通过特征工程弥补预训练模型缺陷•可解释性增强

：代码变更绝对值差提供量化评估依据基于业务经验驱动基于可视化工具分析模型输入限制与特征扩充CodeBERT有输入长度限制致内容截断

，新增编辑距离相似

度和文件名编辑距离特征

，弥补信息损失

，助模型全面分析。代码变更行特征优化基于代码新增/删除行构造变更行并算差的绝对值

，提升模

型性能

，扩充该特征可增强模型对代码变化的捕捉能力。时间维度特征拓展因异常提交多在月末

，新增提交天数之差、距月底天数等时

间特征

，反映提交时间规律

，提高模型对异常提交的检测力。特征类型特征名相似度特征代码变更行特征时间特征

关键实践特征工程的经验分享基于样本打标、案例分析和讨论过程总结的经验，分别从代码相似度、变更行、提交时间三大类特征中扩充出新的子特征代码提交新增/删除行数代码提交变更行数代码提交变更行数差的绝对值、代码提交新增/删除行数差的绝对值提交时间戳、提交月份、提交天提交天数差

，提交日期距离月底的天数余弦距离相似度、欧式距离相似度曼哈顿距离相似度、编辑距离相似度、文件名编辑距离表2用于代码克隆检测的特征集代码变更行扩充模型RFGBMXGBoostCatBoost

关键实践特征工程的经验分享RF、GBM、XGBoost和CatBoost在项目一上使用不同扩充特征组时的表现整体来看

，各