Vibe Coding 违背了它的承诺

在任何一个开发者论坛上待一小时，你都会看到同一份自白被写成一百种不同的样子。有人用 AI 工具在一个周末里搭出了自己的应用。它跑起来了。他上线了。现在是周一，认证坏了，数据库在无声无息地丢行，而那个谁都无法复现的 bug，恰恰就是正在赶走客户的那一个。

半年前我们互相售卖的那个梦，如今站在门口，要求退款。

我想谨慎地说这件事，因为我并不认为造出或用过这些工具的人，当初的兴奋是错的。那次跃进是真实的。看着一个能用的界面从一段平实的英文里显形，是过去十年软件领域里真正有魔力的体验之一。我也感受到了。我们都感受到了。

但在演示和部署之间的某处，发生了一次无声的替换。我们开始把原型叫作产品。我们开始把演示叫作软件。而这场混淆的账单，现在到期了。

误诊

我看到的最常见解释是怪模型。AI 还不够聪明。它会幻觉。它挑错了库。它写出资深工程师会抓住并重写的代码。

这个解释令人安心，因为它暗示解决方案已经在路上了。等半年。下一代模型会更好。差距终会弥合，一切都能跑起来。

我不相信。而我不相信的原因是：我反复看到的失败模式，跟代码质量毫无关系。

微软在 2025 年财报电话会上披露，GitHub Copilot 活跃用户提交的全部代码中，约 46% 现在由 AI 生成。大约同一时期，应用安全公司 Veracode 发布研究，发现 AI 生成的代码在其测试样本中约 45% 引入了安全漏洞。这些数字在变好之前会先变糟，而更聪明的模型并不会修好它们。

问题不在模型。问题在流程。

真正缺失的是什么

带我走一遍 vibe coding 应用是怎么造出来的，然后告诉我架构决策是在哪一步做出的。

你描述你想要什么。AI 生成一个界面和背后的一些代码。你看看界面，点来点去，它大致做了你要的事，于是你宣布完成。在这个循环里，没有任何一刻有谁——人或机器——停下来定义究竟在造什么。

没有 schema。没有数据模型。没有系统可能处于哪些状态的清单，也没有对何谓有效的定义。前端和那个假装是后端的东西之间没有契约。用户做出生成器没预料到的动作时会发生什么，没人做过决定，因为没人预料过。

被造出来的，是一个在你演示时恰好走过的那条特定路径上、看起来像你要的东西的东西。走出那条路径，整个结构就现出脚手架的原形。底下从来没有建筑。

这不是智能的失败。这是定义的失败。而对一个未定义的问题施加再多智能，也不会产出一个已定义的结果。它只会产出同一副脚手架的、更有说服力的版本。

从未被做出的三个决策

让我具体一点，因为抽象正是这场对话一直在原地打转的原因。

认证不是之后再加的功能。它是关于你的用户是谁、他们能看到什么、你的应用坐在哪条信任边界上的决策。在上线两周后把它硬装到一个 vibe coding 应用上，相当于给一栈没有墙的房子安装前门。

数据库 schema 不是 AI 该在生成写入表单的同时去猜的东西。schema 是应用的脊梁。它下游的每一个决策——你能查询什么、能索引什么、之后能改动什么而不至于全盘崩塌——都被事先做出或没做出的选择所限制。当 schema 是即兴发挥的，之后每一次改动都是一次翻修。

API 契约不是可选项——而且在一个 AI agent 直接消费软件的经济里，它比界面更接近产品本身。你的应用一旦要和别的东西对话——支付处理商、邮件服务、另一套软件、一个 AI agent——就必须有一个被定义的接触面。没有它，集成就变成一连串一次性的临时拼凑，没人能维护，也没人愿意接手。

这些都不是高深话题。它们是造出能活过第一个周末的软件的最低门槛。而当整个构建流程就是「描述、看到、上线」时，被跳过的恰恰就是这些。

70% 问题现在有了名字

我不认为有谁是刻意要造出一个交付脆弱软件的行业。我认为这个赛道里冒出来的工具，都在为那个能卖出工具的瞬间做优化——那个魔法时刻，一个想法在一分钟内变成一块能用的屏幕。

