DevData 2025 研发效能基准报告

思码逸研发效能基准报告北京思码逸科技有限公司2025年8月北京思码逸科技有限公司中关村智联软件服务业质量创新联盟E³CI软件研发效能度量工作委员会2025年8月北京思码逸科技有限公司中关村智联软件服务业质量创新联盟E³CI软件研发效能度量工作委员会任晶磊关钦杰、张超、王艳萍、李旺张乐、胡延军、任甲林近年来，这些问题更加频繁地出现在我与管理层的讨论中：在成本控制的范围内，我们研发团队到底把效能发挥到了什么程度?我们与行业里的佼佼者相比又身处何处?随着研发数据与效能度量领域的成熟，我们终于拥有了一面反映行业现状的镜子，回答这些问题可以不再凭感觉、拍脑袋。有效的管理始于准确的认知，而准确的认知离不开客观的数据。这正是我们发起并坚持每年发布《DevData研发效能基准报告》的初衷。去年，我们迈出了第一步。今年，我们带着更深的思考和更足的诚意，编纂了2025年度的报告。今年的报告仍然以客观数据为特色，从代码和项目管理工具中提取数据；辅以主观问卷，主观与客观数据相结合。之所以坚持这种调研方式，是因为研发效能是立体的、充满上下文的复杂系统。客观数据，来源于研发工具链的真实记录—代码提交量、需求交付周期、缺陷的密度究竟是多少?主观问卷，收集的是从业者的体感与实践。正是这种结合，让我们的报告得以从“数据”走向“洞见”,从“现象”走向“归因”。在整理这份来自200+企业、涉及数万名开发者的数据时，我们看到了许多有价值、让人深思的现象：·规模与效率并非简单的反比。与“越大越慢”的传统认知不同，虽然百人内小团队的效率最高，但超过500人的大团队，其生产率中位数反而高于100-499人的中型团队。·组织扩张的真正挑战在于贡献均衡。数据显示，代码贡献均衡度(团队中多少比例的成员贡献了80%的代码)会随企业规模扩大而持续下降，从百人内团队的39%降至五百人以上团队的31%。这提示管理者要警惕因规模扩张带来的知识孤岛与成员冗余的问题。·AI能提升效率，但对质量的作用尚待验证。应用Al的团队效率确实有提升，代码生产率中位数提升了17%。但在质量方面，约40%的企业反馈AI“效果不明显”,说明其在处理有复杂依赖和知识的质量保证工作时仍面临挑战。·行业对AI的认知从狂热走向务实。尽管AI带来了客观的生产率提升，但企业普遍反馈实际效能提升在“20%以下”或“不明显”。这表明，行业已从早期的高期望回归理性，开始务实地看待Al应用的实际效果。·行业整体的交付能力进步。超过46%的企业迈入了交付能力“高等级”行列，这背后是无数团队对DevOps、持续集成和交付等理念的积极探索与实践。限于篇幅，这里不赘述报告内容，正文里会有更多数据与洞察。您可以将这份报告作为一面镜子，对照自身团队；可以把它看作一份地图，找到前进的方向；也可以把它当作一个工具箱，从中汲取优化团队、驱动变革的灵感与方法。在此，我谨代表思码逸，向所有参加本次调研的企业、管理者和开发者们，致以最诚挚的感谢!是你们的开放与信任，构筑了这份行业报告的基石。路漫漫其修远兮，吾将上下而求索。看见，认知，改进—这趟基于数据的研发效能探索之旅，让我们一路推荐语当我们谈论研发效能，并试图把握行业的脉搏与基准时，一份基于客观数据采集、采用科学方法分析，并能为实践提供明确指引的调查报告，其价值不言而喻。去年，《DevData研发效能基准报告》以其开创性的方式——以企业真实研发数据为核心，结合严谨调研与分析—为我们提供了国内首个研发效能基准。它不仅打破了依赖主观问卷的传统局限，更带来了令人信服的客观视角和可参考的具体基线。今年，我们欣喜地迎来这份报告的2025版。这份全新的报告并非简单的数据更新，而是吸纳了更广泛的企业和项目数据样本，使行业基准的画像更为全面和立体。在保持对“交付速率”、“交付质量”、“交付能力”等核心维度关注的同时，进一步扩展了分析指标和维度，挖掘出了更具价值的趋势和细节信息。对于“高效能团队共性”的实践和做法，新版报告也能结合AI等最新技术发展趋势，提炼出更具时效性和针对性的改进方向与实践建议。研发效能的提升是一个持续演进的过程，行业基准也需要不断刷新与校准。去年的报告开辟了道路，今年的报告则在这条道路上走得更深、更远。我推荐研发管理者、技术负责人、效能工程师以及所有关注研发效能提升的同仁阅读这份新版报告。它将是您理解当下国内软件研发效能基准、洞察发展趋势，并最终驱动团队效能突破、做出更明智决策的不可或缺的指南。张乐|腾讯研发效能与AICoding资深技术专家，《软件研发权威指南》主编在当下复杂多变的商业环境中，企业高管们面临着一系列严峻挑战。企业研发效能在行业中处于何种水平?技术投入怎样才能高效转化为商业价值?研发组织又该如何在跌宕起伏的周期中，始终担当起增长的稳定引擎?在此背景下，《DevData2025研发效能基准报告》极具参考价值。这份报告构建起多维度效能坐标系，不仅更新了关键效能指标的行业基准，还深入剖析了顶尖与普通效能团队在组织结构、技术栈选型、工程文化及关键实践等方面的差异。通过严谨的数据分析，报告清晰揭示了卓越开发者体验与业务韧性之间的强关联性，为效能提升提供了可验证的因果逻辑。对决策者而言，它既是精准定位自身效能水平的对标工具，更是技术资源投入、组织架构优化、未来竞争力构建的方向指引，以确保每一份技术投入都能精准锚定驱动业务增长的核心环节。中关村智联软件服务业质量创新联盟E³CI软件研发效能度量专委会秘书长我们正身处一场软件开发领域的深刻范式变革之中。如果说过去几十年，软件工程是从“手工作坊”走向“标准化流程”;那么在AI的催化下，它正以前所未有的速度，从一个依赖理念和框架的“管理时代”,跃迁至一个以数据和度量为基石的“实证主义时代”。Al正在重塑软件工程最核心的“生产”环节，这使得我们过往的认知和管理模式面临失效的风险。思码逸的《DevData研发效能基准报告》不仅是这场变革的忠实记录者，更是积极的推动者和思想引领者。它标志着我们终于拥有了像其他成熟工程学科一样的能力—基于大规模、跨场景的客观数据，来审视、理解和改进我们的工作方式，尤其是在AI这一最大变量的冲击之下。翔实的数据回答行业最关心的问题：AI究竟在多大程度上影响了交付效率和质量?我们该如何设计未来的组织、工具链和工作流，才能驾驭好这把“双刃剑”,最大限度地释放工程师的创造潜力?如果你也在思考这些关乎未来的命题，这份报告将为你提供极为宝贵的洞察与启示。肖然中关村智联软件服务业质量创新联盟秘书长、Thoughtworks中国区总经理在研发效能领域，感性的认知终将被客观的数据所取代。《DevData2025研发效能基准报告》正是这样一面不可或缺的行业明镜。它首次将主观体感与客观数据相结合，基于来自200+企业、数万名开发者的真实工具链数据，为我们揭示了规模与效率的复杂关系、组织扩张的真实挑战以及AI应用的理性现状。这份报告不仅回答了“我们身处何处”,更清晰地指明了“我们该去向何方”。对于任何致力于通过数据驱动实现研发精益化的管理者来说，这都是一份至关重要的战略地图。愿这份报告，能成为您探索之旅上那盏最亮的灯，照亮前路，启迪变革。关村智联软件服务业质量创新联盟研效度量分委会委员茹炳晟腾讯TechLead,腾讯技术委员会委员、中国计算机学会CCFTF研发效能SIG关村智联软件服务业质量创新联盟研效度量分委会委员《DevData2025研发效能基准报告》是一份打开我们衡量组织研发效能视野的宏大分析报告。从中可以清晰洞察，衡量研发能力应该从哪些维度、哪些关键指标入手，极大地缩短了我们在定义指标体系与定位问题自这份报告发布之初，我便高度关注。它不仅代表了整个行业对于研发效能指标定义的系统性基准，也为我们提供了宝贵的参考价值。通过这份报告，管理者不仅能够了解指标的标准定义，还可以结合行业数据，对比自己组织在每个指标维度中的位置，找到改进与突破的方向。更重要的是，这份报告展现出的新颖理念与实践方法，对于中国软件研发行业是一次重要的推动。“Allforone,oneforall”,分享才能创造更大的价值。希望每一位阅读这份报告的同行，都能从中获得养分与启发，共同促进研发效能体系的专业化与行业进步。徐陈飞|车企数字化研发效能度量技术专家作为一名从事多年软件研发体系建设及研发效能提升的工作者，非常清楚如何度量研发效能以及研发效能体系各维度数据的参考值是一个非常大的挑战。2024年的基准报告已经有了客观量化的效能坐标系，2025年的报告更是让人眼前一亮。新增的代码提交颗粒度、函数圈复杂度等指标，让效能画像愈发立体；LLM大模型在研发全流程的渗透数据，揭示了智能时代的效能新法则；不同行业、规模企业的效能差异分析，更让每个读者能精准锚定自身位从"建立基准"到“动态优化",这份报告始终站在实践前沿。它不仅是数据集合，更是一面镜子—照见行业进步，也映出个体短板。对于每一位技术管理者、研发效能体系建设者及相关从业人员，这既是效能提升的指南针，更是数字化转型的解剖刀。值得每一位软件从业者深读。薛增奎|科大讯飞效能平台首席技术专家作为技术管理者，我们的精力常常被分散在项目排期、跨团队沟通和各种细节问题上。团队到底快不快?代码质量行不行?很多时候我们依赖的是直觉和“体感”。但直觉会骗人，团队成员之间的“体感”也可能天差地别。我们一直在寻找一个客观的“参照物”,思码逸出品的《DevData研发效能基准报告》恰好满足了这一点。值得一提的是，今年贝壳也参与了这份基准报告的调研，贡献了我们团队的真实数据，这让报告对我而言不仅是行业洞察，更是一面镜子。它就像一份全面的“团队体检报告”,用众多企业的客观数据告诉我，我们团队的“交付周期”、“单测覆盖度”这些关键指标，在行业里到底处于什么水平，这样“模糊的感觉”就被清晰地量化了。我们能直观地看到改进点，从无休止的内部争论中抽身出来。这份报告，是能让我把力气花在刀刃上的实用工具。贾琳|贝壳研发效能高级架构师基线的构建是一个长期积累的过程，《DevData研发效能基准报告》包含了行业普适与特有的knowhow,助力组织制定合理的管理与改进目标。李鹏汇川技术研发效能与测试负责人 /在这份《DevData研发效能基准报告》中，你将通过详实数据洞悉行业标杆，以深度指标精准评估自身优势，从而发现提升效能的关键路径。正所谓“知己知彼，百战不殆”,它是你在新一年中追求研发卓越的最当产业步入成熟，接踵而至的是对效能的极致追求。技术钱效管理的体系化、标准化和精细化是未来10年的挑战和机会。推荐阅读《DevData研发效能基准报告》,它是我经历过的最佳实践。2025年，我们将全力打造研发一体化效能平台，推行能力复用平台，全面落实研发效能度量，并借助Al全面提升研发效能，达成研发十倍速提升目标。《DevData研发效能基准报告》为我们提供了必不可少的行业基准参考，助力我们制定行之有效的效能提升策略。研发资源是企业的核心资产，研发效能则直接决定了资源利用率的高低。过去我一直在寻找是一个用于衡量团队研发效能水平的指标，但一直没有确切答案，直到遇到了《DevData2025研发效能基准报告》。在此基础上，我设计了一套研发效能体检表，通过量化指标清晰呈现出团队在行业中的位置—哪些维度已经做得足够好，不必继续“卷”,哪些方面还有薄弱点，还需要推动改进。这套研发效能体系最终获得公司高度认可，成为研发管理的重要参考依据。06结语4401调研简介1.2基准数据概览1.3高效能团队特征02基准数据2.1交付速率2.2交付质量2.3交付能力03AI应用专题3.1企业LLM模型的落地应用时长3.2LLM模型应用的价值期待和效果评估3.3LLM模型在辅助编程领域的应用3.4应用LLM模型的企业代码生产率更高3.5LLM应用对代码质量有积极影响04综合分析4.1不同行业的代码和需求交付效率存在差异4.2大规模企业更需关注人员贡献均衡性4.3小规模企业在效率表现上更优4.4敏捷开发模式引领人均生产率提升4.5短迭代周期提升需求交付效率4.6最佳实践的应用对代码生产率有积极影响4.7DevOps实践对持续交付的优化作用5.1所属行业分布415.2企业及团队规模分布4105受访企业特征5.3开发模式分布425.4迭代周期分布425.5效能度量和管理中的挑战42《DevData2025研发效能基准报告》调研简介1.1.1指标定义认知域指标名称单位定义交付速率代码当量#对每次代码提交所做逻辑修改的量化，反映代码产出规模及逻辑复杂度。通过将源代码编译为抽象语法树计算，避免源代码噪音(如格式、字面修改等)影响。需求吞吐量个/月研发团队在统计周期内完成的需求数量(本报告按月计算),反映需求交付产能。需求交付周期天从需求创建到发布的时长，反映研发团队对客户/业务需求的响应速度。需求颗粒度代码当量单个需求的大小/规模，反映需求开发复杂度。通过需求关联的代码当量，评估需求实现的开发工作量，可用于优化对需求颗粒度的估算。代码生产率代码当量/人月研发团队的人均代码产出速率(本报告按月计算人均代码当量)。开发过程稳定性离散系数用于衡量代码生产率离散程度(月度人均当量标准差与均值之比)。系数大，开发过程波动大；系数小，开发过程相对稳定。代码贡献均衡度%统计周期内，新增代码当量中，贡献总计80%以上代码当量的成员占总团队人数的比例。反映团队代码生产力的鲁棒性和知识集中程度，可用于识别人力风险。代码提交颗粒度代码当量单次代码提交(commit)中包含代码当量。值越小，代表变更越小、越专一。交付质量单元测试覆盖度%测试函数直接/间接调用的函数占非测试函数个数的比例。注释覆盖度%有注释的函数占所有函数个数的比例。代码不重复度%无代码重复的函数占所有函数个数的比例。不重复度越高，代码中重复函数越少，可维护性越好。《DevData2025研发效能基准报告》调研简介认知域指标名称单位定义交付质量重点问题密度个/千当量平均每新增一千代码当量，通过静态扫描识别的阻塞和严重问题个数。反映代码内质量保证水平。缺陷修复工作量代码当量平均修复一个缺陷所花费的工作量(含内部测试发现缺陷及线上故千当量缺陷密度个/千当量统计周期内创建的缺陷(内部测试过程发现的bug)数量/统计周期内新增当量。函数圈复杂度%按代码库分区统计，函数在如下4个圈复杂度区间的分布占比：10以下，10-20,20-50,50以上。交付能力部署频率次/时长一段时间内，研发团队成功将代码部署到生产环境并发布给用户的频率。变更前置时间天从代码提交到在生产环境中成功运行所需的平均时间。服务恢复时间天生产环境中发生故障到恢复服务的平均时长。变更失败率%导致生产失败(如服务降级/中断)需补救的部署占比(部署失败次数÷总部署次数)。1.1.2分析方法绝对中位差(MedianAbsoluteDeviation,MAD)是一种用于衡量数据离散程度的统计量，它通过计算数据点与中位数的绝对偏差的中位数来反映数据的分布情况。在本报告中，采用3倍MAD的方法来识别并去除离散值。具体步骤如下：确定阈值为3×MAD,将绝对值大于首先计算数据确定阈值为3×MAD,将绝对值大于首先计算数据集的中位数计算这些绝对偏差的中位数，即MAD值这种方法能够有效识别数据中的异常值，有助于更准确地分析数据的集中趋势和整体特征。《DevData2025研发效能基准报告》调研简介1.2基准数据概览认知域下四分位值中位值上四分位值平均值交付速率月需求吞吐量(个)20人以下21-50人50人以上需求交付周期(天)*7需求颗粒度(代码当量)代码生产率(代码当量/人月)开发过程稳定性*代码贡献均衡度(%)代码提交颗粒度(代码当量)4交付质量单元测试覆盖度(%)9.06%注释覆盖度(%)30.02%34.14%44.07%37.33%代码不重复度(%)77.79%80.02%84.87%重点问题密度(个/千当量)*缺陷修复工作量(代码当量)*7千当量缺陷密度(个/千当量)*函数圈复杂度(企业圈复杂度10以下的函数97.27%97.97%98.50%97.80%认知域指标(单位)下四分位值中位值上四分位值交付能力部署频率介于每月1次到每6个月1次之间介于每周1次到每月1次之间按需(每次多次部署)变更前置时间介于1个月到6个月之间介于1周到1个月之间介于1天到1周之间服务恢复时间介于1周到1个月之间介于1天到1周之间不到1天变更失败率46%-60%0%-15%注：带*的指标，值越小越好；其余指标值越大越好。《DevData2025研发效能基准报告》调研简介1.3高效能团队特征认知域参数评分量表交付速率需求交付周期(天)Q1-Q3代码生产率(代码当量/人月)Q1-Q3开发稳定性(代码生产率离散系数)Q1-Q3代码贡献均衡度(%)Q1-Q3交付质量单元测试覆盖度(%)Q1-Q3注释覆盖度(%)Q1-Q3代码不重复度(%)Q1-Q3重点问题密度(重点问题数/千当量)Q1-Q3千当量缺陷密度(个/千当量)Q1-Q3缺陷修复工作量(代码当量)Q1-Q3函数圈复杂度10以上函数的占比*3+10~20函数的占比*2+20以上的数占比*1交付能力部署频率按需(每天多次部署)介于每周1次到每月1次介于每月1次到每6个月1次变更前置时间介于1天到1周之间介于1周到1个月之间介于1个月到6个月月之间服务恢复时间不到1天介于1天到1周之间介于1周到1个月之间变更失败率0%-10%21%-40%《DevData2025研发效能基准报告》调研简介交付速率开发过程稳定性代码贡献均衡度(%)交付质量单元测试覆盖度(%)注释覆盖度代码不重复度重点问题密度(个/千当量)千当量缺陷密度(个/千当量)缺陷修复工(代码当量)圈复杂度(10以下的函数占比%)交付能力部署频率变更前置时间服务恢复时间变更失败率(%)按需(每天多次部署)介于1天到1周之间不到1天《DevData2025研发效能基准报告》基准数据2.1交付速率2.1.1需求吞吐量2023年月需求吞吐量(个)团队规模下四分位值中位值上四分位值平均值20人以下621-50人2023年月需求吞吐量(个)团队规模下四分位值中位值上四分位值平均值20人以下621-50人50人以上2024年月需求吞吐量(个)团队规模20人以下4821-50人850人以上《DevData2025研发效能基准报告》基准数据图2-1不同规模的受访企业2024年需求吞吐量数据分布图2-2不同团队规模的受访企业年度需求吞吐量平均值对比分析观点小型团队(20人以下),下四分位值(10)、中位值(20)、上四分位值(30)差距相对较小，说明数据离散程度不大，团队效率相对稳定。大型团队(50人以上),平均值(44)远超中位值(23),且从每十分位值看，P10到P100跨度较大，表明少数高负荷月份掩盖了常态低效问题，需警惕“虚假繁荣”。●数值变化：团队规模与需求吞吐量提升并非正相关20人以下50人以上管理难度、团队间差异扩大(十分位值跨度大),整体稳定性弱基准指标应用建议企业可依据自身团队规模参考对应数值。如20人以下团队，可将中位值20作为参考，努力达到或超越该水平；50人以上团队，若处于行业领先追求，可瞄准上四分位值64及以上。对于需求吞吐量较低的团队(如低于下四分位值),需分析是否存在流程瓶颈、人员技能短板等问题。可通过引入敏捷开发方法、加强人员培训等方式，提升团队处理需求的能力。·动态管理：随团队发展和业务变化，定期评估月需求吞吐量指标，根据实际情况调整管理策略和资源配置，以持续提升团队交付效能，例如，●团队扩张后，重新分配资源(如拆分子团队，明确需求交付职责)。·业务需求变复杂时，调整需求管理策略(如增加需求预研环节，提前化解风险),持续适配交付效能。《DevData2025研发效能基准报告》基准数据2.1.2需求交付周期需求交付周期是指平均一个需求从创建到上线所经历的时间跨度，以天数计量。它反映了研发团队将业务需求转化为可交付成果的速度，是衡量团队响应能力的关键指标，合理的需求交付周期需兼顾“交付效需求拆分颗粒度、建立标准化交付流程、强化前置质量管控(如需求评审、技术方案预研)等手段，在确保需求符合业务目标与用户期望的前提下，实现可预期的周期管理。需求交付周期(天)年度下四分位值中位值上四分位值平均值972024年度需求交付周期(天)每十分位值525巧50中位值■2024年■2023年平均值中位值15天为行业效率基准，75%需求可在30天内交付(上四分位值),但2024年长尾需求(异常值)激增，或因大规模需求未拆解、跨团队依赖、规划粗放等，整体效率被拉低；平均值24天右偏，对比2023年平均值21天增加了25%,反映需求复杂度分化加剧，简单需求交付快，复杂需求拖长整体周期。2024年“中位值/平均值”比值从2023年的71.4%(15/21)降至62.5%(15/24),行业均衡性走弱，说明需求交付周期分化加剧，需关注复杂需求管理与流程优化，避免“少数复杂需求拖累整体效率”。·设定合理范围：企业可参考中位值15天，将其作为需求交付周期的阶段性目标，追求在该时间范围内完成需求交付，以达到行业中等偏上水平。若企业处于快速发展或竞争激烈领域，可对标下四分位值7天，提升交付速度。·差距分析：交付周期较长的企业(超过30天),需深入分析需求管理、开发流程、资源分配等环节存在的问题，借鉴周期较短企业的优秀实践，如敏捷开发模式、高效的需求优先级排序等。·持续优化：定期回顾和调整需求交付流程，结合自身业务特点和发展阶段，动态调整交付周期目标，持续提升研发交付效率。2.1.3需求颗粒度需求颗粒度是指将需求拆解后，以代码当量的大小衡量的需求规模。它体现了需求被细化拆分的程度，是衡量研发团队需求管理精细度和项目可控性的关键指标。合理的需求颗粒度需兼顾“开发效率”与“管理复杂度”。团队需综合评估需求规模、功能关联性、技术实现难度等多重因素，通过运用合适的需求拆分方法、建立需求颗粒度标准、加强需求规划与评审等手段，在确保需求可清晰理解与高效实现的前提下，实现需求颗粒度的合理管控。年度下四分位值中位值上四分位值平均值《DevData2025研发效能基准报告》基准数据2024年度需求颗粒度(代码当量)每十分位值4000中位值平均值■2024年■2023年200分析观点分“精细化”与“粗放式”并存的现状。为精细化，能够更好地把控需求。部分企业的需求颗粒度较大，需求规划相对粗放，拆分能力有待提升，行业内需求拆分策略存在多样化的特点。基准指标应用建议·设定合理范围：企业可将中位值122作为参考，将需求颗粒度控制在该水平附近，使需求规模适中，便于开发进行任务分配与进度跟踪。若追求更精细化管理或针对优化型需求，可对标下四分位值24,对需求进行更细致拆分。·策略调整：对于需求颗粒度大于上四分位值492的企业，需重新审视需求拆分策略，避免因需求过大导致开发周期变长、风险增加。可引入敏捷需求拆分方法，将大需求分解为多个小的、可独立交付的功能·动态优化：企业依据项目特点、团队规模和技术能力等因素，动态调整需求颗粒度。例如，按项目周期复盘需求拆分。迭代开发时遇大型项目若小颗粒需求多但交付慢，优化拆分标准(如合并关联子需求)。提前规划“分层拆分”(先拆大模块，再细化子需求),适配团队规模(大团队可承接稍大颗粒，小团队聚焦小颗粒),持续匹配业务与研发节奏。《DevData2025研发效能基准报告》基准数据2.1.4代码生产率代码生产率是指平均每个开发人员在一个月内产出的代码当量，以代码当量/人月计量。它反映了研发团队出速度”与“代码质量”。团队需综合评估人员技能水平、开发工具与环境、项目复杂度等多重因素，通需求的前提下，实现可持续的代码生产率提升。代码生产率(代码当量/人月)年度下四分位值中位值上四分位值平均值2024年度代码生产率(代码当量/人月)每十分位值P80P100代码生产600030004500350030005000中位值平均值■2024年■2023年+26%+18%《DevData2025研发效能基准报告》2024年相较于2023年，代码生产率中位值同比+26%、平均值同比+18%,反映了行业整体代码产出效率提升，企业通过效能提升举措，在“产出速度”上有明显突破。2024上四分位值(5083)略超2023年(5003),且箱线图显示数据更集中于高生产率区间，说明高产出企业占比增加，同时企业间离散程度收窄，行业代码生产率的均衡性与头部引领效应同步增强。企业可将中位值作为参考目标，2024年中位值3773意味着若能达到该水平，企业代码生产率处于行业中等偏上位置。追求卓越的企业可对标上四分位值5083,努力向行业领先水平看齐。代码生产率低于下四分位值2768的企业，需深入剖析原因，如是否存在技术瓶颈、开发流程繁琐、人员技能不足等问题。可通过技术培训、流程优化、引入高效开发工具等方式提升代码产出效代码生产率受多种因素影响，企业应定期监控该指标，结合业务需求和技术发展趋势，持续优化研发管理策略，激励团队不断提升代码产出效率和质量，例如，建立“三维提效机制。人员侧工具侧流程侧码规范，高级攻关性能优化),成果兑换培训资源)。引入低代码平台(覆盖简单需求)、代码生成器(自动生成重复模块),每季度开展“流程瘦身”,砍掉低效环节(如冗余文档编写),试点“需求-开发-测试”并行2.1.5开发过程稳定性人均生产率离散系数是指月人均代码当量波动的带宽，通过12个月的人均代码当量的标准差除以均值计算得出。它反映了研发团队成员人均代码产出在时间维度上的稳定性(值越低，波动越小),是衡量团队内部生产效率均衡性的关键指标。理想的人均生产率离散系数需兼顾“个体差异合理性”与“团队产出稳定性”。团队需综合评估人员技能成长曲线、项目任务分配合理性、技术架构变动等多重因素，通过优化人员技能培养体系、合理分配项目任务、稳定技术架构等手段，在确保团队成员能力充分发挥且产出相对均衡的前提下，实现人均生产率离散系数的合理管控。《DevData2025研发效能基准报告》基准数据0.340.330.300.29中位值0.35K0.320.310.300.280.27平均值人均生产率离散系数年度下四分位值中位值上四分位值平均值2024年度人均生产率离散系数每十分位值分析观点行业内团队人均生产率稳定性略有波动，多数团队波动控制有效，但仍有局部差异。人员技能成长不均、任务分配波动等，生产率稳定性差，而多数团队离散系数集中，行业整体在“个体差异与团队稳定”平衡上仍有优化空间。基准指标应用建议在该水平附近，说明团队人均生产率稳定性处于行业中等水平。追求更高稳定性的企业可对标下四分位值0.21。·差距分析：离散系数高于0.5的企业，需关注团队内成员生产效率差异过大的问题，分析是否存在任务分配不均、人员技能差距过大等情况，通过调整任务分配策略、开展针对性培训等方式提升团队整体稳定性。《DevData2025研发效流程侧推动“模块化稳定架构”,将高流程侧推动“模块化稳定架构”,将高工具侧引入“任务负载均衡系工具侧引入“任务负载均衡系统”,实时监控成员在办需预警并调整(如拆分大需求、协调资源支援)。人员侧每季度开展“技能-产出”化开发流程)。2.1.6代码贡献均衡度代码贡献均衡度，即贡献80%代码当量的人员占比，衡量团队协作健康度(值越高，贡献分布越均衡),是衡量团队资源利用效率的关键指标。合理的代码贡献均衡度需兼顾“核心人员价值发挥”与“团队全员参与度”。团队需综合评估项目特性、人员技能结构、任务分配模式等多重因素，通过优化任务分工、建立合理激励机制、促进知识共享等手段，在确保核心任务高效推进的同时，提升团队整体的代码贡献均衡性。代码贡献均衡度年度下四分位值中位值上四分位值平均值2024年度代码贡献均衡度每十分位值P100《DevData2025研发效能基准报告》基准数据40%50.00%35.00%站3000%警2500%0.00%4.55%代码贡献均衡度区间9.76%分析观点性呈现向好发展趋势。基准指标应用建议·设定合理范围：企业可将中位值作为参考，2024年中位值为36%,意味着若能将自身代码贡献均衡度控制在该水平附近，团队代码贡献均衡性处于行业中等偏上水平。追求更均衡协作的企业可对标上四分问题，审视任务分配和人员协作机制是否合理，通过调整分工、鼓励技术分享等方式，提升其他成员的代码贡献比例。贡献更加均衡。例如，打造“均衡协作生态”。动态调整随项目阶段(如攻坚期依赖核心、动态调整随项目阶段(如攻坚期依赖核心、迭代期侧重全员)、人员变动(如新老交替),灵活调整任务分配策略，持续推升代码贡献均衡度，护航团队协作成长侧设立“代码贡献导师制”,高产者带教低产成员(如分享高效编码、需求拆解技巧),每季度评选“均衡协作之星”(贡献分散且质量优的团队),树立标杆。每迭代开展“任务拆解共创会”,让成员自主认领适配需求(如新人选基础模块、资深开发挑复杂逻辑),配套“任务难度-贡献系数”换算，保障公平激励。2.1.7代码提交颗粒度理想的代码提交粒度应该平衡"可管理性"和"功能完整性"。小而有意义的提交是比较推荐的，但这并不意味着要盲目追求最小化提交。开发者需要根据项目的规模、团队的协作方式以及代码变更的性质来灵活调整提交策略，最终目标是保证代码的可维护性和团队的协作效率。2024年度代码提交颗粒度(代码当量)下四分位值中位值上四分位值平均值42024年度代码贡献均衡度每十分位值P10P20P100136从下四分位值(4)、中位值(18)和上四分位值(72)以及平均值(63)来看，数据离散程度较高。平均值远高于中位值和下四分位值，说明存在一些较大的代码提交颗粒度数据拉高了平均值，可能存在部分开发者一次性提交大量代码的情况。·大部分提交颗粒度较小：下四分位值和中位值相对较小，表明至少50%的代码提交颗粒度在18及以下，说明多数时候代码提交颗粒度处于较细粒度水平，但也有相当比例的提交颗粒度较大。·设定合理范围：可以参考中位值和四分位值来设定代码提交颗粒度的合理范围。例如，将代码提交颗粒度控制在中位值(18)左右或稍高，如10-60之间，作为一个较为理想的区间，既能保证功能完整性，又便于代码审查和问题追踪。·异常监控：对于超过上四分位值(72)的提交，需要重点关注。可以设置监控机制，当代码提交颗粒度超过一定阈值时，要求开发者说明提交原因，进行额外的代码审查，以避免因大颗粒度提交带来的潜在风险，如难以排查问题、增加合并冲突等。·培训引导：基于数据反映的情况，对开发者进行培训，强调合适代码提交颗粒度的重要性。鼓励开发者将较大功能拆分成多个小的、逻辑连贯的提交，遵循良好的代码提交规范，提升整体代码管理水平。《DevData2025研发效能基准报告》基准数据2.2交付质量2.2.1单元测试覆盖度单元测试覆盖度是被测试函数覆盖的函数数覆盖度需兼顾“测试全面性”与“测试有效性”。团队需综合评估代码复杂度、业务逻辑重要性、开发周期等因素，通过完善测试用例设计、采用合适测试策略(如白盒测试、黑盒测试结合)、利用自动化测试年度中位值上四分位值平均值2024年与2023年相比，下四分位值从6.61%升至9.06%,但中位值从15.14%降至12.79%,平均值从15.27%降至13.98%,上四分位值从20.08%降至19.67%。说明虽然部分企业单元测试覆盖度有所提升，但整体行业平均水平呈现下降趋势。·分布差异：2024年数据离散程度相对稳定，整体分布略向低覆盖度区间偏移，表明行业内部分企业单元测试覆盖度管理水平有所波动，可能存在测试资源投入不足或测试策略调整不当等情况。●设定合理范围：企业可将中位值作为参考目标，2023年中位值15.14%可作为追求达到的行业中等水平，追求高质量代码保障的企业可对标上四分位值20.08%及以上，努力提升单元测试覆盖度。·差距分析：覆盖度低于下四分位值9.06%的企业，需审视测试流程和资源投入，检查是否存在测试用例设计不合理、自动化测试未充分应用等问题，通过加强测试团队建设、优化测试方案等方式提升覆盖●持续优化：建立“双维度测试调优机制”,例如注释覆盖度是指有注释的函数在项目总函数个数中所占的比例，以百分比形式呈现。它是衡量代码可读性的关键指标，反映了代码逻辑被文档化解释的程度。理想的注释覆盖度需兼顾“代码理解便利性”与“注释维护成本”。团队需综合评估代码复杂度、人员流动情况、项目维护周期等因素，通过建立注释规范、加强代码审查中对注释的要求、采用自动化注释工具等手段，在确保代码逻辑清晰可理解且不过度增加维护负担的前提下，实现注释覆盖度的合理提升。注释覆盖度(%)年度下四分位值中位值上四分位值平均值《DevData2025研发效能基准报告》P9023.72%28.95%30.38%31.56%34.14%39.77%43.14%45.64%52.09%80.25%2024年与2023年相比，下四分位值从22.36%升至30.02%,中位值从29.12%升至34.14%,平均值从30.70%升至37.33%,上四分位值从32.98%升至44.07%。说明行业整体注释覆盖度有显著提升，更多项目重视代码注释工作。2024年数据分布整体向高覆盖度区间偏移，表明行业内企业在提升代码可读性方面取得较好进展，企业间注释覆盖度离散程度有所减小，整体水平趋于稳定提升。·设定合理范围：企业可将中位值作为参考目标，2024年中位值34.14%意味着若能达到该水平，代码注释覆盖度处于行业中等偏上位置。追求卓越代码质量的企业可对标上四分位值44.07%及以上。注释覆盖度低于下四分位值30.02%的企业，需加强代码注释管理，审视是否存在开发流程中对注释要求不明确、人员对注释重要性认识不足等问题，通过培训、完善规范等方式提升注释覆盖度。构建“动态注释优化机制”,例如工具辅助引入注释扫描工具(如工具辅助引入注释扫描工具(如Doxygen、Pyment),定期(每月)扫描代码库，生成“注释覆盖率+重点模块缺失报告”,针对复杂模块(如代码复杂度超阈值),自动触发“注释补全任务”,指派专人优人员流动响应有成员离职/新加入时，开展“代码注释交接评审”,由需求驱动释”,如解释算法实现思路、时，补充“历史背景注释”,说明功能演变原因，辅助后2.2.3代码不重复度代码不重复度是指项目中不重复函数在总函数中所占的比例，以百分比形式呈现。它是衡量代码可维护性的重要指标，反映了代码遵循“DRY(Don'trepeatyourself)”原则的程度。理想的代码不重复度需兼顾“代码复用性”与“功能实现简洁性”。团队需综合考量项目业务逻辑、开发人员习惯、代码重构成本等因素，通过建立代码复用规范、鼓励模块化开发、定期进行代码审查等手段，在确保功能高效实现且不引入过多复杂逻辑的前提下，实现代码不重复度的合理提升。年度下四分位值中位值上四分位值平均值88.22%91.46%84.97%77.79%80.02%84.87%2024年度代码不重复度(%)每十分位值P10P20P50P60P9065.50%72.93%79.37%80.02%81.52%83.75%85.60%88.79%93.20%2024年与2023年相比，下四分位值从79.26%降至77.79%,中位值从88.22%降至80.02%,平均值从84.97%降至78.87%,上四分位值从91.46%降至84.87%。说明行业整体代码不重复度有所下降，可能存在部分项目代码重复情况增多。·分布差异：2024年数据分布向低不重复度区间偏移，离散程度相对稳定，表明行业内企业在代码重复控制方面出现一定波动，部分企业可能在开发过程中对代码复用的重视程度有所降低。·设定合理范围：企业可将中位值作为参考目标，2023年中位值88.22%可作为追求达到的行业中等水平，追求高可维护性代码的企业可对标上四分位值91.46%及以上，努力提升代码不重复度。·差距分析：代码不重复度低于下四分位值77.79%的企业，需审视开发流程和代码管理策略，检查是否存在代码复制粘贴频繁、缺乏代码复用机制等问题，通过加强代码规范培训、引入代码复用工具等方式提升代码不重复度。《DevData2025研发效能基准报告》构建“全流程代码复用保障机制”,例如开发阶段引入代码查重工具(如思码逸Devinsight开发阶段引入代码查重工具(如思码逸Devinsight),开发人员提交“重复代码预警”,根据重迭代阶段每季度开展“代码复用复盘会”,梳理项目中复用率高的模块(如通用工具类),总结复用经验；对重复代码较多的功能，组织“重构攻坚”,拆解重复逻辑、封装复用组需求阶段2.2.4重点问题密度重点问题密度是指通过Sonar扫描出的阻塞和严重问题数量与千代码当量的比值，以“重点问题数/千当量”计量。它是衡量代码质量的关键指标，反映了单位代码量中存在的严重影响系统运行和稳定性的问题数量。理想的重点问题密度需兼顾“问题发现及时性”与“问题解决彻底性”。团队需综合评估代码审查流程、测试策略、开发人员技能等因素，通过强化代码静态分析工具使用、完善问题反馈与处理机制、提升人员质量意识等手段，在确保及时发现并有效解决重点问题的前提下，实现重点问题密度的合理降低。重点问题密度(重点问题数/千当量)年度下四分位值中位值上四分位值平均值2024年度重点问题密度(%)每十分位值P20P304.192024年与2023年相比，下四分位值从0.54升至1.04,中位值从1.28升至2.11,上四分位值从2.21升至3.60,平均值从1.71升至3.28。说明行业整体重点问题密度大幅上升，代码中严重问题数量显著增多。《DevData2025研发效能基·分布差异：2024年数据分布向高问题密度区间大幅偏移，离散程度增大，反映出行业内企业代码质量出现较大波动，部分企业代码中重点问题激增，可能存在开发过程质量管控不足等情况。企业可将中位值作为参考目标，中位值2.11可作为追求达到的行业中等水平，追求高质量代码的企业可对标下四分位值1.04及以下，努力降低重点问题密度。·差距分析：重点问题密度较高的企业，需全面审视开发流程和质量保障体系，检查是否存在代码审查不严、测试覆盖不足等问题，通过加强质量门禁、增加自动化测试等方式降低问题密度。●持续优化：构建“闭环式质量改进体系”,例如复盘机制会”,分类统计高频问题(如复盘机制会”,分类统计高频问题(如空指针、资源未释放),分析根源(如开发习惯、知识盲区)。针对空指针问题，组织“防御性编程培训”,讲解判库连接关闭流程),通过案例动态调优根据项目类型(如业务系统、工具类项目)差异化设定重点工具联动将Sonar与项目管理平台解决任务”,指派对应开发人员，设定解决时限(如阻塞性问题24小时内处理),任进行“发现-分配-解决”闭2.2.5缺陷修复工作量缺陷修复工作量(代码当量)是指为修复代码中存在的缺陷所投入的代码量，以代码当量计量。它反映了研发团队在修正代码问题上所花费的精力，是衡量代码质量以及研发过程中维护成本的关键指标。理想的缺陷修复工作量需兼顾“问题解决的完整性”与“资源投入的合理性”。团队需综合评估缺陷严重程度、代码架构、开发人员技能等因素，通过优化代码审查流程、提高测试覆盖率、采用高效的修复策略等手段，在确保缺陷得到有效修复且不浪费过多资源的前提下，实现缺陷修复工作量的合理控制。年度下四分位值中位值上四分位值平均值7725●数值变化：2024年与2023年相比，中位值增加了28%,平均值增加了53%。这表明行业内整体缺陷修复工作量有所增加，部分企业修复缺陷投入的代码量出现一定程度上升。·分布差异：从箱线图来看，2024年数据离散程度有所增大，存在较多偏离中位值的情况，反映出行业内企业在缺陷修复工作量上差异明显，部分企业可能面临代码质量问题较多或修复效率较低等状况。基准指标应用建议·设定合理范围：企业可依据自身情况参考相关数值，对标缺陷修复工作量(代码当量)的上四分位值68及以下，努力降低缺陷修复工作量。·查找原因：缺陷修复工作量较高的企业，需深入分析代码质量管控环节，检查是否存在需求理解偏差、开发过程缺乏质量把控、测试不充分等问题，通过加强需求评审、完善质量保障体系等方式减少缺陷产《DevData2025研发效能基准报告》基准数据缺陷分级响应将缺陷按严重度(致命、严重、一般)分级，致命缺陷1缺陷分级响应将缺陷按严重度(致命、严重、一般)分级，致命缺陷1严重缺陷4小时响应、12小时修复；一般缺陷8小时响应、24小时修复，通过明确质量回溯迭代会”,统计高频缺陷类型(如漏),针对接口问题，推动“接口契约测试自动化”;针率专项提升”,通过工具扫描根因分析闭环流程是否需优化),形成《缺陷根因-改进措施对照表》,不同圈复杂度区间的函数数量占比是指项目中处于各个圈复杂度区间(如10以下、10-20、20-50、50以上)的函数数量在总函数数量中所占的百分比。它是衡量代码结构复杂度的重要指标，反映了代码逻辑的难易程度与可维护性。理想的函数数量占比分布需兼顾“代码功能实现”与“代码可维护性”。团队需综合评估业务逻辑需求、开发人员技能、项目长期规划等因素，通过优化代码设计、遵循模块化编程原则、开展代码审查等手段，在确保实现业务功能的前提下，使函数数量在各复杂度区间分布合理，提升代码的可维护性。圈复杂度区间企业函数数量占比中位值上四分位值平均值10以下50以上《DevData2025研发效能基准报告》基准数据·分布情况：从数据来看，圈复杂度10以下的函数数量占比极高，下四分位值、中位值、上四分位值和平均值都在97%以上，说明大部分函数复杂度较低。随着圈复杂度区间升高，函数数量占比逐渐降低，圈复杂度50以上的函数数量占比极低。·行业趋势：整体反映出行业内代码函数倾向于保持较低的复杂度，以保障代码的可读性和可维护性，但仍存在少量高复杂度函数，可能是由于业务逻辑复杂等原因导致。企业可参考圈复杂度10以下函数数量占比的中位值97.97%,努力将大部分函数复杂度控制在该区间，以维持代码的良好可维护性。对于追求更高代码质量的企业，可对标上四分位值98.50%,进一步降低高复杂度函数占比。若企业圈复杂度较高区间(如20-50、50以上)的函数数量占比高于上四分位值，需对这些高复杂度函数进行分析，通过代码重构、拆分功能模块等方式降低其复杂度，提升代码整体质量。构建“复杂度全周期管控体系”,例如迭代阶段迭代阶段理”,统计各区间占比变化，数，组织“重构工作坊”,由评审阶段代码审查加入“复杂度占比”辅助理解)。编码阶段编码阶段集成圈复杂度检测工具(如SonarQube),开发时实时预警(复杂度超20自动提示),强制开发人员拆分函数 通过参数传递协作)。2.2.7千当量缺陷密度千当量缺陷密度是指代码提测后所产生的缺陷数量与千代码当量的比值，以“缺陷数/千当量”计量。它是衡量代码质量的关键指标，反映了单位代码量中潜在问题的数量。理想的千当量缺陷密度需兼顾“缺陷预防”与“缺陷修复效率”。团队需综合评估需求理解准确性、开发过程规范性、测试完备性等因素，通过加强需求评审、规范开发流程、提高测试覆盖率等手段，在确保及时发现并有效修复缺陷的前提下，实现千当量缺陷密度的合理降低。《DevData2025研发效能基准报告》基准数据2024年度千当量缺陷密度(代码当量)下四分位值中位值上四分位值平均值2024年度千当量缺陷密度(代码当量)每十分位值P20P30P70P90P1000.00060.00160.01110.15950.53852.3032分析观点●数值分布：下四分位值为0.004,说明有25%的企业千当量缺陷密度处于较低水平；中位值0.538表明一半企业的缺陷密度在该值及以下；上四分位值2.117和平均值1.787显示部分企业缺陷密度较高，整体数据离散程度较大，企业间千当量缺陷密度差异明显。基准指标应用建议行业中等水平。追求高质量代码的企业可对标下四分位值0.004,向行业领先水平看齐。代码审查不严、测试用例设计不合理等问题，通过完善质量管控体系、提升人员技能等方式降低缺陷密集成实时缺陷预警工具集成实时缺陷预警工具(如Sonar插件),代码提交前自动检测潜在缺陷(如空指针、未处理异常),触发“缺陷预修复提示”,引导开发人员编码时主动规避。建立“缺陷密度动态阈值”,按项目类型(如工具类/业务系统)设不同千当量缺陷密度红线，超阈值自动启动“测试增强流程”(如增加探索性测试、引入第三方漏洞扫描),持续挤压缺陷生存空间，保障代码质量。推行“需求-测试双向追溯”,需求评审时同步设计测试点(如“用户下单”需求，对应“库存扣减校验”“价格计算验证”测试用例),需求变更时联动更新测试用例，从源头减少缺2.3交付能力本报告采用部署频率、变更前置时间、服务恢复时间以及变更失败率共四项指标来衡量受访企业研发团队的交付能力。指标定义及等级结合《2024:AccelerateStateofDevOps》报告以及思码逸对行业调研的数据情况，对指标表现进行了高、中、低等级的分级。其中，部署频率和变更前置时间度量了研发团队持续交付的吞吐量水平，而变更失败率和服务恢复时间反映了研发团队持续交付的稳定性。效能等级部署频率变更前置时间服务恢复时间变更失败率高按需(每天多次部署)介于1天到1周之间不到1天0-10%中介于每周1次到每月1次之间介于1周到1个月之间介于1天到1周之间低介于每月1次到每6个月1次之间介于1个月到6个月之间介于1周到1个月之间21-40%2.3.1各项交付能力分布·部署频率：指单位时间内(如每月、每季度)系统或应用程序进行部署的次数，是衡量研发团队交付效率和快速响应能力的指标。较高的部署频率意味着团队能够更频繁地将新功能或修复的问题推向生产环境，体现了快速迭代的能力。·变更前置时间：是从决定进行代码或系统变更到实际实施变更所花费的时间，反映了研发团队对变更的准备和执行效率。前置时间越短，说明团队响应变更需求的速度越快，流程越顺畅。·服务恢复时间：指系统或服务出现故障后，恢复到正常运行状态所需的时间，是衡量系统可靠性和团队故障处理能力的指标。服务恢复时间越短，表明团队应对故障的能力越强，对业务的影响越小。·变更失败率：是指在所有进行的变更操作中，失败的变更所占的比例，体现了研发团队变更操作的稳定性和质量。变更失败率越低，说明团队在变更过程中的把控能力越强，变更实施更可靠。《DevData2025研发效能基准报告》基准数据120%120%80%60%40%61%20%32%0%24%部署频率变更失败率58%85%100%13%分析观点于中等水平，还有22%的企业处于低水平，这部分企业在交付效率上还有较大的提升空间。业处于中等水平，11%的企业处于低水平，说明在变更流程效率方面，多数企业还有进步的余地。畴。但仍有小部分企业，9%处于中等水平，6%处于高水平，需要提高变更过程的质量把控。基准指标应用建议·明确目标：企业可根据自身情况，参考图中高能力占比企业的水平，设定提升目标。如在部署频率上，可向24%的高能力企业看齐，提高交付频率；在变更失败率上，维持低失败率水平，确保变更质量。更审批、准备流程；服务恢复时间较长的企业，可完善故障预警和应急处理机制。维流程，提升整体交付能力。2.3.2交付能力整体水平级表示交付能力处于平均水平；低等级则意味着交付能力有待提升。《DevData2025研发效能基准报告》基准数据29低42%66%10%20%30%40%50%60%70%企业数量占比0%高中分析观点企业从较低水平向较高水平迈进。·趋势解读：这一变化表明行业内企业在研发管理、运维优化等方面的改进措施取得成效，越来越多企业重视并提升自身交付能力，以适应市场对快速、稳定交付的需求。基准指标应用建议·明确自身定位：企业可根据自身在综合交付能力分布中的位置制定策略。处于低等级的企业，需全面审视研发、部署和运维流程，查找短板，如是否存在需求管理混乱、部署流程繁琐等问题，针对性改进。·对标优秀企业：处于中等级的企业，可向高等级企业学习先进经验，如引入敏捷开发模式、自动化部署工具等，提升交付效率和质量，争取向高等级迈进。争优势，应对市场变化和新的挑战。软件研发行业对LLM(大语言模型)的应用探索日益深入，本专题将通过主观数据(企业反馈、预期等)与客观数据(代码生产率、质量等实际度量指标)相结合的方式进行分析，以全面呈现LLM在行业中的应用现状与价值。·从企业应用LLM的落地时长来看，多数企业已开启相关探索；·在价值期待与效果评估方面，企业期望借助LLM实现降本增效，但效果评估仍处于探索阶段；人人人《DevData2025研发效能基准报告》IAl应用专题80%的受访企业已经开始引入LLM大语言模型辅助研发，36%的企业已经应用超过一年。3.1企业LLM80%的受访企业已经开始引入LLM大语言模型辅助研发，36%的企业已经应用超过一年。您所在组织应用LLM大语言模型的时间?20%不超过3个月3-6个月6-12个月3.2LLM模型应用的价值期待和效果评估大部分受访企业都期望LLM大语言模型能够帮助研发降本增效，其中85%的企业希望能提升编程效率。引入AI之后的提效成果评估目前在业内仍处于探索阶段，26%的企业直接比较交付的结果指标，24%的企业关注用户数、采纳率等间接指标，而另外的半数企业尚未找到合适的评估方法。您所在的组织期望让LLM发挥哪些方面的价值?提升开发(编程)的工作效率47%47%42%49%42%49%标的变化，26%的方法进行比较，50%间接比较：通过用户数、活跃用户数、推影响，24%《DevData2025研发效能基准报告》IAI应用专题3.3LLM模型在辅助编程领域的应用采取，也有部分企业已经采取了相应的措施。目前企业没有更大范围落地AI辅助编程的最主要原因仍然是受限于模型能力有限，其次是高昂的成本高昂以及企业内部运营和培训不足。您所在组织对于AI生成的代码采取了哪些措施?23%23%22%22%目前没有更大范围落地AI辅助编程的主要原因在哪里?32%23%基础大模型无法有效结合私有信息(如公司代码/文档)在使用公有大模型(如GPT-4),但实际效果依然不够好32%23%24%23%在使用私有开源大模型(如Mixtral/Llama),但其能力不足24%23%21%30%硬件成本高昂 21%30%3.4应用LLM模型的企业代码生产率更高在代码生产率方面，主观数据中(小节3.4.1)部分企业反映应用LLM后效率有中高幅度提升，客观数据(小节3.4.2)显示已落地应用LLM的企业代码生产率中位值较未应用企业有明显增幅，二者相互呼应，凸显LLM对代码产出效率提升的实际价值。后续可通过优化应用场景、深化流程融合(如从代码生产延伸到需求分析、测试等环节),推动交付效率向更高层级突破。3.4.1LLM应用对软件交付效率提升的效果分布(主观数据)反映LLM在部分场景中能实现中高幅度提效。成因(如应用场景、企业数字化基础等)。《DevData2025研发效能基准报告》IAI应用专题LLM应用于软件产品交付(可以是研发过程中任何一个阶段)后的实际“效率提升”情况?40%35%34%30%25%25%20%以下提效不明显20-39%40-59%提升80%以上60%-79%3.4.2LLM落地对代码生产率的直接影响(客观数据)将企业应用LLM的情况分为两类：尚未应用LLM与已落地应用LLM。数据显示，尚未应用LLM的代码生产率中位值为3552,已落地应用LLM的代码生产率中位值达4173,代码生产率增幅约17%。这表明，LLM应用对代码生产率有显著提升作用，让企业在代码产出效率上更具优势。力开发人员快速完成重复性、基础性编码工作，减少编码耗时；同时，可智能审查代码，提示潜在错误与优化建议，兼顾代码质量与开发效率。LLM的落地应用与代码生产率中位值417340003552350030002500200050004500对企业研发管理的启示对于期望提升代码生产率的企业，LLM是值得引入的技术工具：发人员掌握工具用法，让LLM赋能编码效率与质量，推动团队产出升级。力(如结合业务场景定制prompts、拓展自动化应用环节),巩固并扩大代码生产率优势，保持研发效能领先。《DevData2025研发效能基准报告》IAI应用专题3.5LLM应用对代码质量有积极影响动“过程质量”向“交付质量”转化，缩小企业间质量提升差距。3.5.1LLM对软件交付质量提升的效果分布(主观数据)13%企业实现20-39%提升，6%实现40-59%提升，4%实现60-79%及80%以上提升。LLM具备优化质量的潜力。LLM应用于软件产品交付(可以是研发过程中任何一个阶段)后的实际“质量提升”情况?45%40%740%k提效不明显20%以下20-39%40-59%60%-79%提升80%以上3.5.2LLM落地对代码质量左移的影响(客观数据)准定位代码中的潜在问题区域，从而更全面地覆盖测试范围，提升软件质量。考，帮助开发人员识别可复用代码模块，遵循“DRY(Don'trepeatyourself)”原则编写代码，优化代码结构。《DevData2025研发效能基准报告》IAI应用专题LLM的落地应用与单元测试覆盖度LLM的落地应用与代码不重复度90%78%60%50%40%30%20%对企业研发管理的启示对于追求高质量代码与高效流程的企业，LLM具备应用价值：·尚未应用LLM的企业：可引入相关工具/服务，借助其测试用例生成、代码优化能力，提升单元测试覆盖度与代码不重复度，增强软件稳定性与可维护性。测试场景),探索更多应用场景(如代码重构辅助、架构设计建议),巩固代码质量优势。《DevData2025研发效能基准报告》综合分析4.1不同行业的代码和需求交付效率存在差异整体呈现“代码生产率越高，需求交付周期越短”的关联：互联网行业代码生产率4210、需求交付周期10天；银行/保险/金融服务行业代码生产率3726、需求交付周期30天；信息和通信行业代码生产率行业特性深刻影响指标表现：对于期望提升代码生产率的企业，LLM是值得引入的技术工具：交付周期；·银行/保险/金融服务行业受合规、稳定性约束，交付速度有所牺牲；·信息和通信行业受技术复杂度、项目管理难度限制，代码产出与交付效率有提升空间。30互联网银行/保险/金融服务信息和通信不同行业的代码生产率4210372635002500150010000互联网银行/保险/金融服务信息和通信4000对企业研发管理的启示各行业企业需结合自身特点优化研发流程：·代码生产率低、交付周期长的企业，可借鉴互联网经验，引入敏捷开发、自动化工具(如CI/CD流水线),提升代码产出效率与交付速度；·同时重视行业特性(如金融合规、通信技术复杂度),在满足合规/稳定要求基础上，探索提效方法(如金融行业试点敏捷+合规评审并行),增强市场竞争力，适配行业竞争与市场变化。《DevData2025研发效能基准报告》综合分析4.2大规模企业更需关注人员贡献均衡性500人以上企业的中位值为31%。可见企业规模越小，代码贡献在人员间的分布越均衡。小规模企业人员沟通协作相对便捷，可能更容易实现任务合理分配，促进成员共同参与代码贡献。致代码贡献集中于部分团队或人员。这可能影响团队整体协作氛围与创新活力，还可能带来知识传递不畅、部分人员技能提升受限等问题，进而对交付效率产生负面影响。不同企业规模的代码贡献均衡度中位值45%39%40%35%30%25%20%5%100人以内100-499人500人以上32%31%对企业研发管理的启示·100人以内企业：延续现有良好协作与任务分配模式，持续关注代码贡献均衡度，避免企业扩张破坏优势，保持全员参与的活力。·100人以上，尤其是500人以上大规模企业：重视代码贡献均衡性问题。可通过优化组织架构(如拆分大团队为敏捷小组)、完善任务分配机制(如引入需求轮值、跨组协作