研发效能协作平台行业研究报告

基本信息

阅读时间：约 28 分钟

字数：约 14,633 字

摘要：市场担心：人工智能已经能写代码，研发效能工具的价值会被模型本身吃掉。数据似乎也在支持这个担心——引入人工智能编码后，开发者的任务完成量提升 21%，合并请求数量增加 98%，但组织层面的交付指标几乎没有改善：在人工智能采用率提升 25% 的样本中，吞吐量反而下降 1.5%、稳定性下降 7.2% [4]；同期的合并请求体积增加 154%、代码评审时间增加 91%、缺陷率上升 9% [1]。写代码变快了，交付没有变快。

市场担心：人工智能已经能写代码，研发效能工具的价值会被模型本身吃掉。数据似乎也在支持这个担心——引入人工智能编码后，开发者的任务完成量提升 21%，合并请求数量增加 98%，但组织层面的交付指标几乎没有改善：在人工智能采用率提升 25% 的样本中，吞吐量反而下降 1.5%、稳定性下降 7.2% [4]；同期的合并请求体积增加 154%、代码评审时间增加 91%、缺陷率上升 9% [1]。写代码变快了，交付没有变快。

我们认为：这不是人工智能的失败，而是它把瓶颈从编码环节推到了评审环节。把一个研发团队的端到端交付周期拆开看，评审等待加评审本身合计约 144 小时，而编码与自测只有约 26 小时。以 190 小时的端到端周期计算，评审等待一项就占 50.5%，编码与自测只占 13.7%（测算）。用阿姆达尔定律衡量：把编码提速一倍，只能改善端到端周期 6.8%；把评审等待缩短一半，可以改善 25.3%（测算）。人工智能恰恰强化了那个占比更小的环节，同时把负担全部压到了占比更大的环节上。

1. 评审等待是可以用容量模型算出来的，因此它可以被管理，而不是只能被忍受。以行业平均 4 天的合并请求等待为基线，在合并请求数量增加 98%、体积增加 154% 的输入下，若没有自动初筛，等待时间会被推高到 20.1 天；自动审查承担 50% 的初筛后回落到 10.1 天；覆盖 70% 后回落到 6.0 天。如果同时把提交拆小、体积指数压到 0.6，等待可以降到 2.4 天，比人工智能之前还低（测算）；
2. 市场集中度远高于效能改善的速度。2025 年中国 DevOps 商业化平台市场规模约 42 亿元、同比增长 18%，阿里云、腾讯云与 Gitee 三家合计占据约 55% 的份额 [8][9][16]。但同一份调研显示，国内企业 DevOps 成熟度处于全面级及以上的比例仅 26.7%，超过 70% 的企业仍处于基础级或起步级 [11]。工具已经很集中，能力却还没有普及；
3. 头部厂商的增长质量优于增速。GitLab 2025 财年营业收入 7.592 亿美元、同比增长 31%，年度经常性收入 10 万美元以上的客户达到 1,229 家、增长 29%，美元净留存率 123% [13]。但在 2026 财年，公司启动全球重组、裁员约 14% 并退出 22 个国家和地区，把资源集中到人工智能基础设施上 [14]。留存率与客户结构的改善，并没有阻止组织层面的收缩——这与本报告对交付指标“个体变快、系统不变快”的判断同源。

这个行业的规模数字同样高度依赖口径。宽口径的表述是：中国 DevOps 市场规模将在 2025 年突破 350 亿元，年复合增长率保持在 20% [6][7]；同一份材料同时给出 DevSecOps 市场规模 78 亿元 [7]。窄口径的表述是：2025 年中国 DevOps 商业化平台市场约 42 亿元、同比增长 18% [8][9][16]。介于两者之间的还有：2024 年中国研发效能工具市场规模 47.8 亿元，预计未来三年以 18.7% 的复合增长率扩张 [8]。同一时间、同一个国家，四个数字之间相差八倍以上。

落差的来源并不神秘。350 亿元的口径覆盖的是企业研发数字化的整体支出，包括自建工具链的人力、内部平台的建设成本与咨询；42 亿元的口径只统计厂商对外销售的商业化平台产品收入 [8]。后者才是本报告关注的竞争性市场，因为只有这一部分才存在厂商之间的份额争夺。在本报告的后续讨论中，凡涉及市场规模，一律使用 42 亿元这个口径，并在必要时并列其他口径作为量级参照。

