VIBE能否推动发展？其中的威胁与机遇

《Communications of the ACM》：Can VIBE Drive Development? Threats and Opportunities

　　2025年2月，曾负责特斯拉人工智能部门的计算机科学家安德烈·卡尔帕西（Andrej Karpathy）提出了一个术语，这个术语迅速传播到了硅谷的Slack聊天频道和大学宿舍中：**“氛围编码”（Vibe Coding）**。起初听起来像是个玩笑，又一个适合成为网络热词的词汇，与“YOLO”（一种投资理念）和“快速失败”（fail fast）这类表达并列。但几周内，《韦氏词典》（Merriam-Webster）就将它收录为俚语，《纽约时报》也开始报道非程序员如何通过与大型语言模型交流来开发应用程序的案例。突然间，“跟随氛围”（going with the vibes）不再仅仅指音乐播放列表或周末的情绪，而演变成了软件开发本身的一个概念。

要理解“氛围编码”，你需要想象一位开发者放弃Java或Python等语言的严格语法，转而与聊天机器人进行对话。机器生成代码，人类接受并测试这些代码，然后提出改进意见。重点从代码的编写转移到了对开发方向的指导上，从按键操作变成了沟通。卡尔帕西本人将这一过程描述为“忘记代码的存在”，转而专注于提示和原型的迭代过程。“氛围编码”的危险与乐趣在于这种对技术的完全信任。与双人协作编程或Copilot辅助的打字不同，“氛围编码”要求人类停止微观管理，让人工智能来构建软件的基础框架。

“氛围编码”已经引起了《通讯》（Communications）杂志读者的关注，相关文章探讨了早期实验对程序员和产品经理工作的影响。但要使这种探索性的编码方法成为软件开发的常规实践，还需要足够的规范性，以防止其沦为低质量的成果。因此，这篇文章既分析了“氛围编码”为更广泛的参与和快速原型设计带来的机遇，也指出了它可能带来的脆弱性、透明度不足以及缺乏纪律性的风险。

一旦我们认识到这一转变，未来的发展方向将是**“氛围驱动的开发”（Vibe-Driven Development, VDD）**，这是一种旨在为混乱带来秩序、为即兴创作带来纪律性的框架。计算机科学史上充满了这样的转折点：最初的野性自由最终被结构所驯服。20世纪60年代，意大利面条代码（spaghetti code）在早期软件项目中盛行，直到埃德萨格·迪杰斯特拉（Edsger Dijkstra）发表著名论文《GoTo语句的危害》（“GoTo Statement Considered Harmful”），促使程序员重新思考他们的编码方式。90年代，面向对象设计成为主流；21世纪00年代，敏捷开发（Agile）和SOLID原则的出现解决了代码臃肿和僵化的问题。每一次，结构都帮助创造力免于被自身的重量压垮。同样的道理也适用于“氛围编码”。

如果“氛围编码”要真正发展起来，就不能仅仅停留在孵化器里的流行术语阶段。它需要一个被业界认可的基石。一种可行的方法是将VIBE视为一个缩写词，其含义包括：

- **可验证性（Verifiable）**：任何由人工智能生成的代码都必须能够被测试、衡量和负责。早期的“氛围编码”实践常常忽视这一点，导致软件在演示环境中运行良好，但在实际应用中却出现问题。可验证性使“氛围编码”基于现实世界。
- **可解释性（Interpretable）**：黑盒代码容易滋生错误和漏洞。“氛围编码”要求即使代码由人工智能编写，人类也必须能够理解其逻辑，这违背了SOLID原则中的“单一职责”（Single Responsibility）原则，更注重代码的清晰度而非复杂性。
- **平衡性（Balanced）**：基于氛围的开发应将速度与可维护性、新颖性与稳定性结合起来。这是对“快速发布”文化的一种平衡。
- **可进化性（Evolvable）**：重构不应是事后才考虑的事情，而应该是工作流程的一部分。在“氛围”指导下编写的代码库应该具备进化能力，而不是固定不变。这里借鉴了SOLID原则中的“开放封闭”（Open/Closed）原则：软件应易于扩展，但防止随意修改。

