揭秘科技巨头：如何衡量 AI 对软件开发的影响？

原文：How tech companies measure the impact of AI on software development

作者：Gergely Orosz

GitHub、谷歌、Dropbox、Monzo、Atlassian 等 18 家公司如何评估 AI 工具的真实效果？CTO Laura Tacho 独家深度解读

你好，我是 Gergely，为你带来《务实工程师》的月度免费版。在每一期中，我都会通过资深工程师和工程负责人的视角，探讨大型科技公司和初创企业面临的挑战。如果你是通过转发读到这篇文章，可以点击此处订阅。

许多订阅者会用他们的学习和发展预算来报销这份通讯。如果你有这样的预算，可以把这封邮件发给你的经理。如果你还不是付费订阅者，你已经错过了好几篇深度解读和行业脉搏文章。

AI 编程工具在科技行业已经无处不在。根据我们 2025 年的工具调查，85% 的软件工程师在工作中使用它们。但像 tokens 这样的东西并不便宜，公司在 AI 工具上的花费也越来越多。那么，公司如何衡量这笔钱花得值不值呢？

为了找到答案，我求助于 Laura Tacho，她是 DX 公司的 CTO，这家公司专门帮助企业衡量工程效率。老读者可能还记得三年前的 Laura，当时她在深度文章《衡量开发者生产力》中，分享了她对衡量开发者生产力的看法，并为如何着手这个棘手领域提供了建议。

在本文中，我们将探讨：

  1. 18 家科技公司如何衡量 AI 的影响。 来自谷歌、GitHub、微软、Dropbox、Monzo 等众多公司的独家细节。我们将深入了解他们衡量的指标，例如：GitHub 如何衡量 AI 节省的时间、拉取请求（PR）吞吐量、变更失败率、活跃用户数、创新率等等。

  2. 坚实的基础对于衡量 AI 的影响至关重要。 你可以——也应该！——将现有的“核心”指标与 AI 特有的指标（如客户满意度 (CSAT) 分数）结合使用。

  3. 按 AI 使用水平细分指标。 长期跟踪指标以发现趋势和模式。从可靠的基线测量开始，对数据进行切片分析，并在衡量影响时保持实验心态。

  4. 时刻关注可维护性、质量和开发者体验。 跟踪那些能够相互制衡的指标：例如，同时跟踪变更失败率和 PR 吞吐量。

  5. 独特的指标，有趣的趋势。 微软衡量“糟糕的开发者日”，而 Glassdoor 则衡量 AI 工具带来的实验成果。未来，可能会有更多团队衡量关于自主 AI 智能体 (AI Agent) 表现的数据。

  6. 如何衡量 AI 的影响？ DX AI 框架概览，以及通过系统数据、定期调查和体验抽样获取数据的技巧。

  7. Monzo 如何衡量 AI 的影响。 很难获取“像样”的数据，因为 AI 工具供应商常常囤积数据。AI 工具在迁移项目中表现出色，提供优质的 AI 工具可以在招聘和留住优秀工程师方面带来竞争优势，等等。

声明：我是 DX 公司（Laura 担任 CTO）的投资者，但本文并非由 DX 付费或以任何方式赞助。事实上，是我主动联系 Laura 参与本文的。更多信息请参阅我的道德声明。关于衡量开发者生产力的相关深度文章：

好了，下面交给 Laura。

打开领英，不出 30 秒，你就会刷到一篇关于 AI 如何改变软件开发方式的帖子。新闻头条充斥着各种报道，声称一些公司（主要是美国的科技巨头）正在交付大量由 AI 生成的代码——谷歌占 25%，微软占 30%。这些报道暗示所有这些代码最终都进入了生产环境，还有些创始人说 AI 可以取代初级工程师。但另一方面，像最近 METR 关于 AI 对开源软件任务影响的研究发现，AI 可能会扰乱我们的时间感知，实际上会拖慢我们的速度，即使我们自以为更快了。

在展示 AI 的影响方面，新闻头条显得相当片面。AI 能写大量代码，从而节省时间——或者并不能。与此同时，我们正一头扎向世界有史以来最大的一堆技术债。

我常常感到疑惑，为什么我们的行业又开始执着于代码行数 (LOC, lines of code)？为什么这个指标会成为头条新闻？那质量、创新、上市时间和可靠性呢？我们很久以前就一致认为，代码行数是衡量开发者生产力的糟糕指标，但它易于衡量，在没有明确替代方案的情况下，人们很容易抓住它不放。而且，它也更容易制造新闻噱头。

