好的氛围？Vibe Coding中共同创造、沟通、心流与信任的质性研究

arxiv.org 2026-06-29T07:51:29.331465

作者：V. Pimenova，Sarah Fakhoury，Christian Bird，M. Storey，Madeline Endres

发表时间：2025年9月15日

摘要

Vibe coding（氛围编程）是由Andrej Karpathy于2025年2月提出的术语，已迅速成为AI辅助软件开发领域中一个引人注目且颇具争议的自然语言编程范式。该范式以与AI助手的迭代式共同设计（co-design）为核心，强调心流（flow）与实验，而非严格的事先规范说明。尽管初步研究已开始探索这一范式，但多数研究侧重于分析代码产物或提出缺乏充分实证支持的理论。我们仍需要一种基于开发者感知与体验的、扎根于实践的Vibe Coding理解。我们首次对Vibe Coding的认知与实践进行了系统性的质性研究。基于来自半结构化访谈、Reddit帖子以及LinkedIn动态的超过19万字的资料，我们描述了Vibe Coding是什么、开发者为什么以及如何使用它、它在哪些方面失效，以及哪些新兴实践旨在支持它。我们提出了一种基于质性研究的Vibe Coding理论，该理论以与AI的对话交互、共同创造（co-creation）以及开发者的心流（flow）与愉悦感为核心。我们发现，对AI的信任（trust）调节着从委托（delegation）到共同创造这一连续体上的移动，并通过维持心流来支撑开发者体验。我们揭示了在规范（specification）、可靠性（reliability）、调试（debugging）、延迟（latency）、代码审查负担（code review burden）以及协作（collaboration）等方面的反复出现的痛点和风险。我们还介绍了已被发现并分享的用于缓解这些挑战的最佳实践（best practices）。最后，我们总结了对AI开发工具未来的启示，并为研究Vibe Coding的研究者指明了方向。

全文

好的，这是文章第2/5部分的翻译。由于您提供的原文仅包含标题、摘要和引言部分（即第1部分），以下翻译基于您提供的全部原文。如有后续部分，请提供文本，我将继续翻译。

好“氛”编码？关于氛围编码中共同创造、沟通、心流与信任的质性研究

VERONICA PIMENOVA，密歇根大学，美国
SARAH FAKHOURY，微软研究院，美国
CHRISTIAN BIRD，微软研究院，美国
MARGARET-ANNE STOREY，维多利亚大学，加拿大
MADELINE ENDRES，马萨诸塞大学阿默斯特分校，美国

摘要

“氛围编码”（Vibe coding）一词由 Andrej Karpathy 于2025年2月提出，它迅速成为一种引人注目且备受争议的、在 AI 辅助软件开发中的自然语言编程范式。该范式以与 AI 助手的迭代式共同设计为核心，强调心流和实验性，而非严格的事先规范。尽管已有初步研究开始探索这一范式，但大多数研究侧重于分析代码产物或提出缺乏充分实证支持的理论。我们仍需要一种基于实践的理解，来把握开发者对氛围编码的感知与体验。我们呈现了首次针对氛围编码感知与实践的系统性定性研究。基于从半结构化访谈、Reddit 帖子以及 LinkedIn 动态中收集的超过19万字的文本，我们刻画了氛围编码的内涵、开发者使用它的原因和方式、它在哪些环节出现故障，以及哪些新兴实践旨在支持它。我们提出了一种基于定性数据的氛围编码理论，其核心是：与 AI 的对话式交互、共同创造，以及开发者的心流与愉悦感。我们发现，AI 信任调节着从授权到共同创造的连续体上的移动，并通过维持心流来支撑开发者体验。我们揭示了在需求说明、可靠性、调试、延迟、代码审查负担以及协作等方面的反复出现的痛点和风险。我们还展示了已被发现并分享的、用以缓解这些挑战的最佳实践。最后，我们探讨了这些发现对 AI 开发工具未来发展的启示，以及为研究氛围编码的研究者指出的方向。

CCS 概念： • 软件及其工程 → 软件开发技术；• 以人为中心的计算 → 自然语言界面。

附加关键词与短语： 氛围编码，AI 共同创造，心流，信任，定性方法

1 引言

“这与混乱无关。这是一种与节奏共舞的编码心流，你的心灵得以自由创造，不再被样板代码所累。”（L46）

