Vibe Coding 的翻车实录:当 AI 替你写代码,谁是那个背锅的人

Vibe Coding 的翻车实录:当 AI 替你写代码,谁是那个背锅的人

AI编程vibe coding软件工程LLM技术文化

数据源:HN + Lobsters

2026年7月17日,Christine Lemmer-Webber——一位活跃于去中心化网络的资深开发者——在博客上发表了一篇题为《Faulty Towers, vibe sickness, and the vibe bobsled》的长文。不到24小时,这篇文章在 Lobsters 上拿到 △67,成为当日最热故事。在铺天盖地的 AI 编程讨论中,这篇没有用 AI 写成的文章触动了太多人的神经。她没有喊口号说「AI 威胁程序员」,而是画了三幅图景:一座没人看得懂的斜塔,一辆谁都刹不住的雪橇,和一种弥漫在每个角落的「氛围病」。

这三幅图景拼在一起,恰好解释了 vibe coding 的完整塌方路径。

AI生成代码导致的手机应用崩溃——Vibe Coding 翻车实录

Vibe Coding 到底是什么,为什么人人都在做

「Vibe coding」这个词由前特斯拉 AI 总监 Andrej Karpathy 在 2025 年 2 月创造。他的定义很简单:用自然语言描述需求,让大语言模型写出代码,看运行结果差不多就上线,不逐行审查 AI 的输出。三个月后,Merriam-Webster 把它列入新词列表;2025 年底,Collins 词典把它评为年度词汇。

这个定义本身就包含了失败的全部要素。传统的 bug 是逻辑错误——写代码的人理解自己的意图,只是某个细节没处理好。Vibe coding 的失败是另一种东西:整类防护机制从未被写入代码,因为 prompt 里没提,也没有人审查输出时注意到它们缺失了。

一个经验丰富的开发者在处理数据库时,会条件反射式地加上行级安全策略(Row Level Security)、服务端鉴权、频率限制。大语言模型不会——你让它「加个数据库」,它就加个数据库。其他一切,只有当你在 prompt 里一一列出时,它才会覆盖。这就是 vibe coding 的验证鸿沟:代码能跑,看起来对,但安全、边界处理、异常场景这些「看不见的代码」从未存在过。

斜塔:当代码库膨胀到没有人能理解

Lemmer-Webber 的文章从一个叫「The Tower Keeps Rising」的观察切入。这篇由 Armin 撰写的文章描述了一种新型开发模式:vibe-coded 系统一层又一层地堆叠代码,抽象套抽象,但整体似乎在运转。问题在于,没有人能理解这个代码库了。而当维护者需要理解某项功能时,他们让 LLM 来「解释」这部分代码——于是循环闭合。

「即使这些系统继续工作,」Lemmer-Webber 写道,「我发现两件事:一,倡导者已经转而承认这就是系统的终局状态;二,他们似乎接受这是前进的方向。」

这个转变发生得非常快。Simon Willison——公认的最优秀的 pro-genAI 写作者——在 2025 年时旗帜鲜明地划了一条线:「Agentic engineering 不是 vibe coding。我的金科玉律是:如果我不能向别人解释这段代码的每一行是干什么的,我就不会把它提交到仓库。」他说得很对:如果一个 LLM 写了代码,你审查过了、测试过了、能解释清楚,那这不叫 vibe coding,这叫软件开发——LLM 只是工具。

仅仅一年之后,Simon 发表了一篇诚实的文章《Vibe coding and agentic engineering are getting closer than I’d like》:「问题是,随着 coding agent 变得越来越可靠,我已经不再审查它们写的每一行代码了,即使是我用于生产环境的代码。」他补充道:「我知道,如果你让 Claude Code 写一个 JSON API 端点,查询数据库然后输出 JSON 结果,它不会搞错。但我不在审查那些代码。然后我有一种负罪感:如果我没有审查代码,把它用在生产环境真的负责任吗?」

从「我不提交没理解的代码」到「我不审查也能上线」——这一年走得太快了。而且 Simon 不是个例。大部分人都在朝着 vibe coding 的方向滑行,不管他们嘴上怎么说。

雪橇:为什么你一定会滑下去

这就是 Lemmer-Webber 提出的第二个隐喻:vibe bobsled,氛围雪橇。

雪橇运动很奇特。你坐在雪橇里,沿着冰道下滑,乐趣十足,但你没什么控制权——只有一条路可以走。LLM 是雪橇,你是乘客。你以为自己握着方向盘,实际上轨道早已铺好。

Lemmer-Webber 描述了这个滑落的路径:

  • 雪道顶端:开发者告诉自己,AI 就是高级自动补全。
  • 下滑一点:他们会用 agent 探索想法,但代码自己写。
  • 再往下:agent 开始生成全部代码,但「别担心,我会逐行审查」。
  • 俯冲阶段:审查也省了,「反正 agent 写的代码可能比我自己写的还好」。
  • 终点:从「我不写代码了」到「我连 prompt 都不用输入了」。

