Vibe Coding：当编程变成“凭感觉说话“，软件工程的根基正在溶解

2025年2月，OpenAI联合创始人Andrej Karpathy随手发了一条推文，创造了一个让整个软件行业陷入狂欢的词：Vibe Coding。一年后，Collins词典将其列为年度词汇，92%的美国开发者日常使用AI编程工具，GitHub上46%的新代码由AI生成。然而，当浪潮开始退去，一组残酷的数据浮出水面：45%的AI生成代码含有安全漏洞，代码重构率从25%暴跌至不足10%，维护成本在18个月内膨胀300%，超过8000家AI创业公司被迫重建代码库。

这场从"写代码"到"聊代码"的范式革命，正在以一种没人预料到的方式，溶解软件工程这门学科最底层的根基。

一、一条推文，一场革命

2025年2月6日，Andrej Karpathy在X上写下了这样一段话：

"There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists."

翻译过来大概是："有一种新的编程方式，我叫它'凭感觉编程'——你完全沉浸在感觉里，拥抱指数增长，甚至忘记代码本身的存在。"

这不是一个严谨的学术定义，甚至不是一个技术方案。它是一句"浴中哲思"，是Karpathy在休假期间随手敲下的一段文字。但就是这个看似随意的表达，精确地命名了一个正在成千上万开发者键盘下悄然发生的范式转变：编程不再是写代码，而是对AI描述你想要什么，然后判断结果是否"感觉对了"。

Karpathy后来回忆说，他自己也没想到这条推文会爆。"我的Twitter账号用了17年，但我基本上还是完全摸不透推文互动的规律。"然而，这条推文在一个正确的时间，为无数开发者共同的感受找到了一个完美的名字。

它之所以击中人心，不是因为Karpathy发明了一种新的编程方法论——事实上，早在2023年3月，Dany Kitishian就在Klover.ai建立了名为"Co-Creator"的AI协作编程框架，只是它从未走出学术圈。Karpathy真正做的事情是：给一个已经存在两年的实践，赋予了一个可传播的名字、一个文化标签、一个全民参与的理由。

而这个名字的力量，远比任何人想象的更大。

"Vibe Coding"这个词的精确之处在于，它描述的是一种感觉状态，而非技术流程。传统编程是理性的、精确的、可验证的；Vibe Coding是感性的、模糊的、靠直觉驱动的。当Karpathy说"顺着感觉走"，他实际上是在为一种全新的开发者体验正名——一种你不再需要理解每一行代码，只需要"感到它应该能跑"的开发方式。

但这个概念的种子，其实早在两年前就已经埋下。

2023年1月24日，Karpathy发过另一条推文："The hottest new programming language is English."——"最热门的新编程语言是英语。"这条推文在当时并未引起同等规模的轰动，但它精准地预言了Vibe Coding的底层逻辑：自然语言正在取代传统语法，成为人类意图与机器执行之间的界面；而AI，正在成为这个界面的编译器。

从"英语是最热门的编程语言"到"忘记代码的存在"，Karpathy用了两年时间，完成了从洞察到命名的跨越。而整个软件行业，则在一个更短的时间内——不到18个月——完成了从旁观到狂欢的跨越。

二、惊人的普及：一场没有人敢缺席的狂欢

Vibe Coding的普及速度，在软件工程史上是前所未有的。

让我们先看一组数字：

• 92%的美国开发者在日常工作中使用AI编程工具
• 46%的GitHub新代码由AI生成
• 25%的Google新代码由AI辅助生成
• 21%的Y Combinator 2025冬季批次初创公司，代码库中超过91%为AI生成
• 85%的开发者将Vibe Coding（基于直觉接受AI代码而非严格审查）作为默认工作流
• 全球AI编程市场规模预计达到85亿美元
• Meta的目标是让大部分代码由AI Agent生成

这些数字描绘的是一幅令人窒息的画面：Vibe Coding不是一种可选的工作方式，它正在成为唯一的默认项。即使那些对AI代码质量持怀疑态度的人，也不敢不使用——因为不使用意味着生产力的绝对落后。

