我们在 2025 年 4 月至 6 月收集的数据表明，85% 的开发者现在至少使用一款 AI 工具进行编码和开发活动。AI 的存在重新定义了技术领导者与开发者的期望。

生成式 AI 工具的采用已被视为一项重要举措。技术经理将其列为提升开发者体验与工作效率的三大组织措施之列，其他两项分别为内部培训和改进开发流程。

开发者对 AI 如何重塑他们的工作有着清晰的认识。当被问及他们预计在未来 1–3 年内工作流会有何变化时，开发者指出了一种转变 — 并非工作完全实现自动化，而是时间分配的重新平衡。

许多人预计 AI 会加快学习速度 (47%)、接管重复性或样板任务 (44%)，并生成初始代码草稿 (42%)。开发者还认为，借助 AI，他们可以将更多时间投入到解决问题、高级设计等有价值的工作中 (39%)。

开发者已经清楚自己希望在哪些方面利用 AI。

如果我们想在 AI 时代提升 DevEx 与工作效率，这些信号值得关注。

2025 年，我们向开发者和技术经理提出了类似问题，这次的问题是关于技术和非技术因素对开发者工作效率的影响程度。两组受访者都认为非技术因素对开发者工作效率的影响稍大一些（经理：89% 对 85%；开发者：89% 对 84%）。

在衡量开发者工作效率与体验时，两个认可度最高的框架是 DORA 和 SPACE。这两个框架为评估开发者工作效率与体验提供了结构化方式。

2024 年，我们询问了参与提升公司 DevEx 与工作效率的技术经理，想了解其是否使用这些框架的特定元素（即指标）来评估开发者的工作效率与体验。

在衡量工作效率方面，开发者报告其公司使用多种方法。

在 2025 年的榜单上，位列榜首的是：

活动日志（例如跟踪代码提交和拉取请求）紧随其后，23% 的开发者表示他们的公司在使用这种方法。

在衡量对开发工具的满意度方面，情况远非完美。近一半 (49%) 的开发者表示这方面存在问题：33% 的开发者表示其对开发工具的满意度完全未得到衡量，另有 16% 的开发者表示不清楚其满意度是否得到衡量。

对于真正衡量 DevEx 的公司，最常采用的三种衡量方法是：

大多数开发者总体上对这些评估持接受态度。当我们询问开发者对 2024 年衡量其工作效率的态度时，42% 的受访者表示自己可以接受，40% 的受访者持中立态度。不过，18% 的受访者承认对这个想法感到不适。

开发者对评估其对开发工具的满意度这一事实感到更加可以接受。超过半数的受访者 (57%) 表示他们可以接受对满意度的衡量，而 39% 的受访者对此持中立态度。

数据表明：开发者大多对评估自身工作效率与体验持接受态度。

这类评估似乎正在成为科技行业的标准做法。公司不应因担心引发开发者不适或负面情绪而停止衡量开发者工作效率与体验。

近三分之二的开发者认为，用于衡量其工作效率的指标不能准确反映出其工作效率和贡献 (36%)，或对此持不确定的态度 (30%)。

这种信任缺失进一步影响了数据在决策过程中的应用。2024 年，我们询问了开发者对基于其工作效率评估做出的决策的了解程度。

只有 22% 的开发者表示他们完全了解其工作效率数据的使用情况，并会定期获得清晰的信息。

还有 32% 的开发者表示他们大致了解，即他们有一个大致的概念，但并不掌握完整信息。其余开发者的知晓程度则明显更低，46% 的开发者对数据使用情况了解有限，或完全不知情。

当我们询问开发者怎样才能让他们更接受对其工作效率的评估方式时，他们提出的诉求如下：

其他关注点包括流程的公平性、结果在决策过程中的使用方式，以及衡量的负责人。开发者希望这一流程审慎、目标明确，并为开发者赋能。

在我们讨论了衡量开发者体验所使用的指标和方法后，我们回到这个问题：组织是否真的在衡量其开发者对工具的满意度。尽管这个指标是 DevEx 的一个重要组成部分，但近半数的开发者报告称，其公司并未评估该指标，或未提供相关数据。具体来说，33% 的开发者表示公司根本没有衡量工具满意度，还有 16% 的开发者不确定公司是否衡量该指标。如果不了解这方面的数据，团队很难发现痛点，也无法采取系统性的行动。

如前文所述，量化开发者的满意度通常受到大家的认可，很少会引发不适。

公司规模似乎在采用衡量做法中起到了一定作用，与中小规模的公司相比，规模更大的公司更有可能衡量 DevEx 与开发者工作效率。

在员工人数超过 1,000 的大型组织中，仅有 30% 的受访技术经理表示其公司未衡量 DevEx 或开发者工作效率。对于中等规模的公司（员工人数为 50 到 1,000），这一数字上升到 34%，而在员工人数少于 50 的小型公司中，这一数字再次上升到 41%。

2024 年，各家公司对开发者进行工作效率评估的频率差异很大。季度 (25%)、月度 (18%) 和每周 (17%) 工作效率评估是各家公司采取的主要做法。

但对于作为 DevEx 核心组成部分的工具满意度，情况则有所不同，相关评估正在发生变化。2024 年，超半数的开发者 (53%) 表示，对其开发工具满意度的衡量间隔不固定。但在 2025 年，这一数字大幅降至29%，越来越多的团队采用月度、季度、年度等结构化衡量做法。季度 (28%)、月度 (18%) 和每周 (9%) 评估变得更为普遍。

谁实际上负责跟踪 DevEx 与开发者工作效率？我们的数据清晰表明：在大多数公司，无论规模如何，团队主管承担（或预计将承担）这些工作的责任（请参阅图表中的其他职位）。

根据我们 2025 年的数据，56% 的受访个人贡献者 (IC) 和半数的各种职位的技术经理（包括工作效率工程师、DevEx 专家、团队主管等）都同意，团队主管是 DevEx 与开发者工作效率衡量的主要推动者。有趣的是，这一结论适用于所有规模的公司。这个选择看起来合乎逻辑 — 团队主管与开发者密切合作，了解他们团队的工作流、面临的挑战和痛点。

在大型公司的开发者和技术经理中，分别有 22% 和 23% 的人认为平台工程团队应负责 DevEx 工作。分别有 25% 和 22% 的人指出，此工作应由专门的专家岗位负责。

在开发者中，30% 的人觉得衡量自己的工作效率与体验完全由他们自己负责。在小型公司中，这一数字上升到 38%，这表明小型组织尤其倾向于让开发者自行应对。