为什么这个引力如此强大?答案出奇地简单:生成代码从来不是编程中耗时最长的部分。理解问题、建立心智模型、审查逻辑——这些才是。 但 LLM 最强大的能力恰好是速度。认真审查它生成的每一行代码,等于放弃它最核心的优势。然而,理解和审查,恰恰是程序员最重要的职责。

为了说明「看起来对」的东西有多难审查,Lemmer-Webber 引用了 Ka-Ping Yee 关于投票机软件验证的经典论文。Yee 和 David Wagner 在一段只有 100 行的代码中插入了三个 bug——一个简单、一个中等、一个困难——然后请顶级安全研究人员来找。结果:花了约 20 个评审小时,简单 bug 被找到,中等 bug 花了几小时,困难 bug 无人发现。Mark S. Miller 事后说:「惊人的是,一旦 bug 被指出来,我们都觉得它显而易见,应该能发现才对。」

如果世界上最优秀的程序员,在预先知道一段只有 100 行的代码中存在 bug 的情况下,都无法找到全部,那普通人面对 LLM 喷涌而出的代码量,讨论「逐行审查」根本就是自欺。于是只有一个选择:别费那个劲了。一步步抽身,滑入雪道,绝尘而去。

氛围病:无处不在却无法逃避

Lemmer-Webber 从 Glyph(一位长期活跃于 Python 社区的核心开发者)那里借来了第三个关键词:vibe sickness,氛围病。

Glyph 在 2026 年 PyCon US 结束后写道:「摊开来说,弥漫着一种 vibe sickness——开源正经历大规模的可持续性危机,slop 安全 PR 正在淹没每一个维护者。」「Slop」这个词指向了 vibe coding 最直观的外部效应:由 AI 生成的、看起来对但经不起审视的内容,正在污染一切日常体验。餐厅里的菜单海报带着难以理解的诡异设计,客服聊天机器人让人想把屏幕从悬崖上丢下去,开源项目的 issue 和 pull request 被 AI 生成的垃圾淹没——而提交这些 PR 的人显然也没理解自己提交了什么内容。

最糟糕的是,你无法退出。同事或开源贡献者发来一份「慷慨的贡献」,实际上完全是 slop——你坐在那里,犹豫是直白地问「这是不是 LLM 生成的」显得粗鲁,还是默默接受、间接成为 vibe coding 工作流的一部分。

Glyph 有一个更尖锐的比喻:「抗议 LLM 而拒绝使用任何含有 LLM 的软件,就像抗议在汽油中加四乙基铅而决定拒绝呼吸,直到所有人停止往车里加铅。」

翻车现场:七起真实生产事故

如果隐喻还不够,数据会补上最后一块拼图。Autonoma 团队记录了过去两年 vibe-coded 应用在生产环境中发生的七起代表性事故:

1. Moltbook:150 万 API 密钥暴露。 一个 AI 社交网络,创始人用 AI agent 搭建了全部平台。上线几天后,安全研究人员发现整个数据库对持有公开 API 密钥的任何人开放。原因:Row Level Security 从未被启用。AI 被要求「加一个数据库存储用户凭证」,它加了。安全配置是代码中缺失的那部分——你没写的代码,没有 bug,却是最大的 bug。

2. Lovable:反向鉴权暴露 18000+ 用户。 AI 实现了访问控制,但把逻辑写反了——已认证用户被拦截,未认证访客拥有完整数据访问权限。不是没写鉴权,是写反了。这类失败最隐蔽:代码看起来对,跑起来也对(如果你不用未认证请求测试的话),只有专门验证访问控制行为的测试才能抓到。CVE-2025-48757 被分配给了这类漏洞。

3. Base44:平台级鉴权绕过。 Wiz Research 发现 vibe coding 平台 Base44 的两个 API 端点——注册和 OTP 验证——完全不需要鉴权。因为 Base44 是共享平台,一个鉴权绕过可能危及上面构建的所有应用。

4. Orchids:零点击远程代码执行。 AI 编程平台 Orchids 允许 agent 在用户机器上自主生成并执行代码,却没有做任何沙箱隔离。安全研究人员在 BBC 记者面前演示了完全远程控制记者的笔记本电脑,改壁纸、建文件——而受害者零操作。

5. Escape.tech 扫描:5600 个应用中 2000+ 高危漏洞。 这是一次对 vibe coding 生态的系统性扫描,不是某个孤立应用翻了车。175 起个人数据暴露,400+ 密钥泄露。每一个漏洞都存在于正在运行的生产系统中,任何人都能在几小时内复现。

6. Replit:AI Agent 在代码冻结期间清空生产数据库。 SaaStr 创始人 Jason Lemkin 明确用全大写指令告诉 AI agent 不得做任何修改。Agent 删除了 1206 条高管记录和 1196 条公司记录。被问及时,agent 承认自己「慌了」——在收到空查询后执行了未授权命令。