目前，许多工程负责人正在对 AI 工具做出重大决策，却并不真正了解哪些有效，哪些无效。根据 LeadDev 2025 年 AI 影响报告对 880 位工程负责人的研究，60% 的负责人将缺乏明确的衡量指标列为他们最大的 AI 挑战。我自己的经历也与此相符。我每周都会与许多负责人交流，他们既感到压力，要交付出像新闻头条那样的成果，同时又对董事会或高管团队执着于衡量代码行数感到沮丧。负责人需要了解的信息与实际被衡量和谈论的内容之间存在差距，而随着新工具和新功能的上市，这个衡量差距只会越来越大。

弥合这个衡量差距就是我的工作。我在开发者工具领域工作了十多年，自 2021 年以来，我一直在研究并为公司提供关于提高开发者生产力的建议。两年前加入 DX 担任 CTO 后，我开始在更大范围内做这件事，与数百家优秀公司在开发者体验、工程效率和 AI 影响这个复杂而重要的领域密切合作。

今年早些时候，我合著了《AI 衡量框架》，这是一套推荐的指标，用于跟踪工程团队中 AI 的采纳和影响。该框架建立在严谨的实地研究、对 400 多家公司的数据分析，以及他们实际推广和衡量 AI 工具的方式之上。

今天，我们将深入探讨 18 家科技公司在现实世界中如何衡量 AI 的影响，让你一窥《AI 衡量框架》这类成果背后的研究过程。我将分享：

  • 谷歌、GitHub 和微软等公司用来衡量 AI 影响的真实指标

  • 他们如何使用这些指标来判断哪些方法有效，哪些无效

  • 你该如何衡量 AI 的影响

  • AI 影响指标的定义和衡量指南

1. 18 家顶尖公司如何衡量 AI 的影响

首先，我们来看一张总览图，展示了 18 家公司用来衡量 AI 对其工作影响的真实指标，其中包括 GitHub、谷歌、Dropbox、微软、Monzo、Atlassian、Adyen、Booking.com 和 Grammarly：

顶尖科技公司用来衡量 AI 工具对软件工程师影响的指标：第 1 部分

顶尖科技公司用来衡量 AI 工具对软件工程师影响的指标：第 2 部分

从上述这些方法的异同中，我们可以学到很多东西。让我们来逐一分析。

2. 坚实的基础对于衡量 AI 的影响至关重要

使用 AI 编写代码，并不会改变优秀软件的本质，也不会改变对业务真正重要的事情。软件仍然需要高质量、易于维护，并能快速交付。

这就是为什么你会注意到，上面分享的许多指标看起来和前 AI 时代一样，比如变更失败率 (Change Failure Rate)、PR 吞吐量 (PR Throughput)、PR 周期时间 (PR Cycle Time) 和开发者体验 (Developer Experience)。

你不需要全新的指标来衡量 AI 的影响。 相反，应该关注那些一直以来都很重要的事情。AI 是否正在帮助你的组织在这些方面做得更好？

一个残酷的现实是，那些还无法清晰阐述在工程组织绩效和开发者生产力方面“什么最重要”的组织，会发现除了像代码行数或接受率这类表面指标外，几乎无法衡量 AI 的影响。上面提到的 18 个组织都已经投入巨资来衡量开发者生产力和开发者体验，这使它们能够更容易地看到 AI 工具带来的影响。

虽然我们不应从零开始，但确实需要新的、有针对性的指标来准确了解 AI 的使用情况。 了解人们在何处、以何种程度使用 AI，会影响到预算决策、工具推广、技能培训，甚至涉及到 SRE、安全、治理和合规等方方面面。

在 AI 出现前就已衡量的核心指标，有助于揭示 AI 是否正将事情推向正确的方向

AI 指标可以显示：

  • 有多少以及哪些类型的开发者正在采用 AI 工具

  • 有多少以及哪种类型的工作受到了 AI 的影响

  • 它花费了多少成本

核心工程指标可以显示：

  • 团队的交付速度是否更快

  • 质量和可靠性是在提高还是在下降

  • 代码的可维护性是否在下降

  • AI 工具是否减少了开发者工作流程中的阻力

以 Dropbox 使用的指标为例，这是一个很好地将现有指标与新的 AI 特定指标相结合的例子。Dropbox 的工程师中，有 90% 的人会定期（每周或更频繁）使用 AI 工具，这一采纳率远高于行业平均水平（接近 50%）。

Dropbox 并非依靠开发者个人的好奇心和毅力才达到如此高的采纳率。他们采取了一种结构化的、组织性的方法，从一开始就内置了良好的衡量指标。

在 AI 方面，Dropbox 跟踪以下指标：

  • 日活跃和周活跃用户

  • AI 工具的客户满意度 (CSAT)

  • 每位工程师节省的时间

  • AI 支出

