关于AI辅助编码的十二种错误方式

# 关于 AI 辅助编程的十二种错误认知 来源：https://third-bit.com/2026/05/20/twelve-ways-to-be-wrong/ 假设下周你的经理要求你证明公司签约使用的 AI 编程工具物有所值，你会用生成的代码行数来衡量，还是关闭的工单数量？或者你会发一份问卷，询问开发者是否感觉更有效率？上述每种方法都有各自的缺陷；下面各节将解释原因。 > 注：本文讨论的是人们如何评估 AI，而非 LLM 辅助编程本身；稍加修改，这些批评就可以适用于关于敏捷开发、测试驱动开发及其他实践的大量主张。如果过去二十年我学到了什么的话，那就是：如果我们当初愿意让人类科学领域的同行教会我们如何正确地研究这类事物，软件工程今天会进步得多。此外，如果你想要一个为期一天的入门课程，介绍如何避免这些错误的研究方法，请[联系我](mailto:[email protected])。我没有资格讲授，但我认识有资格的人，而且我或许能说服他们来教…… ## 统计生成的代码行数 代理指标用来衡量难以直接测量的概念，而代码行数是最古老的代理指标之一。LLM 生成更多代码，但未必带来更好的结果：一个团队在采用 LLM 工具后，每位开发者的代码行数增加了 40%，但测到的只是啰嗦程度，而非生产力。删除 2000 行混乱的逻辑，用 200 行干净的代码替换，这是一个改进，但在该指标上却表现为损失 [Sadowski2019]。更多的代码也意味着更多要阅读、维护和调试的内容，而 AI 对未来负担的贡献并未体现在行数中。 ## 计时人工任务 一项被广泛引用的研究发现，使用 GitHub Copilot 的开发者的任务完成速度比不使用的快 55% [Peng2023]。该任务是从头用 JavaScript 实现一个 HTTP 服务器，限时九十分钟；开发者那天没有其他任务。真正的软件开发涉及在不是你编写的大型代码库中导航、理解工单中含糊不清的需求、与同事协调以及参加会议。在一个从头开始的花哨玩具任务上的速度，并不能预测在这些实际工作上的速度。一项针对经验丰富的开源开发者的随机对照试验发现，与参与者自己的预期相反：让他们使用 AI 工具反而使任务完成时间增加了 19% [Becker2025]。 ## 无控制组的前后对比 你从一月开始使用 LLM；到六月，拉取请求的交付速度更快了，所以工具肯定有效，对吗？但在一月到六月之间，你招聘了十二名工程师、重构了 CI 流水线、切换了云提供商。如果没有一个没有采用该工具的控制组，你就无法将 LLM 的效果与同时发生的其他变化分开。内部有效性需要一个可信的反事实，也就是一种了解如果不这样做可能会发生什么的方式。 ## 询问开发者是否感觉更有效率 像“87% 的开发者表示使用 AI 工具后感觉更有效率”这样的调查结果经常被引用来证明工具有效 [Liang2024]，但有三个因素使自我报告系统性地产生误导： - 霍桑效应：当人们知道自己被观察和评估时，他们的工作方式会不同； - 新奇效应：新工具因为新鲜而感觉更快，这种感觉通常会在几周内消失； - 社会期望偏差：受访者倾向于说他们认为调查想听的话，尤其是在管理层选择了该工具的情况下。 ## 统计提交、拉取请求和工单数量 2023 年，麦肯锡提议使用提交数、拉取请求数、代码审查数等类似活动来衡量开发者个人的生产力 [McKinsey2023]。古德哈特定律指出，当一个指标成为目标时，它就不再是一个好指标 [Goodhart1984]。当开发者知道自己的提交次数被追踪时，他们会做更多、更小的提交；当工单数被追踪时，工单会被拆分。数字改善了，但底层工作并没有 [Beck2023]。活动不等于产出；产出不等于价值。 ## 只测量容易的一半 LLM 使代码生成更快，这一半很容易测量。另一半则更难：花在审查 LLM 生成代码的正确性上的时间，因纠错而浪费的时间（模型错误但自信地给出了建议），由看起来合理但不安全的代码引入的安全漏洞，以及因为建议解决了眼前问题而忽略了周围设计所产生的技术债务。一项对 GitHub Copilot 代码的研究发现，相当一部分生成代码包含安全漏洞，而且那些在时间压力下的开发者以更高的比率接受了不安全的建议 [Pearce2022]。2025 年对五个主要 LLM 的评估发现，没有一个能生成符合行业安全标准的 Web 应用代码 [Dora2025]。一项对超过 30 万个 AI 编写提交的大规模分析发现，超过 15% 引入了至少一个质量问题，其中近四分之一的长期存在于代码库中 [Liu2026]。只测量上升的投入，而忽略同样上升的成本，这不是测量，而是营销。 ## 将采用率视为成功指标 “我们在工程部门实现了 90% 的 AI 工具采用率”是一个采购成果，而不是生产力成果。采用率衡量的是工具是否被安装和打开；它不能说明建议是否有用，开发者是否不经思考地接受，或者接受的建议是否正确。高采用率加上低建议质量，会导致劳动力花时间管理工具，而不是从工具中获益。一项对 IBM 企业级 AI 编码助手的研究发现，尽管该工具通常能带来生产力净提升，但这些收益在其用户群中并不均匀 [Weisz2025]。但采用率比收益更容易测量，这恰恰就是它被报告的原因。 ## 比较志愿者与非志愿者 将选择使用 LLM 的开发者与不使用的开发者进行比较的研究，比较的是两个不同的群体，而不是两种条件。早期采用者在动机上不同于晚期采用者和非采用者，他们更愿意尝试新事物，对使用新工具更舒适，而且更可能已经是高效能者。选择偏差意味着任何观察到的组间差异可能是个体的属性，而非工具的属性。这是行业 AI 生产力报告中最常见的设计缺陷，因为它是最廉价的研究。一项为期两年、对某大型 IT 组织中使用 Copilot 的追踪研究发现，即使在引入该工具之前，使用它的开发者也比非用户更活跃 [Stray2026]。 ## 衡量个人而非系统 个人编码速度是最容易测量的，因此被测量。但如果 AI 工具帮助开发者编码速度快了 30%，而团队从工单到生产的时间没有变化，那么瓶颈就不是编写代码。生成的代码更多也意味着需要审查的代码更多：如果 AI 增加代码量而没有增加审查能力，那么周期时间可能会恶化 [Forsgren2021]。一项针对专业开发者的实证研究发现，虽然 AI 工具提高了经验较少的贡献者的产出，但资深开发者因为需要吸收来自 AI 生成代码的 6.5% 的额外代码审查工作量，他们自身的生产力下降了 19% [Xu2025]。优化流水线的一个阶段而忽略其他阶段，是伪装成生产力研究的系统思维失败。 ## 在新奇期进行测量 一项为期四周的研究发现生产力提升，只是发现了四周的生产力提升。新奇效应是真实存在的：开发者在初期对新工具更投入，这会夸大观察到的表现相对于长期基线的效果。真正重要的效果是在几个月而不是几周内显现的，包括委托给 AI 的技能的萎缩、因错误建议积累的技术债务，或团队协作方式的变化。一项旨在检测短期收益的研究，并不能告诉你研究结束后会发生什么。一项对采用 Cursor 的 807 个开源仓库的分析恰好发现了这种模式：采用带来了大规模但短暂的开发速度提升，同时代码复杂度和静态分析警告也显著且持续地增加 [He2026]。 ## 将建议接受率视为质量信号 LLM 编码助手通常报告开发者接受了多大比例的建议，较高的接受率被呈现为工具有用的证据。接受率衡量的是生成的代码看起来是否足够合理以至于开发者按下 Tab 键；它不能衡量代码是否正确、安全或可维护。处于时间压力下的开发者会接受更多建议，包括不安全的 [Pearce2022]，因此紧迫的截止日期会因完全错误的原因导致接受率上升。一项针对 400 名开发者的企业研究发现平均接受率为 33%，同时开发者满意度很高，但没有追踪接受代码的正确性或安全性 [Bakal2025]。一个奖励“看起来足够好”的指标，并不是奖励“真正好”的指标。 ## 将 AI 与空白进行比较 将 AI 辅助的开发者与使用“空白”的控制组进行比较的研究，选择了一个现实中不存在的基线。没有 LLM 助手的开发者会使用文档、同事以及原本自己思考问题的时间。相关的问题是 LLM 工具是否优于开发者已有的替代方案，而这种比较很少进行 [Peng2023]。选择一个弱的基线会让任何工具看起来都很好；但这并不能证明工具有用。 > 我由衷感谢多年来所有花时间向我解释这些内容的人。我所写的任何错误或过度简化都是我一个人的责任。 ## 参考文献 Bakal2025 Gal Bakal, Ali Dasdan, Yaniv Katz, Michael Kaufman, and Guy Levin: “Experience with GitHub Copilot for Developer Productivity at Zoominfo.” arXiv:2501.13282, 2025. Becker2025 Joel Becker, Nate Rush, Elizabeth Barnes, and David Rein: “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity.” arXiv:2507.09089, 2025. Beck2023 Kent Beck: “Measuring Developer Productivity: Real-World Examples.” Medium, 2023. https://tidyfirst.substack.com/p/measuring-developer-productivity Dora2025 Swaroop Dora, Deven Lunkad, Naziya Aslam, S. Venkatesan, and Sandeep Kumar Shukla: “The Hidden Risks of LLM-Generated Web Application Code: A Security-Centric Evaluation of Code Generation Capabilities in Large Language Models.” arXiv:2504.20612, 2025. Flournoy2025 John C. Flournoy, Carol S. Lee, Maggie Wu, and Catherine M. Hicks: “No Silver Bullets: Why Understanding Software Cycle Time is Messy, Not Magic.” arXiv:2503.05040, 2025. Forsgren2021 Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck, and Jenna Butler: “The SPACE of Developer Productivity.” *ACM Queue*, 19(1), 2021. Goodhart1984 Charles Goodhart: “Problems of Monetary Management: The U.K. Experience.” In Anthony Courakis (ed.), *Inflation, Depression, and Economic Policy in the West*, Rowman and Littlefield, 1984. He2026 Hao He, Courtney Miller, Shyam Agarwal, Christian Kästner, and Bogdan Vasilescu: “Speed at the Cost of Quality: How Cursor AI Increases Short-Term Velocity and Long-Term Complexity in Open-Source Projects.” *Proc. MSR ’26*, 2026. Hicks2025 Catherine M. Hicks, Carol Lee, and Kristen Foster-Marks: “The New Developer: AI Skill Threat, Identity Change & Developer Thriving in the Transition to AI-Assisted Software Development.” https://osf.io/preprints/psyarxiv/2gej5_v2, 2025, https://doi.org/10.31234/osf.io/2gej5_v2. Liang2024 Jenny T. Liang, Chenyang Yang, and Brad A. Myers: “A Large-Scale Survey on the Usability of AI Programming Assistants: Successes and Challenges.” *Proc. ICSE 2024*, 2024. Liu2026 Yue Liu, Ratnadira Widyasari, Yanjie Zhao, Ivana Clairine Irsan, Junkai Chen, and David Lo: “Debt Behind the AI Boom: A Large-Scale Empirical Study of AI-Generated Code in the Wild.” arXiv:2603.28592, 2026. McKinsey2023 Nora Elsayed, Tarek Elhounsri, and Sven Blumberg: “Yes, You Can Measure Software Developer Productivity.” McKinsey & Company, 2023. https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/yes-you-can-measure-software-developer-productivity Pearce2022 Hammond Pearce, Baleegh Ahmad, Benjamin Tan, Brendan Dolan-Gavitt, and Ramesh Karri: “Asleep at the Keyboard? Assessing the Security of GitHub Copilot's Code Contributions.” *Proc. IEEE S&P 2022*, 2022, doi:10.1109/SP46214.2022.9833571. Peng2023 Sida Peng, Eirini Kalliamvakou, Peter Cihon, and Mert Demirer: “The Impact of AI on Developer Productivity: Evidence from GitHub Copilot.” arXiv:2302.06590, 2023. Sadowski2019 Caitlin Sadowski and Thomas Zimmermann (eds.): *Rethinking Productivity in Software Engineering*. Apress, 2019, 978-1484242209. Stray2026 Viktoria Stray, Elias Goldmann Brandtzæg, Viggo Tellefsen Wivestad, Astri Barbala, and Nils Brede Moe: “Developer Productivity With and Without GitHub Copilot: A Longitudinal Mixed-Methods Case Study.” *Proc. HICSS-59*, 2026. Weisz2025 Justin D. Weisz, Shraddha Kumar, Michael Muller, Karen-Ellen Browne, Arielle Goldberg, Ellice Heintze, and Shagun Bajpai: “Examining the Use and Impact of an AI Code Assistant on Developer Productivity and Experience in the Enterprise.” *Proc. CHI ’25*, 2025. Xu2025 Feiyang Xu, Poonacha K. Medappa, Murat M. Tunc, Martijn Vroegindeweij, and Jan C. Fransoo: “AI-Assisted Programming Decreases the Productivity of Experienced Developers by Increasing the Technical Debt and Maintenance Burden.” arXiv:2510.10165, 2025.