但更值得关注的是数字背后的工具分化。2026年的Vibe Coding生态已经高度分层，不同类型的工具对应着完全不同的使用群体和信任模式：

这种分层揭示了一个关键事实：Vibe Coding不是一个单一的行为，而是一个光谱。在光谱的一端，资深开发者用Cursor和Claude Code来加速自己已经能做的事情；在光谱的另一端，完全不懂编程的人用Lovable从零搭建一个"能跑的应用"。

而正是在这个光谱的"零门槛"一端，最大的问题开始酝酿。

Y Combinator那21%的"代码库91%以上由AI生成"的初创公司，看似代表了技术民主化的胜利。但数字背后的真相是：到第90天，其中40-60%的团队发现，修复一个bug会破坏另外三个功能。他们的冲刺产能被稳定化工作吞噬，原始的速度优势完全消失了。

三、狂欢的代价：四重危机正在同时爆发

Vibe Coding最危险的地方，不在于它产出的代码质量差——而在于它的代价是延迟显现的。前30天，交付速度提升3-5倍，所有人都在庆祝。第31到60天，摩擦开始出现。第61到90天，崩溃到来。

而这场崩溃，正在四个维度同时发生。

危机一：安全漏洞被批量生产

这是最严重、最紧迫的问题。

传统开发中，安全漏洞是零星分布的——一个开发者可能在某一个模块里犯了一个SQL注入的错误，代码审查可以发现它。但AI生成代码时，会以相同的模式在多个位置复现完全同类的漏洞。这不是随机错误，这是系统性偏差。

Tenzai安全公司的测试提供了一个令人警醒的案例。他们用五款主流Vibe Coding工具（Claude Code、OpenAI Codex、Cursor、Replit、Devin）分别构建了三组相同的应用。结果发现69个安全漏洞，其中6个为严重级别。这些漏洞不是随机分布在代码各处——它们高度集中在相似的功能模块中，遵循着AI模型在训练数据中学到的"不安全模式"。

更全面的数据：

• Veracode对400万次代码扫描的分析：AI生成代码45%含有安全缺陷
• 云安全联盟（CSA）研究：**62%**的AI代码存在漏洞
• Georgia Tech Vibe Security Radar扫描5600个Vibe Coded应用：超过2000个标记出已确认的安全问题
• 2026年1月，6个CVE被直接归因于AI生成代码（实际数字可能5-10倍更高）
• Fortune 50企业月安全发现量从1000激增至10000以上

这些漏洞呈现出高度一致的"AI签名"模式：

• 70%的Lovable应用在Supabase表上关闭了行级安全（RLS），任何登录用户都能读写其他用户数据
• AI代码几乎从不验证Webhook签名，支付回调可以被伪造
• API密钥和数据库连接串被硬编码在源文件里，然后进入Git历史
• 输入清理几乎完全缺失——表单数据直接进SQL查询，SQL注入和XSS门户大开

Damian Galarza——一位渗透测试专家——在15个AI构建的应用中找到了69个漏洞，平均每个应用近5个。这些应用的创始人都认为自己的产品已经可以上线了。

更令人不安的是，AI不能可靠地审计自己的代码。NetSPI做过一个对照实验：用Vibe Coding构建一个应用，让AI审计它，实施AI建议的修复，然后请人类渗透测试团队再次攻击。结果：人类测试员仍然发现了AI完全漏掉的漏洞。AI能检查常见模式（"RLS开了吗？""有没有像API密钥的字符串？"），但不能推理你的多租户数据模型在并发负载下是否真正隔离了客户数据。

危机二：代码质量的慢性崩溃

如果安全问题是"急性病"，那么代码质量退化就是"慢性病"——它不会立刻杀死你的产品，但会让你的代码库在18个月内变成一座无人敢碰的废墟。

GitClear的数据最为触目惊心：