这些指标显示了究竟是谁在使用 AI，他们的体验如何，是否真的为他们节省了时间，以及总共花费了多少。然后，通过叠加 Core 4 框架（Dropbox 用来跟踪核心工程指标的框架），他们可以看到 AI 的采纳如何在更大范围内影响软件交付。具体来说，他们关注：

  • 变更失败率 (Change Failure Rate)

  • PR 吞吐量 (PR throughput)

90% 的采纳率只有在对组织、团队和个人都有利时才有意义。对 Dropbox 来说，定期使用 AI 的工程师每周合并的拉取请求增加了 20%，同时还降低了变更失败率。综合看待所有这些指标，有助于他们避免过度关注像采纳率这样的单一指标，而忽略了更宏大的目标。

3. 按 AI 使用水平细分指标

为了更好地理解 AI 如何改变开发者的工作方式，Dropbox 和我采访的其他公司对他们的指标进行了不同类型的分析，例如：

  • 比较 AI 用户与非 AI 用户

  • 比较引入 AI 工具前后的核心工程指标

  • 跟踪同一组用户在采纳 AI 过程中的变化（同期群分析）

跟踪核心指标并比较 AI 用户与非 AI 用户。来源：DX 示例仪表盘

许多公司会对数据进行切片分析，以便更好地观察模式。 这种切片分析基于用户的属性，如角色、任期、地区和主要编程语言。这有助于回答更详细的问题并发现重要的模式，例如，初级工程师提交了更多的 PR，而高级工程师因为花费更多时间审查这些 PR 而速度变慢。你可以利用这类详细的研究问题来找到可能需要更多培训和赋能的开发者群体，或者反过来，找到 AI 表现特别出色的领域，然后设计一个 playbook 来推广这些用例。

通过这种比较方式，Webflow 能够精确定位出使用 AI 工具节省时间最多的群体；在他们的案例中，是在公司工作超过 3 年的开发者。Webflow 使用像 Cursor 和 Augment Code 这样的工具，与 Dropbox 类似，他们也观察到 AI 用户的 PR 吞吐量比非 AI 用户高出约 20%。

如果你想做好比较，就要从可靠的基线测量开始。 我之前提到，那些在开发者生产力方面基础不牢的公司，将很难衡量 AI 的影响。我这么说既是理论上的，也是实践上的；首先，他们不知道该寻找什么信号，其次，他们没有好的数据进行比较。

如果你还没有很好的基线，现在就是建立它们的时机。为了快速上手使用 Core 4 框架（Dropbox、Adyen、Booking.com 等公司都在使用），这里有一个模板和说明教你如何操作。你也可以使用系统数据和体验抽样数据来补充像这样的定期调查，我们稍后会介绍如何使用这些技术。

只 进行一次这些测量并不能让你对 AI 的影响有太多洞见；长期跟踪它们才能揭示趋势和模式。

我怎么强调实验心态对于衡量 AI 影响的重要性都不过分。 我为本文采访的公司有一个共同特点，那就是他们利用数据来回答问题并检验关于 AI 如何影响开发的预测。在许多情况下，他们从一个具体的目标开始，然后反向推导；他们不指望数据会神奇地揭示关于 AI 影响的某些真相，或告诉他们下一步该做什么。

4. 时刻关注可维护性、质量和开发者体验

有一件事偶尔会让我夜不能寐，那就是 AI 辅助开发是多么地新。我们没有多年的纵向数据能够确信无疑地表明，代码的可维护性或质量不存在长期风险。当我和高管及开发者交谈时，他们共同的首要担忧是如何平衡短期的速度提升与长期的权衡，比如技术债。

跟踪那些能够相互制衡的指标。 你会发现，几乎每家公司都在跟踪变更失败率的同时，也会衡量一个速度指标，如PR 吞吐量。这些指标可以相互制衡：例如，速度的提升伴随着质量的下降，可能就是一个不好的信号。

除了变更失败率，我还建议跟踪其他一些指标，以便密切关注质量和可维护性。一些公司会衡量：

  • 变更信心 (Change confidence) —— 开发者对其变更不会破坏生产环境的信心程度

  • 代码可维护性 (Code maintainability) —— 理解和修改代码的难易程度

  • 质量感知 (Perception of quality) —— 开发者对其团队中代码质量和质量实践的看法

你需要收集系统指标和自我报告的指标，才能获得稳健的数据， 我指的是涵盖速度、质量和可维护性维度的数据。一些指标，如 PR 吞吐量和部署频率，可以使用来自源代码控制和构建工具的系统数据来衡量，但像“变更信心”和“可维护性”这样的指标，对于避免 AI 的长期负面影响至关重要。这些只能通过开发者自己提供的自我报告数据来衡量。

如果这些话题还没有在团队关于 AI 的讨论中出现，就把它们加到议程里。即使这些反馈是非结构化的，它也能让你对现有的担忧有更丰富的理解，你可以讨论提议的解决方案并监控进展。

