引言与指南

非常感谢大家加入我今天的会议。很高兴看到这么多人留到最后，会议室座无虚席。在接下来的时间里，我们将涵盖大量内容。因此，我将直接开始。如果您想深入了解任何细节，我们已经发布了一本面向高级管理人员的《AI战略手册》。我将介绍的内容大部分都包含在这本手册中，您可以稍后参考。如果您错过了手册的二维码，别担心，我会在最后再次展示。

GenAI 的当前影响

那么，生成式人工智能（GenAI）目前的实际影响是什么呢？没人确切知道，对吧？一方面，Google 告诉我们，每个人的生产力都提高了 10%。这很有意思，毕竟他们本身就已经很高效了。但另一方面，我们看到了一个现在臭名昭著的 MER 研究，其研究方法存在一些缺陷，结果却显示使用代码助手反而导致生产力下降了 19%。这表明存在很大的波动性和不确定性。

这项研究真正有趣的一点是，尽管存在缺陷，参与研究的每位工程师都感觉自己生产力更高了，但数据却显示他们的生产力实际上有所下降。这很有意思，对吧？这种“诱导性心流”让我们对自己的工作感觉良好，但我们需要正视这一点。Dora 也发布了一些很好的研究，但这些研究是基于行业平均数据。

行业平均与公司现实

当我们观察大型样本和平均数据时，可以看到在 AI 采用率提高 25% 的情况下，出现了一些温和但偏向积极的指标：文档质量提高了 7.5%，代码质量提高了约 3.4%。至少这没有朝着错误的方向发展，对吧？当我们深入分析 DX 的数据时，我们发现情况也是如此。我们是一家专注于开发者生产力测量的公司，拥有大量聚合数据。

当我们查看平均值时，我们发现整体的“变更信心”（即对提交到生产环境的变更感到自信的受访者比例）提高了约 2.6%。在代码可维护性方面，另一项定性指标也显示出类似的积极趋势，变更失败率降低了 1%。虽然这并非微不足道，但这并非全部故事。当我们按公司细分同一批研究数据时，情况就不同了。这里的每个条形图代表一家公司。有些公司变更信心提高了 20%，而有些公司则下降了 20%。我们看到了极端的波动性，这就是为什么平均数据看起来如此平淡，却掩盖了更大的变数。

在代码可维护性方面，我们也看到了同样的情况。变更失败率也是如此。例如，在图表的顶端，变更失败率增加了 2%，而行业基准是 4%。这意味着我们可能比以前多 shipping 50% 的缺陷。我们希望确保自己处于这个范围的较低端，但该如何做到呢？我们发现了一些模式。

采用挑战与有效策略

我们看到，一些组织正在实现关键绩效指标（KPI）的积极增长，但其他组织在采用方面却步履维艰，甚至看到了负面影响。自上而下的指令是无效的。比如，强制要求 100% 采用 AI，这只会导致人们每天更新一下文件以示合规，但实际上并没有真正推动任何进展。我们还发现，缺乏教育和赋能对 AI 采用产生了负面影响。有些组织只是开启了技术，然后期望它能自动运行，并且每个人都知道如何最好地使用它。

此外，衡量影响的难度，甚至不知道应该衡量什么，也是一个问题。例如，利用率是否真的能告诉我们 GenAI 影响的全部故事？这是 Dora 的另一张图表，它使用贝叶斯后验分布来表示数据。基本上，您希望数据集中在图表的右侧（黄色区域）。您希望有一个尖锐的峰值，表明我们对某个举措将产生特定影响非常有信心。

如果我们看一些顶级的举措，比如明确的 AI 政策，这很重要。我们希望有时间去学习，不仅仅是提供材料，而是真正给予人们实验的空间。因此，这些因素似乎是推动进展最关键的。

将 AI 集成到 SDLC

我们将讨论如何将 AI 集成到整个软件开发生命周期（SDLC）中。对于大多数组织而言，编写代码从来都不是瓶颈。通过代码补全，我们可以略微提高生产力，但最大的瓶颈存在于 SDLC 的其他环节。创建软件不仅仅是编写代码。我们需要解除使用上的障碍。我们不能仅仅因为担心数据泄露就放弃尝试。要发挥创意，利用现有的强大基础设施，如 Bedrock 和 Fireworks AI，在安全的环境中运行强大的模型。

我们必须就这些指标进行公开讨论。我们需要宣扬成功案例，并让工程师了解我们收集指标和数据的目的——我们试图改进什么。我们必须减少对 AI 的恐惧。人们需要明白，AI 不是要取代工程师的技术，而是要增强工程师的能力，提高业务的吞吐量。我们必须建立更好的合规性和信任机制，并将这些措施与员工的成功联系起来。这些是新的技能。AI 不会抢走你的工作，但一个非常擅长 AI 的人可能会。因此，作为领导者，我们有机会帮助我们的员工更好地利用这项技术。

减少恐惧与建立信任

