Vibe Coding：革命还是鲁莽放纵？
摘要
解码 vibe coding：炒作、希望与开发者的严峻真相
核心要点：虽然 AI 快速加速了代码创建（例如"vibe coding"），但它危险地降低了引入细微 bug、安全漏洞和不可维护复杂性的门槛。行业需要的不仅仅是拥抱速度，而是需要开发者充当专家策展人和批判性验证者，强化良好的设计、代码审查、安全测试和系统理解，以确保 AI 为健壮、可靠的软件做出贡献。对于初学者进行 vibe coding，也需要更好的风险教育。你必须让 AI 生成符合你标准的代码。"Vibe coding"不是低质量工作的借口。
如果你更喜欢听的话，这篇文章也有 NotebookLM 播客版本 😃
"Vibe Coding"的起源
"屈服于感觉，拥抱指数级增长，忘记代码的存在。"
2025 年初，Andrej Karpathy 用这些话向世界介绍了 vibe coding，一种编写软件的挑衅性新方法。Karpathy——OpenAI 的联合创始人和特斯拉前 AI 总监——在一篇半开玩笑的帖子中创造了这个术语。他描述了一种超现实的编码体验：使用一个如此先进的 AI 配对程序员，他可以通过语音识别与它交谈，并简单地通过"感觉"来完成一个项目。
他会要求"最愚蠢的事情"，比如 UI 调整，而不是手动挖掘代码，总是在不审查差异的情况下点击 AI 建议的"全部接受"，每当出现错误时，只需将它们粘贴回 AI 以获得修复。代码库以超出他正常理解的方式增长，但通过迭代地戳和探索（有时甚至要求随机更改直到 bug 消失），他可以得到一个可工作的应用程序。正如 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"标签贴在编程中任何使用 AI 的地方，稀释了它的含义。像 Simon Willison 这样的资深开发者迅速指出，"vibe coding 与在 LLM 的帮助下编写代码不是一回事"。在负责任的 AI 辅助编程中，你可能会使用 GitHub Copilot 或 ChatGPT 等工具来生成代码，但你仍然会批判性地审查、测试和集成该代码，作为正常开发工作流程的一部分。Vibe coding，在其原始意义上，放弃了大部分严格性——它意味着一种对 AI 输出的盲目信任，一种"忘记代码存在"并继续前进的决定。
这种区别至关重要。Karpathy 打算用这个术语来描述一个特定的极端：开发者更像是一个提示给予者和 bug 测试者，而 AI 完成大部分编码工作，开发者不仔细阅读每一行。这几乎是自嘲的——一个专家编码者故意不使用他的技能，只是为了看看 AI 能走多远。但随着这个术语的流行，一些观察者错过了这个眨眼，将 vibe coding 当作一种严肃的方法论来广泛应用。在在线讨论中，可以看到定义向两个方向延伸：一个阵营庆祝 vibe coding 作为一种令人兴奋的新人机协作范式**，另一个阵营谴责它**作为一种危险的草率实践，任何称职的工程师都不应该沉迷其中。
在光谱的一端，爱好者使用 "vibe coding" 来轻松地表示使用 AI 进行快速原型设计——有点像即兴配对编程。他们强调这是关于高层次指导和快速迭代，而不是完全放弃责任。例如，一位开发者解释说：
"vibe coding 更像是与 AI 配对编程，帮助你更快地前进，而不是完全交出控制权"
在这种解释中，"vibe" 只是与 AI 迭代的流动状态：你设定意图，AI 编写一些代码，你引导它，几乎像一次对话。支持者强调，并非所有 AI 的使用都属于 vibe coding——如果你正在深思熟虑地集成 AI 生成的代码，你只是在进行 AI 辅助编程，这可以是非常有纪律的。真正的 vibe coding 是其中的一个子集：专门使用 LLM 构建软件而不审查它编写的代码。正如一位评论者简洁地说，"vibe coding"基本上是*"通过 AI 模型生成代码，甚至不理解它"*——一种以最少的前期规划和最少的代码理解为特征的工作流程。如果你仍在进行健全性检查输出或编写测试，你就没有完全按照原始意义"vibing"。
这种澄清很重要，因为这个术语立即变得两极分化。一些早期采用者自豪地宣称自己是 vibe coders，而许多经验丰富的工程师对听起来像是对软件工程原则的侮辱感到退缩。互联网就是互联网，出现了一些漫画。支持者有时过度炒作 vibe coding 作为一种革命性的新常态，而批评者有时误用这个术语来驳斥任何 AI 使用都是不负责任的。随着时间的推移，出现了一个更加细致的共识，即 vibe coding 指的是一种非常特定且有风险的 AI 驱动开发模式——本质上是*"让 AI 驾驶"*，而人类只是轻推和观察。从谨慎使用 Copilot 到完全"我不再阅读代码"的吹嘘，所有这些细微的立场都在关于 vibe coding 的辩论中被混为一谈。在接下来的部分中，我们将理清这些立场，探索话语的全景：vibe coding 的吸引力、陷阱和失败，以及为什么它同时引发兴奋和恐惧。
吸引力：为什么开发者拥抱 Vibe Coding
"对于低风险项目和原型，为什么不让它运行呢？LLM 可以比熟练的人类快一个数量级地生成代码。"
速度和创造力——这些是 vibe coding 让开发者兴奋的核心承诺。Andrej Karpathy 自己对他新发现的技术的立场在其背景下明显是乐观的。作为专家，他不需要 AI 帮助，但他发现它有趣且解放。AI 可以比他打字更快地生成样板代码，甚至建议整个实现。这意味着他可以以前所未有的速度尝试"疯狂的新想法"。许多黑客认识到了这种潜力：vibe coding 感觉就像拥有一个永不睡觉的超级充电初级开发者。如果风险很低，为什么不沉迷于一点快速的、AI 驱动的黑客攻击，看看什么是可能的呢？
确实，出现了许多成功故事和热情的推荐。一位 Hacker News 用户讲述了完全通过 vibe coding 构建令人惊讶有用的小工具，承认*"它能工作这一事实让我非常惊讶"*。另一位开发者受 Karpathy 例子的启发，描述了：
"感觉就像在做艺术……以一种方式表达事物，然后以另一种方式，测试、丢弃更改，并以新的方式表达它们"
——一种几乎是创造性的人机协作流动状态。那种流动的感觉是一个很大的吸引力。支持者将其比作"进入状态"或与 AI 伙伴实现音乐般的节奏。你不会停下来检查每个分号；你在乘着创造性的浪潮，被看到程序实时演变的感觉所引导。这是通过感觉编码——当人类必须手动处理每个细节时，这是以前不可能的。
此外，vibe coding 暗示了软件创建民主化的未来。通过大幅降低生成可工作代码的门槛，它*"释放了想象力"，让那些有想法但缺乏深厚编程专业知识的人。正如一项分析所指出的，这可能会开启一个"家庭烹饪软件"的时代——由最终用户自己构建的高度个性化的应用程序和工具，因为 AI 助手使他们能够用简单的语言迭代他们的想法。想想一个在营销部门工作的人，他对一个网络应用程序有一个小众想法：使用 vibe coding 工具，他们实际上可能能够在不正式学习编程的情况下对其进行原型设计。爱好者将此称为革命性的*。这并不是说软件工程突然变得微不足道，但有了 AI 副驾驶做繁重的工作，更多的人可以参与创建软件。Vibe coding 将最初的障碍削减到几乎平坦，正如一位评论者所观察到的——如果界面如此自然，潜在的数百万非编码者可以构建自己的自定义工具。其中一些新手反过来*"会被编程 bug 咬到，继续成为"*成熟的开发者，这意味着 vibe coding 甚至可能作为学习的入口，而不是专业知识的替代品。
即使是经验丰富的工程师，在明智地使用时，也会发现 vibe coding 风格的吸引力。它实现了一种高速探索性编程——类似于快速原型设计或黑客马拉松模式。你可以在周末通过简单地描述你的意图并让 AI 填补空白来组合一个概念。如果某些东西不起作用，你戳它，调整提示，或要求 AI 重构，而不是手动跟踪每一行。许多人注意到，这本质上是我们已经进行原型设计的方式的延伸（"写一个扔掉"）。*"有时你只需要一个坐的地方"*一位开发者在为快速而肮脏的构建辩护时打趣道，将 vibe coding 比作匆忙钉在一起的临时椅子——它可能很丑，但它现在给你一个坐的地方。另一个人指出：
"vibe coding 只是探索性编程或良好的老式原型设计的新名称"。
换句话说，黑客攻击某个东西的 0.1 版本——一种历史悠久的做法——通过这些 AI"共同开发者"变得更快、更容易访问。
重要的是，许多实际尝试过 vibe coding 的人报告说，这不是关于魔法或什么都不做；这是一种自己的交互技能。你必须学习如何与 AI 交谈，当它偏离时如何引导它，以及何时介入。
正如一位早期采用者解释的那样，关键是*"将 AI 视为协作者，而不是拐杖"。例如，一位名叫 Jon 的开发者写道，他使用 AI 代理（DeepSeek + Cursor）为 Raspberry Pi 构建聊天机器人界面。他仍然花了 100 多个仔细的提示和改进才得到满意的结果。但这比手动编码所有内容要快得多——AI 通过生成大量代码来增强他的生产力，然后他测试和引导这些代码。这说明了一个重要的细微差别：vibe coding 可以增强*经验丰富的开发者，通过处理常规部分帮助他们更快地编码，而开发者专注于高层次的方向。事实上，一些人认为尝试这种风格是经验丰富的开发者培养对当今 AI 能做什么和不能做什么的直觉的最佳方式之一。这是一次学习经历：通过在项目中将 LLM 推向极限，你可以快速看到它的失败模式和能力，可以说成为一个更好的工程师。当它起作用时，它令人振奋。
最后，我们有具体的成功故事推动炒作。也许最被引用的是一位独立黑客 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"正如一位爱好者写道，在赞扬它如何通过卸载所有乏味的部分重新点燃他对编码的热情之后。但正如我们接下来将看到的，这种自由和速度是有代价的。让 vibe coding 在当下感觉像*"魔法"*的东西可能会导致未来的噩梦。创新的硬币有另一面：质量、安全和理解方面的权衡。
最后，我们有具体的成功故事推动炒作。也许最被引用的是一位独立黑客 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"正如一位爱好者写道，在赞扬它如何通过卸载所有乏味的部分重新点燃他对编码的热情之后。但正如我们接下来将看到的，这种自由和速度是有代价的。让 vibe coding 在当下感觉像*"魔法"*的东西可能会导致未来的噩梦。创新的硬币有另一面：质量、安全和理解方面的权衡。
"它工作直到它不工作"：安全和可维护性问题
"疯狂地按'全部接受'按钮相当于用你的代码库玩俄罗斯轮盘赌。"
这个丰富多彩的警告来自一位资深工程师对 Karpathy 的 vibe coding 方法的反应。尽管它令人兴奋，但 vibe coding 为经验丰富的开发者触发了严重的警报，尤其是在安全、代码质量和长期可维护性方面。在任何生产环境中，盲目接受 AI 生成的代码更改而不审查的场景都是一场噩梦。一位评论者毫不客气地说：
"这种'vibe coding'废话相当于闭着眼睛开车，因为你的特斯拉开着自动驾驶。它工作得很好，直到你撞到树上，想知道为什么 AI 没有看到它的到来。"
用不那么生动的术语来说，担忧是 vibe coding 鼓励完全暂停工程判断。而这不可避免地会在"快乐路径"结束时导致灾难。
安全是最直接的担忧之一。现代应用程序有无数的陷阱——从 SQL 注入和 XSS 到身份验证 bug——需要仔细的代码审查和测试才能捕获。无论多么先进，AI 都（还）没有对你的应用程序的安全模型或业务逻辑的内在理解。它会愉快地编写看起来合理但可能引入细微漏洞的代码。开发者已经在实践中观察到了这一点。一位工程师讲述说，在他使用 AI 编码助手的广泛经验中，"提示安全远远不够"——如果你 vibe code 一个网络应用程序并在不仔细阅读 AI 写的内容的情况下部署它，你就是在招惹危险。他提供了具体的例子：AI 添加了没有身份验证要求的敏感 API 端点，以绕过授权检查的方式修改了现有端点，并生成了带有明显 XSS 漏洞的 HTML 模板。这些中的每一个在生产中都将是一个严重的缺陷。如果没有人类在循环中进行代码审查，这些问题会在不被注意的情况下溜走，因为 AI 并不真正"理解"安全上下文——它只是反刍模式。"过度信任 LLM"被列为 vibe coding 中的顶级反模式；即使是谨慎的开发者也可能被几个好的输出所迷惑，陷入虚假的安全感，只是在稍后的代码审查中遇到令人讨厌的惊喜。
除了安全漏洞，还有更广泛的代码健康和可维护性问题。传统软件工程非常重视代码的可理解性——不仅仅是为了虚荣，而是为了能够修复 bug 并在未来集成新功能。Vibe coding 明确地不强调理解代码。Karpathy 的全部观点是忘记代码的存在，只关注应用程序的行为是否符合预期。这种方法对于快速实验可能*"有趣"，但资深工程师发现将其作为一般实践是可怕的。"代码增长超出了我通常的理解范围，我必须真正阅读一段时间"_Karpathy 承认他的 vibe-coded 项目。对许多人来说，这句话是一个巨大的红旗。如果你不理解自己的代码库，你怎么可能信任它或维护它？*"当你不理解自己的代码库时，你不再是开发者。你只是一个从未学会编码的极其低效的人，只是在使用 AI"_一位批评者尖刻地观察到。这可能听起来很苛刻，但重点是代码理解在真实软件项目中不是可选的。如果生产中出现问题或你需要扩展系统，必须有人知道它是如何工作的。一个 vibe-coded 代码库——一个从提示和 AI 建议中有机增长的代码库——最终可能像一个神秘的黑盒，即使对其创建者也是如此。在最好的情况下，这会减慢进一步的开发；在最坏的情况下，它无法修复，你必须扔掉它。
多位开发者提出了这种情况：
vibe coding "工作直到它不工作，然后你有这个你负责的庞大代码库不工作，你不明白为什么或不知道它是否可以修复。"。
想象一下对一堆你实际上没有编写（几乎无法阅读）的代码负责，这是工程噩梦的素材。想象一下，在现在正在使用的 vibe-coded 系统中出现了一个关键 bug——接下来怎么办？如果原作者将其视为一次性原型，他们甚至可能不在身边或没有耐心去破译它。如果它被交给一个团队，团队面临着陡峭的逆向工程工作。在专业环境中，这是不可接受的。这就是为什么许多经验丰富的声音断言 vibe coding "在任何真正的编程环境中都行不通"，在那里代码质量和问责制很重要。对于个人副项目来说很好，但试着告诉你的员工工程师你合并了你没有看过的代码——这是不可能的。
另一个风险向量是隐藏的 bug 和技术债务。Vibe coding 通常导致一种非常被动的开发风格：你提示一个功能，运行代码，看到错误，将错误反馈给 AI，得到修复，继续，如此循环。这种打地鼠的方法意味着你总是在处理眼前可见的问题，而不是主动设计正确性或健壮性。很容易想象有多少潜在的 bug 或糟糕的设计选择可能在表面下滚雪球。一位开发者将其比作在不知道*"承重墙"*在哪里的情况下建造——你可能会无意中做出结构上不健全的决定。
AI 不会告诉你"嘿，这种方法将难以维护"或"我们在这里引入了性能瓶颈"。它只是编写代码来满足手头的提示。随着时间的推移，这些快速修复和规避可能会累积成严重的混乱。事实上，早期的 vibe coders 报告说你会遇到生产力墙："过了一会儿，我意识到很多炒作只是炒作，很多反感是无稽之谈。[但]我很快发现了反模式。"。同一作者列出了一个反模式，即期望 AI 维护一个连贯的长期计划——它不会。另一个反模式是你自己*"没有计划地工作"*——如果你只是说"给我编码 X"而没有设计，你经常会得到一个无处可去的纠结。换句话说，即使是 vibe coding 的支持者也承认，如果你天真地接近它，你会浪费时间并最终不断重构。一位在两个月内大量尝试 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 还做不到。"
这个引用捕捉了一个广泛共享的情绪：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 营销活动的一部分"*一位开发者干巴巴地评论，对一些大胆的声明表示怀疑。
例如，在 Y Combinator 批次中，一些初创公司声称从 AI 编码中获得了惊人的 10 倍到 100 倍的生产力提升。经验丰富的观察者称这些是可疑的：100 倍的加速意味着将过去需要整个团队一个月的时间压缩到一天，这在现实中显然没有发生。即使是整个组织的 10 倍也会是明显的——"非常明显"——对任何外部观察者来说，但事实并非如此。这些声明可能会诱使技术含量较低的利益相关者推动工程师采用不负责任的工作流程，如未经检查的 vibe coding，希望获得奇迹般的生产力提升。因此，出现了一个明智的指导方针：使用 vibe coding 进行探索和原型，但当涉及到生产时，应用通常的严格性。或者正如一篇博客总结的：
'Vibe Coding'可能会让你达到一个功能概念的 80%。但要生产可靠、安全且值得花钱的东西，你需要经验丰富的人类来做今天的模型做不到的艰苦工作。"
换句话说，最后的 20%——通常是 80% 的努力——仍然需要传统工程。我在70% 问题中写过这个。
有趣的是，一些开发者警告说，原型和生产之间的界限可能会迅速模糊，有时会损害质量。一个"大部分工作"的个人项目可以获得用户或重要性，突然你有一个从未考虑长期性的准生产系统。
一位 HN 用户沉思说，人们通过说它不是为生产而设计的来为 vibe coding 辩护，*"但让我们不要天真，因为它 100% 会被用来推送实际应用程序。"*一旦工具存在，有人最终会在其安全区域之外使用它。事实上，我们已经看到早期实例：独立黑客向客户销售 vibe-coded 应用程序，或内部工具 vibe 组装然后由团队使用。
团队的挑战是如何负责任地整合 AI 驱动的开发。也许一种模式是允许在 spike 或原型阶段进行 vibe coding，但在任何东西上线之前需要完整的代码审查和测试周期。这将保留一些速度优势，同时捕获最严重的问题。工具供应商也意识到了这个差距——我们看到新兴功能，如 AI 生成代码的沙盒执行（以防止安全灾难）和集成测试生成以增强可靠性。生态系统可能会发展，使得"vibing"可以在风险较低的受限环境中完成（例如，AI 不能直接部署到生产，任何代码都必须通过测试）。简而言之，行业正在摸索如何两全其美：vibe coding 的创造力和速度，以及传统方法的安全性和健壮性。
目前，共识是保守的：
"在[AI 代理]进一步发展之前，'vibe coders'将无法在这个世界上发布生产质量的软件，无论代理相对于他们自己的劣质技能集有多么指数级。"
来自一项批评的这一严厉声明强调，今天，vibe coding 在很大程度上仅限于原型软件——有用的实验、个人脚本、一次性应用程序。认为这预示着软件工程的死亡或我们可以以这种方式发布严肃的软件是被高估的。我们仍然需要熟练的人类来拧紧螺栓。目前明智的方法是：*用 vibes 原型，但生产需要纪律。或者正如另一个人更直白地说："学会编码！然后 vibe code。"*使用 vibes 来提高生产力，而不是在真正重要时取代基本理解。
对开发者和团队的影响：我们现在都是产品经理了吗？
"几乎没有什么东西再被晦涩的知识所守门了……如果你不喜欢它，就不要使用它；它不适合所有人。这不是那些像机器一样编码的人的替代品——继续做让你与众不同的事情！"
这个热情洋溢的声明捕捉了 vibe coding 如何改变开发者的自我形象和角色。对一些人来说，这是赋权的——突然他们可以自己做更多事情，而不需要记住 API 细节或成为每个框架的向导。对其他人来说，这是威胁性的——它暗示了一个未来，许多传统编码技能可能被绕过或贬值。让我们解开 vibe coding 的经济和职业影响，以及团队如何围绕这些 AI"共同开发者"重组。
一个直接的观察：vibe coding 将程序员的日常工作更多地转向指定要构建什么而不是制作实现。这导致了诸如*"我们现在都是产品经理"之类的俏皮话。开发者不是花时间深入思考算法或调试指针问题，而是花大量时间描述所需的功能、测试应用程序，并决定什么感觉对或错——可以说是与产品设计和 QA 重叠的任务，而不是经典的软件工程。一些人庆祝这种转变，认为它让开发者专注于更高层次的问题解决和用户需求，而不是样板代码。其他人担心它会降低*专业技能。如果走向极端，未来的初级开发者可能不会学习如何编写排序函数或优化查询；他们可能只是提示 AI"让这个更快"并信任它。随着时间的推移，这会侵蚀人类专业知识的池子吗？
一些经验丰富的声音表达了对技能萎缩的担忧。
"我担心的是，如果我开始这样做，我会停止参与构建某些东西的困难方面。我认为我现在拥有的技能会萎缩"
一位资深开发者坦白。这呼应了一个更广泛的焦虑：过度依赖 AI 辅助可能会使下一代程序员不太能够独立解决难题。如果你只是"vibe out"小项目，从不经历基础学习时刻（调试棘手的 bug、理解算法复杂性等），你可能不会发展出处理这些情况所需的深厚专业知识，当它们不可避免地出现时。另一位评论者想知道：
如果你从每周排查问题 5 次变成每几周一次，因为 AI 修复了大多数问题，会发生什么？这会随着时间的推移削弱你的问题解决能力吗？
这些都是开放的问题。未来的开发者可能只是拥有不同的技能档案——也许更像管弦乐队指挥或 QA 工程师与产品思考者的结合。但过渡期是尴尬的：今天的工程师重视通过动手编码磨练的技能，而 vibe coding 似乎短路了这个训练过程。我们可能需要有意识地调整我们在 AI 普及环境中指导新工程师的方式，确保他们仍然接触到"困难的东西"，而不仅仅是乘坐 AI 自动驾驶。
另一方面，vibe coding 可以向更多人开放这个领域，这具有劳动力市场影响。如果确实"数百万新人"可以用更少的培训创建软件，编码周围的排他性光环可能会消退。一些经验丰富的开发者对此做出了防御性反应。他们以编程作为*"智力精确的艺术"而自豪，并对像"vibe coding"这样的术语感到不满，这些术语让它听起来像是一个随意的即兴会议。一位评论者说，这个术语本身"与编程对我来说意味着的一切背道而驰"*，因为它淡化了严格性。
有一丝文化冲突的暗示：细致的工匠 vs. 快速而松散的 AI 驯服者。如果后一种方法获得突出地位，工匠会感到被贬值吗？可能。HN 上一个特别尖锐的评论是：*"看到一些'工程师'在这里伤害了他们的自尊和感情，这很有趣。事实证明，软件工程不会再是最性感的工作之一……傲慢正在实时爆发。"*这表明一些开发者将 vibe coding 视为一个均衡器——对那些在科技繁荣中感到不可或缺的人来说是一种谦卑的力量。当任何人都可以生成一个基本应用程序时，也许成为程序员不会像 2010 年代那样赋予那么多地位。
然而，在宣布编码职业"完蛋"之前，值得注意的是，经验丰富的工程师仍然具有 vibe coding 无法取代的独特价值。正如我们所看到的，复杂、可靠的系统仍然需要这种专业知识。
一个类比是工业革命：
"仍然有人制造定制的高质量物品……但大多数过去在车间制造的东西现在在工厂生产，工人数量减少了几个数量级。"
在软件术语中，常规的 CRUD 应用程序或简单的网站可能会被 AI"工厂生产"，需要的人类开发者要少得多。但定制的、复杂的系统（或任何新颖的问题）仍然需要熟练的工程师——尽管可能需要的人更少。这提出了棘手的问题：入门级编码工作会减少吗？如果一个拥有 AI 助手的资深人员可以完成五个初级人员的工作，我们还需要那么多初级工程师吗？可以想象，软件团队的形态会发生变化。我们可能会看到对"AI 导航员"或"提示工程师"（非常擅长从 AI 中获得结果的人）以及"AI 审计员"或"软件监护人"（确保 AI 生成的代码符合质量标准的人）等角色的更多需求。
在 Ask HN"你在 vibe coding 吗？"讨论中，一个人评论说他们使用 AI 作为助手，"有点像与一个在某些方面是天才但在其他方面令人难以置信地愚蠢的初级开发者配对。"。这是一个很好的框架方式（对初级人员没有不敬）：当前的 AI 可以做大量的苦力工作（像一个不知疲倦的初级人员），但它们在其他方面缺乏判断力（像一个犯奇怪错误的初级人员）。所以你，人类，充当这个伪开发者的导师/经理。*"我认为在这一点上它不再是编码，它更像是'AI 编码器管理'"*另一位评论者观察到。我们可能会在未来真正看到"AI 开发者经理"的职位发布——某人的日常工作是指导 AI 代理构建软件、审查他们的输出并集成结果。
对于个人职业，还有一个经济角度：那些早期拥抱这些工具的人可能会变得显著更有生产力（至少对于某些任务），可能获得更高的薪酬或超越同行。
相反，那些完全否定 AI 的人可能会发现自己效率较低或落后，如果行业朝这个方向发展的话。这让人想起以前的范式转变——例如，拥抱高级语言的开发者 vs. 坚持汇编的开发者，或者学习自动化的开发者 vs. 手动做所有事情的开发者。但这很棘手，因为将 vibe coding 推向极端在生产中是不可取的，所以必须找到正确的平衡。对开发者来说，最安全的赌注是学会负责任地使用 AI 工具。正如一篇文章所说：AI 编码助手
"使熟练的人能够比以往任何时候都更独立地创造。[但]它不会取代那些能够解决只有经验和直觉才能识别的难题的人。"
因此，结合经验和 AI 熟练度的开发者将处于最佳位置。他们可以利用 AI 在简单部分上的速度，并将自己的技能应用于困难部分。相比之下，只知道如何提示 AI 而没有基础理解的人可能会遇到职业天花板——当 AI 输出不完美时（这经常发生），他们会挣扎。
在团队内部，我们也可能看到协作动态的转变**。如果单个开发者可以通过与 AI vibing 来原型化整个功能，这是否会减少跨专业协作的需求？*例如，拥有 AI 的前端工程师可能会单独实现过去需要后端帮助的东西，因为 AI 可以为他们填写后端代码。这可能会模糊传统的角色界限。它也可能引入新的界限：也许一个"vibe 协调员"*确保由各种人+AI 对生成的代码仍然遵守连贯的架构（因为 AI 可能会引入不一致的模式）。
文档和知识共享也变得有趣——如果一半的代码是由 AI 编写的，你如何记录某些实现背后的理由？一些人建议维护一个*"项目日志"*或让 AI 生成运行的变更日志是有用的，这样人类以后可以理解做了什么。所有这些考虑都暗示团队流程将适应。例如，代码审查可能明确包括识别 AI 编写的部分并仔细检查它们是否存在已知的 AI 失败模式（如不安全的默认值或低效的循环）的步骤。教育和入职可能涉及教新人如何有效地与 AI 共同编码（以及如何仔细检查 AI 工作）。
从经济上讲，如果 vibe coding 和 AI 开发广泛地确实使生产软件更便宜，我们可能会看到总体上创建更多的软件（扩大蛋糕，而不仅仅是减少开发者工作）。这与"个人软件"愿景相关：更多的小众应用程序将值得制作，因为成本更低。公司可能开始期望工程师在 AI 帮助下同时处理多个领域（也许一个人用 AI 构建整个小产品——从前到后——而以前你会雇用单独的专家）。这可能会使超级明星通才开发者更有价值，但也可能意味着每个项目需要的总人数更少。
总之，vibe coding 正在催化对成为开发者意味着什么的重新审视。我们是从工匠转变为 AI 输出的策展人和指挥者吗？如果是这样，我们如何确保下一代仍然学习基础知识？
可能的结果是软件工程将分叉：常规应用程序开发可能会变得更加自动化（由相对技能较低的操作员监督 AI——"公民开发者"概念的演变），而尖端和关键系统仍然掌握在高技能工程师手中，他们现在将 AI 工具作为力量倍增器。
AI 远非杀死程序员，可能会使优秀的程序员更加不可或缺，即使平均的代码猴子工作减少了。我们软件生态系统的长期健康将取决于融合两个世界的最佳：人类专业知识和 AI 辅助。这要求开发者适应，不仅在技能集上，而且在心态上——认识到何时 vibe 以及何时仔细检查。
结论：在 Vibes 和严格性之间取得平衡
vibe coding 的兴起引发了兴奋、反弹和深思熟虑的讨论——最终，它强调了一个永恒的原则：工具会改变，但软件工程的基础仍然存在。
大型语言模型为我们提供了一种令人陶醉的新方式来创建软件，通过*"只是 vibing"*——利用 AI 的庞大知识以闪电般的速度生成代码，通过自然语言提示进行迭代。这感觉像是一个激进的转变，在某些方面确实如此：开发者可以在几小时内完成过去可能需要几天的工作，甚至非开发者也可以通过描述他们的想法来组合简单的应用程序。精灵已经从瓶子里出来了；AI 辅助编码（以各种形式）将继续存在。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 更快地编码，但永远不要外包你的理解。"
当你接受你不理解的代码的那一刻，你就产生了必须偿还的债务。优秀的工程师仍然会偿还这笔债务，只是可能在稍后的阶段（例如，在合并之前详细审查 AI 生成的模块）。糟糕的工程师可能会让它累积，他们或他们的团队稍后会付出沉重的代价。这种动态并不新鲜——想想那些复制粘贴 Stack Overflow 代码而不理解它的开发者。AI 只是放大了它。社区似乎正在就以下建议达成共识**：*阅读差异。编写测试。牢记设计。如果 AI 建议某些东西，考虑为什么。***本质上，将 AI 视为团队中的初级开发者：你欢迎他们的贡献，但你也指导和验证。
另一个可能的结果是专业化。我们可能会看到某些领域，vibe coding（或大量 AI 生成）成为常态，而其他领域则仍然很少见。前端 UI 调整、小型实用程序脚本、内部工具——这些可能会倾向于类似 vibe 的工作流程，因为风险低，迭代速度至关重要。另一方面，库开发、核心算法、安全关键代码——这些可能仍然主要是手写的或至少是手工审计的，因为对错误的容忍度为零。
随着时间的推移，随着 AI 的改进，边界会转移，但开发者会随之转移，总是划分出什么需要人类仔细关注，什么可以自动化。讨论经常重复：*概念的 70%，但最后 30% 需要人类。*随着 AI 在常规事务上变得更好，这可能会逐渐变成 90/10 或 95/5。但最后一片——困难的部分——可能永远不会完全消失。相反，人类将攀登到更高的抽象层次，处理新的难题，而 AI 处理下面更多的苦力工作。这一直是编程自诞生以来的故事，vibe coding 是这个不断演变的抽象故事中的又一章。
最后，vibe coding 一直是讨论我们在软件开发中重视什么的催化剂。它迫使我们问：如果 AI 可以比我们更快地生成代码，我们的角色是什么？许多人给出的答案令人鼓舞：我们的角色是提供愿景、洞察力和深刻的理解。
我们设定意图并确保结果真正满足意图。我们做出需要上下文和远见的艰难决定和权衡。我们还将道德、责任和对用户的同理心注入过程——这些都是目前没有 AI 拥有的东西。Vibe coding 并没有消除对人类的需求；它转移了它。正如一位评论者雄辩地说：
"看待这个问题的另一种方式是，很多人通过放弃一些（不是全部）低级控制并专注于更高层次，可以获得很多好处。"。
那种"放手"可能是可怕的——感觉像是失去了我们工艺的一部分——但如果明智地做，它也可以是赋权的，让我们能够解决更大的问题。
"Vibe coding"这个术语本身可能会随着围绕它的实践成熟而消失。但核心思想——使用 AI 作为积极的开发伙伴——无疑将变得司空见惯。软件社区的挑战和机遇是以一种增强我们能力而不侵蚀我们工作质量和完整性的方式整合这个伙伴。
与任何强大的新工具一样，会有那些滥用它的人和那些掌握它的人。希望通过公开讨论成功和失败（正如我们在本文中所做的那样），我们集体变得更聪明。也许最终的 vibe 是和谐的：人类和 AI 一起工作，每个人都弥补对方的弱点，比以往任何时候都更快更好地构建软件。
到达那里需要实验、纪律，是的，还有一点vibing——但要睁大眼睛，双手准备好在 AI 偏离轨道时抓住方向盘。
最终，"vibes"应该服务于代码，而不是相反。如果我们保持这种观点，vibe coding 确实可以摇滚——而不会让我们滚下悬崖。
相关阅读：