创造了，然后呢？

你有没有过这种经历？

打开 Cursor，描述几句想要的东西，回车，几秒钟后代码就跑起来了。功能能用，界面能看，多巴胺直接拉满。感觉自己在创造，感觉产品马上要成了。

然后你接着加功能，继续 prompt，继续爽。一个下午下来，好像做了以前一周的量。

这个感觉有个名字，叫 Vibe Coding。

一个词，炸出了一整年讨论

2025 年 2 月，Andrej Karpathy 在 X 上发了一条推文，说自己最近写代码的方式变了——「完全沉浸在 vibe 里，拥抱指数级增长，忘了代码本身的存在」。

Karpathy 是 OpenAI 的联合创始人，前 Tesla AI 负责人。他造的词，传播力天然拉满。Collins 字典把 Vibe Coding 选为 2025 年度词汇，Merriam-Webster 也把它列入了「俚语与趋势」。

但这个词能火，靠的不是一个名人的推文。它火是因为太多人对这个感觉产生了共鸣——你不需要会写代码，只需要会说话，就能做出一个能跑的东西。

Y Combinator 2025 年冬季批次里，25% 的初创公司代码 95% 以上由 AI 生成。Cursor 估值做到 293 亿美元，年化收入 10 亿美元。瑞典的 Lovable 上线 8 个月 ARR 破 1 亿美元，其中 63% 的付费用户从来不是程序员。

数字很漂亮。但漂亮数字背后，有些问题开始浮出来。

代码写得快了，然后呢？

Forbes 在 2026 年 6 月发了一篇文章，标题叫《The Vibe Coding Productivity Paradox No One Wants To Talk About》。里面引用了一个 METR 的对照实验，挺打脸的：

METR 找了一群资深开源开发者，让他们在百万行级别的真实代码库上工作，一组用 AI 工具，一组不用。开发者们预测自己用 AI 会快 24%。结果呢？**慢了 19%**。

更扎心的是实验结束后的问卷——他们仍然坚信自己快了 20%。

斯坦福也做了一个随机对照实验，发现使用 AI 工具的开发者写出的代码安全性更差，但他们对自己代码安全性的信心反而更高。

效率和自信都在涨，质量和实际产出却在掉。这就是所谓的「生产力悖论」——编码速度大幅提升，但组织真正捕获的价值没有同步增长。

SIA Partners 在分析这个现象时说了一句很到位的话：瓶颈已经不是代码生产的速度了，是软件组织的结构。

AI 生成的代码，能上生产吗？

Veracode 做了一个测试，把 100 多个大语言模型生成的代码拿去跑 OWASP 十大 Web 安全风险检测。45% 的样本没过。Java 的失败率超过 70%。

CodeRabbit 分析了 470 个开源 PR，发现 AI 写的代码比人工代码平均多出 1.7 倍的问题，跨站脚本漏洞高出 2.74 倍。

Hashnode 2026 年的一份开发者调查显示，41% 的开发者承认，自己把 AI 生成的代码推到生产环境时没有做完整审查。

Gartner 有两个预测，放在一起看很有意思：到 2028 年，40% 的新企业产品会用 Vibe Coding 技术开发；同年，缺乏治理的 Vibe Coding 将使软件缺陷增加 2500%。

Red Hat 的开发者博客用了这样一个标题：《The Uncomfortable Truth About Vibe Coding》。文章里描述了一个很典型的场景：

你用 AI 搭了一个项目，前三个月一切顺利。第四个月开始，改一个小东西，坏了四个功能。你让 AI 修那四个，又搞坏了别的。打地鼠开始了。AI 的上下文窗口只能看到代码的碎片，你的项目变成了一个没人能完全理解的黑箱。

这跟代码写得好不好关系不大。这是工作方式的问题——当你的需求只存在于 prompt 里，代码本身就是唯一的真相来源。而代码在解释「为什么这么写」这件事上，非常差劲。

资深和初级开发者的差距被拉大了

Science 上发表的一项研究给出了一个有意思的数据对比：