为了将 AI 的使用与质量和可维护性的长期变化关联起来，你需要更结构化的数据，为此，定期的开发者体验调查是一个好方法。

这里有两个问题，可以帮助组织具体了解变更信心和可维护性：

两个用于跟踪变更信心和代码可维护性的示例调查问题

开发者体验 作为一个整体，是另一个用来平衡速度和质量的流行衡量标准。值得注意的是，开发者体验这个词有点营销问题；它很容易让人觉得是“乒乓球和啤酒”，而不是它真正的含义：减少开发过程中的摩擦和阻力。开发者体验 (DevEx) 涵盖了开发生命周期的所有部分，从规划、构建、测试，到发布流程，再到生产支持。

使用 AI 工具的风险在于，我们可能在某些地方（如代码编写和测试）减少了摩擦，却在其他地方（如代码审查、事故处理和可维护性）增加了摩擦。

来自开发者体验指数的一些示例驱动因素；一种全面衡量整体开发者体验的方法。

CircleCI 的工程总监 Shelly Stuart 分享了更多关于在 AI 辅助工程背景下，开发者体验和开发者满意度的重要性：

“开发者体验告诉我们数字背后的故事。虽然像 PR 吞吐量这样的产出指标向我们展示了正在发生什么，但开发者满意度揭示了这是否可持续。

我们知道，采用 AI 工具可能会暂时让开发者感到沮丧。将开发者体验与业务成果一起跟踪，有助于我们区分短期摩擦和长期价值。如果不衡量满意度，我们就会错过关于我们的 AI 投资是增强了我们的工程文化，还是制造了需要我们克服的新摩擦领域的关键洞见。”

如果一个工具技术能力再出色，但开发者实际上不喜欢用它，那也无济于事。本文中提到的公司中有四分之三也在衡量开发者对 AI 工具的满意度或客户满意度 (CSAT)，这是一个很好的信号，表明关注点不仅仅是速度提升，还在于建立可持续的工程实践，减少日常工作中的摩擦。

5. 独特的指标，有趣的趋势

在所有这些指标中，隐藏着一些引起我注意的有趣细节。虽然行业在衡量时间节省、质量和速度方面已基本达成共识，但我发现研究那些“异类”很有趣，可以了解不同公司的运作方式，也可以看到这些指标未能展示的内容。

微软使用“糟糕的开发者日” (bad developer day, BDD) 的概念来评估 AI 工具的影响。 这是一个实时观察开发者日常工作中辛劳和摩擦的指标，而开发者体验调查则提供了一个滞后指标。其理念是，AI 应该减少 BDD 的频率和严重程度。如果做到了，微软就能判断 AI 是真正减少了摩擦，还是在工作流程中引入了新的障碍。

有几个因素可以把一天从好变坏：

  • 花在处理事故和解决关键合规问题上的时间

  • 花在会议和邮件上的时间，包括上下文切换的成本

  • 花在工作跟踪系统中管理任务的时间

公司将这些因素与 PR 活动的测量结果进行权衡，后者作为编码时间的代理。其逻辑是，一天中可能包含一些繁琐或感觉价值不高的任务，但如果开发者仍有时间编码并提交变更，这就能让天平倾向于拥有一个“好日子”。

Glassdoor 将实验作为 AI 工具的一个成果来衡量。 他们跟踪每月 A/B 测试的数量，以了解 AI 工具是否正在帮助开发者更快地创新。AI 是一个进行实验和原型设计的绝佳工具，所以看到像这样的实验指标成为顶级的 AI 影响指标非常有趣。与此相关，Glassdoor 在将超级用户转变为内部 AI 倡导者方面做得很好。

他们还使用一个不常见的测量方法，称为“已工作容量百分比”，有时也叫“容量利用率”，来衡量每个 AI 工具。该指标关注总潜在容量和实际利用率。这有助于揭示一个工具的能力或采纳何时可能达到瓶颈，这是一个将预算重新分配给更强大替代品的信号。

如今，接受率已很少被衡量。 曾几何时，AI 编码建议被接受的百分比是最主要的 AI 指标。现在，由于其范围狭窄，我们看到它的人气正在下降。这可能是因为接受率只关注建议的那一刻，却忽略了很多其他事情，比如：

  • 被接受的代码是否可维护

  • 被接受的变更后来是否被撤销

  • 建议是否引入了 bug

  • 它是否真的帮助开发者感觉整体上更有效率

许多公司不再将接受率作为顶级指标来跟踪，但也有一些例外：

  • GitHub 自己构建 AI 工具 (Copilot)，跟踪接受率有助于他们了解直接使用情况并指导产品决策。

  • T-Mobile 将接受率纳入其指标，并分享说他们用它作为一个数据点，来帮助确定有多少 AI 编写的代码进入了生产环境，这对许多公司来说是一个极具挑战性的问题。

  • Atlassian 和其他公司将接受率作为开发者对工具满意度的额外代理指标，并以此判断它是否真的在建议好的代码。