「到魔法的时间」成了被度量的东西。「到生产的时间」是别人的问题。

对一场演示来说，这是合理的优化。对一个如今要负责把真实应用交付给真实用户、真金白银押在上面的软件赛道来说，这是糟糕的优化。它把整整一代开发者搁浅在 90% 的刻度上，手里拿着一个在自己屏幕上能跑、在别处处处崩塌的东西。

Lovable 社区里的开发者给它起了个名字——70% 问题。你做到某个感觉快完成的地步，然后进展停住了。每一次修复都会弄坏别的东西。剩下的活儿不是你能靠提示词一路穿过去的，因为挡住你的不是缺失的代码。是一个几百代生成之前、被无声做出的、缺失的决策。

这个赛道的肮脏秘密是：容易的那部分是前 90%。接下来的 9%——让它真正能服务超过一个用户、超过一台设备、在你没预料到的条件下运行——比前 90% 加起来还难。而最后的 1%，那个把能用的应用和脆弱的应用区分开来的部分，是要求你在开始之前就知道自己在造什么的那部分。

AI 没有改变的那条规则

这是没人想听的话，因为在一个本该全是向前冲的时刻，它听起来像后退一步。

最好的软件从来都是从定义开始的。架构先于代码。在写下任何一行之前，先对问题有清晰的模型。五十人的工程团队手工搭建系统时是这样，如今一个人加一个模型能在一个周末里搭出同一套系统时，也还是这样。

AI 没有改变这条规则。AI 让它更重要，而不是更不重要。

当生产代码的成本趋近于零，生产错误代码的成本也趋近于零。这意味着唯一还有代价的事，是弄清楚正确的代码本该是什么。那份工作——定义的工作、架构的工作、你在开始造之前先决定究竟要造什么的那部分——是唯一没有被廉价商品化的部分。

它也正是当前这一代工具跳过的部分。

这条路真正通向哪里

我不认为答案是放慢速度。我不认为答案是回去手写一切。跃进是真实的，而跃进会留下来。

答案是把定义这一步嵌进循环里——也就是业界现在称为规范驱动开发的做法。不是作为拖慢你的人工关卡，而是作为其余工作真正立于其上的地基。正在琢磨怎么做这件事的人，做的是比你一直看到的更安静的东西。他们即将让这个赛道的喧闹版本，显出它一直以来的本相。关于下一代究竟长什么样，我另外写过。

一块能用的屏幕从来都不等于一套能用的系统。我们都即将重新想起为什么。

延伸阅读

取而代之的是什么：规范驱动开发。这些工具现在如何相比：2026 年最好的 AI 应用构建器。

常见问题

「vibe coding」是什么意思？ Vibe coding 是指用平实的语言描述你想要什么，然后接受 AI 生成的结果，而不指定底下的架构、数据模型或契约。Andrej Karpathy 在 2025 年初提出了这个词。它描述的是一种工作方式，而不是一类工具——你几乎可以在任何 AI 构建器里做 vibe coding。

为什么 vibe coding 做出来的应用会在生产环境崩掉？ 因为这个失败是结构性的，不是代码质量问题。生成循环从不产出 schema、一组被定义的有效状态，或前后端之间的契约。应用在被演示的那条路径上能跑，离开它就崩塌。对一个未定义的问题施加更聪明的模型，得到的仍然是未定义的结果。

什么是 70% 问题？ 它指的是这样一种模式：AI 搭建的应用做到约 70% 完成度后就停止推进——每次修复都弄坏别的东西，再多的提示词也补不上这个缺口。阻塞点通常是几百代生成之前被隐含做出的某个架构决策，不重写就再也改不动了。

AI 生成的代码更不安全吗？ 目前的证据是它需要审查。Veracode 的研究发现，AI 生成的代码在其测试样本中约 45% 引入了安全漏洞；同一时期微软披露，GitHub Copilot 活跃用户提交的代码约 46% 由 AI 生成。产量增长的速度快于验证。

这是否意味着不该用 AI 应用构建器？ 不。对原型、演示和内部工具来说，它们真的很出色，速度也是真的。这里的论点更窄：一块能用的屏幕不是一套能用的系统，而跳过定义阶段的工具，无论模型变得多好，都产不出后者。