• 代码变更率上升41%（因为AI生成的不同版本之间缺乏一致性）
• 代码重复率增加4倍（AI不擅长抽象，更擅长复制粘贴）
• 重构比例从2021年的25%暴跌至不足10%（人类开发者倾向于"接受并继续前进"，而非停下来优化AI代码）
• 63%的开发者表示，调试AI生成的代码所花时间超过了自己手写的时间

为什么会这样？因为Vibe Coding制造了一种新型的"所有权真空"。当代码是人类写的，写代码的人知道为什么做了某个设计决策。当代码是AI生成的，没有任何一个人的大脑里装着"为什么这么做"的理由。几个月后需要维护时，面对的是一群没有作者、没有注释、没有设计意图的代码。

CodeRabbit分析了470个GitHub开源PR后的结论更加残酷：AI协作代码的重大问题数量是纯人类代码的1.7倍。这还不算最坏的情况——因为CodeRabbit分析的是"被提交到GitHub的代码"，而大部分质量最差的Vibe Coded代码可能根本没走到PR那一步。

Vibe Coded代码库与传统代码库的质量差距，可以用一组对比数据清晰呈现：

12%的测试覆盖率——这意味着Vibe Coded代码库中，近九成的功能从未被自动化测试验证过。这些代码能跑，只是因为"到目前为止还没出问题"。

危机三：维护成本的指数膨胀——"Vibe Slop"的技术债海啸

2026年，开发者社区出现了一个新黑话："Vibe Slop"（氛围垃圾）。它特指那些由AI生成、开发者未经审查就接受的低质量代码——能跑，但臃肿、脆弱、难维护。

这个看似戏谑的词背后，是真实的经济灾难。

一项覆盖数百个工程团队的实证研究发现，Vibe Coded代码库的维护成本在18个月内膨胀300%——即维护开销增长到初始基准的4倍。而这仅仅是直接成本，还没算机会成本：

• 一个50,000的VibeCodedMVP，要提升到生产级质量需要∗∗额外50,000的VibeCodedMVP，要提升到生产级质量需要∗∗额外200,000-$500,000**的补救费用
• 安全修复：50,000−50,000−100,000
• 测试套件重构：80,000−80,000−150,000
• 架构重建消除重复：70,000−70,000−200,000
• 性能优化：30,000−30,000−50,000

更宏观的数据：2024-2025年，约10,000家初创公司尝试用AI构建生产级应用。到2026年中期，超过8,000家需要部分或完全重建代码库。Gartner预测，到2028年，40%的AI密集型项目将面临取消或重大重做。

这个财务轨迹有一个清晰的模式：

这就是Vibe Coding最残酷的真相：它给你前30天超速行驶的快感，然后在接下来的18个月里，让你连本带利地把节省的时间全部还回去——外加300%的利息。

《华尔街日报》2026年5月的一篇调查报告将Vibe Slop问题带入主流视野。星巴克在2026年5月撤掉了其全北美AI库存管理工具——这个系统运行了仅9个月就因"无法处理真实世界供应链物流的复杂性"而被废弃。PwC的2026年CEO调查发现，56%的CEO报告AI投资零财务回报。

Karpathy本人对AI代码质量的评价可能是最扎心的。他在2026年4月的Sequoia访谈中说：

"有时我看到它写出来的代码，会有一点心脏病发作的感觉。它能跑，但真的很恶心。"

这不是一个AI怀疑论者的批评。这是Vibe Coding这个词的发明者在亲口告诉你：AI能写出能跑的代码，但"能跑"和"好代码"之间的鸿沟，比大多数使用者意识到的要大得多。

危机四："认知外包"——程序员正在系统性"变傻"

前三重危机都是关于代码的。第四重危机是关于人的。

Vibe Coding的本质是一种认知外包——将编程过程中最核心的思维活动（算法设计、架构推理、边界条件分析）外包给AI。问题在于，外包得越多，你自身的相关能力就退化得越快。

这不是一个抽象的哲学担忧，而是有数据支撑的趋势：