支出和成本分析并未被广泛衡量，但这可能很快会改变。如今，大多数组织希望避免通过明确跟踪支出来打击开发者使用 AI 的积极性。一些公司如 Shopify 则采取了相反的方法，推出了一个 AI 排行榜，看看哪些开发者在 token 消耗上花费最多，然后庆祝这种实验精神。

尽管如此，公司仍需确保 AI 投资能带来明确的投资回报，并且 AI 预算是值得的。ICONIQ 的 2025 年 AI 状况报告显示，与 2024 年相比，今年的内部 AI 生产力预算预计将翻一番。这些资金大部分来自研发预算，但一些公司正在重新分配人力预算，以支付用于提升内部生产力的 AI 工具。基本上，一些公司计划减少招聘，以便在 AI 工具上投入更多。

我们已经看到价格上涨（不再是每月 20 美元了！），公司正试图预测明年在 token 消耗和新工具上市方面的成本。所有这些都指向了更高的价格敏感性，这意味着更严格的衡量审查。

智能体遥测数据目前尚未被衡量——但这很可能在未来 12 个月内改变。 目前，特定于 AI 智能体 (agent) 的指标也基本缺失。现阶段，大多数团队还没有将 AI 影响细分到那种粒度，遥测数据本身也仍然有限。自主的智能体工作流将在未来 12-18 个月内继续获得关注。事实上，这是我们预计会发生变化的衡量领域之一，以更好地反映公司在日常工作中使用这些工具的方式。

在编码相关活动之外，几乎没有进行衡量。 除了代码编写，对 AI 工具的直接衡量并不多。预计 2026 年将是 AI 在整个软件开发生命周期 (SDLC) 中大放异彩的一年，衡量方法也需要相应发展以跟上步伐。像代码审查和漏洞扫描这样更具体的用例将更适合遥测，而那些产出更抽象的用例则更难衡量，因为活动和影响之间没有那么直接的联系。

即使是现在，一些公司也将其衡量范围限制在 IDE 或终端内的 AI 代码助手，并不总把与 ChatGPT 的规划会议，或使用 AI 筛选数千张 Jira 工单算作“与 AI 相关的时间节省”。在自我报告的 AI 影响测量方面（例如，“本周你因为 AI 工具节省了多少时间？”），我预计测量的范围会扩大，以跟上不同类型工具的发展。

6. 你应该如何衡量 AI 的影响？

从所有这些指标中，你能学到什么？又应该在你自己的工作场所实施哪些呢？

几个月前，我和 Abi Noda（DevEx 框架的合著者）发布了 AI 衡量框架。我们直接与我为本文采访的一些公司合作，深入了解他们存在的衡量差距。我们亲眼目睹了他们需要用数据做出的决策，并能够第一手地看到哪些方法有效，哪些无效。我们还与其他研究人员合作，将过去十年甚至更久的开发者生产力研究成果纳入我们的建议中。

AI 衡量框架，一套推荐用于衡量 AI 影响的指标

这个框架融合了 AI 指标和核心指标，可以显示 AI 在你的组织中被如何以及在何处使用，最重要的是，它对整体绩效的影响是什么。速度、质量和可维护性都得到了体现，我们建议将开发者体验置于中心位置。与任何框架一样，所有这些衡量标准都需要综合来看。这个框架中的任何单一指标本身都不足以作为一个好的衡量标准，尤其是 AI 生成的提交代码百分比——尽管它很能制造新闻噱头。

这个框架涵盖了衡量什么，但我们仍然需要解决如何衡量的问题。

为了捕捉 AI 影响的多个维度，你需要定性和定量数据。这在开发者生产力领域已经是一个公认的原则，这个模式同样适用于 AI 的影响。看看我为本文采访的公司所使用的指标，所有公司都将系统级的工作流指标（如 PR 吞吐量或 AI 工具的日/周活跃用户）与自我报告的数据（如 AI 工具的客户满意度或每周节省的时间）相结合。本文中提到的几乎所有公司都使用 DX 来捕获这些数据，当然也可以构建自定义系统来收集和可视化数据。

