纯粹编程主义者：氛围编程究竟有没有用处？

导读：曾经，一些编程纯粹主义者认为 BASIC 语言有害，而现在的人工智能甚至连 BASIC 都无法做到。

一个前景光明的项目，必然需要一支团队 —— 这是公认的事实。这支团队必须由经验丰富、判断力强、具备分析逻辑能力和良好人际沟通技巧的优秀开发者组成。

而AI 编码在其中的定位仍存在巨大争议。但企业 IT 领域对 “氛围编程”（Vibe Coding）的态度却十分明确：要么是在推销它，要么是对它敬而远之。

原因很简单。代码生成工具的卖点是 “通过自然语言指令快速出结果”，无需使用者掌握代码工作原理的专业知识。这一点在某种程度上确实成立，精心挑选的两分钟演示也确实令人印象深刻。从这方面来看，氛围编程与已经存在了 30 年的低代码 / 无代码运动甚为相似。

但氛围编程随后便会暴露致命缺陷：它具有不确定性。

低代码 / 无代码平台的界面对用户输入的响应是一致的。无论是调整字体，还是彻底换一种全新思路重新开始，迭代优化都能顺利推进。而氛围编程则可能在相同指令下，不同时间给出截然不同的结果。想要调整结果，很大程度上取决于 AI 如何解读你的需求，以及它对自己最初想法的执着程度 —— 通常这种执着还相当强烈。

更别提当你的工具不断变化时，如何维护一个没有人类完全理解的代码库了。如果 30 年后低代码 / 无代码领域都没有出现太多成熟的生产级应用，那么氛围编程的前景无疑更加黯淡。即便氛围编程实现了其最基本的功能 —— 快速生成原型来探索想法 —— 也会遭遇 “原型无法舍弃” 的问题，最终演变成难以控制的 “怪物”。一旦某个原型看起来能运行，来自外部的压力通常会迫使团队立即在此基础上进行开发。这种情况在任何环境下都已经够糟糕了，而 “氛围” 根本无法应对这种局面。

不过，在某个方面，氛围编程确实拥有其他工具难以比拟的吸引力。自开机就能直接进入 BASIC 解释器的家用电脑时代以来，新手用户终于能通过简单输入就能实现一些功能了。

林纳斯・托瓦兹（Linus Torvalds）上周将它视为一大优势，认为这与当年从电脑杂志背面抄录程序的日子颇为相似。这话并不是没有道理 —— 如果你经历过那个年代，就会记得修正数百行晦涩代码中的逻辑错误或打印错误是多么可怕的经历 —— 但这几乎完全偏离了核心问题。

当年的 BASIC 语言也遭遇了与如今氛围编程类似的批评，被认为会助长糟糕的编程习惯，催生结构混乱、难以理解、无法维护的代码。编程界泰斗埃德加・迪杰斯特拉（Edsger Dijkstra）在《GOTO 语句有害论》中就提出了这一观点，而这句话在数十年间一直被广泛引用。这就好比说，那些拿起乐器只是想试试身手的孩子，或者被没有正规训练背景的老师教导的孩子，永远只能做出糟糕的音乐。通常情况下确实如此，但大多数优秀的音乐家都是这样起步的。音乐的起源本就如此。如果你发现自己热爱它，就会不断进步。而BASIC 语言的情况也是如此。

但氛围编程却没有这样的成长路径。这并非完全是它的错。在现代计算环境中，要实现 “有用的功能”，就需要编写包含 API、复杂结构的代码，核心逻辑之外还充斥着无数繁琐的附加部分。通过反复调整指令来 “瞎折腾”，无法建立起编写代码所必需的内在理解框架；而没有了那种突然顿悟带来的多巴胺奖励 —— 这种奖励正是许多人早期编程经历的动力源泉 —— 这个过程也无法激励自学成才者继续坚持下去。

如果 “氛围编程” 不涉及实际编码，或许会是个好主意。比如提供入门方向、学习建议，帮助构建一个能快速看到结果的环境，而这些结果明确依赖于探索和尝试新想法。这类工具其实已经存在了 —— 它们叫做书籍，叫做教程。

能在学习过程中立即产生生产力当然是件好事，而且没有任何教程或书籍能提供独特、创新的专属结果。

目前尚不清楚大语言模型（LLM）是否能可靠地实现这一点，但这会是一个有趣的实验。幸运的是，确实有一种可行的方法：加入一支愿意提供指导、并能为你分配合适任务来培养技能的支持型团队，团队成员需具备丰富经验。

如果你对编码的实际情况知之甚少，氛围编程听起来确实很棒。这正是生成式 AI 最大的风险之一 —— 它能激发与现实脱节的自信心。同样，如果你还记得自己当初对编码一无所知的日子，可能会觉得氛围编程是帮助他人踏上编程之路的好方法。

但这两种想法都忽略了，学习和编码在很大程度上与动力、回报、理解能力、对未来的认知有关，而最重要的是，这一切都需要在与人协作的环境中完成。

这才是真正的 “氛围”，伙伴们。