
从汇编到人工智能:“氛围编程”为何只是我们抽象故事的又一章

两天前,Andrej Karpathy 在科技推特上提出了一个名为“氛围编程”(vibe coding)的挑衅性观点,点燃了激烈的讨论——你“完全沉浸于氛围,拥抱指数级增长,甚至忘记代码的存在”。他演示了如何使用 AI 工具(如 Cline)在大约一小时内构建一个完整的 LLM 阅读器应用程序,几乎没有触碰键盘。
人们的反应是可预测的,对于了解计算机历史的人来说,这种反应熟悉得令人毛骨悚然。但要理解为什么,我们需要追溯历史。很久很久以前。
到底什么是“抽象”? 抽象是将复杂性隐藏在更简单的界面之后。当你开车时,你不需要考虑发动机——你只需要使用方向盘和踏板。计算中的每一个新抽象层都遵循同样的模式,让我们能够专注于解决问题,而不是管理细节。
汇编语言之战(1950年代)

最初,只有机器码——直接输入给处理器的原始 1 和 0。当汇编语言在 1950年代被引入时,它提供了人类可读的助记符而不是二进制,许多程序员感到愤怒。他们认为,从直接的机器指令中抽象出来会导致低效的代码和理解力的丧失。
听起来熟悉吗?
FORTRAN 革命(1957)
接着是 FORTRAN。John Backus 厌倦了用汇编语言编写复杂的数学计算,于是创建了我们现在所说的第一种高级编程语言。他的动机是什么?正如他所说:“我的大部分工作都源于懒惰。我不喜欢编写程序。”
抵制是激烈的。许多程序员怀疑编译器能否与手工编写的汇编代码效率相匹配。他们错了。FORTRAN 不仅达到了汇编语言的性能——它还使那些不想以机器指令思考的科学家和工程师也能进行编程。
Unix 时刻(1973)

但也许与今天的“氛围编程”争论最相关的历史相似之处发生在 1973 年。Dennis Ritchie 和 Ken Thompson 决定用一种名为 C 的新语言重写 Unix。用高级语言编写整个操作系统的想法被认为是荒谬的。
批评者认为
- 它会太慢
- 你会失去对硬件的控制
- 增加的复杂性会使系统难以维护
相反,C 语言对机器细节的抽象使 Unix 成为有史以来最具可移植性和影响力的操作系统之一。正如 Thompson 后来所说:“Unix 非常简单,只是需要一个天才才能理解它的简单性。”
模式显现
看看这些历史时刻,一个清晰的模式显现出来
- 引入新的抽象层
- 老手抵制,声称失去控制
- 早期采用者接受它
- 抽象层证明了它的价值
- 它成为新的常态
- 循环往复
这个模式已经反复上演
- 汇编语言 → “那机器控制怎么办?”
- C 语言 → “太慢了,需要汇编”
- Python → “真正的工程师用 C++”
- React → “直接写原生 JS”
- AI → “你不会理解代码”
现代高塔

我称之为“现代抽象高塔”的图表说明了我们已经走了多远。每一层都解决了特定的问题
- 汇编将我们从二进制中解放出来
- C 语言赋予我们可移植性
- 高级语言自动化了内存管理
- 框架标准化了模式
- 现在,AI 有望完全抽象掉实现细节
但“氛围编程”之所以引人入胜,原因在于:它不仅仅是又一个抽象层——它可能是我们向计算机表达意图方式的根本性转变。我们不再通过精确的指令告诉机器具体该做什么,而是转向用自然语言描述我们想要达成的目标。
并非所有人都将 AI 视为抽象

Karpathy 宣布时流传的钟形曲线梗图抓住了开发人员态度的有趣之处。在曲线的两端,你发现相同的结论(“让 AI 来编写代码”)但达成的途径完全不同。专业知识较低的人出于天真的乐观而接受它,而专业知识最高的人则通过对抽象层的深入理解来接受它。那么中间的人呢?那些谨慎的怀疑论者坚持“AI 需要我的专家指导”——也许他们忽略了完全抵制和完全接受都属于我们以前见过的相同周期的一部分。
寻找平衡
在 Cline,我们认识到这种历史模式。正如 C 语言没有消除汇编语言,但使得它对大多数任务不再必要一样,AI 不会消除传统的编码,但会改变我们投入认知努力的地方。
我们的方法提供了一种人机协作的体验,开发人员可以
- 用自然语言表达意图
- 审查和批准 AI 建议的更改
- 保持控制的同时提高速度
- 在需要时下降到较低的抽象级别
前方的路
“程序必须编写出来供人阅读,执行机器是附带的,”Harold Abelson 写道。即使我们增加了新的抽象层,这个原则仍然是正确的。目标不是消除复杂性,而是更有效地管理它。
“氛围编程”是否会像以前的抽象层一样具有根本性意义仍有待观察。但有一点很清楚:那些完全否定它的人,正在重复 1957 年的汇编程序员、1973 年的系统程序员以及每一个抵制最终成为标准的抽象层群体的论调。
开发的未来不是在极端之间做出选择——而是要理解哪个抽象级别适合每个任务。有时这意味着进入完全的氛围模式。其他时候则意味着深入研究实现细节。关键是拥有区分两者的工具和智慧。
本博客由 Cline 产品营销部的 Nick Baumann 撰写。关注我们 @cline 获取更多关于开发未来的见解。