全球口径的差异同样巨大。Custom Market Insights 的测算为 2025 年 169.7 亿美元、按 22.2% 的年复合增长率在 2034 年达到 1,032 亿美元；IMARC 的测算为 2025 年 158 亿美元、按 19.74% 的年复合增长率在 2034 年达到 836 亿美元 [7]。两套口径对 2025 年的判断相差 7%，但对 2034 年的判断相差 23%——差别全部来自复合增长率的取值。对工具厂商而言，这意味着任何以十年为期的规模论证都缺乏可靠的约束条件。

政策与需求构成了这个行业的两条支撑线。需求侧的证据是：中国信通院调查显示 2024 年已有 78% 的企业将提升研发效能列为战略级目标，超八成企业已开展效能度量工作 [8]。供给侧的证据是标准：信通院 2025 年正式发布研发运营一体化通用效能度量模型，为行业提供统一的度量框架；截至 2026 年一季度，国内共有 40 余家企业完成分级能力评估，通过高级别的企业集中在金融与政务两个强监管行业 [9][16]。

讨论研发效能，必须先接受一个事实：这个领域的指标分布极度右偏，平均值几乎没有解释力。2025 年的调查数据显示，部署频率为按需（每天多次）的受访者占 16.2%，每小时至每天占 6.5%，每天至每周占 21.9%，每周至每月占 31.5%，每月至半年占 20.3%，半年以上占 3.6% [5]。最高的两档合计 22.7%，但这部分团队贡献了绝大部分的交付量。

变更交付周期的分布更能说明问题。少于 1 小时的受访者占 9.4%，少于 1 天占 15.0%，1 天至 1 周占 31.9%，1 周至 1 月占 28.3%，1 月至 6 月占 13.2%，超过 6 月占 2.0% [5]。落在 1 天到 1 个月这个区间的团队接近六成，而这个区间恰好是评审等待耗时最容易被放大的区间——一次跨天、跨周的评审排队，就足以把一个原本 1 天的交付周期推到 1 周以上。

变更失败率的分布同样说明稳定性仍有大量改善空间。累计占比数据显示，变更失败率落在 0% 至 2% 的受访者占 13.7%，2% 至 4% 占 16.7%，4% 至 8% 占 36.2%，8% 至 16% 占 26.0%，16% 至 32% 占 19.5%，32% 至 64% 占 12.5%，超过 64% 占 8.5% [5]。把这些分档换算成体量：变更失败率超过 16% 的受访者合计占 40.5%（测算），也就是说每十家团队里有四家，每六次变更就有一次以上需要回滚或热修。

把这三组分布放在一起，可以得出一个与市场叙事相反的结论：行业并不缺先进实践，缺的是把中位数整体抬起来的杠杆。头部团队已经把变更交付周期压到 1 小时以内、把变更失败率压到 4% 以下，这些团队的问题在于边际收益已经很薄；而处在中位数附近的六成团队，面临的是评审排队、环境不一致、人工回归测试覆盖率不足 30% 这类基础问题 [11]。效能工具真正能大规模产生回报的位置，在后者而不是前者。

把可比的年度读数排成序列，可以看到一条清晰的分流线。每日及以上部署的团队占比从 2024 年的 34% 升至 2025 年的 38%，2026 年预计进一步升至 40% 至 43% [2]。交付吞吐的改善是稳定而缓慢的，每年提升约 4 到 5 个百分点。

同期其他指标的走向并不一致。中位变更交付周期从 2024 年的 4.5 天改善到 2025 年的 3.8 天，2026 年预计为 3.2 至 3.6 天；中位周期时间从 56 小时降到 48 小时、预计进一步降到 40 至 46 小时；中位合并请求体积从 125 行降到 110 行、预计降到 95 至 105 行 [2]。但与之相反，中位变更失败率从 14% 上升到 16%、预计维持在 15% 至 18% [2]。吞吐在改善，稳定性在恶化——这正是一份报告把人工智能描述为双刃剑的原因：它带来 30% 至 40% 的周期时间改善，同时把变更失败率推高 15% 至 25% [2]。

