Vibe Coding 吃掉了我的作业：对AI方法在新建软件工程与编程中的评估

# 氛围编程吞噬了我的作业：面向绿地软件工程与编程的AI方法评估
来源：https://arxiv.org/html/2606.18293

###### 摘要

得益于生成式AI的迅猛发展，我们正处于一场可能永远改变人机交互方式的范式转变之中。我们观察到，越来越多的人开始使用自然语言提示来构建应用和编码基础设施，而无需具备该领域的底层知识——这种做法被称为"氛围编程"。可以说，它代表了编程领域自诞生以来一直追求的方向，即每一层更高的抽象都被构想出来。就输入方式而言，氛围编程有望成为高级编程范式的终点：完全消除人类对代码语法的使用，转而用母语进行编程。本文旨在评估氛围编程在绿地软件工程任务中的可行性，并分析用于衡量其软件工程能力的基准测试。为此，我们开发了一套评估套件，用于分析LLM在Python中执行简单、独立的绿地编程任务的熟练程度，从而对此提供聚焦性的见解。

## I. 引言

代码的自动生成一直是计算领域的长期目标Brooks [1986 (https://arxiv.org/html/2606.18293#bib.bib18)]，尽管"自动编程"的定义随时间不断变化，但其本质始终是追求比用户当前可用抽象层级更高的编程方式Parnas [1985 (https://arxiv.org/html/2606.18293#bib.bib19)]; Zhang等 [2024 (https://arxiv.org/html/2606.18293#bib.bib17)]。氛围编程表面上代表了这一发展的自然终点——用户只需提供自然语言请求，AI代理负责管理其余一切。"氛围编程"一词由OpenAI联合创始人、前研究员Andrej Karpathy创造Palazzo [2025 (https://arxiv.org/html/2606.18293#bib.bib16)]，他将这种做法描述为"顺应氛围"，即让AI完全控制代码生成，无需人工审查。虽然AI辅助编程已存在多年Yetiştiren等 [2023 (https://arxiv.org/html/2606.18293#bib.bib20)]，且需要软件工程师在循环中审查和修复代理可能产生的任何问题，但近期出现了大量程序员完全不审查AI生成代码的现象，这在很大程度上归因于氛围编程所带来的感知可及性，吸引了众多没有编程背景的新程序员涌入，例如来自临床领域的人员Chow和Ng [2025 (https://arxiv.org/html/2606.18293#bib.bib1)]。这还包括一些企业，它们利用这一趋势为裁员正名，随后却因无法应对AI的缺陷而被迫回退Ropek [2025 (https://arxiv.org/html/2606.18293#bib.bib21)]。

由于这种做法的普及速度之快，迫切需要评估AI代理生成相关且功能正常代码的可靠性，以及用于评估这项任务执行情况的基准本身。随着软件工程入门门槛前所未有的降低，AI承受了更大的压力以产生可靠的结果，而它突然崛起并被一些软件工程师批评为为时过早，原因在于对人类介入缺失下代码质量的担忧Faragó [2025 (https://arxiv.org/html/2606.18293#bib.bib8)]; Maes [2025b (https://arxiv.org/html/2606.18293#bib.bib9)]。氛围编程的潜在应用涵盖所有形式的编程任务，与其他编码方法一样，所有这些任务都可以归类为绿地方法或棕地方法Synoptek [2018 (https://arxiv.org/html/2606.18293#bib.bib25)]——前者指不依赖于现有架构的独立编程任务，从更大规模看，可以指从头开始开发应用系统；后者涉及对现有系统的功能级实现任务，通常表现为对已有架构的扩展或改进。

向代理表达提示的方式可以揭示一个人在编程领域的专业水平；高级提示更宽泛，以直接的方式传达用户需求（例如"向我展示数字1到10"），而低级提示则以计算机更容易理解的方式指定实现该目标的手段（例如"创建一个包含数字1到10的数组，并使用for循环依次打印每个数字"）。有编程背景的人天生更能理解计算机的思考方式和任务执行方式，从而能够在需要时以较低的抽象级别表达请求，以提高输出的可靠性，因为这减少了歧义Foster [2025 (https://arxiv.org/html/2606.18293#bib.bib23)]。编写更好提示的一般技巧被称为"提示编程"，还涵盖其他技术，例如链式思考（CoT），它通过要求LLM"逐步思考"再解决问题来分解提示Khojah等 [2024 (https://arxiv.org/html/2606.18293#bib.bib22)]。

鉴于提示的歧义性对输出可能产生的影响，我们在评估氛围编程在绿地任务中的表现以及用于衡量该表现的基准时，必须认识到该领域更深的知识可能对输出质量产生潜在影响，以便正确判断氛围编程对外行和经验丰富的程序员是否有用，这或许能让我们确定提示编程所需的最低熟练程度，以使氛围编程可行。基于以上考虑，我们开发了一套严格的绿地评估套件，将一组请求Python编程任务的提示发送给四个不同的LLM，以产生氛围编程输出，并根据该输出判断任务是否成功完成。这为我们未来建立可对当代AI模型和软件代理进行端到端软件构建排名的透明评分协议提供了有力的概念验证。我们创建了一个测试提示列表，并根据技术深度将其分为三类：

1. 表层请求。
2. 使用模糊或通用语言请求特定功能和/或实现。
3. 使用低级行话请求特定功能和/或实现。

我们认为这是与其他大语言模型（LLM）评估相比的一个重要区别，因为它们没有关注查询本身的内容Liu等 [2023 (https://arxiv.org/html/2606.18293#bib.bib2)]。最后，我们选择专门评估绿地任务，这是有充分理由的；LLM在大量代码库上进行训练，它们生成的所有代码都可能源于这些代码库Bistarelli等 [2025 (https://arxiv.org/html/2606.18293#bib.bib24)]。这给棕地任务带来了额外的困难，因为它们需要适配现有系统的工作流程，如果需求足够小众，模型可能难以产生组合代码来完成任务而无需人工输入Li等 [2025 (https://arxiv.org/html/2606.18293#bib.bib27)]。虽然这本身是一个值得进一步探索的方向，但我们认为这与本项目评估氛围编程作为长期策略所选方法不太一致（即，因为氛围编程是非程序员青睐的不干涉编码方法，我们认为它从自然语言提示中生成独立工作程序的能力最终才是相关的）。我们的假设是，较低级别的查询会产生更可靠的结果，但会以可及性为代价（而可及性是氛围编程的主要卖点），但最终的读数可能挑战这一观点。

## II. 相关工作

由于氛围编程近期才发展起来，其基准测试仍处于起步阶段。不仅只有少数几篇论文对其进行了探索，而且已有的工作也被批评为衡量不当，同时有一半声称衡量抽象概念（如推理）的基准，却对推理的含义或衡量方式没有明确定义Claburn [2025 (https://arxiv.org/html/2606.18293#bib.bib15)]。一项研究Chen等 [2025 (https://arxiv.org/html/2606.18293#bib.bib3)] 指出，现有的评估基准并未充分评估代理的氛围编程能力。为此，他们提出了一个名为FeatBench的新基准，专注于功能实现。该研究还指出，如Jimenez等 [2024 (https://arxiv.org/html/2606.18293#bib.bib11)] 所代表的解决问题型基准与氛围编程的能力最为相关，因为它们基于问题描述构建代码，但往往忽略了氛围编程性能的其他方面，例如功能实现。最终，他们确定AI代理倾向于采用激进的实现方法。如果没有仔细的规范说明，AI代理可能会远远超出预期范围，造成难以在不手动检查代码的情况下调试的错误。然而，这种行为也有其好处，即可能创建比预期更优越、更健壮的软件架构。这凸显了需要一种方法来控制氛围编程代理的实现激进程度。

FeatBench的一个显著局限性是它只关注Python进行评估，未能充分覆盖绿地项目的范围。我们最初的计划是用一种语言代表三种不同的"类型"（标记语言、脚本语言、面向对象语言），即HTML、JavaScript和Python。不幸的是，由于时间和资源限制，系统不得不缩减为仅支持Python。然而，我们的工作系统是用R语言构建的，它作为一个有效的中心枢纽，如果获得扩展批准，可以连接多种语言。此外，FeatBench侧重于功能级实现（即棕地编程），而我们的系统测量模型在执行不围绕现有系统的简单任务方面的能力。

另一篇论文Samsyudin [2025 (https://arxiv.org/html/2606.18293#bib.bib4)] 基于性能评估的结果，建立了一个指导负责任采纳氛围编程的三支柱框架——混合集成、人工监督和上下文感知部署。他们评估了无AI的传统编码、人在循环中的AI助手以及完全自主的氛围编程代理的性能，并得出结论：氛围编程不应取代AI辅助编程，人类开发人员仍需负责验证输出，并且该做法应限于非关键应用、教育情境和快速原型开发，直到当前的质量和安全问题得到解决。该评估的结果表明，氛围编程可以将效率提高高达27%，但代价是可维护性、安全性和用户信任度的下降，这一观点得到了Moss [2025 (https://arxiv.org/html/2606.18293#bib.bib10)] 的支持。总体而言，它获得了71.4的系统可用性量表（SUS）评分，高于传统编码但低于AI辅助编码。开发人员接受了定性反馈调查，结果突显了用户体验的喜忧参半：63%的人报告了与语法相关的心理负担减轻，而只有37%的人在没有人工审查的情况下完全信任氛围编程的输出。这项研究为我们自己的评估套件奠定了坚实的基础，但我们对其进行了调整，以衡量绿地任务的熟练程度，并根据查询所表达的专业水平来区分其可靠性和输出质量。

可维护性问题在Maes [2025a (https://arxiv.org/html/2606.18293#bib.bib5)] 中得到了呼应，他提出了一个推荐严格人工监督程度的框架——然而，固有的缺陷在于，"氛围编程"与其他形式的AI辅助编程的区别在于，人类对代码的参与被保持在最低限度Fawzy等 [2025 (https://arxiv.org/html/2606.18293#bib.bib6)]，甚至完全排除。因此，将可维护性委托给人类，使得氛围编程无法完全适用于需要关注此类问题的项目。尽管如此，在未来，开发一个能够通过适当提示应用更新的编码惯例的代理，可能是一个潜在的自动化替代方案。目前，可维护性并非测试套件能够轻易衡量或评估的属性，因为它是一个连续体，既部分主观（人类理解的难易程度因人而异），又对未来发展和版本敏感。安全性也已成为引入氛围编程到其实践中的大公司面临的主要问题。YouTube用户Logically Answered对此进行了广泛报道Jayakumar [2025 (https://arxiv.org/html/2606.18293#bib.bib12)]，他重申了LLM功能背后的现实：它们并非真正具有逻辑性，可被归结为预测最可能的下一个词或动作并生成它的算法。他指出，因此AI模型并不真正知道它们生成的代码是否正确，而是生成它们认为基于其训练所使用的公共代码最可能出现的代码，而由于公共代码往往质量参差不齐，这导致了效率极低且具有深层架构缺陷和漏洞的代码，以至于一些程序员宁愿自己从头开始，也不愿修复所有问题Wreden [2025 (https://arxiv.org/html/2606.18293#bib.bib14)]。Apiiro的Itay Nussbaum指出，虽然语法错误减少了，但诸如权限提升等架构缺陷却暴增了322%Monsanto [2025 (https://arxiv.org/html/2606.18293#bib.bib13)]，这促使他评论道："AI在修复拼写错误，却创造了定时炸弹。" 对于本项目，我们决定考察氛围代码的通用可靠性和功能性，以便建立一个强大且可扩展的基础。然而，像安全性这样的指标在旨在评估更复杂任务的未来系统迭代中，可能成为可行的基准。

LLM本质上是预测机器，可以被视为常见幻觉产生的核心原因；一个诚实的AI代理对无法执行的任务回复"我不知道"保证了"错误"答案，而推测性猜测无论概率多小都有机会产生正确的响应。因此，一个因训练不足而产生幻觉的LLM在大规模测试中，其表现看起来会比诚实的代理成比例地更好。这一假设得到了Knobel和Radziwill [2025 (https://arxiv.org/html/2606.18293#bib.bib7)] 的一项研究的支持，该研究确定AI习惯于优先考虑能力的外观而非承认自身局限性，从而导致系统性的欺骗模式。将这些发现与我们对LLM概率性质的理解结合起来，我们可以推断，由此产生的行为并不仅仅是关于最大化正确性的概率，而是最大化它所认为的"理想答案"的概率，此时表达方式也变得相关。我们可以推测……