• 开发者对AI工具的好感度从2023年的77%下降到2026年的60%
• 对AI代码准确性的信任度从2024年的43%下降到2026年的33%
• 但使用率持续上升。没有人敢不用。

这种"越不信任越要用"的悖论，指向了一个更深层的问题：Vibe Coding正在制造一代"只会描述需求、不会理解实现"的开发者。

资深开发者（10年以上经验）报告AI工具带来了81%的生产力提升。但初级开发者的结果参差不齐。原因很直观：资深开发者知道什么是好的输出——他们能立刻判断AI生成的代码是否在架构上合理、是否有边界条件漏洞、是否符合团队规范。初级开发者缺乏这种判断力，会全盘接受AI输出，然后带着一堆"看起来能跑"的代码走向生产环境。

中山大学与阿里巴巴的联合研究提供了一个更精确的量化视角：在代码维护任务中，AI模型在75%的情况下会破坏原本正常的代码功能。这意味着，让一个不懂代码的人用AI去"修"一个已有系统，有四分之三的概率会让情况变得更糟。

一个在开发者圈子里流传的比喻越来越流行：Vibe Coding就像一台自动挡汽车。它让你不需要理解离合器、转速和档位就能上路，但当你遇到结冰路面或陡峭坡道时，你不知道如何应对，因为那些本应在手动挡驾驶中自然习得的"车辆感知能力"从未进入过你的肌肉记忆。

亚马逊内部的一个案例尤其荒诞。为了提高AI编码工具的使用率，亚马逊推出了"Tokenmaxxing"排行榜——谁调用AI最多，谁就上榜。结果：token消耗暴增300%，项目实际进度零增长。工程师们沉迷于刷榜，而不是——你懂的——写代码。

而更令人深思的是一个来自工程一线的现象："AI写代码+人类审查"这个看似完美的分工模型，在实践中是不可持续的。审查AI生成的代码所需的心智努力至少是写代码的2倍——你需要先理解AI生成的逻辑，再判断它是否正确，然后推测它遗漏了什么。而人类的注意力是有上限的。当AI每秒可以吐出数百行代码时，人类的审查能力已经彻底被淹没。

四、Karpathy本人的倒戈——从"Vibe Coding"到"Agentic Engineering"

如果说前面的数据还不够有说服力，那么听听Karpathy自己怎么说。

2026年2月，在Vibe Coding诞生整整一年后，Karpathy在X上发布了一篇长文，标题几乎可以概括一切："再见，Vibe Coding。你好，Agentic Engineering。"

他写道：

"一年前的Vibe Coding，是大家用当时能力还比较弱的LLM，做些好玩的一次性项目、演示和小探索。而一年后的今天，利用LLM Agent编程已成为专业人士的'默认设置'。只不过，监督和审查要更多了些。"

这个"只不过"背后是整个范式的升级。Karpathy提出的新概念Agentic Engineering（智能体工程）有两个关键词：

Agentic（智能体）——因为你99%的时间不再直接写代码，而是在指挥智能体干活，"充当监工"。

Engineering（工程）——因为这不是随意的"感觉"，而是"包含着艺术、科学和专业技能的、有深度可精进的能力"。

从Vibe到Agentic，从Coding到Engineering——这不是文字游戏，而是一次彻底的自我纠偏。Karpathy实际上在说："我之前说的'忘记代码的存在'，字面意思被很多人理解错了。不是让你真的不关心代码，而是让你把精力从写代码转移到管代码。"

在2026年4月Sequoia Capital的访谈中，Karpathy把这种转变讲得更透彻：

"Vibe Coding抬高的是所有人能做软件的下限。Agentic Engineering要保住的是专业软件过去已有的质量门槛。"

他还提到了一个个人转折点：2025年12月。在这个月之前，AI生成的代码"有帮助但常常需要修补"。从这个月开始，"直接能用"。"我记得不上一章我需要纠正它是什么时候了。然后我就越来越信任这个系统。"

