Usage, Effects and Requirements for AI Coding Assistants in the Enterprise: An Empirical Study
本文通过对 57 名开发人员进行调查并分析 35 项现有调查研究，旨在评估 AI 编程助手和代码大语言模型（CodeLLMs）在企业级软件工程中的就绪度、影响及需求。
原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
想象一下，你是一位在大型、高风险厨房（即企业）中工作的厨师。多年来，你不得不亲手切好每一种蔬菜，测量每一种香料，并从零开始编写每一份食谱。然后，一位新的厨房助手来到了这里：一位 AI 编程助手。它就像一位超级聪明的副厨，可以瞬间建议食谱、以闪电般的速度切菜，甚至为你编写菜单。
这篇论文是一份关于这位新副厨在现实企业厨房中表现究竟如何的成绩单。作者们（来自 IBM 的研究人员）不仅是观察助手的运作，他们还询问了来自不同部门（金融、研究、销售）的 57 位真实厨师（开发者）对它的看法。他们还查看了来自世界各地的其他 35 份报告，以了解更宏观的情况。
以下是他们的研究结果，使用了简单的类比：
1. “速度 vs. 质量”的权衡
说法： 大多数厨师觉得速度变快了。约 88% 的开发者表示 AI 提高了他们的生产力。有些人甚至说自己快了一倍。
类比： 这就像是用电动钻头代替手拧螺丝刀。你可以用一半的时间装好架子。然而，仅仅因为你能快速钻孔，并不意味着架子一定是水平的。论文指出，虽然速度提升了，但人们担心代码（即架子）是否安全以及日后是否易于维护。有些厨师对这个“电动钻头”过于自信，以至于忘记了检查墙体是否稳固。
2. 并非“一招鲜吃遍天”
说法： 论文发现，不同部门使用 AI 的原因完全不同。
类比：
- 研究人员将 AI 用作图书馆的检索卡片。他们要求它查找晦涩的信息或生成复杂的数据集，以测试新的理论。
- 销售团队将它用作营销文案撰稿人。他们希望它能帮助“推销产品”或生成合成数据以展示给客户。
- 软件工程师将它用作拼写检查器和自动补全工具。他们希望它编写枯燥、重复的代码，以便他们能专注于应用程序的创意设计。
- 启示： 你不能只给所有人提供相同的工具设置。一种“一刀切”的方法行不通；AI 需要根据具体的任务进行定制。
3. “信任但要验证”的问题
说法： 开发者保留了大约 25% 到 50% 的 AI 编写的代码。他们并不会只是简单地复制粘贴所有内容。
类比： 把 AI 想象成一个初级实习生。实习生很擅长起草报告，但他们可能会编造事实或使用错误的语气。资深开发者（人类）必须阅读每一个字，修正错误，并确保内容表达正确。
- 如果 AI 编写的代码看起来很完美，但隐藏着安全漏洞（就像一把锁看起来很漂亮，但实际上锁不住门），人类必须捕捉到这一点。
- 论文发现，如果 AI 犯错太多，或者人类花在修复 AI 工作上的时间比自己动手写还要多，那么这个工具就会变成负担，而不是助力。
4. 厨师们的下一步愿望清单
开发者告诉研究人员，他们接下来需要什么样的“超级副厨”。他们将这些需求分为两类：
短期需求（“修补缺陷”清单）：
- 更好的记忆力： AI 需要了解“整个厨房”，而不仅仅是它脚下站着的那个台面。它需要理解整个代码库（整个餐厅的历史），而不会产生混乱。
- 无缝集成： 不要让我们频繁切换窗口。AI 应该就在我们使用的工具内部，就像内置的烤箱定时器一样，而不是一个我们需要单独打开的独立应用。
- 诚实： 如果 AI 不确定，它应该说：“我对此不是 100% 确定”，而不是自信满满地给出一个错误的答案。
长期需求（“科幻梦幻”清单）：
- 建筑师： AI 不应仅仅是切菜，它应该能够根据一个模糊的想法，从头开始设计整个厨房布局。
- 自主代理： AI 应该能够独立完成整个班次。它应该能够发现一个 Bug，修复它，测试它，然后提交工作，而无需人类干预。
- 专家： 它需要了解建筑物的特定规则（合规性、安全法），以免在烹饪时意外违反法律。
5. “作业”差距
说法： 大多数现有研究仅关注学生或非常特定的任务。这项研究则观察了大型公司中真实的、经验丰富的专业人士。
类比： 之前的研究就像是在安静、空旷的赛道上测试新车，驾驶员是测试司机。而这项研究则是让这辆车行驶在早高峰的交通流中，面对的是真实的通勤者。他们发现，虽然车很快，但交通状况（复杂的企业规则、安全性、不同的语言）使得使用起来比赛道测试中所呈现的情况更加困难。
总结
论文得出结论：AI 编程助手是强大的生产力助推器，但它们并非魔法。它们就像是一个非常快速、知识渊博但偶尔会产生“幻觉”的初级合伙人。
- 优点： 它们节省了处理枯燥任务的时间，并帮助人们学习新的语言。
- 缺点： 它们可能会引入安全漏洞，并且并不总是理解公司独特规则的具体语境。
- 未来： 要实现真正的价值，它们需要从仅仅是“自动补全”转变为“自主架构师”，能够理解整个项目，而不仅仅是当前正在输入的代码行。
作者强调，我们不应将这些工具视为“设置好就不用管”的解决方案，而应将其视为需要人类监督、定制化和建立信任的协作伙伴。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。