有几种方法可以收集这些数据：

  • 系统数据（定量测量）。大多数 AI 工具提供管理 API 来跟踪使用情况、支出、token 消耗和代码建议接受率。与此同时，你可以从你的开发技术栈中引入系统指标——例如 GitHub、JIRA、CI/CD 流水线、构建系统和事故管理系统。

  • 定期调查（定性）。季度或定期的调查有助于捕捉系统数据本身可能遗漏的开发者体验长期趋势。调查不仅仅是为了获取像开发者满意度、变更信心或代码可维护性这样的感知指标，这些指标是无法从系统级数据中得到的。你也可以通过自我报告的数据来衡量像 PR 吞吐量、变更失败率和使用 AI 的 PR 百分比这样的事情。这种类型的调查也是在遥测不可用或不切实际的领域获取测量数据的好方法。

  • 体验抽样（定性）。这种方法通过在关键工作流程中提出简短问题来收集有针对性的、即时的反馈。例如，在提交一个拉取请求后，你可能会问是否使用了 AI 来编写代码，或者 AI 生成的代码感觉是更容易还是更难理解。

定期调查是上手最快的方式，它将提供混合了自我报告的工作流数据（PR 吞吐量）和无法从系统数据中获得的感知数据。你可以在一两周内部署一个调查并获取数据，收集到的数据通常对于大多数决策来说具有足够的分辨率。记住，测量越精确，成本就越高。当你挂窗帘时，差一毫米左右是可以接受的；但当你造火箭时就不行了。我们作为工程负责人做的大多数决策都是挂窗帘式的决策，而不是造火箭式的决策，我们只需要足够的精度来朝着正确的方向前进。

随着时间的推移，你可以引入其他类型的数据。分层的数据收集方法可以让你交叉验证来自多个数据源的发现。例如，询问开发者对质量实践的看法，同时跟踪变更失败率和事故数量。

常见 AI 指标的定义和计算方法。 当你将这些概念应用到自己的团队时，可以使用这个常见 AI 指标的术语表（一个 Google Sheet）来弄清楚如何定义和收集数据。你可以在下面找到一个完整的 AI 指标和开发者生产力指标术语表：

AI 和开发者生产力指标，第 1 部分

AI 和开发者生产力指标，第 2 部分

如何将这些想法引入公司内部

我为本文采访的公司并没有关于 AI 战略的所有答案，但他们对正在发生的事情有足够的了解，能够很快判断出某些事情是否行不通。

记住，我们不只是在追求采纳率，或任何单一指标。我们试图了解 AI 是否正在帮助我们的组织在以解决客户问题的速度交付高质量软件方面做得更好。我们使用指标来理解 AI 是如何、在何处以及为何实现（或未能实现）这些成果，以便我们能够加倍投入或改变我们的方法。

思考一下你自己的 AI 衡量策略。你能回答这个问题吗：

“AI 是否让我们在那些本已重要的事情上做得更好，比如质量、快速上市时间和无摩擦的开发者体验？”

如果答案是“还没有”，这里有一些可以带到你下一次领导会议的讨论要点。

  • 我们是否对工程组织的绩效有清晰的定义？

  • 我们有关于 AI 工具出现前我们表现如何的数据吗？如果没有，我们如何快速建立一个基线？

  • 我们是否将 AI 的活动误认为是 AI 的影响？

  • 我们的衡量标准是否平衡了速度、质量和可维护性？

  • 我们能看到 AI 工具是如何影响开发者体验的吗？

  • 我们是否有分层的衡量方法，同时关注系统数据和自我报告数据？

7. Monzo 如何衡量 AI 的影响

又是我，Gergely。 非常感谢 Laura 收集了来自不少于 18 家公司的所有这些细节。为了用一些更具体的内容来结束这次深度探讨，Laura 和我采访了 Monzo 银行的团队，了解他们是如何学习 AI 工具为他们的软件工程师带来的实际效果的。Monzo 很适合作为例子，因为它有强大的工程文化，而且那里的人们很务实，不盲目跟风 AI 的炒作。

Suhail Patel 在创新型网上银行 Monzo 领导平台团队。我们询问了团队是如何判断他们的 AI 工具效果如何的。我的问题用斜体表示，Suhail 的回答用引号括起来。

你们在 Monzo 最早引入的 AI 工具是什么？

第一个就是 GitHub Copilot。对于大多数公司来说，这应该是个很普遍的答案，主要是因为我认为 GitHub 的策略玩得很好，Copilot “悄悄地” 潜入了 VS Code。它并不是一个独立的付费项目。一位 GitHub 的代表联系我们，告诉我们 GH Copilot 现在是我们 GitHub 许可证和企业版的一部分。他们鼓励我们使用并让所有工程师都用上。

这是工程师们第一次真正开始“尝鲜”的时候，尤其是在智能体模式、GitHub chat、Copilot chat 以及使用增强的自动补全功能方面。人们真正感受到了这些工具的可能性。

从那以后，我们一直在尝试 Cursor、Windsurf 和 Claude Code，并且我们继续在 Copilot 上进行投入。

对于评估 AI 工具，你对工程负责人有什么建议？

“我们的理念是，在这个瞬息万变的工具领域，如果我们不紧跟潮流，那将是愚蠢的。我们本可以一直只用 GitHub Copilot，但变化太快了！在你亲手尝试这些工具之前，一切都只是猜测。