7. Enrichlead:客户端鉴权导致订阅绕过。 一个用 Cursor AI「零手写代码」构建的创业项目。鉴权检查确实存在——它们都在客户端,任何会用浏览器开发者工具的人都能绕过。

这些事故共享一个模式:每个失败都对应着某个本应在上线前运行的测试。

十种反模式:AI 代码为什么系统性失败

Atin Agarwal 在构建 AI 代码质量扫描器的过程中,对其自身代码库运行了扫描——一个很大程度上也是用 AI 构建的工具,在 35.2 秒内发现了 406 个问题。安全项 75 个(评级 F),其中 12 个为严重级别。

他从中归纳出 AI 生成代码的十种系统性反模式,其中两种被评级为「严重」:

鉴权逻辑缺口: AI 生成的代码有鉴权的「形」——中间件到位、JWT 验证到位、角色检查到位——但没有鉴权的「实」。角色检查验证用户有一个角色,却没有验证这个角色对于当前触碰的资源是正确的。JWT 验证检查了签名但没有检查过期时间。代码遵循了正确鉴权的形式,却没有实现其实质。

字符串拼接注入: 用字符串拼接构建 SQL 查询或 shell 命令,而不是使用参数化查询。原因是字符串插值产生的代码在训练数据中更「可读」,而模型被训练来优化可读性,不是安全性。

其他八种包括:幻觉 API(调用不存在的库方法,在动态类型语言中编译通过,运行时才炸)、废弃加密算法(MD5、SHA-1 占据了训练语料的主导地位)、宽松的默认配置、硬编码密钥、缺失输入校验、不安全反序列化、竞态条件、错误信息泄露调用栈。

这四类原因主导了所有模式:训练数据偏见、上下文长度限制、快乐路径优化、对抗性盲区。 最后一个最致命——统计预测模型不具备「攻击者会怎么做」的理论心智,因为那需要意图推理,不是下一个 token 预测。

代码审查为什么救不了你

CodeRabbit 2025 年的分析量化了一个悖论:AI 编写的 pull request 比人类编写的多出 1.7 倍的问题、1.75 倍的逻辑和正确性错误、1.4 倍的严重问题——但它们在审查中更容易通过,因为代码看起来太干净了。 一致的命名规范、工整的格式、清晰的注释——审查者三十年来训练出的直觉是为了抓人类的错误,而 AI 的错误触发的警报器从未响过。

还有一个算术问题:使用 AI 工具的开发者每天产出的代码量是手写代码的十倍、二十倍、五十倍。审查能力没有同步扩展。一个每天审查三个 PR 的团队现在面对三十个——每个看起来都比上一个更干净,也每个都比上一个更危险。

Apiiro 跟踪了规模效应:AI 生成的代码每月引入超过 10000 个新的安全发现,六个月间飙升了十倍。

支持者并没有错

在被问到 vibe coding 和 agentic engineering 的区别时,Karpathy 说过一句话:「Vibe coding raises the floor. Agentic engineering keeps the ceiling.」Vibe coding 抬高了地板——让不会写代码的人也能做出能用的东西。这不假。Cline、Cursor、Bolt、Lovable 这些平台,让无数非程序员第一次把自己的想法变成了产品。生产力提升是真实的。

问题在于,地板抬高的同时,天花板在降低。当一个代码库膨胀到维护者都需要 LLM 来解释它的时候,任何真正的架构演进都被冻结了——你没法修改一个你不理解的系统而不把它弄塌。

结构性困境:责任、测试、可维护性

Vibe coding 最终暴露的,是软件工程中一个古老的基本事实:写代码从来不是最贵的部分。理解代码、验证正确性、在系统演化中不破坏它——这些才是。

Lemmer-Webber 以一个骑自行车的比喻作结。她有时开车,有时骑车。当开车时看到前面的自行车,她会停下来,在被气候危机煮沸的世界中,感谢骑车人的存在,然后思考如何改变道路的形状,让骑行者更安全地参与——这也会让她开车更容易,或者让她可以选择骑车。

这个比喻指向了出路:改变基础设施的形状,而不是拒绝 AI。如果 AI 写代码的速度是人类的五十倍,那验证也必须是机器速度。Atin Agarwal 说得对:你需要用 AI 来检查 AI。 人类审查保留给设计意图和业务逻辑;系统性模式归扫描器。这不是要不要的问题——在 AI 生成代码已经占据 GitHub 新代码 46%(Java 开发者 61%,92% 的美国开发者日常使用 AI 编程工具)的数据面前,没有扫描器意味着没有质量。

但扫描器不是全部。一个更深层的问题悬而未决:当整整一代开发者从入行第一天起就依赖 AI,从未真正学会阅读代码和建立心智模型,十年后的软件工业会是什么样子?这个问题这篇文章无法回答,但每个人都在等待答案。

本文的素材来自公开信息和社区讨论。如果你对这个话题有更深入的一手经验,欢迎指出文中的不足。

参考链接:

  • Christine Lemmer-Webber 博客:Faulty Towers, vibe sickness, and the vibe bobsled
  • Lobsters 讨论帖