PDF面向开发人员的有效 AI 支持
需求与担忧调查
Mansi Khemka 和 Brian Houck
多年的软件工程和产品开发经验告诉我们，构建令客户满意的产品的最佳方法是与客户沟通。与实际客户交谈可以深入了解他们的挑战和喜爱之处。这会带来创新和创造性的问题解决方法（而不会产生新的问题），并防止破坏客户已经满意的现有工作流程。
然而……人工智能的兴起让许多领导者忘记了这些经验，他们急于创建新的 AI 驱动的开发工具，却常常不咨询实际的开发人员。我们的研究旨在帮助弥合这一差距，并让公司、产品团队和从业者同行深入了解开发人员在使用 AI 工作时的机会和担忧。有了这些信息，产品团队和领导者可以做出更好的产品决策，并更有效地沟通周围正在发生的变化。
现有的大部分文献都侧重于从以性能为中心的角度，例如 GitHub Copilot11,12 生成的代码的相关性或开发人员生产力的感知提升9，来研究 AI 驱动的开发工具（例如由 OpenAI 的 Codex3 驱动的 GitHub Copilot）的影响和功效。虽然一些研究探讨了开发人员如何使用此类工具1,8，但其范围有限。我们的方法旨在反转视角，优先考虑开发人员的声音。
虽然这些工具和研究具有价值，但我们需要了解开发人员想要什么，而不是我们认为他们想要什么。开发人员的工作流程是多方面的。他们的职责范围从应用程序开发（计划、构建、测试等）到与团队成员管理沟通和寻找职业发展机会等任务。因此，我们进行了一项调查，重点是直接与从新员工到经验丰富的专业人士的开发人员互动。调查问题深入了解了开发人员对 AI 的看法、他们希望如何使用 AI 以及他们在采用 AI 时最关心的问题。
虽然一些调查结果与当前的推测相符，但另一些结果则显示出与预期的偏差。但在研发中承认并考虑这些结果将使 AI 的采用具有指导性而非投机性。这种方法还深入了解了为什么一些团队可能在组织内推动 AI 工具的采用方面遇到困难。
本文的第一部分概述了调查的详细信息。第二部分讨论了最令开发人员兴奋的 AI 领域。第三部分讨论了他们的担忧。文章最后讨论了组织和领导者可以做些什么来解决这些担忧。
方法
我们在 2023 年 4 月 4 日至 14 日期间进行了调查，旨在收集软件开发人员在 AI 领域的观点。该调查旨在回答两个问题
• 开发人员最希望 AI 在哪些工作方面提供帮助？
• 开发人员在将 AI 集成到其工作流程中最担心什么？
以下是用于进行和分析调查的方法
1. 调查平台。 该调查使用 Microsoft Forms 进行，这是一个在线平台，方便创建适合收集受访者反馈的可共享表单。
2. 样本选择。 从 3,000 名随机选择的受邀者中，共收集到 791 份回复（回复率为 26%）。虽然选择过程主要针对软件开发人员，但由于目标算法的原因，少量软件开发主管和项目经理被无意中包括在内。这 54 份回复已从结果中排除。
3. 人口统计信息。 所有受访者均为 Microsoft 员工，特别是云 + AI 部门的员工。为了确保结果的公正性，积极为 AI 支持的开发工具做出贡献的开发人员部门团队的成员被排除在外。此外，该调查仅关注美国员工，明确排除了合作伙伴级别及以上的开发人员。
4. 调查结构。 该调查包含九个问题
• 七个与 AI 相关的核心问题，外加两个补充问题，询问参与者是否希望收到调查结果以及是否想参加抽奖。
• 五个核心问题采用选择列表格式，其余两个是开放式文本问题，让受访者可以自由表达自己的观点。
• 平均回复时间为 10 分钟。
• 选择列表问题以随机顺序显示给每位参与者，参与者可以在一个到三个选项之间进行选择。这迫使参与者优先考虑他们的回复，并防止他们选择大多数或所有答案的情况。
5. 激励。 为了鼓励参与，受访者有机会赢得 50 张礼品卡中的一张，每张价值 50 美元。这些礼品卡的获奖者通过随机抽奖选出。
表 1 列出了调查项目，不包括有关资格或参加可选抽奖的问题。
开发人员最希望 AI 在哪些工作方面提供帮助？
这个问题深入了解了如何优先考虑 AI 产品功能以满足开发人员的需求。回复分布在 17 个不同的选项中（外加一个“其他”选项）。大多数开发人员（96%）选择核心开发活动作为其前三名中的至少一项。旨在减少官僚繁文缛节的选项（例如，解析电子邮件或跟踪和管理工作项）被 37% 的开发人员选中，而 25% 的开发人员选择福祉活动（例如，帮助放松和/或减轻压力）作为其前三名中的一项。应该注意的是，新入职的开发人员（入职时间不到六个月的开发人员）更倾向于选择福祉领域作为其前三名之一（高出 13 个百分点）。
下一节详细讨论了主要发现。对于每个发现，我们都精选了开放式文本回复，这些回复代表了从开发人员那里听到的关键主题。图 1 显示了为前两个问题提供的选项以及选择每个选项的受访者百分比。
请注意，总和大于 100%。这是预期的，因为受访者可以选择一个到三个选项。
生成单元测试、集成测试和功能测试
被 44% 的受访者选中
软件测试是软件开发的关键部分，可确保应用程序的可靠性和性能，并有助于防止生产中出现代价高昂的缺陷。测试可以验证产品是否满足其要求，并让利益相关者对产品质量充满信心。虽然测试的价值可能很高，但它通常是一项具有挑战性的活动，许多开发人员可能觉得它不如核心功能工作令人兴奋。此外，曾经被认为是完全独立的角色（在某些组织中仍然被认为是独立的角色）现在已被简化为软件开发人员的另一项核心开发任务。本质上，开发人员现在正在做曾经是两份工作的事情。
“单元测试是一个单调的过程。如果 AI 可以自动生成这些用例，那就太好了。”
因此，开发人员回复说他们最希望委托给 AI 驱动工具的任务是编写测试，这并不令人意外。这不仅可以减轻“单调”，还可以产生更高质量的测试，并进而产生更高质量的产品。AI 可以为减轻测试负担所做的一切都可以改善 DevEx（开发人员体验）和客户成果。
“开发一个功能所花费的时间与测试一个新开发的功能所花费的时间大致相同，有时甚至在测试上花费的时间更多。我们需要提出更全面的测试用例，但有时我们仍然会遗漏一些边缘情况。此外，大多数测试代码都是有规律且可预测的，因此我认为 AI 可以在功能代码完成后帮助完成测试代码。”
分析代码中的缺陷、漏洞或优化
被 42% 的受访者选中
编写单元测试、集成测试和功能测试主要侧重于验证软件的功能正确性和预期行为。然而，分析代码中的缺陷、漏洞或优化则检查代码在安全性和性能特征方面的表现。这两项活动不仅是互补的，而且是重复性的，因此看到这两个领域被相似数量的受访者提及也就不足为奇了。
由于拥有大量的历史背景，AI 工具非常适合帮助检测和缓解代码漏洞，因此可能会让开发人员对其能力更有信心。识别运行时错误（例如空指针异常）或安全漏洞（例如缓冲区溢出）都是 AI 理论上可以识别并“左移”到开发工作流程的代码编写部分的模式。
“我认为 AI 擅长执行闭环任务并从其看到的数据中提取常见见解。例如，代码漏洞和优化已经在网上撰写和讨论了数十年，并且在每个代码库中都非常丰富。我相信 AI 在这方面的建议，尽管我会彻底审查任何建议的更改。”
结对编程一直是开发人员获得帮助以查找代码中的优化和减少缺陷的一种方式。然而，混合工作时代使此类活动更具挑战性，一些开发人员承认 AI 可以帮助填补这一空白。
“在编写代码时，如果有人 [AI] 告诉我代码的潜在问题，那就像与某人进行结对编程。”
在与同事进行人工审查之前，使用 AI 帮助进行代码级审查和改进是开发人员可以设想的事情。
“如果在请求同事进行代码审查之前，让 AI 检查代码，那就太棒了。”
编写文档
被 37% 的受访者选中
通常，SDLC（软件开发生命周期）的 60-70% 都用于维护软件5。当开发人员重新访问代码片段时，文档在理解代码、设计决策及其用法方面起着关键作用。尽管它很重要，但这是一个繁琐的过程，并且经常被完全忽略。此外，由于多个开发人员经常在同一个代码库上工作，因此代码库的变化速度很快，因此文档也需要以类似的速度更新。这在开发人员对文档的需求与他们对创建文档的反感之间造成了紧张关系。
“作为开发人员，我们讨厌没有文档来帮助我们更好地理解代码；与此同时，作为开发人员，我们讨厌编写文档。如果 AI 工具可以帮助解决这个难题，那将对任何人都有帮助 :)”
请注意，代码的自动文档化需要上下文感知，这使得开发人员怀疑是否可以完全依赖 AI 而无需人工校对。这一点可能有助于标准化指南，以确定文档应在编写代码时生成还是在使用/更新代码时生成。
“如果 AI 能够从以前编写的代码创建文档，那将使新手更容易上手不熟悉的代码。我看到 AI 在文档编写方面做了‘繁琐的工作’，但软件工程师仍然需要通读生成的文档并进行编辑以确保准确性。”
对错误和事件执行根本原因分析
被 31% 的受访者选中
RCA（根本原因分析）是提高软件质量不可或缺的一部分，因为它体现了从错误中学习以防止未来再次发生的原则。将 AI 集成到 RCA 中可以减轻开发人员的负担，让他们开始着手发现根本问题。它可以自动化数据分析、模式识别和故障定位，使开发人员能够专注于战略问题解决。
“我希望工具能够自动分析和识别 [服务事件] 的根本原因，或者至少让我接近根本原因。运行查询，查找故障发生的位置，并将其添加到工单中。”
将 AI 纳入 RCA 符合现代开发人员的双重任务：创建和维护健壮的软件。虽然 AI 在 RCA 中的作用是一个令人兴奋的前景，但在实施时应理解它补充而非取代经验丰富的开发人员的细致判断。
编写新代码和/或重构现有代码
被 25% 的受访者选中
编写新代码通常等同于开发人员的成就感，让他们感到既有生产力2 又对当天的工作贡献感到满意4,6。这种创造行为不仅对其个人成长和精通至关重要，而且还提供了创新、试验新技术和应对独特挑战的机会。
调查受访者表示，他们认为 GitHub Copilot 等 AI 工具可以通过减少花费在样板代码上的时间、使与不熟悉的 API 交互更容易，甚至改变编写代码的整个开发人员体验来增强代码编写体验。
减少样板代码：“它对于样板代码或大致勾勒框架非常棒。”
学习如何使用新的 API：“我经常需要查找我不熟悉的 API 的用法。我不想不得不筛选 [文档]。”
改变开发人员体验：“我不应该编写代码，而应该能够通过语音与 AI 对话，描述我想要什么。”
在描述 AI 辅助编码工具的理想体验时，一些开发人员谈到他们希望专注于大局，而不是处理所有实现细节的语法细节。
“我设想它像在我旁边有一个人说，‘嘿，你遗漏了一些东西；你应该考虑这样做……’一样直观和无缝。如果能够专注于代码更改的更大图景，而让我的‘副驾驶’担心实现细节，那就太好了。”
AI 驱动的开发工具将彻底改变代码编写体验，使开发过程不仅更高效，而且更直观，使开发人员能够将注意力集中在总体愿景和创新上。
开发人员希望如何使用 AI 的主要结论
调查揭示了开发人员对 AI 集成的期望层次结构，反映了他们希望 AI 能够处理从重复性任务到复杂任务的各种任务。
1. 自动化例行任务。 大多数开发人员（96%）预计 AI 将减轻例行任务的乏味，例如生成测试和文档。这些任务虽然必不可少，但通常被视为单调乏味，并且会分散对更具创造性的开发方面的注意力。AI 在增强这些领域的潜力可以显着提高 DevEx 和产品质量。
2. 简化管理职责。 很大一部分人（37%）希望 AI 可以简化管理开销，例如电子邮件解析和任务管理。这些职责虽然不是开发的核心，但会占用大量时间，并且非常适合 AI 的组织能力。
3. 增强福祉和效率。 较少的开发人员（25%）优先考虑 AI 用于福祉活动，例如减轻压力，这表明他们更希望 AI 专注于提高工作效率而不是个人管理任务。
请注意，按经验年限划分的每类开发人员的百分比，其选择百分比大致相同。也就是说，经验丰富的专业人士与新员工一样有可能选择“生成单元测试”。例外情况是：“评估绩效以帮助确定成长领域”，近 20% 的新员工对此表示兴奋，而其他类别只有 4-5%；以及“澄清需求”，职业生涯早期的新员工中约有 9-11% 对此表示兴奋，而更资深的类别中只有 1-6%。
“AI 应该感觉像结对编程——有点像钢铁侠和贾维斯。我不应该编写代码，而应该能够通过语音与 AI 对话，描述我想要什么，然后 AI 应该能够编写代码、分析代码、优化代码、帮助我测试和调试代码，然后帮助我创建和管理 PR，以便将代码放入存储库。我的工作应该侧重于创造力，而不是受限于我的打字速度。让我们更有效率，以便我们可以更快地交付更好的功能，从而使我们在竞争中占据优势。”
开发人员在将 AI 集成到其工作流程中最担心什么？
AI 在软件开发中的大规模增长和采用引起了广泛关注。自动化许多单调任务的承诺范围已被公认为真正具有变革性。然而，这与许多人对此持有的怀疑态度齐头并进。
“我很好奇这一切将如何发展。我感觉到公司似乎席卷一切的‘AI 帮助你 x’ 带来了一些个人倦怠感。炒作非常高。就像一家巨头公司典型的做法一样，我们将为 AI 构建一些好的用途和一些坏的用途；希望坏的用例不会让用户反感。”
为了了解开发人员对将 AI 集成到其日常工作中持有的主要担忧，我们向他们展示了一系列可能的担忧，并要求他们确定他们认为最重要的一项。以下部分探讨了其中一些担忧，并精选出来进行更详细的讨论。与上一节一样，每个担忧都得到了精选的开放式文本回复的支持。图 2 显示了我们为问题 2 提供的担忧列表，以及认可每个担忧的受访者百分比。
华而不实，而非有用
被 29% 的受访者选中
对软件开发中 AI 的怀疑通常源于这样一种看法，即 AI 目前的能力被夸大了，或者未能兑现其承诺。虽然 AI 在演示中令人印象深刻，但开发人员担心 AI 工具可能无法处理现实世界编程的复杂性和多样性。
“对我来说，它看起来更像是一个噱头。为了让我让外部的东西管理我的日历、优先处理任务或重构在影响数百万客户的生产服务中使用的代码，它需要经过很长一段时间的自我证明，而且至少这在未来似乎还很遥远。”
这种怀疑可能解释了为什么一些组织一直在努力说服其开发人员采用他们可用的 AI 工具。解决开发人员的怀疑需要多方面的方法。AI 工具开发人员需要确保他们提供的产品不仅技术先进，而且透明且易于理解。这可以通过为 AI 工具配备文档和解释性框架，或在工具中集成可解释的 AI10 来实现。通过随着时间的推移在各种现实世界场景中展示一致且可靠的性能，这些工具（和工具制造商）可以逐渐赢得开发人员的信任。这种开放性不仅建立信誉，而且还使工程师能够批判性地对待 AI 建议，就像他们对待人类同事的建议一样。
“我认为从长远来看，重要的是教工程师 Copilot 为什么推荐其特定的做事方式。我可以看到工程师变得自满，不再试图理解问题是如何解决的。就像从 Stack Overflow 复制/粘贴而不进行分析可能是一件坏事一样，这可能会产生相同的结果。”
将缺陷或漏洞引入您的工作
被 21% 的受访者选中
虽然许多人担心 AI 可能华而不实，但开发人员却怀有更深层次的担忧：AI 可能会通过引入缺陷或漏洞来主动降低工作质量的风险。这种担忧不仅仅是未能满足期望的挫败感——它还包括 AI 可能破坏软件系统的完整性和安全性的可能性。
“我担心 AI 会创建看起来正确但实际上不正确的答案。”
这种情绪加剧了先前强调的怀疑态度，放大了开发人员在将 AI 嵌入其工作流程时采取的谨慎态度。它强调了 AI 透明度的必要性、对新兴工具的全面培训以及人工监督的关键作用。确保 AI 帮助而不是阻碍开发取决于人类专业知识和人工智能之间的这种共生关系。
自动化取代您的工作
被 10% 的受访者选中
关于 AI 的一些担忧包括它可能如何影响工作保障，例如工作岗位流失或增强。有点令人惊讶的是，本次调查中只有 10% 的开发人员将工作岗位流失确定为担忧。此外，只有 5% 的人将“由于自动化而导致薪酬减少”作为担忧。尽管如此，一部分开发人员对智能自动化可能侵占传统上为人类专业知识保留的领域的可能性表示不安。
“我感觉自己像 Blockbuster 和 Netflix。[AI] 即将取代我。”
AI 功能的快速进步是重大进步的标志，但对某些人来说，这引发了他们的角色可能发生重大改变的想法。
“如果 AI 能够根据需求输入提示编写、调试和记录代码，那么人类软件工程师是否会被降级为仅执行随叫随到和维护工程师任务？对于我自己和许多其他人来说，这是工作中最不愉快和解决问题的方面。”
这项调查揭示了领导者和组织讨论的一个关键点：因 AI 导致工作岗位流失的担忧。领导层有责任积极主动地解决这些担忧，不仅要通过对话，还要通过营造拥抱变革的文化。诸如全面培训计划之类的举措，这些计划可以提高员工与 AI 协同工作的技能，这将至关重要。领导者还必须传达人类洞察力和创造力的价值——AI 无法复制的品质——通过确保团队成员了解他们在技术增强型环境中不断发展、不可替代的角色。
加剧工作场所的偏见
被 5% 的受访者选中
开发人员还表示，AI 有可能加剧工作场所的偏见，因为它依赖于可能反映现有偏见的历史数据。
“我担心 AI 结构中存在的偏见可能会对软件工程行业的少数族裔产生不利影响。如果 AI 的设计没有考虑到所有人，那么它最终会对那些在开发过程中未被考虑在内的人产生偏见，并且通常不太可能在之后修复该软件，因为它通常被认为对较小的人群来说太过费力了。”
纵观历史，偏见是无可辩驳的，因此务必确保我们没有使用 AI 来生成基于此类偏见的输出。为了避免这种情况，需要设置护栏，以纳入多样化的数据、提高透明度并制定道德准则和公平性指标，以避免出现这种情况。Microsoft 关于负责任的 AI7 的资源就是一个组织解决此问题方法的示例。
开发人员对 AI 的其他担忧
本文讨论了开发人员对 AI 采用的一些主要担忧，但这并没有削弱少数人投票选出的担忧的价值：例如，对 AI 对环境的影响的担忧。只有 1% 的开发人员选择它作为首要关注点，这可能是因为普遍缺乏意识或因为调查的设计限制他们只能选择一个选项，而不是因为缺乏关注。领导者和组织不仅应明确解决开发人员的主要担忧，还应提高对这些不太受欢迎的担忧的认识，并积极采取措施来减轻这些担忧。
“毫无疑问，这是一种非常强大的工具。潜力巨大。重要的是对所涉及的风险采取积极主动的方法，而不是对这种快速扩展的技术采取常见的被动方法。至少，将两者结合起来。”
科技行业中 AI 的未来
人们对 AI 既充满兴奋，也充满愤世嫉俗。这项调查突出了这两个方面，使组织领导者有机会采取措施来解决这些问题。组织和领导者如何帮助解决围绕 AI 的需求并减轻担忧？本节列出了一些他们可以采取的方法。
教育和意识
关于 AI 的员工教育有三个方面：（1）AI 模型是如何工作的？（2）如何在现有服务/技术中采用 AI 工具/API？（3）如何为领导者配备技能，以指导他们的团队完成技术转型？
减轻怀疑不仅仅是揭开 AI 的神秘面纱；还在于让领导者做好准备，以应对 AI 带来的文化转变。组织 AI 训练营、推广在线课程以及提供侧重于 AI 背景下变革管理的领导力研讨会，可以帮助建立一支知识渊博且适应性强的员工队伍。
透明度
这再次具有多个维度：（1）在服务中集成 AI 的透明度，集成在何处以及哪些部分等；以及（2）利用可解释的 AI10，即向开发人员解释 AI 的结果，而不是仅仅接受 AI 输出的表面价值。这允许开发人员与 AI 进行推理，从而做出明智的决定来接受或拒绝结果。这也有助于提供反馈，以减轻/抑制从历史数据中学习到的偏见。
伦理考量
对这种担忧有很多方面，起初，它可能会让人感到不知所措。这些方面可能因 AI 对环境的影响到其训练的数据集而异。为了推动解决方案，第一步是理解和承认问题。可以通过为每种场景发布道德准则并建立一个伦理委员会来解决这些担忧，该委员会负责确保准则得到遵守。
人在回路中
许多受访者报告称，AI 更像是一种噱头，而不是有用的辅助工具，这是他们最关心的问题。与其将任务完全委托给 AI 或完全委托给人，不如通过采用人在回路中的 AI 来达成折衷方案，尤其是在执行关键任务时。
结论
将人工智能融入软件工程师日常工作的旅程并非一帆风顺。然而，它预示着开发者将创意愿景转化为实际解决方案的方式将发生变革性转变。正如我们所见，GitHub Copilot 等人工智能工具已经在重塑代码编写体验，使开发者能够提高工作效率，并将更多时间用于创意和复杂的任务。围绕人工智能的怀疑论，从对工作保障的担忧到其实际功效的质疑，都突显了采取平衡方法的必要性，这种方法应优先考虑透明度、教育和伦理考量。通过这些努力，人工智能不仅有可能减轻日常任务的负担，还有可能开启创新和增长的新视野。
致谢
我们衷心感谢所有研究参与者和研究审阅者提供的宝贵反馈和见解。
参考文献
1. Barke, S., James, M. B., Polikarpova, N. 2023. Grounded Copilot: 程序员如何与代码生成模型互动。编程语言汇刊, 7(OOPSLA1), Article 78, 85–111; https://dl.acm.org/doi/abs/10.1145/3586030.
2. Beller, M., Orgovan, S., Buja, S., Zimmermann, T. 2020. 注意差距：关于自动测量和自我报告的生产力之间的关系。IEEE软件 38(5); https://ieeexplore.ieee.org/document/9311217.
3. Finnie-Ansley, J., Denny, P., Becker, B. A., Luxton-Reilly, A., Prather, J. 2022. 机器人来了：探索 OpenAI Codex 对入门编程的影响。在第24届澳大利亚计算教育会议论文集, 10–19; https://dl.acm.org/doi/abs/10.1145/3511861.3511863.
4. Forsgren, N., Storey, M. A., Maddila, C., Zimmermann, T., Houck, B., Butler, J. 2021. 开发者生产力的 SPACE：其内涵远超你的想象。acmqueue 19(1), 20–48; https://queue.org.cn/detail.cfm?id=3454124.
5. Gradišnik, M., Beranič, T., Karakatič, S. 2020. 历史软件指标变化在预测开源软件开发中未来可维护性趋势方面的影响。应用科学 10(13), 4624; https://www.mdpi.com/2076-3417/10/13/4624.
6. Meyer, A., Barr, E., Bird, C., Zimmermann, T. 2019. 今天是美好的一天：软件开发人员的日常生活。IEEE软件工程汇刊 47(5); https://ieeexplore.ieee.org/document/8666786.
7. Microsoft AI. 赋能负责任的 AI 实践。2024; https://www.microsoft.com/en-us/ai/responsible-ai.
8. Mozannar, H., Bansal, G., Fourney, A., Horvitz, E. 2022. 字里行间：建模 AI 辅助编程中的用户行为和成本。arXiv:2210.14306; https://arxiv.org/abs/2210.14306.
9. Peng, S., Kalliamvakou, E., Cihon, P., Demirer, M. 2023. AI 对开发者生产力的影响：来自 GitHub Copilot 的证据。arXiv:2302.06590; https://arxiv.org/abs/2302.06590.
10. Ribeiro, M. T., Singh, S., Guestrin, C. 2016. 我为什么要信任你？解释任何分类器的预测。在第22届 SIGKDD 国际知识发现与数据挖掘会议论文集, 1135–1144; https://dl.acm.org/doi/10.1145/2939672.2939778.
11. Vaithilingam, P., Zhang, T., Glassman, E. L. 2022. 期望与体验：评估大型语言模型驱动的代码生成工具的可用性。在人机交互会议扩展摘要, 1–7; https://dl.acm.org/doi/10.1145/3491101.3519665.
12. Ziegler, A., Kalliamvakou, E., Li, X. A., Rice, A., Rifkin, D., Simister, S., Sittampalam, G., Aftandilian, E. 2022. 神经代码补全的生产力评估。在第6届 SIGPLAN 国际机器编程研讨会论文集, 21–29; https://dl.acm.org/doi/10.1145/3520312.3534864.
Mansi Khemka 是微软的一名软件工程师。她的工作帮助为微软各种服务和员工的安全与合规设置护栏。她在人工智能领域拥有丰富的背景，这得益于她在哥伦比亚大学获得的硕士学位以及她在该领域过去和正在进行的研究。
Brian Houck 是微软的首席应用科学家，专注于提高微软内部开发人员的福祉和生产力。他的工作不仅探索影响开发者生产力的技术因素，还探索影响工程师日常体验的文化、环境和组织因素。在过去的三年里，他的大部分研究都集中在向远程/混合工作模式的转变如何影响开发者。
版权 © 2024 归所有者/作者所有。出版权已授权给 。
最初发表于 Queue vol. 22, no. 3—
在 数字图书馆 中评论本文
更多相关文章
Mark Russinovich, Ahmed Salem, Santiago Zanella-Béguelin, Yonatan Zunger - 智能的代价
LLM 容易出现幻觉、提示注入和越狱，这对它们的广泛采用和负责任的使用构成了重大但可以克服的挑战。我们认为这些问题是固有的，至少在当前这一代模型中是这样，并且可能在 LLM 本身中也是如此，因此我们的方法永远不能基于消除它们；相反，我们应该应用“纵深防御”策略来缓解它们，并且在构建和使用这些系统时，要假设它们有时会在这些方面失败。
Sonja Johnson-Yu, Sanket Shah - 你对人工智能一窍不通
长期以来，很难确定人工智能到底是什么。几年前，此类讨论会演变成长达数小时的会议，绘制维恩图并试图绘制出人工智能的不同子领域。快进到 2024 年，我们现在都确切地知道什么是人工智能。人工智能 = ChatGPT。或者不是。
Jim Waldo, Soline Boussard - GPT 和幻觉
本实验的发现支持以下假设：基于 LLM 的 GPT 在更受欢迎且已达成普遍共识的提示上表现良好，但在有争议的主题或数据有限的主题上则表现不佳。应用程序响应的可变性突显了模型依赖于其训练数据的数量和质量，这与依赖于多样化和可信贡献的众包系统类似。因此，虽然 GPT 可以作为许多日常任务的有用工具，但应谨慎解读它们对晦涩和两极分化主题的参与。
Erik Meijer - 虚拟阴谋：将大型语言模型用作神经计算机
我们探讨了大型语言模型 (LLM) 如何不仅可以充当数据库，还可以充当动态的、最终用户可编程的神经计算机。这种神经计算机的本地编程语言是一种受逻辑编程启发的声明式语言，它将思维链推理形式化和外部化，就像它可能发生在大型语言模型内部一样。
© 保留所有权利。