但信任是一把双刃剑。Karpathy承认，信任度的提升并不意味着质量的提升。他看到的AI代码有时让他"心脏病发作"——能跑，但"很丑"，臃肿、重复、抽象别扭。他甚至提到一个自己反复尝试却失败的例子：让AI做代码精简。"我不断地让LLM'再简化一点'，它就是做不到。你能感觉到你在RL（强化学习）回路之外。就像在拔牙。"

这个观察直指Vibe Coding的根本局限：AI模型之所以在某些任务上极强、在某些任务上极弱，不是因为"理解"的差异，而是因为训练数据的覆盖范围和强化学习奖励信号的有无。代码生成被大量训练，所以AI能写能跑的代码。代码优雅性没有被有效奖励，所以AI写不出好代码。

Karpathy用一个令人难忘的比喻来描述LLM的本质："我们不是在造动物，我们在召唤幽灵。"

动物智能来自进化、身体、环境互动、内在动机。LLM不是这样——它来自大规模人类文档的统计模式，叠加强化学习和偏好数据的塑造。它没有动物式的情绪或动机。你对它大喊大叫，不会让它更努力。你鼓励它，也不会激发它。

理解这一点对于使用AI编程工具至关重要：不要把它当聪明人或愚笨人，要把它当一个由数据分布决定的"幽灵"。它在训练数据和RL覆盖的"能力高峰"里表现出色，在数据分布之外的"能力断崖"上则会犯令人难以置信的低级错误。

Karpathy举了个例子：一个最先进的模型可以重构10万行代码、找到零日漏洞，但当你问它"我要去50米外的洗车店洗车，应该开车还是走路"，它会说"走路，因为很近"——完全忽略了你要洗的是车，车必须到洗车店。

五、光谱的两端：谁在狂欢，谁在裸泳

Vibe Coding最残酷的特征是它的不均衡效应——它不是均匀地影响所有开发者，而是像一个分光镜，把不同水平的开发者折射到完全不同的轨道上。

用36氪报道中的话说：

"一端是初级开发者。他们爱死Vibe Coding了，因为这让他们产生了自己无所不能的幻觉。但遗憾的是，因为缺乏判断力，他们只会生成一堆无法维护的'屎山'。"

"另一端是资深大神。他们利用Vibe Engineering获得了10倍的效率提升。因为他们懂架构、懂模式，并且一眼就能看出AI生成的代码'虽然不是最完美的，但对于当前功能来说已经足够好了'。"

这不是简单的"强者更强、弱者更弱"。它是一种根本性的角色分流：

初级开发者的危机不仅是技术上的，更是认知上的。当一个完全依赖AI写代码的开发者被问到"这个系统是怎么工作的"，他能给出的最诚实的回答只能是"AI说它能工作"。他没有构建过系统的心智模型，他只是在操作一个黑箱。

而资深开发者的优势也不仅是技术上的。正如一位在大型科技公司设计大规模系统的工程师所言："在大厂设计大规模系统的经验，反而让我能更好地驾驭AI。核心原因在于：我知道一个好的系统长什么样。"

这句话值得反复品味。它意味着在Vibe Coding时代，最有价值的技能不是"会写代码"，而是**"知道什么是好代码"**。而"知道什么是好"这种判断力，几乎不可能通过AI辅助获得——它来自亲身踩过的坑、亲手拆过的雷、亲眼见过的系统崩塌。

这也是为什么Karpathy在Sequoia访谈的结尾说出了那句已经成为经典的话：

"你可以外包你的思考，但不能外包你的理解。"

他进一步解释：思考步骤可以让AI跑很多遍，但如果人没有理解，就无法判断哪条路线是对的；无法写出好的规格；无法发现Agent在身份绑定、系统结构、代码质量上的错误。而他自己正在变成瓶颈——"我要知道我们到底在建什么，为什么值得做，以及怎样指导我的Agent。"

六、Vibe Coding不会消失，它正在变成另一种东西

到这里，一个自然的问题是：Vibe Coding是一场泡沫吗？它会像许多技术热词一样迅速消退吗？