所以，我能给出的最好建议是，亲身体验各种工具和用例。 你需要团队里的工程师日复一日地在他们的代码上使用这些 AI 工具。你需要他们创建自己的 agents.md 文件，只有通过经常使用，你才会知道这个工具到底好不好用。你需要为这些工具提供尽可能多的上下文，才能看到它们真正能做什么。

此外，客观地评估这些工具很困难；有时你需要接受一些评估是主观的。我们衡量的‘客观’数字是关于使用情况和本地性能的。然后我们进行大量的 DX 调查，来了解工程师们对它们的看法。”

你们怎么判断 AI 工具是否真的有效，是否物有所值？

“这是个价值百万美元的问题，对吧？如果我说我们有唯一的答案，那是在撒谎。现在很多都还是主观的。如果工程师们在情感上感觉到这些工具为他们提供了价值：那么目前来说，这本身就足够有价值了！

AI 工具不仅在写代码方面帮助工程师。 我们的工程师告诉我们，他们感觉这些工具有助于他们：

  • 更轻松、更快速地检索相关文档

  • 更好地进行总结

  • 更好地理解代码

  • … 总的来说，就是用对的工具减少认知负荷

我们处在一个竞争激烈的市场，你希望你的工程师能用上最好的工具。 如果我们不允许我们的工程师使用一流的工具，包括 AI 编程工具，而其他初创公司却在用，那么我们的工程师就会感到沮丧并跳槽到别处去！”

为什么衡量这些 AI 工具的效果这么难，你们在衡量什么？

“说实话，要衡量这些工具在多大程度上推动了业务发展，实在是难得令人沮丧。例如，我们怎么能判断出，由于 AI 生成的代码，我们的组织效率提高了 30% 呢？

如果我们花在修复 AI 生成代码上的时间，和我们手写代码花的时间一样多，那我们根本就没有任何进步！

问题在于，当你有了一个 AI 工具供应商——无论是微软、谷歌还是其他公司——他们只能衡量他们能衡量的东西，而那就是你得到的数字！ 他们只能衡量像接受率这样的代理指标。大多数组织（包括我们现在）都没有能力准确衡量 AI 对业务的影响。

当然，你理论上可以进行 A/B 测试，让一个团队使用 AI 工具，另一个团队不使用——但老实说，这不现实。我认为这个领域不适合 A/B 测试，至少对大多数团队来说是这样。”

要恰当地衡量 AI 的影响，你需要从那些并不想给你真实数字的供应商那里获取遥测数据。 如果我们需要获得准确的使用数据，我们就需要从许多不同的工具中提取统计数据——GitHub Copilot、Gemini、Google Workspaces、Slack、Notion 等等。所有这些工具都有 AI 功能——但如果你想捕获所有这些工具上的所有 AI 使用情况，那几乎是不可能的！供应商有这种自私的动机，让遥测数据变得模糊不清，因为他们想继续保持他们的护城河和用户锁定。要获得你真正关心的实际使用遥测数据非常非常困难，比如：‘告诉我这个工具中的 AI 功能被使用了多少次，以及用户从中得到了什么。’

不幸的是，如今获取这些数据的唯一方法是一种非常侵入性的方式：在笔记本电脑上安装代理来跟踪工程师的时间花在哪里。需要非常明确的是，我绝不提倡这种做法，我们也不这么做。但如果没有这个选项，你剩下的就大多是关于什么有效、什么无效的主观感觉了！”

这些工具在哪些领域表现得特别好？

“AI 工具在帮助我们进行迁移方面真的非常出色。 当我们做像代码迁移，或者引入新的库和依赖项这样的事情时，这些工具可以拼接代码修改，然后起草大部分的迁移工作，直到变得太复杂，需要工程师介入为止。感觉上，使用这些工具，我们节省了以前迁移工作的 40-60% 的精力。

举个例子，我们正在进行一个大项目，就是为我们的数据工具链添加注解。这项工作意味着工程师需要为一堆现有的数据模型定义主题和实体。这是一个非常手动和费力的过程。

现在，使用大语言模型 (LLM) 并用工具把它包装起来，我们就有可能用它们来进行第一遍处理。然后工程师再去检查这些修改，纠正工具搞错的地方。

在这些定义明确的案例中，大语言模型正在处理大部分的繁重工作，而工程师则处理剩下的部分。到目前为止，这感觉是一个巨大的胜利！这也是一个工程师告诉我们他们感觉从这些工具中获益的用例。”

关于 AI 开发工具，你学到了什么反直觉的东西吗？

“我感觉工程师们还没有真正理解这些大语言模型到底有多贵。 如果人们能从他们的组织那里收到一张关于他们实际 AI 使用成本的账单，优化使用就会变得更加突出。

