氛围编程的不安真相

我们正处于软件开发的一个奇怪时刻。任何有互联网连接和信用卡的人都可以启动一个AI编程助手并开始构建应用程序。你用简单的英语描述你想要什么，按回车，然后看着代码在你的屏幕上出现。

这就是氛围编程——通过与AI对话而不是自己写每一行代码来构建软件的实践。Andrej Karpathy今年早些时候创造了这个术语，它之所以流行起来，是因为它准确地捕捉到了数百万人现在如何接近开发的真实情况。你描述氛围，AI处理细节。

工具的普及速度超出所有人的预期。Cursor、GitHub Copilot、Windsurf、Claude和ChatGPT各自承诺让软件创建更容易。公平地说，它们以真正有意义的方式兑现了这一承诺。那些从未想过自己会成为开发者的人正在交付真实的产品。那些本会死在"有朝一日我会学编程"坟墓里的想法，终于见到了天日。

但问题是：氛围编程是近年来出现的最令人兴奋也最危险的开发实践。要理解为什么，需要抛开炒作，深入了解当最初的新奇感消退后出现的不安现实。

让我们不要假装氛围编程不起作用。它绝对有效——对于某些事情来说。需要一个快速原型？一个闪卡app？一个着陆页？你可以在几分钟内从想法变成可运行的代码。我最近读到的一位开发者仅用提示词就构建了一个功能完整的闪卡app，带有可编辑的卡片、翻转动画和持久化存储。没有输入分号，没有调试console日志——只有对话。

我在短短几个月内将五个概念变成了现实，创建了三个最小可行产品（MVP）。以前需要我投入整个季度晚上的项目，现在只需要一个周末。速度是真实的，否认它是不诚实的。

当你在处理简单、自包含的项目时，效率的提升是毋庸置疑的。自然语言是我们大脑实际的工作方式。我们用概念和意图思考，而不是用花括号和类型声明。氛围编程让我们保持在这种思维方式中。你可以专注于你试图构建什么，而不是迷失在实现细节的如何中。

1、它在哪里崩塌

但现实终究会来。你的项目已经进行了三个月。你一直在与AI助手来回对话，添加功能，修复bug，进行调整。一切都感觉很顺畅，直到突然之间不再顺畅了。

你改变一个小东西，四个其他功能就坏了。你让AI修复那些，然后别的东西又变得奇怪。你在自己的代码库上玩打地鼠游戏。Reddit上一位开发者描述得恰到好处："AI仍然太蠢了，它会修复一个东西但破坏你代码中的十个其他东西。"

图1：把一个巨大的提示词拼在一起并期望AI完美协调是灾难的配方！

这不是AI笨。这是在没有规格说明的情况下构建的自然后果。当你进行氛围编程时，你的指令在代码生成的那一刻就过时了。代码本身变成了软件做什么的唯一事实来源——而代码极不擅长解释它为什么这样做。决策背后的意图丢失了。使一切合理的思维模型淡化了。你留下了一个能运行（差不多）但没有人——包括AI——能完全理解的代码库。

这就是为什么这么多氛围编程项目在三个月左右撞墙。代码库已经增长到超出了任何人在脑海中把握的能力。AI的上下文窗口只能看到片段。你没有地图来帮助你找回一个稳定版本。

2、具体性为王

在AI编程工具上取得真正成功的开发者不只是在氛围编程。他们在做规格说明。

规格驱动开发翻转了指令和代码之间的关系。你不是把提示词当作一次性任务，而是把规格说明作为权威蓝图——代码必须遵循的唯一事实来源。当某东西坏了，你不去代码里修复它。你细化规格并重新生成。

这听起来像是额外的工作，而且确实如此。但考虑一下你得到了什么。你的规格说明变成了实际保持最新的版本控制文档。你可以在规格层面与队友协作，而不是在代码审查上争论。当你需要改变某东西时，你在一个地方改变它，而不是在相互关联的代码路径中搜索，希望不会破坏其他东西。