答案是：不会，但它正在被重新定义。

2026年正在发生一个显著的"结构化转向"。如果说2025年是"忘记代码存在"的狂热实验期，那么2026年正在形成一套新的工程纪律：

工具链标准化：从AI生成到CI/CD验证的完整流水线正在成为标配。SAST（静态应用安全测试）、code review、测试覆盖被强制集成到AI代码的生产管道中。

最佳实践沉淀：分层审核（低风险功能允许AI输出直接通过，高风险功能强制人工+安全双重审查）、架构先行（先讨论设计再生成代码）、定期"人类重构日"等方法论正在成为共识。

专业化分工：AI负责实现，Senior开发者负责架构和质量判断——这个分工模型正在被越来越多的团队采用。

微软、IBM等公司提出的"Objective-Validation Protocol"（目标-验证协议）代表了下一个范式：人类定义目标和验收条件，AI Agent自主执行和迭代，人类在关键节点验证。这比Vibe Coding更激进——连"描述实现方式"都交给了AI自己，但比原始Vibe Coding更严谨——因为验证标准是提前定义好的。

那些成功避开Vibe Slop危机的团队，有一些共同特征：

• AI生成模块合并前强制60%最低测试覆盖率
• 从项目开始预留20%冲刺产能用于债务削减
• 使用独立的AI代理角色分别负责编码、审查和测试
• 每次PR运行自动化重复检测和密钥扫描
• 每4-6个功能冲刺后安排一个稳定化冲刺

这些实践代表了一种新的工程文化：用AI，但不盲信AI。外包实现，但不外包责任。

结语：当"感觉"取代"理解"，什么还值得坚守？

Andrej Karpathy在Sequoia访谈的最后被问到一个问题：当智能变得便宜，什么仍然值得深入学习？

他的回答翻译过来是：

"你必须理解你在做什么。信息必须进入你的脑子里。你可以让AI帮你思考很多遍，但如果你不理解目标和不理解系统，你就无法判断哪条路线是对的。"

这是一个Vibe Coding发明者的终极反思——不是抛弃AI，而是重新定义人与AI的分工边界。

API名称可以忘，但张量、视图、内存效率的概念不能丢。Agent可以写支付逻辑，但身份绑定、资金归属的安全约束必须人来规定。AI可以生成大量代码，但抽象是否臃肿、结构是否脆弱，必须人来判断。

软件工程的根基不在代码里，在理解里。代码是理解的外化，不是理解的替代品。

Vibe Coding没有错。错的是把Vibe当成全部。当编程变成"凭感觉说话"，那些仍然愿意深入理解每一行代码为什么这样写的开发者，不会是被时代淘汰的人——他们将是下一个时代最稀缺的人。

因为说到底，AI能替你写代码，但不能替你做判断。能替你实现功能，但不能替你承担责任。

而当Vibe Coding的热潮退去，真正留下来的，不会是那些最擅长"凭感觉"的人，而是那些从未放弃理解的人。

2026年6月30日

参考资料：

• Andrej Karpathy 2025年2月6日 X 推文及后续讨论
• Andrej Karpathy 2026年2月 "Goodbye Vibe Coding, Hello Agentic Engineering" 长文
• Andrej Karpathy 2026年4月 Sequoia Capital AI Ascent 访谈
• Tenzai Security AI代码安全测试报告（2026）
• Veracode 400万次代码扫描安全分析（2026）
• 云安全联盟（CSA）AI生成代码漏洞研究报告（2026）
• Georgia Tech Vibe Security Radar 应用扫描数据（2026）
• GitClear 代码质量趋势分析（2021-2026）
• CodeRabbit 470个GitHub开源PR分析
• SonarSource 全球技术债务调查（2026）
• Gartner AI密集型项目预测（2026）
• 《华尔街日报》Vibe Slop调查报告（2026年5月）
• PwC 2026 CEO调查
• Collins English Dictionary 2025年度词汇