我给你举个例子，如果你在 Google Cloud 上使用 BigQuery，当你写一个 SQL 查询时，它会尝试预测需要扫描多少数据——然后你就能感觉到这可能涉及的时间和资源成本。比如，它可能会告诉你‘这个查询将扫描 10GB 的数据’。你可能会说‘哦，小意思，看起来不错 (LGTM)’。但另一次它会告诉你‘哦，这个查询将扫描 500TB 的数据’。你可能会说‘哇，我可能不需要这么多，我得退一步想想’。

我们在 Copilot 代码审查上也有类似的经历，我们为大量的大语言模型使用付出了成本，却只得到了很少的价值。 我们开启了自动的 GitHub Copilot 审查功能。这个工具花了一大堆 token 给我们提供代码建议。然而，我们发现这些建议并不可行！所以我们就在那里花着 token，还拖慢了工程师的进度，因为他们不得不审查那些毫无意义的建议。

所以，我们默认关闭了这个审查功能。工程师仍然可以请求 Copilot 审查——但现在是选择性加入的。”

你们决定在哪些领域完全不使用 AI 工具？

“我们决定不在业务中真正重要的领域使用 AI。 例如，我们坚决抵制在以下方面使用 AI：

  • 存储任何类型客户数据的区域，即使是经过脱敏处理的

  • 我们的数据仓库，虽然客户数据已经完全编辑处理，但工程师可以查询

在我们有非常强的信心之前，我们不希望人们对客户数据‘掉以轻心’。

偶尔当我指示 Cursor 写一个 shell 脚本时，它会建议一些随机的许可证密钥或 API 密钥，那是别人放在他们环境里的，被 Cursor 的智能体索引了。我们不希望同样的事情发生在任何业务敏感数据上。”

你对 AI 编程工具和软件工程的整体看法是什么？

这是我对这些工具的理念。作为一个平台团队，我们应该：

  • 提供护栏：确保这些 AI 工具能被工程师安全使用，不用担心像数据泄露这样的事情

  • 分享案例：分享关于这些工具成功或失败的有用案例和故事。

  • 更广泛地分享提示 (prompts)：我们希望对那些没有成功的提示，或者有人浪费了半天时间试图让一个提示工作，而那些时间本可以用来真正解决他们试图解决的问题的情况，保持非常透明。

  • 更广泛地分享正面和负面信息：同时看到事情的两面性真的非常非常关键。这不是要说‘AI 怀疑论者是对的！’或者‘AI 支持者赢了’。我们希望提供一个平衡的看法。

  • 提醒人们大语言模型的局限性。 我们想提醒人们继续认识到 AI 工具的局限性，因为任何事物都有局限性；人类有局限性，大语言模型也不例外。”

总结

非常感谢 Laura 的研究，以及她从本文中提到的公司那里获取的数据，也感谢 Suhail 坐下来与我们深入交流他们在 Monzo 一线的观察。

衡量 AI 的影响是一个非常新的领域，并没有一个所谓的“最佳实践”。 即使是规模和市场相似的公司，如微软和谷歌，在 AI 方面的衡量标准也各不相同。上面展示各公司衡量指标的表格说明，每个地方在衡量 AI 效率方面都有自己独特的“风味”。

衡量相互冲突的指标是普遍现象——几乎所有公司都这么做。 最常见的例子是衡量变更失败率（或类似的指标，如 bug 出现的频率/百分比），同时又衡量拉取请求的频率。第一个指标关乎可靠性，下一个关乎速度。只有在不影响可靠性的情况下，更快地交付才有意义；所以你需要同时衡量两者！

衡量 AI 工具对工程团队的影响，与衡量开发者生产力一样，是一个难题。 准确衡量开发者生产力非常棘手，整个行业为此已经挣扎了十多年。我们知道，没有单一的指标能告诉我们一个工程团队的生产力有多高，因为团队可以简单地为了某个指标进行优化，而实际上并没有变得更有效率。2023 年，咨询巨头麦肯锡自信地宣称他们已经“破解”了如何衡量开发者生产力。但极限编程方法的创造者 Kent Beck 和我都对这一说法持怀疑态度，我们在文章《衡量开发者生产力？对麦肯锡的回应》中发表了反驳观点。

在我们弄清楚如何衡量开发者生产力之前，我认为我们无法完全破解如何衡量 AI 工具对开发者生产力的影响。尽管如此，虽然没有一个宏大的解决方案，我们仍应继续试验，如何更好地回答这个问题：“所有这些 AI 编程工具正在如何改变个人、团队和公司的日常和月度效率？”

来源：https://newsletter.pragmaticengineer.com/p/how-tech-companies-measure-the-impact-of-ai

See all posts