--- title: 260307-Vibe Coding：革命还是鲁莽放纵？ description: 解码 vibe coding：炒作、希望与开发者的严峻真相 author: Addy Osmani source: https://addyo.substack.com/p/vibe-coding-revolution-or-reckless date: '2026-03-07' category: 01-core-concepts tags: - AI 编程 - Vibe Coding - 代码质量 - 软件工程 - AI 辅助开发 --- # Vibe Coding：革命还是鲁莽放纵？ **作者：Addy Osmani** **原文：[查看原文](https://addyo.substack.com/p/vibe-coding-revolution-or-reckless)** > ## 摘要 > > 解码 vibe coding：炒作、希望与开发者的严峻真相 --- **核心要点：虽然 AI 快速加速了代码创建（例如"vibe coding"），但它危险地降低了引入细微 bug、安全漏洞和不可维护复杂性的门槛。行业需要的不仅仅是拥抱速度，而是需要开发者充当专家策展人和批判性验证者，强化良好的设计、代码审查、安全测试和系统理解，以确保 AI 为健壮、可靠的软件做出贡献。对于初学者进行 vibe coding，也需要更好的风险教育。你必须让 AI 生成符合你标准的代码。"Vibe coding"不是低质量工作的借口**。 如果你更喜欢听的话，这篇文章也有 [NotebookLM 播客](https://notebooklm.google.com/notebook/d6227310-1ae0-4443-b3a7-8283df1549af/audio)版本 :) ## "Vibe Coding"的起源 > _"屈服于感觉，拥抱指数级增长，忘记代码的存在。"_ 2025 年初，Andrej Karpathy 用这些话向世界[介绍](https://x.com/karpathy/status/1886192184808149383?lang=en)了 **vibe coding**，一种编写软件的挑衅性新方法。Karpathy——OpenAI 的联合创始人和特斯拉前 AI 总监——在一篇半开玩笑的帖子中创造了这个术语。他描述了一种超现实的编码体验：使用一个如此先进的 AI 配对程序员，他可以通过语音识别与它*交谈*，并简单地通过"感觉"来完成一个项目。 他会把一些原本会亲手处理的琐碎改动——比如 UI 微调——也直接交给 AI，在不细看差异的情况下点下“全部接受”，遇到报错就把错误信息继续贴回去，让系统再迭代一轮。代码库会以一种远超个人逐行掌控的速度膨胀，但靠着不断试、不断调，他依然能把一个应用推到“能跑”的状态。正如 Karpathy 自己承认的： > _"对于一次性的周末项目来说还不错……我只是看东西、说东西、运行东西和复制粘贴东西，它大部分时候都能工作。"_ 换句话说，他不是精心制作代码——他是在 AI 的帮助下*感觉*自己的方式，将软件开发视为与机器的即兴对话。因此，"vibe coding"诞生了，半认真半开玩笑地描述这种与 AI 一起编码的自由形式、直觉驱动的模式。 Karpathy 的帖子触动了神经。几周内，_vibe coding_ 成为《纽约时报》、《Ars Technica》和《卫报》等主流媒体报道的流行语。这是一个引人注目的起源故事：世界顶级 AI 研究人员和程序员之一公开尝试将控制权交给 AI 编码器。对于资深工程师受众来说，这个场景听起来既有趣又令人担忧——可能是对未来的一瞥，或者只是 AI 炒作的漫画。要理解其中的细微差别，我们必须看看 **vibe coding 的定义如何演变**，超越 Karpathy 最初的"周末项目"背景，以及今天不同的开发者如何解释（和误解）这个想法。 ## 定义"vibe"：从 Karpathy 的意图到工程界的热议 > _Vibe coding 从来不是用来描述**所有** AI 辅助编码的——它是一种特定的风格，你甚至在运行之前都不阅读 AI 的代码_ Karpathy 发明这个词，本来更像是半开玩笑地描述一种**靠直觉和交互式反馈推进开发**的极端方式。然而术语一旦出圈，含义很快就被拉宽了。很多人开始把任何用了 AI 的编程都叫作 “vibe coding”，结果反而模糊了边界。像 Simon Willison 这样的资深开发者很快就指出，_“vibe coding 并不等于在 LLM 帮助下写代码”_。在负责任的 AI 辅助开发里，你当然可以用 GitHub Copilot、ChatGPT 等工具生成代码，_但你仍然要像平时一样审查、测试并集成这些结果_。而 Vibe Coding 在它最原始的定义里，恰恰是把这层严格性大幅后移了。 这种区别至关重要。Karpathy 打算用这个术语来描述一个**特定的**极端：开发者更像是一个提示给予者和 bug 测试者，而 AI 完成大部分编码工作，开发者不仔细阅读每一行。这几乎是自嘲的——一个专家编码者故意*不*使用他的技能，只是为了看看 AI 能走多远。但随着这个术语的流行，一些观察者错过了这个眨眼，将 _vibe coding_ 当作一种严肃的方法论来广泛应用。在在线讨论中，可以看到定义向两个方向延伸：**一个阵营庆祝 vibe coding** 作为一种令人兴奋的新人机协作范式**，另一个阵营谴责它**作为一种危险的草率实践，任何称职的工程师都不应该沉迷其中。 在光谱的一端，爱好者使用 _"vibe coding"_ 来轻松地表示**使用 AI 进行快速原型设计**——有点像即兴配对编程。他们强调这是关于高层指导和快速迭代，而不是完全放弃责任。例如，[一位](https://news.ycombinator.com/item?id=42913909#:~:text=It%E2%80%99s%20not%20about%20replacing%20solid,not%20handing%20over%20control%20entirely)开发者解释说： > _"vibe coding 更像是与 AI 配对编程，帮助你更快地前进，而不是完全交出控制权"_ 在这种解释里，_"vibe"_ 更像是一种与 AI 持续来回迭代的流动状态：你设定意图，AI 先给出一版实现，你再继续引导它。支持者强调，*并非*所有 AI 的使用都属于 vibe coding——如果你仍在认真集成、审查和测试 AI 生成的代码，你做的其实是 AI 辅助开发，而且完全可以很有纪律。真正意义上的 vibe coding，只是其中一个更激进的子集：**主要依赖 LLM 构建软件，且把代码审查明显后置**。如果你还在做健全性检查、补测试和守住验收标准，那其实已经不再是最原始定义下的“纯 vibe”流程了。 这种澄清很重要，因为这个术语立即变得**两极分化**。一些早期采用者自豪地宣称自己是 _vibe coders_，而许多经验丰富的工程师对听起来像是对软件工程原则的侮辱感到退缩。互联网就是互联网，出现了一些漫画。支持者有时过度炒作 vibe coding 作为一种革命性的新常态，而批评者有时误用这个术语来驳斥*任何* AI 使用都是不负责任的。随着时间的推移，出现了一个更加细致的共识，即 _vibe coding 指的是一种非常特定且有风险的 AI 驱动开发模式_——本质上是*"让 AI 驾驶"*，而人类只是轻推和观察。从谨慎使用 Copilot 到完全"我不再阅读代码"的吹嘘，所有这些细微的立场都在关于 vibe coding 的辩论中被混为一谈。在接下来的部分中，我们将理清这些立场，探索**话语的全景**：vibe coding 的吸引力、陷阱和失败，以及为什么它同时引发兴奋和恐惧。 ## 吸引力：为什么开发者拥抱 Vibe Coding > _"对于低风险项目和原型，为什么不让它运行呢？LLM 可以比熟练的人类快一个数量级地生成代码。"_ 速度和创造力，是 vibe coding 最吸引人的承诺。对 Karpathy 这样本身就有极强实现能力的人来说，AI 的价值不在“替他写代码”，而在于把试错速度拉到更高：样板代码生成更快，整段实现也能更早成形，于是他可以以前所未有的速度尝试新点子。很多黑客式开发者也正是被这一点吸引：如果风险很低，为什么不借助 AI 快速探索一轮，看看边界到底能推到哪里？ 确实，出现了许多成功故事和热情的推荐。一位 Hacker News 用户讲述了完全通过 vibe coding 构建令人惊讶有用的小工具，承认*"它能工作这一事实让我非常惊讶"*。另一位开发者受 Karpathy 例子的启发，描述了： > _"感觉就像在做艺术……以一种方式表达事物，然后以另一种方式，测试、丢弃更改，并以新的方式表达它们"_ ——一种几乎是创造性的人机协作流动状态。那种**流动**的感觉是一个很大的吸引力。支持者将其比作"进入状态"或与 AI 伙伴实现音乐般的节奏。你不会停下来检查每个分号；你在乘着创造性的浪潮，被看到程序实时演变的*感觉*所引导。这是通过*感觉*编码——当人类必须手动处理每个细节时，这是以前不可能的。 此外，vibe coding 暗示了**软件创建民主化**的未来。通过大幅降低生成可工作代码的门槛，它*"释放了想象力"*，让那些有想法但缺乏深厚编程专业知识的人。正如[一项分析](https://www.lycee.ai/blog/why-vibe-coding-is-overrated)所指出的，这可能会开启一个*"家庭烹饪软件"*的时代——由最终用户自己构建的高度个性化的应用和工具，因为 AI 助手使他们能够用简单的语言迭代他们的想法。想想一个在营销部门工作的人，他对一个网络应用有一个小众想法：使用 vibe coding 工具，他们实际上可能能够在不正式学习编程的情况下对其进行原型设计。爱好者将此称为*革命性的*。这并不是说软件工程突然变得微不足道，但有了 AI 副驾驶做繁重的工作，更多的人可以*参与*创建软件。_Vibe coding 将最初的障碍削减到几乎平坦_，正如一位评论者所观察到的——如果界面如此自然，潜在的数百万非编码者可以构建自己的自定义工具。其中一些新手反过来*"会被编程 bug 咬到，继续成为"*成熟的开发者，这意味着 vibe coding 甚至可能作为学习的入口，而不是专业知识的替代品。 即使是经验丰富的工程师，在明智地使用时，也会发现 vibe coding 风格的吸引力。它实现了一种**高速探索性编程**——类似于快速原型设计或黑客马拉松模式。你可以在周末通过简单地描述你的意图并让 AI 填补空白来组合一个概念。如果某些东西不起作用，你戳它，调整提示，或要求 AI 重构，而不是手动跟踪每一行。许多人注意到，这本质上是我们已经进行原型设计的方式的延伸（"写一个扔掉"）。*"有时你只需要一个坐的地方"*一位开发者在为快速而肮脏的构建辩护时打趣道，将 vibe coding 比作匆忙钉在一起的临时椅子——它可能很丑，但它现在给你一个坐的地方。另一个人指出： > _"vibe coding 只是探索性编程或良好的老式原型设计的新名称"_。 换句话说，黑客攻击某个东西的 0.1 版本——一种历史悠久的做法——通过这些 AI"共同开发者"变得更快、更容易访问。 **重要的是，许多**_**真正试过**_** Vibe Coding 的人都提到：这并不是“什么都不做”，而是一种新的交互技能。你得学会怎样描述意图、怎样在偏离时纠偏，以及什么时候必须介入。** 正如一位早期采用者[解释](https://news.ycombinator.com/item?id=42913909#:~:text=interface%20for%20my%20Raspberry%20Pi,a%20collaborator%2C%20not%20a%20crutch)的那样，关键是*“把 AI 当作协作者，而不是替代思考的工具”*。例如，一位名叫 Jon 的开发者写道，他使用 AI 智能体（DeepSeek + Cursor）为 Raspberry Pi 构建聊天机器人界面，前后仍然投入了一百多轮提示和修正，才得到满意结果。但这依旧比手动从头写完要快得多——AI 负责加速生成，他则负责测试、引导和取舍。这里的细微差别非常重要：Vibe Coding 可以*增强*经验丰富的开发者，让他们把时间更多放在高层方向上，而不是重复性实现上。对很多人来说，尝试这种工作方式本身也是一种学习过程：你会更快摸清今天的 AI 擅长什么、不擅长什么。 最后，我们有具体的**成功故事推动炒作**。也许最[被引用](https://www.lycee.ai/blog/why-vibe-coding-is-overrated#:~:text=Levelsio%20recently%20%E2%80%98vibe%2Dcoded%E2%80%99%20a%20whole%20game%20and%20made%20more%20than%2080%2C000%20USD%20in%20revenue%20in%20a%20matter%20of%20weeks.%20Sure%2C%20his%20large%20audience%20and%20influencer%20status%20may%20have%20played%20a%20role%2C%20but%20it%20was%20enough%20to%20excite%20even%20more%20wannabe%20vibe%2Dcoders.)的是一位独立黑客 _Levelsio_，据报道他"vibe-coded"了一整个游戏，并在几周内从中获得了超过 80,000 美元的收入。虽然他的大量追随者无疑帮助了销售，但一个独立创作者能够如此快速地通过 AI 帮助制作出一个有利可图的游戏，这一事实点燃了想象力。其他人展示了主要通过提示 AI 构建的大量项目。一位开发者分享了搜索查询 DSL 和用于构建 Unix 管道的 GUI 工具的链接——不是微不足道的玩具——声称*"所有这些基本上都是用 Karpathy 描述为 vibe coding 的相同工具和方法制作的"*。甚至有程序员使用 vibe coding 在系统语言中生成低级代码的案例。一位爱好者讲述了他如何让 AI（带有 Claude Sonnet 的 Cursor）用 C 编写新 DSL 的 95%，包括像 Lua 脚本和数据库查询这样的棘手集成——他只介入设置内存管理和架构，自己只输入了大约 5% 的代码。*"这是一个疯狂的心理空间"*他指出，但实验成功了。这样的轶事表明，在有能力的人手中，vibe coding 可以产生非平凡的、可工作的系统。它不仅限于调整 UI 或编写 CSS（一些人有的误解）；人们通过这种方法构建了整个网站和复杂的功能。 总之，vibe coding 的吸引力在于**速度、创造性流动和扩大访问**。它提供了一个世界的味道，在那里告诉计算机你想要什么更接近于对话，而不是费力地翻译成代码。对于许多开发者——尤其是那些从事副项目或实验性想法的人——这种味道是甜蜜的。"Vybe on"正如一位爱好者[写道](https://vybestack.dev/blog/rendered/2025-03-30-howto-vibe.html#:~:text=I%20had%20not%20coded%20too,do%20everything%20I%20dislike%20doing)，在赞扬它如何通过卸载所有乏味的部分重新点燃他对编码的热情之后。但正如我们接下来将看到的，这种自由和速度是有代价的。让 vibe coding 在当下感觉像*"魔法"*的东西可能会导致未来的噩梦。创新的硬币有另一面：**质量、安全和理解方面的权衡**。 最后，我们有具体的**成功故事推动炒作**。也许最[被引用](https://www.lycee.ai/blog/why-vibe-coding-is-overrated#:~:text=Levelsio%20recently%20%E2%80%98vibe%2Dcoded%E2%80%99%20a%20whole%20game%20and%20made%20more%20than%2080%2C000%20USD%20in%20revenue%20in%20a%20matter%20of%20weeks.%20Sure%2C%20his%20large%20audience%20and%20influencer%20status%20may%20have%20played%20a%20role%2C%20but%20it%20was%20enough%20to%20excite%20even%20more%20wannabe%20vibe%2Dcoders.)的是一位独立黑客 _Levelsio_，据报道他"vibe-coded"了一整个游戏，并在几周内从中获得了超过 80,000 美元的收入。虽然他的大量追随者无疑帮助了销售，但一个独立创作者能够如此快速地通过 AI 帮助制作出一个有利可图的游戏，这一事实点燃了想象力。其他人展示了主要通过提示 AI 构建的大量项目。一位开发者分享了搜索查询 DSL 和用于构建 Unix 管道的 GUI 工具的链接——不是微不足道的玩具——声称*"所有这些基本上都是用 Karpathy 描述为 vibe coding 的相同工具和方法制作的"*。甚至有程序员使用 vibe coding 在系统语言中生成低级代码的案例。一位爱好者讲述了他如何让 AI（带有 Claude Sonnet 的 Cursor）用 C 编写新 DSL 的 95%，包括像 Lua 脚本和数据库查询这样的棘手集成——他只介入设置内存管理和架构，自己只输入了大约 5% 的代码。*"这是一个疯狂的心理空间"*他指出，但实验成功了。这样的轶事表明，在有能力的人手中，vibe coding 可以产生非平凡的、可工作的系统。它不仅限于调整 UI 或编写 CSS（一些人有的误解）；人们通过这种方法构建了整个网站和复杂的功能。 总之，vibe coding 的吸引力在于**速度、创造性流动和扩大访问**。它提供了一个世界的味道，在那里告诉计算机你想要什么更接近于对话，而不是费力地翻译成代码。对于许多开发者——尤其是那些从事副项目或实验性想法的人——这种味道是甜蜜的。"Vybe on"正如一位爱好者[写道](https://vybestack.dev/blog/rendered/2025-03-30-howto-vibe.html#:~:text=I%20had%20not%20coded%20too,do%20everything%20I%20dislike%20doing)，在赞扬它如何通过卸载所有乏味的部分重新点燃他对编码的热情之后。但正如我们接下来将看到的，这种自由和速度是有代价的。让 vibe coding 在当下感觉像*"魔法"*的东西可能会导致未来的噩梦。创新的硬币有另一面：**质量、安全和理解方面的权衡**。 ## "它工作直到它不工作"：安全和可维护性问题 > _"疯狂地按'全部接受'按钮相当于用你的代码库玩俄罗斯轮盘赌。"_ 这个略带情绪的[警告](https://www.kushcreates.com/blogs/why-vibe-coding-makes-me-want-to-throw-up)，来自一位资深工程师对 Karpathy 那套做法的反应。vibe coding 的确令人兴奋，但对成熟团队来说，真正拉响警报的是它在**安全、代码质量和长期可维护性**上的风险：如果在生产环境里不经审查就接受 AI 生成的改动，后果通常不会太好。一位评论者毫不客气地说： > _"这种'vibe coding'废话相当于闭着眼睛开车，因为你的特斯拉开着自动驾驶。它工作得很好，直到你撞到树上，想知道为什么 AI 没有看到它的到来。"_ 换个没那么戏剧化的说法，真正让人担心的是：vibe coding 很容易诱导人把工程判断暂时放到一边。一旦离开“快乐路径”，问题就会集中暴露出来。 **安全**是最直接的担忧之一。现代应用遍布各种陷阱——从 SQL 注入、XSS 到认证授权漏洞——这些都需要明确约束、细致审查和充分测试才能挡住。即使模型再强，它也不会天然掌握你的业务安全边界；如果 prompt 和上下文没有把这些边界交代清楚，生成结果就可能写出*表面合理、实则危险*的实现。开发者已经在实践中见过很多类似例子：敏感 API 缺少身份验证、端点修改绕开授权检查、模板里埋入明显的 XSS 风险。没有人类审查，这些问题完全可能混进生产环境。真正需要警惕的，不是“AI 很笨”，而是**人在几次顺利体验后过度放松了验证动作**。 除了安全漏洞，还有更广泛的**代码健康和可维护性**问题。传统软件工程非常重视代码的可理解性——不仅仅是为了虚荣，而是为了能够修复 bug 并在未来集成新功能。Vibe coding 明确地不强调理解代码。Karpathy 的全部观点是忘记代码的存在，只关注应用的行为是否符合预期。这种方法对于快速实验可能*"有趣"*，但资深工程师发现将其作为一般实践是可怕的。*"代码增长超出了我通常的理解范围，我必须真正阅读一段时间"\_Karpathy 承认他的 vibe-coded 项目。对许多人来说，*这句话是一个巨大的红旗*。如果你不理解自己的代码库，你怎么可能信任它或维护它？*"当你不理解自己的代码库时，你不再是开发者。你只是一个从未学会编码的极其低效的人，只是在使用 AI"\_一位批评者尖刻地观察到。这可能听起来很苛刻，但重点是代码理解在真实软件项目中不是可选的。如果生产中出现问题或你需要扩展系统，必须有人知道它是如何工作的。一个 vibe-coded 代码库——一个从提示和 AI 建议中有机增长的代码库——最终可能像一个神秘的黑盒，即使对其创建者也是如此。在最好的情况下，这会减慢进一步的开发；在最坏的情况下，它无法修复，你必须扔掉它。 多位开发者提出了这种情况： > _vibe coding "工作直到它不工作，然后你有这个你负责的庞大代码库不工作，你不明白为什么或不知道它是否可以修复。"_。 想象一下对一堆你实际上没有编写（几乎无法阅读）的代码负责，这是工程噩梦的素材。想象一下，在现在正在使用的 vibe-coded 系统中出现了一个关键 bug——接下来怎么办？如果原作者将其视为一次性原型，他们甚至可能不在身边或没有耐心去破译它。如果它被交给一个团队，团队面临着陡峭的逆向工程工作。在专业环境中，这是不可接受的。这就是为什么许多经验丰富的声音断言 _vibe coding "在任何真正的编程环境中都行不通"_，在那里代码质量和问责制很重要。对于个人副项目来说很好，但试着告诉你的员工工程师你合并了你没有看过的代码——这是不可能的。 另一个风险向量是**隐藏的 bug 和技术债务**。Vibe coding 通常导致一种非常被动的开发风格：你提示一个功能，运行代码，看到错误，将错误反馈给 AI，得到修复，继续，如此循环。这种打地鼠的方法意味着你总是在处理眼前可见的问题，而不是主动设计正确性或健壮性。很容易想象有多少潜在的 bug 或糟糕的设计选择可能在表面下滚雪球。一位开发者将其比作在不知道*"承重墙"*在哪里的情况下建造——你可能会无意中做出结构上不健全的决定。 如果任务里没有明确要求长期维护性、性能约束和架构边界，这些维度就很容易被后置。随着时间推移，那些为了快速推进而做出的局部修补，可能慢慢累积成结构性混乱。事实上，早期的 vibe coder [报告](https://vybestack.dev/blog/rendered/2025-03-30-howto-vibe.html#:~:text=What%20Does%20Not%20Work)说，你迟早会撞上一道**生产力墙**：_“过了一会儿，我意识到很多炒作只是炒作，很多反感也是无稽之谈。\[但\]我很快发现了反模式。”_ 同一作者列出的反模式之一，就是期待 AI 自己维持长期一致的计划；另一个则是开发者本人没有先给出计划。换句话说，即使支持 Vibe Coding 的人也承认：如果你在没有设计约束的前提下直接开跑，最终常常还是要回头重构。 > _"一开始你似乎在取得进展，但由于你没有结构，你被出现的下一个错误或功能所吞噬……你在开始时'节省'的时间，你以后必须花费来重写代码以做你最初打算做的事情。"_ 实际上，你以闪电般的速度产生**技术债务**。如果没有仔细的结构，项目可能会退化成一个不连贯的拼凑，最终迫使重写——抹去最初的速度优势。 **也许最严厉的批评是 vibe coding 缺乏所有保持软件质量高的传统检查：设计审查、代码审查、测试、调试**。 这是在程序性恍惚中编码，希望结果是正确的。 > *"Vibe coding 垃圾零理解、没有调试、没有代码审查、没有安全、没有问责、没有真正的结构"*一位博主愤怒地说。 夸张归夸张，他指出的是正常的安全网不存在。如果 AI 引入了一个细微的 bug，而你从不编写单元测试或仔细阅读差异，你不会捕获它，直到运行时出现问题（如果有的话）。当你确实遇到 AI 无法立即修复的 bug 时，那怎么办？通常人类仍然必须卷起袖子调试——只是现在他们在调试他们没有完全编写的代码。在实践中，vibe coders 说你*必须*有时介入。"我绝对可以比机器更好地调试"一位经验丰富的开发者指出，描述他最终如何介入来解决 AI 出错的问题。AI 助手也可能陷入对 bug 的错误假设，为一行问题提出复杂的修复。人类调试器可以识别这一点并纠正路线，但前提是他们重新参与代码。这种振荡——从代码中脱离，然后深入调试——如果管理不善，可能会鞭打生产力，很容易想象经验不足的开发者完全迷失。 总之，vibe coding 的*"快速行动，打破东西"*精神可能会产生快速结果，但它**打破了软件工程的契约**，该契约要求**理解和警惕**。来自资深开发者的集体智慧可以简单地总结为：*如果你确实选择 vibe code，请以极度怀疑的态度对待输出。*在信任它之前审查代码。像测试手写的任何东西一样彻底地测试它。否则，你离一个未检查的缓冲区或逻辑错误只有一步之遥，可能导致安全事件或崩溃的系统，而你不知道如何修复。正如一位 Hacker News 评论者干巴巴地说： > *"老实说，这听起来像是通过随机钉未切割的木头，直到它勉强看起来像一把椅子并支撑你的体重来建造一把椅子。"*是的，你最终得到了一把"椅子"——但谁会在生产中坐在上面？ ## 原型工具还是生产责任？（个人项目 vs. 专业软件） > _"为了好玩而 vibe coding 一个原型很容易。开发一个具有身份验证、安全性、最佳实践的健壮软件解决方案……要困难得多，vibe coders 还做不到。"_ 这个[引用](https://www.lycee.ai/blog/why-vibe-coding-is-overrated#:~:text=Vibe%20coding%20a%20prototype%20for,Maybe%20they%20never%20will)捕捉了一个广泛共享的情绪：**vibe coding 可能对个人或一次性项目可以接受，但它还没有准备好在生产中黄金时段**。即使 Andrej Karpathy 也小心地将他的实验框定为他为周末项目做的事情，"没有人依赖它"。他含蓄地承认，这种方法（至少目前）在可靠性很重要时不合适。许多 vibe coding 的支持者也呼应这一点：这是*实现想法并验证它们*的好方法——在原型阶段对初创公司来说是"梦想"——但当你从演示到生产时，必须启动不同的态度。一位工程师评论说，他不介意下一个 TikTok 克隆是由 AI 生成的，*"但核电站的软件……或医疗设备呢？"*对于高风险或长期软件，无忧无虑的 vibe 方法是不可行的。 **个人工具 vs. 生产系统**之间的这种分裂一再出现。支持者经常试图通过说"放松，没有人建议将 vibe-coded 应用发送给付费客户或关键基础设施——这是为了学习和个人项目"来化解批评者。事实上，vibe coding 的当前使用很多是在私人实验、黑客马拉松演示或作者单独使用的小众工具中。HN 上的一位评论者指出，我们不应该*太*危言耸听：_"它不必是某人构建软件的唯一方式……vibe coding 可以是学习和探索的好方法。构建一个扔掉，正如他们所说。"_ 这里的想法是，使用 AI 快速组合一个版本 1 没有什么问题，完全期望你可能会*丢弃或重写*它，一旦你证明了这个想法。事实上，这符合 Fred Brooks 的经典建议（"计划扔掉一个"）。正如另一位工程师插话的那样，细微差别是 Brooks 的意思是你应该在第一次实现时尽力而为，然后如果需要愿意扔掉它——*而不是*你应该故意一开始就做一个半生不熟的工作。危险在于，如果有人将 vibe coding 视为甚至不尝试在版本 1 上进行合理工程的许可证，他们可能最终会*锚定*在一个糟糕的基础上，因为它"有点工作"，然后尝试修补它而不是正确地重建。这个人建议，健康的方法可能恰恰相反：*首先*自己做一个诚实的实现（这样你就能深入理解问题），*然后*也许让 AI 试一试并比较，这样你就能判断输出。这样，你就可以利用 AI 而不会从一开始就完全依赖它可能有缺陷的方法。 在公司和团队中，vibe coding 提出了实际的工作流程问题。**vibe-coded 原型可以交给团队进行生产化吗**？可能可以，但如果团队必须费力地审计和重构它，可能会抵消最初的速度优势。一些人预见这将成为一种新的交接，类似于数据科学家在 Jupyter 中原型化某些东西，然后工程师正确地重写它。然而，担忧是，如果管理层只看到闪亮的原型工作，他们可能会低估使其达到生产质量所需的努力——导致部署不安全的东西的压力。已经有愤世嫉俗的看法，认为技术领导层或投资者正在炒作 AI 开发，作为削减工程成本或跳过步骤的一种方式。*"是的，vibe coding 是伟大的 LLM 营销活动的一部分"*一位开发者[干巴巴地评论](https://news.ycombinator.com/item?id=43393100#:~:text=WuxiFingerHold%20%20%2017%20,%E2%80%93)，对一些大胆的声明表示怀疑。 例如，在 Y Combinator 批次中，一些初创公司[声称](https://news.ycombinator.com/item?id=43448432#:~:text=I%20think%20the%20bigger%20,or%20even%20100x)从 AI 编码中获得了惊人的 10 倍到 100 倍的生产力提升。经验丰富的观察者称这些是可疑的：100 倍的加速意味着将过去需要整个团队一个月的时间压缩到一天，这在现实中显然没有发生。即使是整个组织的 10 倍也会是明显的——"非常明显"——对任何外部观察者来说，但事实并非如此。这些声明可能会诱使技术含量较低的利益相关者推动工程师采用不负责任的工作流程，如未经检查的 vibe coding，希望获得奇迹般的生产力提升。因此，出现了一个明智的指导方针：使用 vibe coding 进行**探索和原型**，但当涉及到生产时，应用通常的严格性。或者正如一篇博客总结的： > _'Vibe Coding'可能会让你达到一个功能概念的 80%。但要生产可靠、安全且值得花钱的东西，你需要经验丰富的人类来做今天的模型做不到的艰苦工作。"_ 换句话说，最后的 20%——通常是 80% 的努力——仍然需要传统工程。我在[70% 问题](https://addyo.substack.com/p/the-70-problem-hard-truths-about)中写过这个。 有趣的是，一些开发者警告说，原型和生产之间的界限可能会迅速模糊，有时会损害质量。一个"大部分工作"的个人项目可以获得用户或重要性，突然你有一个从未考虑长期性的准生产系统。 一位 HN 用户[沉思](https://news.ycombinator.com/item?id=43536002#:~:text=sanity%20check%20the%20output)说，人们通过说它不是为生产而设计的来为 vibe coding 辩护，*"但让我们不要天真，因为它 100% 会被用来推送实际应用。"*一旦工具存在，有人最终会在其安全区域之外使用它。事实上，我们已经看到早期实例：独立黑客向客户销售 vibe-coded 应用，或内部工具 vibe 组装然后由团队使用。 **团队真正的挑战**，是如何把 AI 驱动的开发以负责任的方式纳入流程。一个合理模式也许是：在 spike 或原型阶段允许更多 vibe coding，但在任何东西准备上线前，都必须走完整的代码审查和测试周期。这样既能保留一部分速度优势，也能拦住最严重的问题。工具厂商也在补这条鸿沟——比如 AI 生成代码的*沙盒执行*、自动化测试生成，以及更强的权限隔离。行业正在摸索的，正是如何同时拿到两边的好处：Vibe Coding 的创造力和速度，以及传统工程流程的安全性与健壮性。 目前，共识是[保守的](https://cendyne.dev/posts/2025-03-19-vibe-coding-vs-reality.html#:~:text=Agents%20do%20enable%20skilled%20people,their%20own%20inferior%20skill%20set)： > _“在 AI 智能体继续进步之前，单靠极端的 vibe coding 工作流，还不足以稳定产出生产级软件。”_ 这类批评想强调的是：今天的 vibe coding 更适合*原型软件*——实验、个人脚本、一次性应用。把它直接等同于软件工程的未来终局，或者据此推断“严肃系统以后都能这样发布”，显然言过其实。更稳妥的结论是：*可以用 vibes 做原型，但进入生产依然需要纪律。*Vibe Coding 可以提高生产力，但不应该替代对系统的基本理解。 ## 对开发者和团队的影响：我们现在都是产品经理了吗？ > _"几乎没有什么东西再被晦涩的知识所守门了……如果你不喜欢它，就不要使用它；它不适合所有人。这不是那些像机器一样编码的人的替代品——继续做让你与众不同的事情！"_ 这个热情洋溢的声明捕捉了 vibe coding 如何改变开发者的自我形象和角色。对一些人来说，这是赋权的——突然他们可以自己做更多事情，而不需要记住 API 细节或成为每个框架的向导。对其他人来说，这是威胁性的——它暗示了一个未来，许多传统编码技能可能被绕过或贬值。让我们解开 vibe coding 的**经济和职业影响**，以及团队如何围绕这些 AI"共同开发者"重组。 一个直接的观察：vibe coding 将程序员的日常工作更多地转向**指定要构建什么**而不是制作实现。这导致了诸如*"我们现在都是产品经理"*之类的俏皮话。开发者不是花时间深入思考算法或调试指针问题，而是花大量时间描述所需的功能、测试应用，并决定什么*感觉*对或错——可以说是与产品设计和 QA 重叠的任务，而不是经典的软件工程。一些人庆祝这种转变，认为它让开发者专注于更高层的问题解决和用户需求，而不是样板代码。其他人担心它会*降低*专业技能。如果走向极端，未来的初级开发者可能不会学习如何编写排序函数或优化查询；他们可能只是提示 AI"让这个更快"并信任它。随着时间的推移，这会侵蚀人类专业知识的池子吗？ 一些经验丰富的声音表达了对**技能萎缩**的担忧。 > _"我担心的是，如果我开始这样做，我会停止参与构建某些东西的困难方面。我认为我现在拥有的技能会萎缩"_ 一位资深开发者坦白。这呼应了一个更广泛的焦虑：过度依赖 AI 辅助可能会使下一代程序员不太能够独立解决难题。如果你只是"vibe out"小项目，从不经历基础学习时刻（调试棘手的 bug、理解算法复杂性等），你可能不会发展出处理这些情况所需的深厚专业知识，当它们不可避免地出现时。另一位评论者[想知道](https://news.ycombinator.com/item?id=43393100#:~:text=I%20certainly%20don%27t%20hate%20vibe,your%20thinking%20as%20an%20engineer)： > _如果你从每周排查问题 5 次变成每几周一次，因为 AI 修复了大多数问题，会发生什么？这会随着时间的推移削弱你的问题解决能力吗？_ 这些都是开放的问题。未来的开发者可能只是拥有不同的技能档案——也许更像管弦乐队指挥或 QA 工程师与产品思考者的结合。但过渡期是尴尬的：今天的工程师重视通过动手编码磨练的技能，而 vibe coding 似乎短路了这个训练过程。我们可能需要有意识地调整我们在 AI 普及环境中指导新工程师的方式，确保他们仍然接触到"困难的东西"，而不仅仅是乘坐 AI 自动驾驶。 另一方面，vibe coding 可以**向更多人开放这个领域**，这具有劳动力市场影响。如果确实"数百万新人"可以用更少的培训创建软件，编码周围的排他性光环可能会消退。一些经验丰富的开发者对此做出了防御性反应。他们以编程作为*"智力精确的艺术"*而自豪，并对像"vibe coding"这样的术语感到不满，这些术语让它听起来像是一个随意的即兴会议。一位评论者说，这个术语本身*"与编程对我来说意味着的一切背道而驰"*，因为它淡化了严格性。 有一丝文化冲突的暗示：细致的工匠 vs. 快速而松散的 AI 驯服者。如果后一种方法获得突出地位，工匠会感到被贬值吗？可能。HN 上一个特别尖锐的评论是：*"看到一些'工程师'在这里伤害了他们的自尊和感情，这很有趣。事实证明，软件工程不会再是最性感的工作之一……傲慢正在实时爆发。"*这表明一些开发者将 vibe coding 视为一个均衡器——对那些在科技繁荣中感到不可或缺的人来说是一种谦卑的力量。当任何人都可以生成一个基本应用时，也许成为程序员不会像 2010 年代那样赋予那么多地位。 **然而，在宣布编码职业"完蛋"之前，值得注意的是，经验丰富的工程师仍然具有 vibe coding 无法取代的独特价值。正如我们所看到的，复杂、可靠的系统仍然需要这种专业知识**。 一个[类比](https://news.ycombinator.com/item?id=42913909#:~:text=The%20industrial%20revolution,magnitudes%20fewer%20workers.)是*工业革命*： > _"仍然有人制造定制的高质量物品……但大多数过去在车间制造的东西现在在工厂生产，工人数量减少了几个数量级。"_ 换成软件行业的语言，常规 CRUD 应用或简单网站，未来确实可能更像被 AI “工厂化生产”，所需的人类开发者数量也可能下降；但定制系统、复杂系统，以及新问题密集的系统，仍然需要成熟工程师来把关。这也引出了一个现实问题：团队形态会不会变化？答案大概率是会。我们可能会看到更强调 AI 编排、结果审计和质量把关的新角色，而不是简单沿用过去的分工方式。 在 Ask HN“你在 vibe coding 吗？”的讨论里，也有人把这种协作理解成一种新的工作分工：AI 负责高速生成与执行，人类负责判断、约束和整合。这个说法虽然带点调侃，但有一部分是成立的——当 AI 接手越来越多实现工作后，开发者的价值会更集中在方向判断、边界设定、结果审查和系统整合上。未来出现更多围绕 AI 编排和审查的新岗位，并不奇怪。 **对于个人职业，还有一个经济角度：那些早期拥抱这些工具的人可能会变得显著更有生产力（至少对于某些任务），可能获得更高的薪酬或超越同行**。 相反，那些完全否定 AI 的人可能会发现自己效率较低或落后，如果行业朝这个方向发展的话。这让人想起以前的范式转变——例如，拥抱高级语言的开发者 vs. 坚持汇编的开发者，或者学习自动化的开发者 vs. 手动做所有事情的开发者。但这很棘手，因为将 vibe coding 推向极端在生产中是不可取的，所以必须找到正确的平衡。对开发者来说，最安全的赌注是*学会负责任地使用 AI 工具*。正如一篇[文章](https://cendyne.dev/posts/2025-03-19-vibe-coding-vs-reality.html#:~:text=Agents%20do%20demonstrate%20enough%20capability,agentic%20AI)所说：AI 编码助手 > _"使熟练的人能够比以往任何时候都更独立地创造。\[但\]它不会取代那些能够解决只有经验和直觉才能识别的难题的人。"_ 因此，结合经验**和** AI 熟练度的开发者将处于最佳位置。他们可以利用 AI 在简单部分上的速度，并将自己的技能应用于困难部分。相比之下，只知道如何提示 AI 而没有基础理解的人可能会遇到职业天花板——当 AI 输出不完美时（这经常发生），他们会挣扎。 在团队内部，我们也可能看到**协作动态**发生变化。**如果单个开发者借助 AI 就能把整个功能的原型先跑出来，会不会减少跨职能协作的频率？**例如，有 AI 加持的前端工程师，也许能独立完成过去需要后端协助的一部分工作。这会模糊一些旧的角色边界，同时也可能催生新的分工：有人更偏向 AI 编排，有人更偏向架构一致性和质量守门。 文档和知识共享也变得有趣——如果一半的代码是由 AI 编写的，你如何记录某些实现背后的理由？一些人建议维护一个*"项目日志"*或让 AI 生成运行的变更日志是有用的，这样人类以后可以理解做了什么。所有这些考虑都暗示团队流程将适应。例如，代码审查可能明确包括识别 AI 编写的部分并仔细检查它们是否存在已知的 AI 失败模式（如不安全的默认值或低效的循环）的步骤。教育和入职可能涉及教新人如何有效地与 AI 共同编码（以及如何仔细检查 AI 工作）。 从经济上讲，如果 vibe coding 和 AI 开发广泛地确实使生产软件更便宜，我们可能会看到总体上创建更多的软件（扩大蛋糕，而不仅仅是减少开发者工作）。这与"个人软件"愿景相关：更多的小众应用将值得制作，因为成本更低。公司可能开始期望工程师在 AI 帮助下同时处理多个领域（也许一个人用 AI 构建整个小产品——从前到后——而以前你会雇用单独的专家）。这可能会使超级明星通才开发者更有价值，但也可能意味着每个项目需要的总人数更少。 **总之，vibe coding 正在催化对**_**成为开发者意味着什么**_**的重新审视。我们是从工匠转变为 AI 输出的策展人和指挥者吗？如果是这样，我们如何确保下一代仍然学习基础知识**？ 可能的结果是软件工程将分叉：常规应用开发可能会变得更加自动化（由相对技能较低的操作员监督 AI——"公民开发者"概念的演变），而尖端和关键系统仍然掌握在高技能工程师手中，他们现在将 AI 工具作为力量倍增器。 AI 远远谈不上“杀死程序员”，它更可能让优秀工程师变得更加不可替代，即使某些重复性实现工作会减少。软件生态的长期健康，取决于能否把两边的优势结合起来：人类的专业判断，以及 AI 的执行效率。这要求开发者不仅调整技能栈，也调整心态——知道什么时候可以快速探索，什么时候必须回到严格检查。 ## 结论：在 Vibes 和严格性之间取得平衡 Vibe Coding 的兴起引发了兴奋、反弹和认真讨论——但最终，它强调的仍然是那个老原则：**工具会变，软件工程的底层约束不会消失**。 大型语言模型确实给了我们一种全新的软件构建方式：你可以通过自然语言提示快速迭代，把过去几天的工作压缩到几小时里，甚至让非开发者也能拼出简单应用。这种变化是真实的，而且不会消失。Vibe Coding 作为这条光谱中更极端的一端，展示了当前能力边界能被推到哪里——既有惊人的提速，也有明显的失控风险。 从我们的探索中得出的关键要点是**细微差别**。 **Vibe coding 既不是我们所知的编程的终结，也不是懒惰黑客的无意义流行语。它是一个具有特定优势和劣势的工具和技术。在正确的环境中使用——黑客马拉松项目、原型、个人脚本——它可以显著减少摩擦并打开创造性的大门**。 在错误的环境中鲁莽使用——安全敏感的生产系统、有多个协作者的团队项目——它可能会招致灾难。经验丰富的工程师已经正确地为炒作踩了刹车：*"不要相信那些大胆声称软件工程正在消亡"*的人，因为 vibe coding。构建健壮、可维护、复杂的软件仍然需要仔细的思考、协作和专业知识。AI 可以协助这些任务，但它不能取代背后的人类判断，至少在今天的模型中不能。 那么我们从这里走向何方？讨论建议朝着**两全其美的方法**前进。我们不应该完全抛弃 vibe coding；相反，我们应该驯化它。这意味着建立模式和工具，使其更安全、更有效。 例如，采用*"安全 vibe coding"*实践，如沙盒执行 AI 编写的代码，让 AI 在编写代码时生成测试和文档，并设置明确的界限（例如，始终审查关键部分的代码，始终强制版本控制等）。一些努力，如 Anthropic 的 Claude"Artifacts"或 Gemini 的"Canvas"环境，已经展示了沙盒如何允许人们 vibe code 而不会冒险损害实际系统。同样，IDE 开始以更受控的方式集成 AI——例如，让 AI 建议多文件重构，但将其作为 Git diff 暂存供你检查，而不是盲目应用它。随着这些工具的成熟，vibe coding 的工作流程可能会变得更加**交互式和透明**，解决许多当前的抱怨。 教育也将适应。就像我们教新程序员使用调试器或版本控制一样，我们可能会教他们如何有效地与 AI 编码助手协作。其中一部分将是灌输不放弃*理解*的重要性。 **一个恰当的座右铭可能是**：_**"使用 AI 更快地编码，但永远不要外包你的理解。"**_ 当你接受一段自己并不理解的代码时，债务就已经产生了。优秀工程师往往会在后续阶段把这笔债务补回来，比如在合并前补足审查、测试和结构整理；而糟糕的做法，是让这笔债一路滚到团队未来的维护成本上。这个问题并不新鲜——过去复制粘贴 Stack Overflow 代码而不理解的人，也会遇到同样的后果。AI 只是把这件事放大了。社区逐渐形成的共识其实很朴素：**看 diff、补测试、守住设计、理解每个关键决定。** 另一个可能的结果是**专业化**。我们可能会看到某些领域，vibe coding（或大量 AI 生成）成为常态，而其他领域则仍然很少见。前端 UI 调整、小型实用程序脚本、内部工具——这些可能会倾向于类似 vibe 的工作流程，因为风险低，迭代速度至关重要。另一方面，库开发、核心算法、安全关键代码——这些可能仍然主要是手写的或至少是手工审计的，因为对错误的容忍度为零。 随着时间的推移，随着 AI 的改进，边界会转移，但开发者会随之转移，总是划分出什么需要人类仔细关注，什么可以自动化。讨论经常重复：*[概念的 70%，但最后 30% 需要人类](https://addyo.substack.com/p/beyond-the-70-maximizing-the-human)。*随着 AI 在常规事务上变得更好，这可能会逐渐变成 90/10 或 95/5。但最后一片——困难的部分——可能永远不会完全消失。相反，人类将攀登到更高的抽象层次，处理新的难题，而 AI 处理下面更多的苦力工作。这一直是编程自诞生以来的故事，vibe coding 是这个不断演变的抽象故事中的又一章。 **最后，vibe coding 一直是讨论我们在软件开发中重视什么的催化剂。它迫使我们问：如果 AI 可以比我们更快地生成代码，我们的角色是什么？许多人给出的答案令人鼓舞：我们的角色是提供愿景、洞察力和深刻的理解**。 我们设定意图并确保结果真正满足意图。我们做出需要上下文和远见的艰难决定和权衡。我们还将道德、责任和对用户的同理心注入过程——这些都是目前没有 AI 拥有的东西。Vibe coding 并没有消除对人类的需求；它转移了它。正如一位评论者雄辩地说： > _"看待这个问题的另一种方式是，很多人通过放弃一些（不是全部）低级控制并专注于更高层，可以获得很多好处。"_。 那种"放手"可能是可怕的——感觉像是失去了我们工艺的一部分——但如果明智地做，它也可以是赋权的，让我们能够解决更大的问题。 "Vibe coding"这个术语本身可能会随着围绕它的实践成熟而消失。但核心思想——使用 AI 作为积极的开发伙伴——无疑将变得司空见惯。软件社区的挑战和机遇是以一种*增强*我们能力而不侵蚀我们工作质量和完整性的方式整合这个伙伴。 与任何强大的新工具一样，会有那些滥用它的人和那些掌握它的人。希望通过公开讨论成功和失败（正如我们在本文中所做的那样），我们集体变得更聪明。也许最终的 vibe 是和谐的：人类和 AI 一起工作，每个人都弥补对方的弱点，比以往任何时候都更快更好地构建软件。 走到那一步需要实验，也需要纪律；可以保留一点“凭手感探索”的空间，但前提始终是睁大眼睛，随时准备在 AI 偏离轨道时接管方向盘。 **最终**，vibe 应该服务于代码，而不是反过来。只要守住这个前提，Vibe Coding 就能成为有效的方法，而不是把团队带向失控。 --- **相关阅读**： - [70% 问题：关于 AI 辅助编码的严峻真相](https://addyo.substack.com/p/the-70-problem-hard-truths-about) - [超越 70%：最大化人机协作](https://addyo.substack.com/p/beyond-the-70-maximizing-the-human)