本文内容基于斯坦福大学研究员 Yegor Denisov-Blanch 在AIEWF 2025 大会上的演讲，该研究分析了来自数百家公司的近10万名开发者的真实数据。感兴趣并有条件的可以去 YouTube 观看全部演讲内容。

　　近，“AI将取代软件工程师”的论调甚嚣尘上。Meta的马克·扎克伯格（Mark Zuckerberg）甚至在今年年初表示，他计划在年底前用AI取代公司所有中级工程师[2]。这种愿景无疑能鼓舞人心，但也给全球的技术决策者带来了压力：“我们离用AI取代所有开发者还有多远？”

　　斯坦福大学软件工程生产力研究团队的[敏感词]发现，为这个问题提供了一个更现实、更细致的答案。经过对近10万名软件工程师、600多家公司、数千万次提交以及数十亿行私有代码库数据的深入分析，这项大规模研究表明：人工智能确实可以提升开发者生产力，但它绝非一个“一劳永逸”的[敏感词]解决方案，其影响是高度情境化且充满细微差别的。虽然平均生产力提升了约20%，但在某些情况下，AI甚至可能适得其反，降低生产力。

现有研究的局限性：为何我们之前的认知是片面的？
        
（图片来源于网络）

　　在深入了解斯坦福大学的研究方法和结论之前，我们必须先理解为什么此前许多关于AI对开发者生产力影响的研究可能存在偏颇。斯坦福研究团队指出了三大常见缺陷：

　　1.盲目追求提交（Commits）和拉取请求（PRs）的数量：许多研究仅仅通过衡量提交或PR的数量来评估生产力。然而，这忽略了一个关键事实：任务大小差异巨大。提交更多代码并不一定意味着生产力更高。更甚的是，研究发现，AI生成的代码常常会引入新的错误或需要返工（rework），导致开发者不得不投入时间去修复AI先前制造的“烂摊子”。这意味着开发者可能在“原地打转”，看似工作量大，但实际效率并未真正提升。

　　2.“新项目”（Greenfield）与“现有项目”（Brownfield）的偏见：有些研究会将开发者分成使用AI和不使用AI的两组，并让他们在“新项目”（即从零开始构建，没有任何现有上下文）上进行比较。在这种“绿地”场景下，AI确实在生成样板代码方面表现出色，能够显著超越不使用AI的开发者。然而，大多数软件工程任务都涉及现有代码库和复杂的依赖项（即“棕地项目”）。在这种更贴近现实的场景中，AI的优势远没有在新项目中那么明显，因此这些研究的结论往往难以普遍适用。

　　3.对调查问卷的过度依赖：研究发现，询问开发者他们认为自己有多大生产力，其结果“几乎和抛硬币一样”不可靠。一项对43名开发者的实验表明，人们对其自身生产力的判断与实际测量结果之间相关性极低，平均偏差约30个百分点，只有三分之一的人能准确估计自己所属的生产力四分位数。尽管调查问卷对于衡量士气等非量化问题有价值，但它们不能有效衡量实际生产力或AI对其影响。

　　斯坦福大学的严谨之道：衡量“功能性”而非代码行数

　（图片来源于网络）

　　为了克服上述局限性，斯坦福大学的研究采用了更为严谨的代码审核自动化算法[3]。他们的核心目标是衡量?“代码随时间变化所交付的实际功能性”，而不仅仅是代码行数或提交次数。

• 　　从专家验证到自动化模型：理想情况下，代码应由10-15名专家小组独立评估其质量、可维护性和实际产出。研究发现，这些专家之间的意见高度一致，并且他们的评估能够有效预测真实世界的结果。为了将这一过程规模化并使其经济可行，研究团队开发了一个自动化模型，该模型能够与Git版本控制系统无缝连接。它分析每个提交（commit）中的源代码更改，并根据多个维度对其进行量化。由于每个提交都有唯一的作者、时间戳和标识符，这使得他们能够精确衡量团队或公司在时间维度上的生产力变化，即“代码交付的功能性”。

• 　　庞大且私有的数据集：这项研究的关键在于，它利用了来自600多家公司的大量私有代码库数据。这些数据涵盖了近10万名软件工程师、数千万次提交和数十亿行代码。与可能具有误导性的公共代码库不同，私有代码库更具自含性，能更准确地衡量团队或组织的生产力。研究团队因此能够观察到时间序列上的数据趋势，例如COVID-19和AI对生产力的影响。