那么，我们如何减少恐惧呢？首先，为什么我们需要这样做？有很多好理由，但我喜欢引用 Google 的“项目亚里士多德”（Project Aristotle）。这是 Google 在 2012 年进行的一项研究，旨在找出高效团队的特征。他们原以为成功的秘诀在于高绩效员工、经验丰富的管理者以及无限的资源，但他们大错特错了。压倒一切的生产力指标是“心理安全感”。这一点在今天同样适用。

我们还有像 SweetBench 这样的数据。我相信很多人都见过它。代理（agents）在没有人类干预的情况下可以完成约三分之一的任务。这意味着它们无法完成另外三分之二的任务。再次强调，我们是在增强，而不是取代。我们还没有准备好，也许永远不会准备好。因此，我们需要对我们正在做的事情保持透明。我们需要设定非常明确的意图——我们是利用 AI 来增强，而不是取代。我们需要主动沟通这一点，而不是等到人们感到不满甚至害怕。

度量 AI 影响：速度与质量

我们需要明确表示：“不，我们在这里是为了帮助你，为你提供更好的开发者体验，并提高业务的吞吐量。”我们必须再次就指标进行讨论。那么，应该看哪些指标呢？DX，作为一家开发者体验和生产力测量公司，我们关注两个关键的衡量维度：速度和质量。我们希望提高 PR 的吞吐量，提高我们的开发速度，但不是通过制造一堆未来会带来技术债务的“垃圾代码”。那样只会将瓶颈推迟到未来。

因此，我们应该关注诸如变更失败率、整体质量感知、变更信心和可维护性等指标。我们有三种类型的指标可以关注：遥测指标（来自 API 的数据，有时不准确——例如，“接受”与“建议”的例子，工程师需要点击“接受”才能被 API 记录，即使接受了，他们也可能重写所有建议的代码）。这提供了一些背景信息，但我们也需要进行体验抽样。例如，在 PR 表单中添加一个新字段，询问“我是否使用 AI 生成了此 PR”或“我是否喜欢使用 AI 生成此 PR”，以此来收集数据。然后是自我报告数据或调查数据。我们非常重视调查，但要强调的是，我们重视的是有效的调查。

有效的调查与系统性思维

我们需要超过 90% 的参与率，并设计那些将开发者体验视为系统性问题而非个人问题的调查。正如 W. Edwards Deming 所说，90% 到 95% 的组织生产力是由系统决定的，而不是由工人决定的。因此，基础的开发者体验和开发者生产力指标仍然最重要。我们的 AI 指标，如利用率，告诉我们技术的使用情况，但这些我们一直以来可以信赖的核心指标，则告诉我们这些举措是否真的在奏效。我们是否真的在推动进展并实现我们想要的结果？

公司案例与 DXAI 框架

顶尖公司正在关注不同的方面。我们看到 Microsoft 提供了采用指标，他们还有一个很棒的指标叫做“糟糕的开发者日”。Dropbox 也在关注类似的东西，比如采用率（周活跃用户、日活跃用户），但也关注质量指标，如变更失败率。Booking.com 也在关注类似的方面。

基于这些洞察，我们构建了一个框架。我们率先推出了我们称之为“DXAI 测量框架”。它很大程度上受到 Dora 的 SPACE 框架和我们核心的四个指标集（您可以稍后询问我）的启发。我们把这些指标归一化为三个维度：利用率、影响和成本。您可以将其视为一个成熟度曲线。很多人一开始只是想弄清楚发生了什么：谁在使用这项技术？有多少比例的 PR 是 AI 辅助的？通过体验抽样，有多少任务被分配给了代理？然后，我们可以进一步成熟这个视角，将利用率与影响相关联：这项技术实际上对开发速度有什么影响？对质量有什么影响？这时，我们就能更全面地了解我们的影响。最后是成本。虽然我喜欢开玩笑说我们已经过了云计算的炒作周期 15 年了，但仍有新公司出现，教我们如何理解和优化云成本。所以，我们拭目以待。尽管如此，我也听到过一些可怕的故事，比如有人每天花费 2000 美元在 token 上。所以，我们可能确实需要关注这一点。

合规性、信任与模型控制

那么，合规性和信任呢？我们能做些什么来确保工程师可以信任所生成的输出？我们有很多可以操作的杠杆，但我特别想谈谈为系统提示（system prompts）建立反馈循环。这些可以被称为系统提示、光标规则或代理 Markdown。几乎所有主流解决方案都有类似的功能，允许你提供一套规则来控制模型的行为。我不会深入技术细节，但有一个例子是，模型提供了过时的 Spring Boot 版本信息。我们想要 Spring Boot 3，但它却一直在发送 Spring Boot 2 的内容。

这里的关键 takeaway 是建立反馈循环。设立一个“守门人”，在组织内有一个人或一个团队，能够接收反馈，并理解如何维护和持续改进这些系统提示。通过这种方式，我们就能持续地控制这些助手、模型或代理对整个业务的影响。