需要特别说明 2025 年的一次方法论变化：该年度的调查不再使用精英、高、中、低四档划分，改为按分位数分布与画像聚类呈现结果 [2][3]。官方给出的解释是，最有价值的比较并不是与他人横向对比，而是同一个应用或服务在不同时间的纵向比较；研究的目标是持续学习与改进，而非单纯追求达到顶尖的交付效能 [5]。对使用者而言，这意味着沿用了近十年的「精英团队」目标值不再是合适的对标基线。

要判断优化哪个环节最有效，需要先把端到端交付周期拆开。本报告采用的构成如下。评审等待取 96 小时，对应行业平均的合并请求等待时间 4 天，大体积合并请求（500 行以上）的等待时间为 9 天 [4]。评审本身取 48 小时，对应平均评审周期 6.2 天中扣除排队等待后的实际评审占用。编码与自测取 26 小时，锚定小规模团队的中位周期时间 [2]。部署与验证取 14 小时，含环境准备、灰度与上线后观察。持续集成流水线取 6 小时。五项合计 190 小时（测算）。

按占比排序，结论非常直接：评审等待占 50.5%，评审本身占 25.3%，编码与自测占 13.7%，部署与验证占 7.4%，持续集成流水线占 3.2%（测算）。两项与评审相关的时间合计占 75.8%。换句话说，一个软件变更从提交到上线，有四分之三的时间花在「等待别人看」和「别人正在看」上，只有不到七分之一花在写代码和自测上。

这解释了一个长期存在的错位：研发效能工具市场的核心卖点长期集中在代码托管、持续集成与流水线编排，这些能力优化的都是占比合计不到 13% 的环节。而真正占据一半周期的评审排队，在多数企业的工具链里只不过是一个通知与状态流转功能。工具的投资方向与瓶颈所在的位置，在过去若干年里一直是错开的。

这个结构还有一个副作用：评审等待是纯等待，不产生任何价值，但它会被计入交付周期，并被外部当作团队的能力指标。于是出现了两套并行的事实——团队的实际工作时长（编码 26 小时加评审 48 小时）约为 74 小时，而对外承诺的交付周期是 190 小时，两者相差 2.57 倍（测算）。中间那 116 小时全部是排队。

把上面的时间构成代入阿姆达尔定律，可以直接算出每个环节的改善杠杆。定律的形式是：若某环节占端到端周期的比例为 w，该环节提速 s 倍，则整体周期的改善幅度等于 w 乘以（1 减 s 的倒数）。在 s 等于 2（即提速一倍）的前提下，整体改善幅度就等于该环节占比的一半。

据此计算，各环节提速一倍带来的端到端周期改善是：评审等待 25.3%，评审本身 12.6%，编码与自测 6.8%，部署与验证 3.7%，持续集成流水线 1.6%（测算）。评审等待的杠杆是编码环节的 3.7 倍。反过来看：若把编码时间压缩到零——这在工程上不可能——端到端周期也只能改善 13.7%。

这条结论对工具选型有直接含义。任何一项效能投入，其上限收益都可以用「该环节占比乘以免除比例」估算。一个能把流水线构建时间从 6 小时压到 1 小时的优化，端到端周期的改善上限是 2.6%（测算）；而一个能把评审等待从 96 小时压到 48 小时的动作，改善上限是 25.3%（测算）。两者的投入产出比差着接近十倍，但在采购决策里，前者往往更容易被写成可量化的验收指标。

还需要指出一个容易被忽略的边界：阿姆达尔定律给出的是上限，但真实系统里的环节并不独立。缩短评审等待会提高合并频率，从而增加流水线触发次数与部署频次，把压力转移到后面两个环节。因此实际收益会低于上限值，并且需要流水线与发布能力同步扩容。这也解释了为什么纯粹的评审加速工具很少能单独产生 25% 的周期改善。

人工智能编码工具对个体开发者确实有效。2025 年度的调查显示，使用人工智能的开发者在任务完成量上提升 21%，代码生成速度显著加快 [1]。GitLab 的内部指标同样显示，使用其核心人工智能平台的开发者生产力提升 40% 至 50% [15]。问题出在这些改善没有传导到组织层面。同一批数据显示，在人工智能采用率提升 25% 的样本中，组织吞吐量下降 1.5%、稳定性下降 7.2% [4]。下游的四项交付指标——交付周期、部署频率、变更失败率、失败恢复时间——在多数样本中持平甚至恶化 [1]。