“氛围编码”这一短语由 AI 研究者 Andrej Karpathy 于2025年2月首次提出，并迅速流行开来，因为它激发了想象，抓住了使用大语言模型（LLM）进行加速创意编程这一新风格的热忱——这种风格将开发者从以往必须先思考技术和工程细节的束缚中解放出来，直接进入“氛围”。然而，该术语也受到了批评¹，因为它可能轻视了 AI 支持的开发的重要性。尽管存在这些批评，且缺乏对该术语的正式定义或共识，但这个短语仍被频繁使用，并且可能在一定程度上推动了一种新的编程范式的转变——这种范式减少了对事先明确需求的依赖。

¹参见 Hacker News 上由 Andrew Ng 的评论引发的相关讨论。

作者联系方式： Veronica Pimenova，密歇根大学安娜堡分校，美国，pimenova@umich.edu；Sarah Fakhoury，微软研究院，美国，sfakhoury@microsoft.com；Christian Bird，微软研究院，美国，cbird@microsoft.com；Margaret-Anne Storey，维多利亚大学，加拿大，mstorey@uvic.ca；Madeline Endres，马萨诸塞大学阿默斯特分校，美国，mendres@umass.edu。

arXiv:2509.12491v1 [cs.SE] 2025年9月15日

2 背景

这一框架出现的时机，恰逢行业致力于提升开发者“体验”的浪潮。该浪潮认识到，编程过程中的愉悦感不仅能带来更具创造性的软件解决方案[18, 19]，也能让软件用户感受到快乐。当然，这也与大量为理解生成式AI对开发速度与软件质量影响的研究不谋而合。这一独特范式转变的速度之快，促使我们有必要探究“vibe coding”这一概念正在演化出何种“意义”，以及这对软件开发与工程实践的未来释放出何种信号。我们及时开展的研究，旨在理解开发者社群在使用这一短语时的实际含义，为何专家与非开发者会进行vibe coding，以及他们具体如何操作。我们还试图揭示他们对自己所创建软件的看法，以及所面临的挑战。此外，我们调查了放弃传统、有原则、以设计为先的软件工程方法所带来的感知风险。具体而言，我们探讨了开发者拥抱LLM（大语言模型）意味着什么——这些模型帮助他们抵达在坐下来开始vibe coding时可能未曾预料到的解决方案。研究一种潜在的新编程范式的重要性，已从arxiv上涌现的相关研究（见第6节相关工作）中显而易见。

为了全面捕捉与“vibe coding”相关的多个层面，我们采用了一种混合数据源的定性分析方法，包括社交媒体帖子与半结构化访谈。在社交媒体方面，围绕vibe coding，Reddit与LinkedIn平台上已形成了一个“实践社群”[56]。在Reddit上，该社群已发展到15.9万名成员，发帖者分享他们的体验、担忧与最佳实践，并寻求对自己“vibe code”产品的反馈。在分析中，我们抓取了r/vibecoding中的关键Reddit帖子，以及LinkedIn上标记为#vibecoding的最新热门帖子。此外，我们还对11名从业者进行了访谈，以更深入地了解他们的实践、挑战与体验。总计，我们采用灵活的定性方法论[12]，分析了超过19万字的有关vibe coding体验与实践的内容。

我们的综合分析得出一个理论，该理论将vibe coding视为许多人所认为的一种新的软件开发交互范式——它支持人类与AI智能体共同创作软件，并捕捉开发者在“vibing”时的心理心流体验。我们还进一步捕捉了开发者遇到的痛点，以及他们为解决这些痛点所采用的实践。我们同时表明，对AI的信任在共同创作体验中起到中介作用，并影响vibe coding的心流。最后，我们分享了在vibe coding新兴实践社群中，开发者最担心的主要风险。简而言之，本文贡献如下四点：

1. 一个基于经验的理论定义，将vibe coding与交互、共同创作、心流和信任联系起来。
2. 实践特征描述：vibe coding发生的地点与原因、开发者委派的任务、以及他们如何引导模型。
3. 痛点与策略的综合，包括沟通、规划/抽象、验证、代码质量与协作方面的问题。
4. 对工具与研究的启示：支持心流的同时不削弱可靠性或团队协调的指导原则与可供性。

2Background（背景）

为了为我们的研究提供背景，我们概述了与自然语言编程范式（第2.1节）、AI共同创作（第2.2节）以及心流（第2.3节）相关的背景知识。

32.1 自然语言编程范式

