关于AI辅助编程的十二种错误评估方式

假设下周你的经理要求你证明公司签约的AI编码工具物有所值。你会衡量生成的代码行数还是关闭的工单？或者你会发送调查问卷询问开发者是否感觉更有效率？每种方法都有不同的缺陷，下文将解释原因。

注意：本文讨论的是人们如何评估AI，而非LLM辅助编码本身；稍加改写，这些批评也适用于敏捷开发、测试驱动开发等其他实践的主张。如果我在过去二十年中学到了什么，那就是如果我们愿意让人文科学领域的同行教我们如何正确研究这类问题，软件工程今天会进步得多。

计算生成的代码行数：代理指标用于衡量难以直接测量的概念，代码行数是最古老的之一。LLM生成更多代码，但不一定带来更好的结果：团队在采用LLM工具后每位开发者的代码行数增加40%，衡量的是冗长而非生产力。删除2000行混乱逻辑并用200行整洁代码替代，是看似损失的改进。更多代码也意味着更多阅读、维护和调试的工作，而AI对此未来负担的贡献并未体现在行数中。

计时人工任务：一项被广泛引用的研究发现，使用GitHub Copilot的开发者完成任务的速度比不使用的快55%。任务是在90分钟内从头开始用JavaScript实现HTTP服务器，开发者当天没有其他义务。真正的软件开发涉及浏览未编写的庞大代码库、理解描述模糊的工单需求、与同事协调、参加会议。在绿色场玩具任务上的速度无法预测这些任务的速度。一项针对有经验的开源开发者的随机对照试验发现，结果与参与者自我预测相反：使用AI工具使任务完成时间增加了19%。

前后对比无对照组：你从1月开始使用LLM；到6月，拉取请求交付更快，所以工具一定有效，对吗？但1月到6月之间你招聘了12名工程师，重构了CI管道，并更换了云提供商。没有未采用工具的对照组，你无法分离LLM的效果与同期发生的其他变化。内部有效性需要可信的反事实，即知道否则会发生什么的方法。

询问开发者是否感觉更有效率：诸如“87%的开发者报告使用AI工具后感觉更有效率”的调查结果常被引用为工具有效的证据，但有三点使得自我报告具有系统性误导：霍桑效应（知道被观察时工作方式不同）、新奇效应（新工具因新奇而感觉更快，但感觉通常在几周内消退）、社会期望偏差（受访者倾向于说调查想听的话，尤其是管理层选择了工具时）。

计算提交、拉取请求和工单数量：2023年，麦肯锡提议使用提交、拉取请求、代码审查等活动数量来衡量个人开发者生产力。古德哈特定律指出，当一个指标成为目标时，它就不再是好指标。当开发者知道提交数量被追踪时，他们会进行更多、更小的提交；当工单数量被追踪时，工单被拆分。数字改善，但基础工作并未改善。活动不是产出，产出不是价值。

仅衡量简单的一半：LLM使代码生成更快，这一半容易衡量。另一半更难：审查LLM生成代码正确性的时间、调试错误建议的时间、看似合理但不安全的代码引入的安全漏洞、以及来自忽略周围设计只解决直接问题的建议的技术债务。对GitHub Copilot代码的研究发现，相当一部分生成代码包含安全漏洞，且时间压力下的开发者接受不安全建议的比例更高。2025年对五个主要LLM的评估发现，没有一个能生成符合行业安全标准的Web应用程序代码。一项对30多万个AI撰写提交的大规模分析发现，超过15%引入至少一个质量问题，其中近四分之一长期存在于代码库中。只衡量上升的输入而忽略同样上升的成本，不是衡量，而是营销。

将采用率视为成功指标：“我们在工程部门实现了90%的AI工具采用率”是采购结果，而非生产力结果。采用率衡量工具是否安装和打开，不说明建议是否有用、开发者是否不加思考地接受、或接受的建议是否正确。高采用率加上低建议质量，会导致团队花时间管理工具而非受益于工具。对IBM企业AI编码助手的研究发现，虽然工具通常提供净生产力提升，但这些收益并非在用户群中均匀分布。但采用率比收益更容易衡量，这正是它被报告的原因。

比较志愿者与非志愿者：比较选择使用LLM的开发者与未使用的开发者的研究，比较的是两个不同群体，而非两种条件。早期采用者与晚期采用者和非采用者在直接预测生产力的方面存在差异：他们更有实验动机，更适应新工具，更可能是高绩效者。选择偏差意味着任何观察到的群体差异可能是人的特性而非工具的特性。这是行业AI生产力报告中最常见的设计缺陷，因为它是最便宜的研究。一项为期两年的大型IT组织Copilot使用纵向研究发现，使用工具的开发者即使在使用前也一直比非用户更活跃。

衡量个体而非系统：个体编码速度是最容易衡量的，因此被衡量。但如果AI工具帮助开发者编写代码快30%，而团队从工单到生产的时间没有变化，那么瓶颈不是编写代码。生成更多代码也意味着更多代码需要审查：如果AI增加代码量而不增加审查能力，周期时间可能恶化。一项针对专业开发者的实证研究发现，虽然AI工具提高了经验较少的贡献者的输出，但高级开发者的生产力下降了19%，因为他们吸收了AI生成代码带来的6.5%的代码审查负载增加。优化管道的一个阶段而忽略其他阶段，是伪装成生产力研究的系统思维失败。

在新奇期间衡量：一项为期四周的研究发现生产力提升，只是发现了四周的生产力提升。新奇效应是真实的：开发者在初始阶段对新工具更投入，这相对于长期基线会夸大观察到的表现。真正重要的效果会在数月而非数周内显现，包括因任务委托给AI导致的技能萎缩、错误建议积累的技术债务、或团队协作方式的变化。旨在检测短期收益的研究，并不能告诉你研究结束后会发生什么。对807个采用Cursor的开源仓库的分析正好发现了这种模式：采用带来了大量但短暂的开发速度提升，同时伴随着代码复杂性和静态分析警告的显著且持续的上升。

将建议接受率视为质量信号：LLM编码助手通常报告其建议被开发者接受的分数，更高的接受率被视为工具有用的证据。接受率衡量生成的代码看起来是否足够合理以至于开发者按下Tab键；它不衡量代码是否正确、安全或可维护。时间压力下的开发者接受更多建议，包括不安全的，因此紧迫的截止日期使接受率因完全错误的原因而上升。一项对400名开发者的企业研究发现平均接受率为33%，同时伴随高开发者满意度，但没有跟踪接受代码的正确性或安全性。一个奖励看起来足够好的指标，并不是奖励真正好的指标。

将AI与无工具比较：将AI辅助开发者与使用无工具的对照组比较的研究，选择了实践中不存在的基线。没有LLM助手的开发者会使用文档、同事以及他们原本用于思考问题的时间。相关问题是LLM工具是否优于开发者已有的替代方案，而这种比较很少进行。选择弱基线使任何工具看起来不错，但这并不使工具变得有用。

我衷心感谢多年来花时间向我解释这些内容的所有人。我所写的任何错误或过度简化都完全是我的责任。