• 10 年以上经验的开发者使用 AI 工具，生产力提升 81%
• 初级开发者使用同样的工具，没有可衡量的产出改善

原因不复杂。资深开发者知道好代码长什么样，能一眼看出 AI 哪里写错了。初级开发者缺少这种判断力，AI 写什么就接受什么。

这带来一个连锁效应：以前初级开发者靠写样板代码学习和成长，现在样板代码全被 AI 包揽了。学习路径断了，从初级到资深的成长阶梯消失了。Forbes 的文章直接说，资深工程师在一夜之间变得更值钱了，因为他们变成了 AI 输出的「守门人」。

回到那个问题：创造了，然后呢？

前面聊的都是 Vibe Coding 本身的优劣。但我觉得真正值得想的，是另一个层面的事。

Vibe Coding 把「创造」这件事的成本压到了接近零。一个想法从脑子里到能跑的 demo，可能只要一个下午。这很爽，也很危险。

因为创造从来不是最难的环节。

以前写代码是瓶颈——想法便宜，实现难。会编程的人因此有优势。现在代码几乎免费了，那价值转移到了哪里？

转移到「创造之后」的那些事上。

东西做出来了，要让别人知道——这是分发的问题。渠道、SEO、社媒、口碑，每件事都比写代码慢，反馈周期长，没什么即时满足感。

东西能用了，要让人信任你——这是品牌的问题。用户凭什么用一个 AI 随手生成的东西？他们要的是背后有人在负责，有问题能找到人修。

V1 能跑了，要做到 V10——这是持续经营的问题。Vibe Coding 擅长给你第一版的爽感，但第三个月开始维护成本爆炸，功能加得越多，代码越乱。

用一句话概括：Vibe Coding 压缩了从想法到 demo 的时间，但往往拉长了从 demo 到真正可用产品的时间。

那些「创造之后」的事——获客、收费、运营、维护——没有一件是 Vibe Coding 能帮你的。它们慢、难、不产生多巴胺。但钱就在那里。

怎么用 Vibe Coding 才对？

我倾向 Red Hat 和 SIA Partners 给出的建议：分场景对待。

原型阶段，尽情 vibe。验证想法、做 demo、探索可能性，这时候速度就是一切。Karpathy 本人也是这个意思——他最初描述的就是「扔掉的周末项目」。

但一旦进入生产阶段，写 spec、写测试、做 code review 就绕不开了。SIA Partners 把这叫做「混合模式」：探索时用 AI 快速迭代，落地时用规范驱动的方式工程化。

Forbes 的建议更具体：分开跟踪两个数字——「首次可运行版本的时间」和「从可运行版本到生产就绪的时间」。Vibe Coding 压缩了第一个数字，但经常膨胀第二个。

说到底，Vibe Coding 是一个好工具，但不是一个好策略。工具用得好不好，取决于你用它来做什么。如果你用它来快速验证想法，然后认真地把验证过的东西做成产品——那是正道。如果你沉迷在「又做出了一个新东西」的循环里，那可能只是在原地堆沙堡。

每座沙堡都很漂亮。但你知道海浪会来。

参考链接

1. Vibe coding - Wikipedia
   https://en.wikipedia.org/wiki/Vibe_coding

2. Forbes: The Vibe Coding Productivity Paradox No One Wants To Talk About
   https://www.forbes.com/sites/jodiecook/2026/06/11/the-vibe-coding-productivity-paradox-no-one-wants-to-talk-about/

3. SIA Partners: Fixing the Vibe Coding Productivity Paradox
   https://www.sia-partners.com/en/insights/publications/fixing-vibe-coding-productivity-paradox

4. Red Hat Developer: The uncomfortable truth about vibe coding
   https://developers.redhat.com/articles/2026/02/17/uncomfortable-truth-about-vibe-coding

5. DEV Community: Vibe Coding Is Bad News For Good Ideas
   https://dev.to/mrmatthogg/vibe-coding-is-bad-news-for-good-ideas-1j8g