Vibe Coding 就是祖传代码

Vibe code is legacy code

尽管存在广泛的误解，但 “vibe coding” 这个词是 Andrej Karpathy 创造的，用来形容一种 AI 辅助编程的方式，在这种方式下，你“甚至忘了代码的存在”。

祖传代码

对于没人能看懂的代码，我们已经有了一个专门的词：祖传代码 (legacy code)。

祖传代码是人见人嫌的，而且理由很充分。但为什么呢？你不是有代码吗？看看不就懂了？

大错特错。没人能看懂的代码就是技术债。要想弄懂陌生的代码，以便进行调试，需要花费大量时间，更不用说在不引入新 bug 的情况下添加新功能了。

我们都知道，编程的本质是理论构建 (theory building)，而不是生产一行行的代码。这就是为什么我们总是嘲笑那些试图用代码行数来衡量开发者生产力的商业人士。

当你进行 vibe coding 时，你正以大语言模型 (LLM) 能达到的最快速度，疯狂地累积技术债。这也正是为什么 vibe coding 非常适合原型开发和一次性项目：只要你不需要维护它，它就算不上是祖传代码！

原型和一次性代码

我曾愉快地用 vibe coding 开发过一些应用，比如：

• 计算每周的增长率
• 给《纽约时报》的 Connections 游戏评分
• 向我的未婚妻求婚

我不需要持续开发这些应用，所以我是否理解它们的代码，并没有成为问题。这些应用也非常小，这意味着即使我将来需要回头阅读代码，我所承担的技术债也不会太多。通过 vibe coding，我构建这些应用的速度远超传统方式，而且这个过程非常爽。

Vibe coding 是一个光谱

Vibe coding 存在于一个光谱之上，其程度取决于你对代码的理解程度。你理解得越多，你 vibe coding 的成分就越少。

仅仅因为你是一名工程师，在提出需求时说“我需要一个带持久化数据库的 Web 应用”，你的 vibe coding 程度就已经低于一个非程序员了。非程序员可能只会说想要一个“App”，却不了解 Web 应用和原生应用的 distinctions，也不懂持久化数据存储是如何工作的。

把信用卡给一个孩子

最糟糕的情况，莫过于让一个非程序员用 vibe coding 来构建一个他们打算长期维护的大型项目。这就像把信用卡交给一个孩子，却没有先向他解释什么是债务。

可以想象，第一阶段是欣喜若狂的。“我只要晃晃这张小塑料片，就能拿走店里任何我想要的东西！”

这很像现在的情形：“AI 现在什么都能做了！谁还需要学编程啊！快看它刚刚为我做的东西！”

但只要等上一个月，你就会收到信用卡账单。“我真的需要买那些东西吗？我该怎么填上这个窟窿？”

这和 vibe coder 很像。“我的代码坏了。这些文件和文件夹到底是干嘛的？我该怎么才能修好它？我为 vibe coding 花掉的 400 美元能退款吗？”

如果你看不懂代码，你唯一的办法就是让 AI 帮你修复，这就像用一张信用卡去还另一张信用卡的债，无异于拆东墙补西墙。

2025 年，如何用 AI 进行严肃的编程

如果你正在构建一个严肃的、打算在 2025 年进行维护的项目，Andrej 的看法是正确的：

[要] 紧紧地拴住这个新来的、过度热情的实习生天才。他拥有百科全书般的软件知识，但同时也总是对你胡说八道，勇气过剩，却对优秀代码几乎毫无品味。重点是要放慢速度、保持防御姿态、小心谨慎、甚至有些偏执，并且总是抓住每一个即时学习的机会，而不是把任务甩手出去。

— Andrej Karpathy,twitter

我们如何拥抱 AI 进行构建

在 Val Town，我们已经通过数十种方式将 AI 融入了我们的产品。Townie 是我们的 AI 助手，它可以主动地读取和编写代码、运行代码、查看日志，并不断迭代直到任务完成。

Townie 是一个很棒的 vibe coding 工具。我衷心向那些理解其中利弊的人推荐它。我自己有时也用它进行 vibe coding。其他时候，当它对一个我非常在意的项目进行精细修改时，我会对它严加看管。这两种方式都既有趣又有用。

