Vibe Coding的另一半故事：做出产品之后，你能不能守住？

"Vibe coding can build a product. It just can't maintain one. The difference between the two groups isn't skill — it's whether they understand what they built."

写在前面

Pieter Levels 用 3 小时做了个飞行模拟器，10 天后月收入 $100K。Amos 凭借3个人、0融资、AI全栈，做到年入百万美金。Piotr 用"目录站"做到月入$13K，把模版卖了，赚到第二份钱。

这类故事，或自愿，或不自愿，你大概已经听过看过不下 10 遍了。

但是另一个故事，你估计没怎么见过。

某独立开发者纯用 Cursor 做了一个 SaaS，上线、用户进来、庆祝。3 个月后，API 密钥被盗刷，数据库出现损坏，用户抓到漏洞绕过订阅直接白嫖。他打开代码想修，发现看不懂；让 Cursor 修，修一个地方坏另一个地方。最后，产品下线，永久关闭。

我的立场很清楚：Vibe Coding 能帮你做出产品，但它做不了一件事——让产品活过 3 个月。问题不在工具，在你使用它的方式。

如果你现在正在用 Cursor / Lovable / Bolt 构建网站、app，这篇文章或许对你有所启发。

一、Vibe Coding 现在有多普及？

2026年，已经不需要讨论了，数据说明了一切：92% 的美国开发者每天在用 AI 编程工具；GitHub 中有 46% 的新代码由 AI 生成；YC Winter 2025 报告显示，21% 的创业公司代码库里，超过 91% 是 AI 写的。

2025年初，Andrej Karpathy 创造了「Vibe Coding」这个词，年底已经是柯林斯词典年度词汇。到了2026年初，这个词变成了某种骂人的词汇。一旦你对外展示自己的网站或者app，就会听到类似「你这个是 Vibe Coding 出来的吧」的言语，带着些许嘲讽。

Vibe Coding 确实把建产品的门槛降低了，而且降得很彻底。

但，没有人告诉你，那些 AI 生成的网站、app，在6个月后，还有多少在正常运营。

目前没有人公开追踪这个数字。

从某种意义上说，这个缺失本身就值得注意。

二、多数人以为的风险，和真正的风险

大多数人听到「Vibe Coding 有风险」，以为是在说：AI 写的代码质量差。

这是误解。

真正的问题不是代码质量，是代码的可维护性。

AI 写的代码在「能跑起来」这件事上完全没问题。

问题是，当它出错的时候，当需要加一个功能的时候，当用户数量涨了需要优化的时候，你能不能读懂它、改动它、不让它出现连锁式的崩溃？

一个在 IH 社区流传的真实经历：

"他用 Cursor 建了整个 SaaS，零手写代码。上线之后，随机出现奇怪的事情，比如API 密钥被盗刷、订阅无效、数据库损坏。他打开代码想调试，读不懂。让 Cursor 修，每修一个地方都会破坏另一个地方。最后只能下线产品。"

这不是 AI 写的代码质量差，是他不知道自己的产品是怎么运作的。

这是两个完全不同的问题。

三、真实情况：做得到，守不住

Snyk 撰写的报告也把用 Vibe Coding 的人分成了两类：

成功的那批：

用 Vibe Coding 快速验证想法，保留了对核心逻辑的理解。出了问题知道去哪里找。不把 AI 当「黑盒子」，而是当「速度放大器」。

失败的那批：

把 Vibe Coding 当成「不需要懂代码就能做产品」的工具。代码 100% 依赖 AI 生成，出了问题完全靠 AI 修，从来没有读过自己的代码。

以至于，HN 和 IH 社区现在出现了一个新生意：「Vibe Coding cleanup as a service」。

简单说，就是一个帮"失败的那批"人做代码修复或清理的服务。这些服务商说，清理的成本通常比重写更贵。

Snyk 还补了一个数据。

AI 生成的代码里，硬编码 API 密钥和权限配置错误是最常见的安全问题。这类问题在代码审查中容易被发现，但如果你从来没有读过自己的代码……

那你根本就不会知道自己暴露了什么。

四、对正在用 Vibe Coding 建网站的人，具体意味着什么

先说好消息：以上这些问题，都是可以规避的。不需要你变成「真正的程序员」，需要的只是换一种用法。

坏消息是：很多人发现这些问题的时候，产品已经上线了，用户已经在用了，改动的代价比一开始就做对高 10 倍。

所以，其中核心的一个认知转换就是：

Vibe Coding 是速度工具，不是理解工具。

你可以用它快速做出来，但你必须知道「做出来的东西是怎么运作的」。不需要能写，但需要能读、能改、能知道出了问题去哪里找。

如果你现在完全看不懂自己的代码，这不是正常状态。

这是一个定时炸弹。

我在做 OpenClaw 相关网站的时候，也遇到过类似的问题：Agent 跑出来了，但出了 bug 完全不知道从哪开始排查。

我现在的方法就是，一次只让 AI 写一版，我会让 AI 解释自己看不懂的代码，验证跑通之后，然后再搞定下一个。

每一步都保证自己知道发生了什么。

慢是慢了一点，但不会在凌晨3点收到 OpenClaw 打来的电话。

上线之前，检查这 5 件事

如果你正在用 Vibe Coding 建网站或 App，上线之前把这个清单过一遍：

1. 你能不能用自己的话解释这个网站是怎么存数据的？

不需要解释代码，需要解释逻辑。「用户注册之后，数据存在哪，谁能读，谁能改」。这个你应该知道。说不清楚，先搞清楚再上线。这是最基础的，也是最多人跳过的一步。

2. API 密钥有没有暴露在前端？

让 AI 帮你做一次安全检查，具体问：「请检查这个项目里有没有 API 密钥被硬编码在前端代码里，有没有任何密钥出现在 git 历史里」。这件事花 10 分钟，可以避免毁掉整个产品。AI 生成的代码，这是最高频的安全漏洞。

3. 主要流程有没有亲自完整走过一遍？

注册、付费、取消、找不到东西、输错内容，这些流程需要自己以真实的用户视角亲自走一遍。Vibe Coding 生成的代码在「正常路径」上通常没问题，在「边界情况」上经常出错。不要假设 AI 已经处理好了。要假设 AI 没有处理好。

4. 出了大问题，你有没有一个不重建就能修复的路径？

不是让你懂所有技术，是让你在上线前花一小时，把最坏的几个场景在本地模拟一遍。比如，数据库连不上怎么办、支付接口挂了怎么办、用户数据异常怎么排查。知道这些，不是因为它一定会发生，而是当它发生时你不会陷入完全的失控。

5. 你有没有一个「出了问题去哪找答案」的清单？

把你的项目用到的主要技术的官方文档和社区论坛先收藏好。不需要你现在全看完，需要的是出了问题时你知道去哪里找，而不是只能问 AI、依靠 AI，然后越改越乱。