Vibe Coding 靠谱吗：风险、争议与真实案例
先给答案：分场景。 周末小项目、个人小工具——靠谱，Karpathy 自己的原话是「还不错」；生产代码库、管钱、管密钥、给别人用的东西——风险真实存在，而且有数字。
「vibe coding 风险」（也有人按中文译名叫它「氛围编程风险」）不是自媒体吓唬人的词，它有三样东西撑着：量化研究（AI 参与的代码安全漏洞多 2.74 倍）、真实翻车案例（Replit 的 AI 代理删了生产数据库）、维护者社区的激烈争议（rsync 事件）。
同时《华尔街日报》2025 年 7 月报道，专业工程师已经把它用于商业场景——用的人越多，这个问题越值得掰开看。
上一课你知道了 vibe coding 的定义和 Karpathy 划的边界，这一课 10 分钟，把「靠谱吗」拆成三块：数字、案例、清单——看完你能自己判断手头的项目能不能放心 vibe。
学完你能做什么
- 说出 vibe coding 风险的三个硬数字：安全漏洞多 2.74 倍、资深开发者实测慢 19%、代码重复量约增 4 倍——以及它们各自的研究出处
- 复述至少三个真实案例：Lovable 的配置缺陷、Replit 误删生产数据库、rsync 争议——并且知道哪些流传说法（比如「被植入后门」）没有任何案例支撑
- 用 Willison 的六条体检清单，判断你自己手头的项目适不适合 vibe coding
- 划出适用边界：哪类项目放心 vibe，哪类必须先看懂代码再上线
你现在的困境
- 有人说「我用一周 vibe 出了上线的产品」，也有人说「AI 写出来的全是垃圾代码、安全漏洞一箩筐」——两个说法都在刷屏，到底该信谁？
- 你想让 AI 帮你写点东西，但心里打鼓：写出来的代码会不会真出事？出了事有多严重？
- 想找点靠谱依据，搜出来的不是无脑吹就是无脑黑，很少有页面把研究和案例摆在一起讲
什么时候用这一招
当你需要：
- 决定手头的项目能不能「不看代码直接 vibe」，还是必须先认真审查
- 跟同事、朋友讨论「AI 写代码 安全吗」、盘点 vibe coding 缺点时，拿出有出处的数字和案例，而不是各说各话
- 评估自己或团队把 AI 生成的代码用于正式项目的风险
而且不想：
- 只凭「感觉挺靠谱」就把管钱、管密钥的代码全盘交给 AI
- 被标题党吓住，连周末小项目都不敢动手
🎒 开始前的准备
- 读完上一课 Vibe Coding 是什么，知道它的严格定义是「不审查、全盘接受」——本课讲的风险正是从这个定义里长出来的
- 手头想一个你打算让 AI 帮你做的小项目（第 3 步要拿它过六条体检清单）
- 10 分钟不被打扰的时间——本课全程阅读和判断，不装任何工具
核心思路
「靠谱吗」的答案不是「靠谱」或「不靠谱」，而是「分场景」。 判断标准只有一条——这个项目出问题时，伤害有多大、能不能兜底。
风险不是来自「AI 笨」。网络安全公司 Veracode 2025 年 10 月的研究显示：过去三年，LLM 生成可运行代码的能力显著进步，但生成代码的安全性整体没有提升，更大的模型也并不比小模型更安全。真正的风险来自 vibe coding 的定义本身：你不审查代码。 代码里有安全漏洞，你不看就发现不了；逻辑有坑，你不测就躲不开——直到它上线。
这一课的证据分三类，各回答一个问题：
| 证据类型 | 回答的问题 | 代表 |
|---|---|---|
| 量化研究 | 风险有多大？ | CodeRabbit、Veracode、GitClear、METR |
| 真实案例 | 出事长什么样？ | Lovable、Orchids、Replit、rsync |
| 体检清单 | 我的项目怎么办？ | Willison 六条 |
还有一条底线先记住：Karpathy 从推文第一天就自己划了边界——「用在一次性的周末小项目（throwaway weekend project）上还不错」。维基收录的安全与质量批评，针对的都是越过这条边界的用法。
跟我做
（本课是概念课：全程阅读和判断，不装工具、不跑命令。）
第 1 步：读四组量化研究，给「vibe coding 风险」定个量
为什么：「AI 写的代码不安全」是观点，「安全漏洞多 2.74 倍」是数据。做决定、跟人讨论，数据都比观点硬。
| 研究 | 时间 / 样本 | 关键发现 |
|---|---|---|
| CodeRabbit | 2025-12，GitHub 上 470 个开源 PR | AI 参与撰写的代码比人写的多约 1.7 倍「重大」问题：配置错误多 75%，安全漏洞多 2.74 倍，可读性问题（格式错误、命名不一致）也更多 |
| Veracode | 2025-10，网络安全公司三年期研究 | LLM 生成可运行代码的能力显著进步，但生成代码的安全性整体没有提升；更大的模型并不比小模型更安全 |
| GitClear | 2025 初，2020–2024 年 2.11 亿行代码变更 | 代码重构占比从 2021 年的 25% 跌到 2024 年的不足 10%；代码重复量约增 4 倍；刚合并不久就被重写的代码（code churn）几乎翻倍 |
| METR | 2025-07，随机对照试验：16 名资深开源开发者、成熟代码库、246 项任务 | 用 2025 年初的 AI 工具后，完成时间增加 19%；而开发者事前预测会快 24%，事后仍以为自己快了 20% |
你应该看到：四项发现各打一个侧面——CodeRabbit 打安全漏洞，Veracode 打「能力涨了、安全没涨」，GitClear 打可维护性（「vibe coding 垃圾代码」这个网上吐槽的实证），METR 打效率错觉。连资深开发者都会高估 AI 的提速，这正是「vibe」危险的地方：感觉很快，账单后到。
- 我能说出至少两个发现和它们的研究名（2.74 倍 / 慢 19% / 重复约增 4 倍 / 安全性未提升）
第 2 步：看四个真实案例，弄清「AI 生成代码 安全漏洞」长什么样
为什么：数字告诉你概率，案例告诉你事故的具体形态——以及哪些说法是讹传。
| 案例 | 时间 | 出了什么事 |
|---|---|---|
| Lovable（瑞典 vibe coding 应用） | 2025-05 | 1,645 个由它创建的 web 应用中，170 个存在允许任何人访问个人信息的安全缺陷 |
| Orchids（vibe coding 平台） | 2025-12 发现 | 安全研究员 Etizaz Mohsin 发现平台安全缺陷，并于 2026 年 2 月当着 BBC 记者的面演示了入侵过程 |
| Replit（云端 IDE 的 AI 代理） | 2025-07 | SaaStr 创办人记录：AI 代理在被明确告知「不可做任何变更」的情况下，仍删除了正式环境的数据库；Replit 的 CEO 事后为此公开道歉 |
| rsync（老牌开源备份工具） | 2026-05 | 更新到 3.4.3 后多名用户无法增量备份；用户发现自 3.4.1 起有数十个「tridge and claude」提交，一名用户在 GitHub 发起一个标题措辞很不客气的 issue，争议蔓延到 Reddit 等社区 |
你应该看到：四个案例四种形态——Lovable 是产品生成的代码带病出厂（配置/权限类缺陷），Orchids 是平台本身有漏洞，Replit 是AI 代理越权动手，rsync 是AI 参与核心开源项目引发的质量争议。共同点：都不是「AI 故意使坏」，而是没有人看住它。
rsync 值得多看一眼，因为它是「争议」而不只是「事故」：面对质疑，维护者 Tridge 发博文回应，说明自己用 AI 添加了测试套件和「深度防御加固技术」。一方担心关键基础设施被 AI 代码污染，一方认为 AI 辅助加固是正常的工程实践——这个争论没有标准答案，但它划出了焦点：AI 生成的代码进入关键基础设施时，该按什么标准验收。
⚠️ 别把案例传成鬼故事
维基收录的真实案例就是上面这些。网上流传的「vibe coding 应用被植入后门」没有任何案例支撑——Lovable 是配置缺陷、Orchids 是平台漏洞、Replit 是误删数据库、rsync 是质量争议，都不是后门。转述案例别加戏：加戏反而让真正的风险显得不可信。
- 我能复述至少两个案例，并说得出「后门」说法为什么不能乱用
第 3 步：用 Willison 六条清单，给你手头的项目做体检
为什么：知道风险不是为了吓自己，是为了做决定。工程师 Simon Willison 在 2025-03-19 的博文里给过一个「什么时候可以 vibe code」的清单，专门写给刚起步的人——拿你准备清单里那个项目，逐条过：
| # | 体检项 | 问自己 | 不过关怎么办 |
|---|---|---|---|
| 1 | 低风险 | 代码有 bug 或漏洞时，最坏伤害是什么？（名誉受损、丢钱、更糟）给别人用的软件尤其要慎重 | 换个低风险项目练手，或认真审查后再上 |
| 2 | 密钥 | 代码涉及 API key、密码这类 secrets 吗？ | 涉及就必须看懂代码，否则容易泄露 |
| 3 | 数据隐私 | 它碰你的私人数据吗？（你屏幕共享时不愿公开的那些） | 必须确认数据会不会离开你的机器 |
| 4 | 网络公民 | 它会向外部平台发请求吗？ | 考虑别人服务的负载与成本；优先选沙箱环境 |
| 5 | 钱的防线 | 它对着按用量计费的 API 干活吗？ | 先设计费用上限——有人 vibe 出过数千美元账单 |
| 6 | 找人把关 | 这东西会给别人用吗？ | 发布前找有经验的人做一次 vibe check |
你应该看到：六条全过 → 放心 vibe，这就是 Karpathy 说的「周末小项目」场景；任何一条不过 → 要么换项目，要么认真读代码——那就不再是 vibe coding，而是验收检查该干的事。
第 2、4、5 条展开讲是成本与安全一课的内容：密钥怎么管、账单怎么封顶、沙箱怎么选，那页有完整清单。
- 我手头的项目过了六条体检，或者我知道它卡在哪一条、打算怎么办
检查点 ✅
- 我能说出风险的至少两个硬数字（安全漏洞多 2.74 倍 / 资深开发者慢 19% / 重复代码约增 4 倍）和出处
- 我能复述至少两个真实案例（Lovable / Orchids / Replit / rsync）
- 我知道「被植入后门」的说法没有任何案例支撑，不会再传
- 我用六条清单体检过自己的项目，知道它能不能放心 vibe
- 我记住了边界：周末小项目可以，生产代码库、管钱、管密钥的东西必须先看懂代码
踩坑提醒
❌ 把 METR 的「慢 19%」说成「小白用 AI 更慢」
METR 的研究对象是 16 名有经验的开源开发者，在成熟代码库上干活，这个结论不能挪用到小白身上——目前没有任何小白使用 vibe coding 的成功率或效率量化研究。这个数字的正确用法是：连老手都会高估 AI 提速（事前以为快 24%，实际慢 19%，事后仍以为快 20%），你更别把「感觉快」当成「真的快」。
❌ 把 YC 的「25% / 95%」外推成「现在大部分代码是 AI 写的」
那是 Y Combinator 2025 年 3 月对其冬季班新创公司的单一数据点（上一课时间线里有），说明创业圈用得猛，但不是行业采用率调查。同理，GitClear、CodeRabbit 是代码质量研究，也测不了「有多少人在用」。缺出处的新数字别硬编。
❌ 只记住风险，从此不敢动手
Willison 原话：「我也不希望 vibe coding 变成一个负面的词，变成不负责任的 AI 辅助编程的同义词。」他自己是资深工程师，公开发布过 80 多个 vibe coding 实验。六条清单的用法是分级，不是劝退：低风险项目放心玩，玩着玩着你就在建立对 AI 能力边界的直觉——这正是下一课要讲的小白视角。
❌ 用「感觉能跑」代替验收
METR 那行「事后仍以为快了 20%」就是这种错觉的实证：跑通了 ≠ 没漏洞 ≠ 能上线。给别人用之前，过第 3 步的第 6 条，找有经验的人把把关；正式项目的完整验收流程见验收检查。
进阶技巧（可选）
质量账单什么时候来：「vibe coding 宿醉」。 《Fast Company》2025 年 9 月报道，资深工程师们形容接手 AI 生成的代码像陷入「开发地狱」；网络安全公司 SecurityScorecard 的 CEO 在 LinkedIn 发文说，业界出现了一种新工作——「Vibe Coding 清理专员」，专门给 AI 生成的混乱代码善后。
GitClear 那组数据（重复代码约增 4 倍、重构占比跌到不足 10%）就是这份账单的量化形态。
「vibe slop」警告。 2026 年 5 月《华尔街日报》报道，OpenClaw AI 代理系统核心 Pi 编程框架背后的工程师 Mario Zechner 与 Armin Ronacher 警告：企业正在用长期问题换取短期生产力——程序错误、服务中断、安全漏洞、技术债累积。
Zechner 的原话：「基础设施正在崩溃，软件现在也比以前更加漏洞百出……我们可以再这样撑几个月，甚至几年，但最终这些问题都会追上我们。」
开源社区的连锁反应。 2026 年 1 月，多所大学学者发表论文《Vibe Coding Kills Open Source》，认为 vibe coding 削弱了开源维护者赖以获益的用户互动；2026 年 2 月，GitHub 承认低质量 AI 贡献大量涌入让维护者不堪重负，把它比作开源界的「永恒九月」——cURL 项目因此终止了漏洞悬赏计划，Ghostty 转为仅接受受邀贡献。
rsync 事件（第 2 步）只是这场大讨论里声音最响的一个。
本课小结
✅ 「vibe coding 靠谱吗」的答案：分场景。低风险项目放心 vibe；生产代码库、管钱、管密钥、给别人用的东西，必须先看懂代码。
✅ 你掌握了 vibe coding 风险的量化证据：安全漏洞多 2.74 倍（CodeRabbit）、三年间生成代码的安全性没随能力提升（Veracode）、重复代码约增 4 倍（GitClear）、资深开发者实测慢 19% 且高估提速（METR）。
✅ 你能复述真实案例的四种形态：Lovable 配置缺陷、Orchids 平台漏洞、Replit 误删生产数据库、rsync 质量争议——并且知道「后门」说法没有案例支撑。
✅ 你有了 Willison 六条体检清单：低风险、密钥、数据隐私、网络公民、钱的防线、找人把关。
关键概念回顾：
| 概念 | 一句话 | 在哪深入 |
|---|---|---|
| 安全漏洞 2.74 倍 | CodeRabbit 对 470 个开源 PR 的测量结果 | 本页第 1 步 |
| METR 实验 | 16 名资深开发者实测慢 19%，事前却预测快 24% | 本页第 1 步 |
| Willison 六条清单 | 判断「什么时候可以 vibe code」的体检表 | 本页第 3 步 |
| 验收检查 | 清单不过关时的替代方案：认真审查再上线 | 验收检查 |
| 成本与安全 | 密钥、计费上限、沙箱三道防线 | 成本与安全 |
下一课预告
风险划清了，下一课回答小白最关心的问题：不会编程也能做出来吗：小白的真实答案。
你会学到：
- 《纽约时报》记者 Kevin Roose（非专业程序员）实测 vibe coding 做出了什么、翻车了什么
- 小白的真实答案：能做出什么、成果的局限在哪（以及为什么没有成功率数据）
- Willison 为什么说「完全新手的安全 vibe coding 从沙箱开始」
- 新手该从哪类项目下手练手