传导失败的原因可以被量化。人工智能让生成大块代码变得廉价，于是合并请求体积增加 154%；合并请求数量增加 98%；两者叠加使评审工作量激增，代码评审时间随之增加 91%；在质量门禁来不及消化的压力下，缺陷率上升 9% [1]。与此同时，资深工程师约有 60% 的时间花在评审上，而不是在做架构决策 [4]。最稀缺的资源被锁定在最拥挤的环节。

值得注意的是，这种压力并没有转化为职业倦怠。2025 年的调查发现，人工智能使用与倦怠或摩擦之间没有相关性；开发者与人工智能协作时每天交互的合并请求数量增加 47%，但情绪压力指标保持中性 [1]。原因被归结为开发者从样板代码与文档检索中获得了认知减负，这部分缓解抵消了并发工作流增加带来的压力 [1]。这个发现对产品设计有直接含义：如果开发者的痛苦已经不在写代码上，那么以「写得更快」为核心卖点的工具所能提供的边际价值必然递减。

行业已经开始按这个判断调整方向。GitLab 在 2026 财年把定价模型从纯席位制改为席位加用量的混合模型，理由是反映人工智能带来的价值交付 [15]；同时公司启动全球重组、裁员约 14%（约 350 人），退出 22 个国家和地区，把投资聚焦到人工智能基础设施与下一代代码托管能力上 [14]。「按价值收费」与「组织收缩」同时发生，本身就说明行业的价值分配正在重新洗牌。

评审等待之所以长期被当作不可控因素，是因为它很少被写成公式。实际上它可以近似建模为「评审需求工时除以评审容量」的排队问题。本报告采用一阶近似：在评审容量固定、系统未饱和的区间内，等待时间与评审总需求工时近似成正比。评审总需求工时等于合并请求数量乘以单个体积对应的评审工时，再乘以人工需要承担的比例。

以行业平均 4 天的合并请求等待为基线，代入人工智能带来的变化：数量指数 1.98（对应增加 98%）、体积指数 2.54（对应增加 154%）。若没有自动初筛，等待时间被推高到 20.1 天；自动审查承担 30% 的初筛后为 14.1 天；承担 50% 后为 10.1 天；承担 70% 后降到 6.0 天（测算）。这里要特别注意方向：公开数据显示大体积合并请求的等待已经是 9 天 [4]，模型给出的 10.1 天与之处在同一量级，说明这套近似没有系统性偏离现实。

二维敏感性表显示，两个变量的作用并不对称。在自动初筛覆盖率为零的那一列，把体积指数从 2.54 压到 0.6，等待时间从 20.12 天降到 4.75 天，差距 15.37 天；而在体积指数为 1.0 的那一行，把初筛覆盖率从零提到 70%，等待时间从 7.92 天降到 2.38 天，差距 5.54 天（测算）。压缩体积的收益是提高初筛覆盖率的三倍。

这条结论落到工程实践上就是一句话：把提交拆小，比让机器人看得更快更有效。体积指数 0.6 意味着单次合并请求的改动量降到行业历史水平的六成，这在实践中对应的是把大功能拆成可独立验证的小步提交，并配合特性开关把未完成的功能隔离在生产之外。组合起来的最优情形（体积指数 0.6 加初筛覆盖 50%）把评审等待压到 2.4 天，低于人工智能引入之前的基线（测算）。

把 2.4 天代回端到端周期，评审等待从 96 小时降到 57.6 小时，端到端周期从 190 小时降到 151.6 小时，改善 20.2%（测算）。这就是本报告认为研发效能协作平台在人工智能时代最确定的增长点：不是帮开发者写得更快，而是帮团队在代码变多之后仍能把它审完、验完、发出去。

中国 DevOps 商业化平台市场的集中度已经很高。按 2025 年约 42 亿元的市场规模计算，阿里云、腾讯云与 Gitee 三家合计占据约 55% 的份额 [8][9][16]。三家的路径差异明显：Gitee 凭借长期深耕代码托管赛道，在私有化政企市场渗透率领先；阿里云与腾讯云则依托自有云计算存量客户实现规模化扩张 [9][16]。