我们使用“自然语言编程”（natural language programming）来指代开发者利用日常语言指定、修改或编排软件的各类方法，这一概念借鉴了人机交互（HCI）领域关于“自然编程”（natural programming）的研究，该研究探讨了人们在学习正式语法之前如何表达计算意图[36]。

用自然语言编程的雄心可以追溯到早期计算时代。面向业务的编程语言（如COBOL）采用了类似英语的语法以降低使用门槛[7]。第四代语言（4GL）运动则推动了声明式、任务级规范的开发，通过针对数据和业务逻辑的高层抽象，承诺实现“无需程序员即可编程”[22]。然而，纯自然语言若无形式化根基——即将语言与明确定义领域内的可执行语义相连接——被证明是不够充分的。经典的人工智能系统将语言局限于狭窄的可执行领域，例如SHRDLU在积木世界中将命令转化为动作和解释[57]，以及LUNAR通过将阿波罗月球地质学问题翻译为结构化数据库查询并附带可验证结果[58]。

为管理歧义，出现了两种互补策略。受控自然语言（例如Attempto Controlled English）限制了语法和词汇，使句子能够确定性地映射到逻辑[15,16]。与此同时，通过演示编程（Programming by Demonstration, PBD）和通过示例编程（Programming by Example, PBE）则从具体工件中推断意图[11]，后来通过如FlashFill[21]这样的程序合成方法得以形式化，该方法从输入/输出对或部分规范中求解程序[53]。总的来说，这些研究表明，当自然语言与示例、类型、测试或部分程序结合使用时，效果最佳。

机器学习将该领域从基于规则的翻译转变为基于学习的、数据驱动的映射。早期的统计语义解析器利用概率模型将话语映射到逻辑形式[63,64]。随后，深度学习使得基于并行语料库训练的序列到序列（sequence-to-sequence）的NL→Code成为可能，并且在可执行预言（executable oracles）提供客观验证的场景下表现最佳。例如，Spider[61]上的Text-to-SQL、CoNaLa[60]中的Python代码片段，以及基于HumanEval[6]的Codex模型评估等。将神经网络的灵活性与确定性检查相结合被证明至关重要。

在代码上训练的大语言模型拓宽了范围与交互方式。像Codex这样的系统超越了特定领域的映射，扩展到通用编程语言[6]，实现了对话式编程（conversational programming），即开发者迭代地用自然语言描述目标、请求修改并完善实现[47]。这将语言从翻译界面提升为主要编程界面，但如果没有系统的规范或测试，迭代可能会偏离目标并累积错误。

我们沿三个设计轴组织自然语言编程：

• 交互模式：一次性翻译 vs. 对话式改进。
• 根基策略：纯自然语言 vs. 结合工件（输入/输出示例、测试、类型、模式、部分程序）的自然语言。
• 验证方式：临时检查 vs. 系统性预言（单元/属性测试、预期输出、形式化规范）。

这些轴明确了流畅交互与精确规范、自然性与语义根基、创造性探索与正确性保证之间的权衡。

不同的范式占据着这一空间的不同区域（表1）。NL→Code系统通常使用带有有限根基的一次性交互，并依赖人工验证[6]。NL→DSL[29,61]和PBE[21]则通过模式/DSL约束或可执行预言，以表达性换取可靠性。对话式环境强调高交互性的对话[47]，通过上下文逐步建立根基[2]，尽管验证通常仍是非正式的[54]。

Vibe Coding 占据了高交互、低根基的角落：开发者以对话方式进行迭代，几乎不依赖形式化支架，依靠即兴验证和运行-改进循环。这与探索式编程（exploratory programming）相符，其中目标通过编程过程逐渐演变[24]。第4.2–4.5节将研究实践者如何权衡这些因素，这对快速进展有何帮助，以及在哪些方面会损害可靠性。

（表1）

4 范式、交互、基础确立、验证

表 1. 通过我们三个轴描述的自然语言编程范式。氛围编码优先考虑交互流畅性，而非正式的基础确立和验证。

2.2 AI 共同创作的其他范式

关于 AI 辅助编程和设计的研究往往让用户意图变得明确且可解释，这与氛围编码靠直觉驱动的风格形成对比。基于工具性交互理论[3]，Riche 等人倡导具象控件——滑块、提示片段以及其他可操作元素——使用户能够外化、调整和复用意图，而不是……

查看原文