最重要的是，你保持了控制。AI成为你明确表达意图的强大执行者，而不是一个做出你不理解的决策的不可预测的协作者。

图2：通过任务规格说明来指定你想要的东西，整体上会得到更好的结果。氛围编程仍然有它的位置，但在更小、受控的范围内。

想想一个好的规格说明实际上做了什么：它迫使你在开始构建之前表达你想要什么。图2显示了两种工作流之间的差异。规格驱动开发让你考虑边界情况、定义约束条件，并思考用户体验。这些不是官僚主义的障碍——它们正是将能用的软件与差不多能用直到不能用的软件区分开来的关键。

3、不安的中间地带

这是热情支持者不想承认的：你仍然需要懂技术。你仍然需要理解软件如何工作：架构、依赖、约束、权衡。一个不懂这些东西的人写的规格说明不是一个可行的蓝图；它是一张愿望清单。

入门门槛降低了，但并没有消失。氛围编程扩展了你的能力范围，但并没有取代你的基础。效率提高十倍的开发者并没有放弃他们的专业知识。他们只是以新的方式使用它。

想想几十年前从汇编语言到高级语言的转变。我们失去了对机器如何工作的详细理解。但我们仍然需要懂技术。我们仍然需要理解计算机。抽象变了，对能力的要求没有变。

这为"现在任何人都能编程"的说法创造了一个尴尬的现实。是的，任何人都能生成代码。但生成代码和构建可持续的软件不是同一件事。一个能运行的演示和生产系统之间的鸿沟仍然巨大，而AI并不会自动弥合这个鸿沟。它只是让演示更容易达到。

4、什么真正有效

最有效的方法结合了自然语言的效率和显式规格的严谨性。你仍然可以在探索想法或原型设计时进行氛围编程。但当你构建重要的东西——需要维护、调试和扩展的东西——你需要护栏。

注意氛围编程在规格驱动工作流中仍然有它的位置：在单元级别。如果你能编写一个单元测试或功能测试来验证输出，这个范围就小到可以进行氛围编程。如果你不能在那个层面测试它，你需要一个规格。这就是让你避免打地鼠陷阱的关键：每个部分都足够小，可以在加入更大系统之前单独验证。

明确你想要什么。明确你想要如何实现它。记录你的决策。定义你的约束。创建验收测试来验证你的规格是否被实际实现。

这不再只是理论了。行业正在赶上，真正的工具正在涌现来弥合氛围编程和构建之间的鸿沟：

• Amazon的Kiro
• GitHub的Spec Kit
• Codeplain
• Tessl

甚至GitHub的研究部门早在2023年就探索了这个领域，推出了SpecLang——一个使用结构化自然语言生成代码的实验性项目。虽然它从未作为产品发布，但它开创的理念现在正在整个生态系统中出现。

这些项目的共同点是什么？它们都认识到氛围编程的自由放任性质无法扩展。在某些时候，你需要结构。你需要一些超越聊天窗口而持久存在的东西。

当你把细节留给不确定性时，AI会填补空白。有时它填补得非常出色。有时它每次生成代码时都填充不同的内容，导致一位研究者所说的"功能闪烁"——那种令人困惑的体验，你的按钮今天是蓝色的，明天是绿色的，因为你从未指定它应该是什么颜色。

解决方案不是完全放弃氛围编程。而是要认识到你何时已经超越了原型阶段，需要转变到更有纪律的模式。用氛围来探索。用规格来构建。

5、未来是具体的

氛围编程不会消失。它太有用、太易获得、太符合人类自然的思维方式。但蓬勃发展的开发者不会是氛围编程最厉害的那些人。而是那些学到具体性为王的人。

魔法不在氛围中。在于确切地知道你想要什么，并清楚到连AI都不会误解地表达出来。

这比听起来更难。但这正是将可持续软件与等待下一个提示词冲走的数字沙堡区分开来的技能。

原文链接: The uncomfortable truth about vibe coding

汇智网翻译整理，转载请标明出处