内容概要
在本次演讲中，斯坦福大学研究员 Yegor Denisov-Blanch 探讨了一项涉及 120,000 名开发者的深入研究，旨在确定 AI 工具在软件工程中的真实投资回报率（ROI）。他提出了一种超越代码行数等简单指标的生产力衡量方法，分析了驱动 AI 成功应用的关键因素（如代码库的整洁度），并介绍了一个用于追踪工程产出的框架。演讲最后通过一个案例研究展示了为何仅依赖拉取请求（PR）数量会导致对 AI 影响力的误判。
目录
-
介绍与方法论
-
议程与生产力趋势
-
顶尖绩效的驱动因素
-
环境整洁度的影响
-
AI 工程实践基准
-
衡量 AI ROI
-
案例研究：超越拉取请求（Pull Requests）
-
结论与参与呼吁
介绍与方法论
公司在 AI 工具上花费了数百万美元用于软件工程，但我们真的知道这些工具在企业环境中的效果吗？还是说这一切只是炒作？为了回答这个问题，过去两年我们一直在研究 AI 对软件工程生产力的影响。
我们的研究既包含时间序列分析（基于 Git 历史数据回溯），也是横截面研究（跨越多家公司）。我们衡量影响的主要方式是使用一个机器学习模型，该模型能够模拟人类专家小组的评估。
原理是这样的：想象一名软件工程师提交了一个代码 Commit，这个 Commit 会由 10 到 15 名独立专家组成的多个小组进行评估。专家们会从实施时间、可维护性和复杂性等方面对该代码进行评价，并输出评估结果。
我们利用这些专家小组对数百万次评估的标签训练了一个模型，以此来大规模复制专家小组的能力。如果对模型的输出有任何疑问，你随时可以组建自己的人工小组进行验证，你会发现模型结果与现实情况具有很高的相关性。
议程与生产力趋势
今天我们将讨论四件事。首先，我们将探讨推动软件领域 AI 生产力提升的一些因素。其次，我们会查看我们开发的一个 AI 实践基准。然后，我们将探讨如何在软件工程中衡量 AI 的投资回报率（ROI）。最后，我们将通过一个案例研究来总结。
我们选取了 46 个使用 AI 的团队，并将他们与 46 个未使用的类似团队进行匹配，按季度衡量 AI 带来的净生产力收益。数据显示，阴影区域代表数据的中间 50%，深蓝色线代表中位数，截至今年 7 月，这一群体的生产力提升约为 10%。
我想请大家注意一个事实：表现最好的团队与表现最差的团队之间的差距正在扩大。如果我们要非常不科学但在图示上预测未来的话，可能会出现一种“富者愈富”的效应：成功的早期 AI 采用者通过复利扩大优势，而那些陷入困境的团队则会落后得更远。
最终这种差距可能会收敛，但这表明作为一个企业领导者，你确实需要清楚自己当前处于哪个梯队，以便及时修正方向。如果不衡量 AI 对工程师的影响，你就无法做到这一点。
顶尖绩效的驱动因素
我们开始调查驱动顶尖团队表现更好的因素。首先我们查看的是 AI 使用量，即 Token 的消耗量。
在这张图表中，纵轴同样是生产力增长，横轴是对数刻度下的每位工程师每月的 Token 使用量。你可以看到相关性非常低，线性相关系数仅为 0.20 左右。
在 1000 万 Token 的使用量附近甚至出现了一种“死亡谷”效应，使用该量级 Token 的团队表现似乎比使用量稍少的团队更差。虽然这只是方向性的观察，但也很有趣。这里的结论可能是：AI 使用的质量比 AI 使用的数量（价值）更重要。
环境整洁度的影响
我们进行了更深入的挖掘，想知道工程师的工作环境是否会影响 AI 的生产力。我们提出了一个实验性的“环境整洁度指数”。这是一个综合评分，涵盖了测试、文档类型、模块化程度和代码质量。
该指数在底部横轴上从 0 到 1 排列。纵轴依然是相对于未使用 AI 团队的生产力提升。你可以看到环境整洁度与 AI 带来的收益之间存在大约 0.40 的 R-squared 相关性。这说明：要解锁 AI 的生产力收益，必须投资于代码库的卫生状况。
为了说明这个概念，我们在图表的纵轴上列出了可能由 AI 完成的任务百分比，并用三种颜色区分。绿色意味着 AI 可以完成该冲刺（Sprint）中的大部分工作；黄色意味着 AI 可以提供帮助；红色意味着 AI 用处不大。这虽然是图示性的，但传达了核心观点。
任何代码库在任何时间点都位于该图表的一条垂直线上。我们发现：首先，整洁的代码能放大 AI 的收益。其次，你需要管理代码库的熵（即技术债务），因为如果你只是不受控制地使用 AI，它会加速这种熵增，导致代码库整洁度向左侧退化。作为人类，你需要从另一侧推动以改善或维持整洁度，从而持续获得 AI 的红利。
第三，工程师需要知道何时使用 AI，何时不使用。如果他们不加区分，就会出现左侧线条所示的情况：AI 的输出被拒绝或需要大量重写，这会导致工程师失去信任，认为“这根本不管用，我不用了”，进而导致 AI 收益进一步崩塌。
AI 工程实践基准
接着我们思考，能否不仅关注使用量，还能了解这些公司和工程师是如何使用 AI 的？于是我们提出了“AI 工程实践基准”。我们可以扫描你的代码库，检测 AI 的“指纹”或伪影（Artifacts），即团队使用 AI 的痕迹。
目前这还是方向性的，但在不断演进。我们可以根据使用每种 AI 模式的活跃工程工作的百分比来量化这一点，并利用 Git 历史按月重复检测。
这个基准大致分为几个等级：0 级是人类完全不使用 AI 编写代码；1 级是个人使用，工程师之间不共享 Prompt（提示词）或不对其进行版本控制；2 级是团队使用，团队之间共享这些 Prompt 和规则。
3 级则更复杂，AI 自主完成特定任务，尽管可能不是整个工作流；4 级是代理编排（Agentic Orchestration），即由 AI 运行整个流程。如果你在 Sweeper 研究门户网站注册，可以使用这个开源工具。
我们将此基准应用于研究数据集中的一家公司，这家公司有两个业务单元，拥有完全相同的 AI 工具访问权限（相同的许可证、支出和工具）。但按业务单元划分，采用率和使用率差异巨大。
左侧的第一个业务单元似乎大量使用 AI，几乎 40% 的工作都用到了 AI；而右侧的第二个业务单元则明显落后。这带来的启示是：拥有 AI 访问权限甚至有 AI 使用量，并不保证 AI 在整个公司内被以相同的方式使用。作为领导者，你不仅要了解工程师是否在使用 AI，还要了解他们“如何”使用 AI。
衡量 AI ROI
好的，让我们深入探讨如何真正衡量软件工程中的 AI 投资回报率（ROI）。理想情况下，我们应该基于业务成果来衡量，例如“我给工程师提供了 AI，然后赚了更多钱、收入更高或净收入留存率提升”等业务 KPI。
问题在于，从“处理”（提供 AI）到“结果”（业务成果）之间存在太多噪音。此外还有混杂变量，如销售执行力、宏观环境、产品策略等。因此，虽然那是理想状态，但遗憾的是我们需要寻找替代路径。
最合乎逻辑的路径是关注“工程产出”，因为这里有清晰的信号。但我们需要超越单纯衡量 AI 使用量，转而衡量工程产出。
这里有几个注意事项，这个话题讨论得很激烈。首先，这假设产品部门能正确地将增加的产能引导到产生价值的地方。如果无法引导，那就是产品问题，虽然与工程紧密相关，但略有不同。
第二个注意事项是，这假设工程确实是价值的瓶颈（通常确实如此），并且你可以通过使用平衡的指标体系以及建立不将指标武器化的良好公司文化来防范古德哈特定律（Goodhart's Law）。
第三，AI 仍然非常新，衡量代理指标总比不衡量好。在这场 AI 竞赛中会有赢家和输家，进步胜过完美。我想说明的是，指标不需要完美才有用。
要获得 AI 的 ROI，你需要做两部分工作：衡量使用情况，以及衡量工程产出。让我们从使用情况开始。
对于企业来说主要有两类：基于访问权限（Access-based）和基于实际使用（Usage-based）。基于访问权限是看人们何时获得工具访问权，你可以设置试点组与对照组，或者衡量同一团队随时间的变化。
但基于访问权限的方法噪音很大，黄金标准是基于实际使用，即利用编码助手 API 的遥测数据来确切知道谁在何处使用 AI。
这里的限制是供应商 API 各不相同。像 GitHub Copilot 这样的工具会聚合数据，而像 Cursor 这样的工具则提供更细粒度的数据。最大的收获是，你可以利用 Git 历史追溯以往的影响。你不需要现在设定实验并等待 6 个月，如果你已经采用了 AI，完全可以回溯过去进行分析，这很容易。
看完了使用情况，我们来看看如何衡量工程产出。我们提议的框架包含“主要指标”和“护栏指标”。
主要指标是“工程产出”，它不是代码行数，不是拉取请求（PR）数量，也不是 DORA 指标。它基于我之前提到的模拟专家小组的机器学习模型。第二组是“护栏指标”，你需要将其维持在健康水平，但不应追求最大化（最大化它们没有意义）。
护栏指标分为三类：返工与重构、质量技术与风险、人员与 DevOps。要注意第三类并非生产力指标，它们有用，但你不能为了最大化开发人员生产力而盲目提升它们，它们在某点会失效。这里的目标可能是保持护栏指标健康，同时尽可能提高主要指标。
案例研究：超越拉取请求（Pull Requests）
现在让我们深入一个案例研究。我们要展示的是一家大型企业，我们选取了一个由副总裁领导的 350 人团队，并测量了拉取请求（Pull Requests）。这样做是为了说明你不能仅通过测量 PR 来了解 AI 是否对你有帮助。
该团队在今年 5 月采用了 AI，我们测量了之前 4 个月和之后 4 个月的数据。我们看到 PR 增加了 14%。太棒了。但这忽略了审查者的负担和代码质量。
于是我们测量了代码质量。首先，你可以把代码质量看作是 0 到 10 分的可维护性量表。我们的方法论可以在线查阅。你会发现在 AI 引入前，他们的代码质量相当稳定一致。一旦采用 AI，发生了两件事：代码质量下降了，且变得更加不稳定。
接着我们查看了我们的指标——工程产出（并非代码行数）。我们将每个月的产出总和分解为四个部分：返工（Rework）、重构（Refactoring）、新增（Added）和移除（Removed）。
返工是指修改或编辑近期刚写的代码；重构是指修改较旧的代码。新增和移除则不言自明。我们可以将这家公司与行业内类似公司进行基准比较。
在这里，AI 的使用产生了两个效果。首先，返工增加了 2.5 倍，这是非常糟糕的。其次，有效产出（作为生产力的代理指标）并没有实质性变化。
结论是什么？回顾一下：我们看到 PR 增加了 14%，但这不具决定性，因为更多的 PR 不代表更好；代码质量下降了 9%，这很有问题；有效产出没有显著增加；而返工大幅增加。
那么，这次 AI 采用的 ROI 是多少？可能是负的。我想指出的是，如果这家公司没有更彻底地衡量，而仅仅看 PR 数量，他们会认为：“嘿，我们要发了，生产力提高了 14%，换算成钱是数百万美元，肯定能抵消 AI 许可证的费用。”
另一方面，我认为这家公司不应该放弃 AI。他们应该利用这些数据来理解哪里做错了，如何改进，因为 AI 是大势所趋，它将改变工程师的工作方式，你不能简单地放弃它。
结论与参与呼吁
这就结束了我们今天的分享。如果你喜欢这个演讲，并希望为你的公司获取类似的洞察，我邀请你参与我们的研究。今天你看到的所有内容都可以通过参与研究获得，部分内容可以通过我们研究门户的实时仪表板访问。
我特别想邀请那些可以使用 Cursor Enterprise 的公司参与，因为我们非常需要这类数据，以便发表关于软件工程中 AI 使用颗粒度的论文。你可以访问 softwareengineeringproductivity.stanford.edu 注册。非常感谢。