细分赛道的份额结构同样值得记录。较早的调查数据显示，Gitee 在需求与研发管理领域以 30.38% 的份额位列第一，在一体化 DevOps 平台领域占 25.49%，在代码管理工具领域占 31.03% [10]。另有 32% 的企业选择私有云部署方案，以满足金融、政务等行业的数据本地化要求 [10]。私有化与国产化是这个市场区别于全球市场的最大变量，它把竞争从产品能力部分转移到了合规适配能力上。

与高集中度形成对比的是低成熟度。中国信通院《中国 DevOps 现状调查报告》显示，国内企业 DevOps 成熟度处于全面级及以上的比例仅为 26.7%，超过 70% 的企业仍处于基础级或起步级 [11]。这些企业面临的典型问题非常具体：人工打包与手动上传服务器使一次部署耗时 2 至 4 小时，回归测试靠人工点击、自动化覆盖率不足 30%，开发、测试、预发布与生产四套环境不一致、配置漂移频发，上线后靠用户报缺陷才发现问题 [11]。

信通院的标准体系给出了这一市场的评价坐标。研发运营一体化通用效能度量模型于 2025 年正式发布，成熟度模型分为先进突破级、产业推广级、创新引领级、领航标杆级与卓越示范级五个级别 [9]。截至 2026 年一季度，国内共有 40 余家企业完成分级能力评估，其中通过高级别评估的企业以金融、政务、通信等强监管行业为主 [9][16]。这说明标准的采用者集中在合规压力最大的行业，而不是效能压力最大的行业。

GitLab 是这个赛道最有参考价值的公开样本，因为它同时披露收入、客户结构与留存率。2025 财年营业收入 7.592 亿美元、同比增长 31%；按通用会计准则毛利率 89%、非通用会计准则毛利率 91%；非通用会计准则经营利润率 10%，非通用会计准则调整自由现金流 1.2 亿美元 [13]。此前一个财年的收入为 5.799 亿美元 [13]。

客户结构的变化比收入增速更能说明问题。截至 2025 财年第四季度末，年度经常性收入 5,000 美元以上的客户达到 9,893 家、同比增长 15%；10 万美元以上的客户达到 1,229 家、同比增长 29%；100 万美元以上的客户增至 123 家、同比增长 28%；美元净留存率为 123% [13]。大客户增速是小客户增速的两倍，留存率高于 120% 意味着存量客户本身还在扩容。

后续一个季度的数据延续了这一趋势。截至 2025 年 7 月 31 日的季度，年度经常性收入 5,000 美元以上客户增至 10,338 家、10 万美元以上客户增至 1,344 家，非通用会计准则毛利率维持在 90% [15]。更值得注意的是留存的来源：过去一年美元净留存率的增长中，80% 由客户扩席位驱动 [15]。这意味着客户愿意为同一个人数规模付更多钱，而不是简单地把用户数堆上去。

但增长并没有消除组织压力。2026 年 6 月，GitLab 宣布启动全球重组计划，裁员约 14%（约 350 人），并退出 22 个国家和地区，公司表示此举旨在精简运营、压平组织架构，以聚焦投资于人工智能基础设施与下一代代码托管能力；同期预计产生 3,000 万至 3,500 万美元的重组费用 [14]。重组当季（截至 2026 年 4 月 30 日）营收 2.642 亿美元、同比增长 23%，订阅收入从 1.945 亿美元升至 2.393 亿美元，通用会计准则净亏损从 3,590 万美元收窄至 500 万美元 [14]。收入与客户指标在改善，组织在收缩——这再次印证本报告的核心判断：行业的价值正在从「让开发者更快」转移到「让系统接得住更快的产出」。

中国市场的落地约束可以从调研读数中直接读出来。《软件研发效能 2025 中国年度调查报告》显示，基础软件与平台、互联网两个行业的受访者各占 24%，合计接近半数；岗位角色以开发工程师（15%）为主力、管理者（14%）紧随其后；组织规模上中小企业（20 至 99 人）与超大型企业（10,000 人以上）各占 28% 与 26% [12]。

这些读数里有三个关键约束。第一，个人能力而非工具能力是流水线建设的主要挑战，持有这一判断的受访者占 50% [12]。这说明采购平台并不能解决建设问题，能力缺口会在部署落地阶段暴露。第二，架构治理普遍缺乏标准自动化与可视化能力，持此判断的约占 30% [12]。架构层面的失控会反向放大评审负担——评审人不得不从代码正确性一路审到架构一致性。第三，人工智能代码的风险监管正在加强，41.94% 的受访者提到了这一点 [12]。本报告第六章描述的评审压力，在中国市场会首先以合规审查的形式出现。