用 AI 编程的变化如此之快，以至于很难预测明天会发生什么。但我相信，理论构建仍将是构建复杂软件活动的核心。我们的技术专长依然重要！而且我乐观地认为，AI 将继续以令人惊喜的方式改善编程。

但是，如果你认识哪个非程序员正花费数千美元，用 vibe coding 来实现他们价值十亿美元的应用创意，请把这篇文章发给他们。Vibe coding 无法带他们到达想去的地方。他们最终将不得不学会用他们自己的肉眼去读代码 😱，并明白一个道理：有时候，从头开始构建一个编写良好的代码库，比修复一个谁也看不懂的祖传系统要容易得多。

---

这篇随笔是我上个月一次演讲的精炼版本：《人脑在编程中的角色》。感谢我的未婚妻 Emily 数月来倾听我对此类话题的咆哮，并为我拍摄了演讲视频。感谢 Malte 和 Rippling 主办这次演讲。 感谢 Geoffrey Litt, Jimmy Koppel, Max McDonnell, Tom MacWright, Charmaine Lee, Brent Jackson, 和 Dan Shipper 对本文的反馈。感谢 Simon Willison 和 Andrej Karpathy 在 AI 的狂热吹捧和悲观否定声中，成为理性的声音。

---

总结与我的看法

这篇文章的核心观点非常明确且切中要害：作者将当前流行的、由 AI 辅助的 vibe coding 与软件工程中臭名昭著的“祖传代码”和“技术债”直接挂钩。他犀利地指出，在不理解代码的情况下，单纯依赖 AI 生成代码，本质上是在以惊人的速度制造未来难以维护的麻烦。

作者并非全盘否定 vibe coding。他将其描绘成一个“光谱”，并清晰地划分了适用场景：

1. 优点：对于原型、一次性项目或非核心任务，vibe coding 是极佳的工具，能大幅提升效率，让想法快速落地。
2. 风险：对于需要长期维护的严肃项目，这种方式是灾难性的。它绕过了编程最核心的环节——理论构建，即开发者对系统架构、逻辑和目标的深入理解。

文章通过“把信用卡给孩子”这个生动的比喻，形象地警示了非专业人士滥用 AI 编程工具的潜在危险：初期看似无所不能，后期则会陷入难以偿还的“技术债务”危机。

我的看法：

我完全赞同作者的观点。这篇文章是在当前 AI 浪潮中一剂清醒剂，它没有陷入“AI 将取代程序员”或“AI 毫无用处”的二元对立，而是提供了一个非常务实且富有建设性的视角。

1. 开发者的角色正在演变，而非消失。 AI 确实像一个“热情但品味堪忧的天才实习生”。未来，程序员的价值将更多地体现在架构设计、需求分析、代码审查和系统思维上。开发者不再是单纯的代码“生产者”，而是代码的“架构师”、“质检员”和“项目经理”。如何提出正确的问题、评估 AI 生成方案的优劣、并将其整合进一个健壮且可维护的系统中，将成为核心竞争力。
2. “理论构建”的重要性前所未有。 正如文中所说，编程的本质是构建一个 mentale model（心智模型）。AI 可以填充细节，但无法替代人类去构建这个宏观的、融会贯通的理论蓝图。当系统出现问题时，只有真正理解其“理论”的人，才能进行有效的诊断和修复。否则，就像文中所说，只能寄希望于用一个“黑箱”去修复另一个“黑箱”，结果往往是更大的混乱。
3. 对非技术人员的警示恰逢其时。 AI 的低门槛让许多非技术背景的创业者看到了“零成本”实现宏大构想的希望。这篇文章的警告非常及时：原型和真正的产品之间有巨大的鸿沟。将一个通过 vibe coding 生成的原型发展成一个可扩展、安全、稳定的商业产品，所需要的工程知识和纪律，并不会因为 AI 的存在而减少，反而可能因为初期的混乱而变得更加复杂。

总而言之，AI 是一个强大的赋能工具，它将编程的门槛降低了，也把生产力的上限提高了。但它并未改变软件工程的基本原则。对于想要构建严肃、持久软件的人来说，人类的智慧、经验和深刻理解，依然是不可或缺的基石。