摘要：这个由Andrej Karpathy几个月前创造的术语，现在已经成为我们看待软件工程方式整体转变的简称。它的核心理念是AI在代码生成方面采用"放手"模式：机器只需接收人类的输入，然后自主生成源代码。

这个由Andrej Karpathy几个月前创造的术语，现在已经成为我们看待软件工程方式整体转变的简称。它的核心理念是AI在代码生成方面采用"放手"模式：机器只需接收人类的输入，然后自主生成源代码。

尽管大语言模型在这方面还未达到100%自主，仍需要一些调试工作，但氛围编程本质上要求程序员退后一步，让AI自主发挥。在当前对这一现象的报道中，福布斯理事会成员Shubham Nigam引用了MIT技术评论的Rhiannon Williams的话：

"并非所有AI辅助编程都是氛围编程。要真正进行氛围编程，你必须准备好让AI完全掌控，并避免在过程中检查和直接调整它生成的代码——完全交给AI的'氛围'。"

虽然这是一个口语化术语，但它也要求人类保持距离——不要在大语言模型创建代码时在旁监督。

专家对商业氛围编程的见解

以下是今年4月"行动中的想象力"小组讨论的更多内容。来自Hyperskill的Nikolay Vyahhi采访了Artem Lukoianov、Heena Purohit和Aldo Pareja，讨论这一趋势。

"我认为这个术语的美妙之处在于它准确地呈现了实际发生的情况，"Lukoianov说。"你甚至不需要阅读它生成的代码。你只需要向系统发出提示，它就为你生成部分代码，然后，很多时候，因为开发者出了名的懒惰，你甚至不读代码。"

"你甚至不试图理解代码在做什么，"Pareja补充道，他推测当IDE和其他工具开始整合单元测试时会发生什么。"你甚至不读代码。你只是在感受它。"

小组成员Zach Lloyd谈到了源代码管理的现实。

"开发者会遇到麻烦，然后试图通过氛围编程摆脱困境，或者他们的生产系统出现问题时，试图通过氛围编程解决，"他说。"所以在终端中，我们看到它超越了生成代码，变成了一种整体感觉：'让我看看AI能否为我修复这个问题，也许我不必确切了解它在做什么。'"

Lloyd将这种能力描述为一把双刃剑：一方面，对于感到困顿的开发者来说，这是"神奇的"；另一方面，他认为，人类编程者完全不知道系统在做什么可能是危险的。

AI的局限性

小组成员Heena Purohit指出了让AI独立承担项目的一些挑战。

她论证说，这些系统通常不擅长"远程思考"，即系统各组件如何交互。

"当然，你可以在几分钟或几秒钟内生成数百万行代码，但你仍然需要理解代码实际在做什么，这样在需要时你才能排除故障和调试，"她说，并暗示在许多情况下，扩展可能是个问题。

相比之下，Lukoianov给出了某种有条件的观点，认为我们大多已经达到目标，并将很快完全实现。

"氛围编程能力已经足够好，让我们停止编写任何代码，"他说。"对我来说，更多的问题是我们如何围绕这一点设计系统……我们如何向大语言模型提供正确的信息，如何总结我们的代码库，以及如何为大语言模型提供正确的工具来实际执行得更好？在我个人看来，我觉得大语言模型已经到位了。关键在于我们如何正确提供关于代码库、需求以及相关法规和安全问题的信息。所以这完全关乎向大语言模型提供正确的信息、正确的输入和正确的工具，最终我们会达到目标。"

他指出，在1980年代，我们必须非常接近硬件——现在情况不同了。

"你不会过多思考操作系统，"他说。"你不会过多思考硬件，除非你在从事非常专业的工作。"

全员参与

无论如何变化，Pareja认为全栈开发者仍然有价值。

"如果你使用工具来同步不同的进程，而你有一百万个进程，你的系统会崩溃，"他说。"你需要理解这些约束。"

结论

如果我要总结这次小组讨论中的一些最重要观点，我认为大部分都围绕着需要编程知识来管理系统开发的细节和边缘情况。换句话说，AI可以做所有事情，但可能不会100%按照你需要的方式完成。有句老话说：如果你想做对，就必须自己动手。

也许大语言模型在没有任何监督的情况下能让我们完成80%的工作，但跳过上下文并完全忽视机器在做什么通常不是好主意，部分原因正如小组成员所阐述的。所以人类在循环中目前仍然是相关的。但关键是，氛围编程是如此新颖和根本性的东西，我们可能会花费大量时间来找出如何最好地实践它。

来源：至顶网一点号