如果“氛围编码”要成为一种可靠的开发方法，它不能仅仅停留在随意使用的阶段。我们需要为它建立一个被业界认可的规范体系。这样，它才能为更广泛的参与和快速原型设计提供支持，同时避免出现质量低下的问题。

**历史启示**
围绕“氛围编码”的热情并非新的现象。历史上曾出现过许多承诺简化编程的尝试：20世纪60年代，COBOL被宣传为“任何经理都能理解的语言”；80年代，苹果的HyperCard允许非程序员通过拖放操作构建交互式应用；2010年代，“无代码”（no-code）的概念随着Bubble和Webflow等平台的出现而重新兴起。这些尝试都承载着一个乌托邦式的愿景：有一天，人们只需用简单的语言就能告诉计算机该做什么。卡尔帕西说“最热门的新编程语言是英语”，这一观点可以追溯到艾伦·图灵（Alan Turing）关于自然语言作为编程界面的想法。然而，每次尝试都遇到了同样的人力障碍——复杂性的限制。COBOL程序变得难以维护，HyperCard因专业程序员的忽视而停滞不前，无代码平台虽然为业余爱好者提供了便利，却难以支撑大型基础设施。如今，“氛围编码”如果缺乏监管，也可能遭遇类似的命运：虽然充满创新，但缺乏持久性。

**“氛围时代”的机遇**
不过，机遇也是显而易见的。例如，《纽约时报》记者凯文·鲁斯（Kevin Roose）没有编程背景，却使用“氛围编码”开发了分析冰箱内容并推荐午餐菜单的应用程序，以及生成购物清单的工具。这些看似简单的应用实际上体现了巨大的变革：编程的门槛降低了。曾经需要多年学习的内容现在可以在一个周末内完成原型设计。创业公司也注意到了这一点。Y Combinator报告称，2025年冬季批次的创业项目中，有25%的代码库是由人工智能生成的。对于资金紧张的创业者来说，“氛围编码”不仅是娱乐，更是生存手段。为什么还要雇佣十个人的团队，而两个人和一个聊天机器人就能构建一个基本功能的产品呢？在这个新时代，代码生成能力已成为风险投资的新动力。

这种民主化趋势与1990年代的开源运动类似：当时Linux让任何人都可以为世界上最先进的操作系统做出贡献。如今，“氛围编码”让任何人都能无需专业技能就能创造功能性软件。创造力的大门已经被彻底打开。

**潜藏的威胁**
然而，开放的门槛也可能带来问题。批评者指出，“氛围编码”产生的代码往往脆弱、不安全且难以维护。资深开源开发者西蒙·威利森（Simon Willison）直言：“依靠‘氛围编码’生成生产环境下的代码显然很危险。”问题不仅在于人工智能可能生成错误或虚假评价，还在于这样的代码难以维护。这种危险类似于20世纪70年代流水线软件的早期问题：虽然生产效率大幅提升，但质量却大幅下降。如果“氛围编码”缺乏规范，可能会导致类似的情况。

**未来的方向**
为了避免这些风险，我们可以将重构（refactoring）视为“氛围驱动开发”（VDD）的重要组成部分。在传统开发中，重构是默默无闻的代码清理过程。英国开发者马丁·福勒（Martin Fowler）将其比作园艺，即修剪枝条、重新布置结构以确保系统健康生长。在“氛围编码”中，这一点变得更加紧迫。由于人工智能生成的代码往往缺乏风格一致性，人类需要不断进行重构，以确保代码的质量和可维护性。重构应该成为工作流程的一部分，而不是事后才考虑的事。

总之，“氛围编码”可能源于灵感，但“氛围驱动的开发”要求我们将其发展成一种负责任的编程哲学。

**总结**
“氛围编码”带来的兴奋情绪并不新鲜，历史上不乏类似的尝试。每次尝试都伴随着乌托邦式的期望：用简单的语言控制计算机。然而，每一次都遇到了复杂性的阻碍。要使“氛围编码”成为成熟的开发方法，我们需要为其建立明确的规范和原则，如可验证性、可解释性、平衡性和可进化性。只有这样，我们才能真正利用人工智能的潜力，同时保持软件的质量和安全性。