本报告识别的风险按重要性排列如下。

1. （一）效能指标被平均化误读。分布极度右偏，用平均值设定目标会让中位数团队长期无法达标；
2. （二）评审加速后压力后移。缩短评审等待会提高合并频率，把压力转移到流水线与发布环节；
3. （三）人工智能生成代码的合规风险。41.94% 的受访者提到相关监管加强 [12]，安全门禁若不前置会形成新的返工；
4. （四）私有化交付摊薄毛利。32% 的企业选择私有云部署 [10]，交付与适配成本显著高于公有云席位；
5. （五）市场份额集中于云厂商。三家合计约 55% [8][9]，独立工具厂商的生存空间被持续压缩；
6. （六）厂商重组带来续约不确定性。头部厂商退出 22 个国家和地区并裁员 [14]，客户的长期服务承诺需要重新评估。

需要持续跟踪的指标分三组。交付侧关注端到端交付周期的分位数而非平均值、评审等待时长、以及合并请求体积与数量的比值。组织侧关注评审人数量与每周评审工时的容量、资深工程师的评审时间占比、以及完整级及以上成熟度企业的占比。市场侧关注商业化平台规模与前三大厂商份额、私有化部署项目占比、以及经过分级评估的企业数量与行业分布。

最后需要说明本报告的适用范围。本报告讨论的是研发效能协作平台的效能机制与市场结构，不涉及任何具体公司的估值判断，也不构成对任何工具、平台或厂商的推荐。所有标注「测算」的数字均为本报告基于外部锚参数推算的结果，推算公式与参数取值在正文中逐项给出；凡无法获得可靠外部锚的参数，本报告一律标注为数据缺口并降级为定性讨论或采用区间假设。

本报告共设八条可证伪链，覆盖评审等待作为核心瓶颈的判断、阿姆达尔效应下的投入优先级、人工智能收益被评审环节吸收的机制、评审容量模型的可计算性、市场集中度与能力成熟度的背离，以及评审环节作为增长点的条件。每条链均给出依据、边界、反面证据、跟踪指标与证伪条件，读者可按证伪条件自行验证判断的有效性。台账如下：

本报告所有关键数据均按四档标注数据来源档次，以区分证据强度与可复核性：

• [T1]一手或官方口径：上市公司定期报告与官方新闻稿披露数据，可直接复核；
• [T2]机构二手口径：权威调研报告、行业标准发布方与技术社区整理的年度调查数据，口径可能存在差异；
• [T3]媒体转引口径：媒体报道与厂商发布的行业资料，未经独立审计，仅作量级参考；
• [缺口]数据缺口：无法获得可靠来源的数据，本报告一律降级为定性讨论或采用区间假设并明确标注。

需要特别说明六处口径限制。其一，中国 DevOps 市场规模存在 350 亿元与 42 亿元两套口径，差额来自是否计入企业自建工具链的内部投入，本报告在讨论竞争格局时使用 42 亿元口径，并在正文并列全部口径且不做加总。其二，交付效能指标的分布数据来自问卷调研，样本以中大型组织为主，对微型团队的代表性有限。其三，端到端交付周期 190 小时的时间构成为本报告基于平均合并请求等待 4 天、平均评审周期 6.2 天与中位周期时间构造的测算值，不是任何机构的披露值，其中评审本身的 48 小时为扣除排队等待后的估计。其四，评审容量模型采用一阶线性近似，假设等待时间与评审需求工时成正比，在系统接近饱和时会低估等待时间，本报告以二维敏感性表覆盖参数区间。其五，人工智能带来的合并请求数量与体积变化倍数来自单一调研口径，不同团队差异可能很大。其六，成熟度分布与调研读数均以受访企业为分母，不能直接换算为全国企业比例。

所有标注「测算」的数字，均为本报告基于外部锚参数推算的结果，推算公式与参数取值在正文中逐项给出；测算值与外部锚存在偏差时，均在正文标注对账结果。不同调研机构因样本差异，同一指标可能存在数值差异，以原始调研口径为准。