了解“温度”（temperature）参数如何工作也很有价值，尤其是在构建代理时。我们可以控制模型确定性和非确定性。当模型预测下一个 token 时，它并非只有一个选择，而是有一个 token 矩阵，每个 token 都关联着一定的概率。我们有一个叫做“温度”的设置，它代表了熵或随机性，可以控制在选择 token 时涉及的随机性程度。这有时被称为提高模型的“创造力”。它的值在 0 到 1 之间。出于我刚才提到的原因，不要使用 0 或 1，否则会发生奇怪的事情。但您需要一个介于 0 和 1 之间的十进制数。

当温度较低时（例如 0.001），我们两次给它相同的任务，它会给出完全相同的输出，逐字不差。当我们将温度设置得更高时（例如 0.9），我让代理为我创建一个渐变。这是一个简单的任务。它给出了两个相对有效的解决方案。我确实要求它提供一个 JavaScript 方法，但只有其中一个给出了 JavaScript 方法。关键在于，它们是解决同一问题的截然不同的方法，因为我增加了模型的“创造力”。因此，我们需要根据用例来考虑，在哪些场景下应该有更多的创造力，哪些场景下应该有更多的确定性，而温度是我们可以用来控制这一点的一个设置。您可以使用 Docker、Model Runner、LM Studio 等工具来尝试所有这些。

员工成功与最佳实践

我们如何将 AI 与更好的员工成功联系起来？我们必须提供教育和充足的学习时间。我们进行了一项研究，抽样调查了许多开发者，他们每周至少节省了一小时。我们让他们对最有价值的五个用例进行排序。然后，我们围绕这些用例构建了一个指南，其中包含代码示例和提示示例。我们通过数据分析确定了最佳实践，并鼓励大家反思 AI 的使用方式。我们已经让这本指南成为某些工程团队的必读材料，对此我们感到自豪。这也是我们可以帮助教育的一种方式。

但我们必须给予时间。我们没有时间详细介绍所有内容。我认为有趣的是，排在第一位的用例是“堆栈跟踪分析”（stack trace analysis），这并非生成式用例，而是一种解释性用例。我们还看到了其他一些并不令人意外的用例。每种用例都有相应的示例。

解除使用限制与 SDLC 集成

那么，如何解除使用限制呢？我们如何确保能够创造性地让工程师最大限度地利用 AI？可以利用自托管和私有模型，这越来越容易实现。从第一天起就与合规部门合作，确保您的工作符合组织的合规要求。您可能会发现，您对某些事情做了很多假设，认为自己做不到，但实际上是可以做到的。然后，围绕各种障碍进行创造性思考。

最后，我们如何实现跨 SDLC 的集成？我们应该考虑做什么？我是一位坚定的 Eli Gold“约束理论”的粉丝，可能在座还有其他人。在非瓶颈环节节省一小时是毫无价值的。当我们查看近 14 万名工程师的数据时，我们发现 AI 确实带来了可观的年化时间节省，但这些节省却被上下文切换、中断、会议过多等因素所抵消。我们可以在这里节省时间，但却在那里损失更多时间。所以，找到瓶颈，解决瓶颈。

实际案例分析

摩根士丹利（Morgan Stanley）公开表示，他们正在构建一个名为“Dev Gen AI”的工具，该工具可以分析大量遗留代码，如 Cobalt、mainframe natural，甚至（我不得不承认）Pearl，因为我是一名老派的 Pearl 开发者，但现在它也变成了遗留代码。该工具可以创建规范，直接交给开发人员，让他们在无需进行大量逆向工程的情况下开始现代化代码。目前，他们每年节省约 30 万小时。《华尔街日报》 和 《商业内幕》 都有关于此的报道，他们对此非常公开。

Zapier 应该成为所有人的榜样。他们拥有一系列机器人和代理，可以协助入职。现在，他们可以在两周内让工程师具备工作能力。行业基准是大约一个月，或者在一般情况下是 90 天。由于他们能够提高新入职工程师的效率，他们意识到自己应该招聘更多人，而不是通过裁员来维持现状，并试图提高单个工程师的生产力。他们说：“不，我们可以从单个工程师那里获得更多价值。我们应该比以往任何时候都更快地招聘。”他们确实在这样做，并且这极大地增强了他们的竞争优势。我认为这是正确的态度。

Spotify 也在帮助他们的 SRE（站点可靠性工程师），在检测到事件时汇总上下文信息，并将运行步骤和其他上下文信息直接推送到 SRE 频道，从而消除了在找出问题根源和解决事件时浪费的关键时间。这显著提高了他们的平均修复时间（MTTR）。所以，让我们对 SDLC 中实际存在的瓶颈领域发挥创意吧。

后续步骤

好的，下一步是什么？将这份指南作为参考，用于将 AI 集成到您现有的开发工作流程中。确定一种衡量和评估 GenAI 影响的方法。确保我们不在前面展示过的那些图表的负面区域。然后，跟踪和衡量 AI 的采用情况，并观察其与整体影响指标的相关性，并不断迭代最佳实践和用例。

再次感谢大家。