　　关键发现：AI对开发者生产力影响的细微之处

　　研究的结论清晰指出，AI确实提升了开发者生产力，但这远非一个普遍适用的解决方案。其效益因任务复杂度、项目成熟度、编程语言和代码库规模等多种因素而异。

　　总体生产力提升：初步看似可观，但“返工”成本不可忽视

　　　（图片来源于网络）

　　AI编码工具可以初步增加交付的代码量约30-40%，带来更高的生产力感知。然而，这通常涉及大量的“返工”（rework）——即修复AI引入的bug和问题。返工指的是修改近期提交的代码，这通常是浪费性的。考虑到这些返工后，所有行业和领域内的净平均生产力提升约为15-20%。

　（图片来源于网络）

　　任务复杂度与项目成熟度是关键

　　　（图片来源于网络）

　　AI的效益与任务的性质和项目的成熟度密切相关。

　　·低复杂度、新项目任务（Greenfield Low Complexity）：AI在此类场景下表现出色，带来30-40%的生产力提升。这是AI擅长生成初始、直接代码的典型场景。

　　·高复杂度、新项目任务（Greenfield High Complexity）：提升幅度较为温和，约为10-15%。

　　·低复杂度、现有项目任务（Brownfield Low Complexity）：表现仍然不错，有15-20%的提升。

　　·高复杂度、现有项目任务（Brownfield High Complexity）：这是AI提供帮助少的领域，提升幅度仅为0-10%。研究表明，对于这类高复杂度的任务，AI甚至更有可能因引入难以发现的错误而降低工程师的生产力。

　　编程语言的流行度至关重要：

　　（图片来源于网络）

　　AI的训练数据和能力使其在不同编程语言上的表现差异巨大。

　　·高流行度语言（例如：Python、Java、JavaScript、TypeScript）：这些语言获得了显著的生产力提升，低复杂度任务可达20%，高复杂度任务为10-15%。

　　·低流行度语言（例如：Cobol、Haskell、Elixir）：AI提供的帮助微乎其微。因为AI在这些语言上表现不佳，开发者不愿意频繁使用它。对于这些语言中的复杂任务，AI实际上可能降低生产力，因为它生成的代码质量过差，反而拖慢了开发进程。不过，这类“冷门”语言的开发工作量在全球范围内可能仅占5-10%。

　　代码库规模是重要的限制因素

　　（图片来源于网络）

　　研究还发现一个显著趋势：随着代码库规模的增加（例如，从1万行到1000万行代码），AI带来的生产力提升急剧下降。这主要是由于以下三个原因：

　　·上下文窗口限制（即使是大型语言模型，其性能也会随着上下文长度的增加而显著下降，例如，从1,000个token增加到32,000个token时，性能可能从90%下降到约50%）。

　　·信噪比（更大的代码库可能会混淆模型，降低其有效性）。

　　·依赖项和特定领域逻辑（更复杂的代码库具有更错综复杂的依赖项和独特的业务逻辑，AI难以准确理解和复制）。

　　总结：制定数据驱动的AI战略

　　斯坦福大学的这项研究清晰地表明，AI无疑是软件工程师的强大工具，在大多数情况下确实提高了生产力。然而，盲目跟风、期待AI成为解决所有问题的“银弹”是危险的。理解其局限性至关重要。AI并非一个在所有场景下都能平等提升生产力的[敏感词]药。显著的提升通常体现在：低复杂度任务、新项目、常用编程语言以及相对较小的代码库。

　　对于工程负责人和技术决策者而言，关键在于制定符合自身情况、数据驱动的AI战略，而不是仅仅追随潮流。这意味着：

　　1.精准评估应用场景：识别出能从AI中受益的任务和项目类型。

　　2.设定切合实际的期望：在高复杂度、大型遗留项目或使用冷门语言的场景中，谨慎评估AI工具的引入，并关注其可能带来的“返工”成本。

　　3.持续衡量与调整：采用更科学的生产力衡量方法，超越简单的代码提交量，关注实际交付的功能和质量，并根据数据调整AI工具的使用策略。
        终，成功的关键不是“是否”使用AI，而是“如何”智慧地使用AI，从而[敏感词]化其效益，同时避免潜在的陷阱。

        （本文内容来源于网络）