Vibe 编码宿醉是真实的：关于生产环境中 AI 生成代码，没人告诉你的事
Source: Dev.to
上个月，一位创业公司的创始人把他们的代码库发给我审查。他自豪地说：“用 Cursor 在一个周末完成的，已经准备好用于我们的 A 轮演示。”
我打开了仓库。三十秒后，我关闭了 Slack，给自己倒了一杯酒。
代码能够运行。这不是问题。问题在于它只能暂时运行——靠胶带、祈祷以及 Claude 那个星期二下午的某种幻觉支撑着。
这就是 vibe‑coding hangover。如果你今年已经将 AI 生成的代码投产，可能已经感受到了它。
什么是真正的 Vibe Coding？
该术语在 2025 年初因 Andrej Karpathy 在推特上谈到“完全顺从氛围”和“忘记代码的存在”而走红。
Collins Dictionary 刚刚将其评为 2025 年度词汇。
现在 84 % 的开发者 每天都在使用 AI 编码工具。
但这里没有人提及：实际上关于 vibe coding 有 两个定义 在流传，混淆它们正导致混乱。
| Definition | Description |
|---|---|
| 1. The Meme | “我不阅读代码。我只接受 AI 给我的内容，然后继续。” |
| 2. The Reality | “我使用 AI 更快生成模板代码，但我仍然审查所有内容并理解发生了什么。” |
大多数恐怖故事来自 Definition 1。大多数生产力提升来自 Definition 2。
问题是？每个人都 认为 自己在做 Definition 2。
我在每个 Vibe‑Coding 灾难中看到的 5 大模式
在审阅了今年 15 + 个 vibe‑coding 项目——从周末小玩意到已获融资的初创公司——后，我识别出了反复出现的噩梦。
1. “在我的机器上可以工作”幻觉
AI 在解决 happy path（理想路径）方面异常擅长。让 Claude 构建一个登录表单，你会得到一个漂亮的表单，只要用户输入有效的邮箱和正确的密码就能完美运行。
但如果问它以下情况会怎样：
- 有人向邮箱字段粘贴 50 000 字符
- 数据库连接在认证过程中超时
- 用户双击提交按钮
- 会话在表单加载到提交之间过期
鸦雀无声。
我上个月审查了一个支付处理流程。AI 生成的代码对成功支付处理得天衣无缝。失败支付呢？错误处理竟然只有：
} catch (error) {
console.log("Something went wrong");
}就这么简单。放在处理真实金钱的支付系统里。
2. 架构失忆症
肮脏的秘密： AI 不会记住你的架构。
每一次提示都是一次全新的开始。所以当你在周一请求功能 A，周二请求功能 B，周三请求功能 C 时，你会得到三个在各自孤立环境下完美合理的功能——但组合在一起却是彻底的混乱。
我见过：
- 同一个 React 应用里出现三种不同的状态管理方案
- 绕过你专门为安全设置的 ORM 的数据库查询
- 认证逻辑在 七 个地方被重复实现（且实现方式各不相同）
- API 端点返回 四 种不同格式的数据
AI 为每个问题都提供了最优解，但它没有“我们出于某种原因决定这么做”的概念。
3. 安全定时炸弹
这点让我彻夜难眠。
一家瑞典的 vibe‑coding 平台 Lovable 今年早些时候进行过安全审计。在使用该工具构建的 1 645 个应用中，170 个存在漏洞，能够让任何查看的人获取用户数据。
这相当于 10 % 的关键失败率，而这些应用的创始人本以为已经可以投入生产。
常见模式：
// AI‑生成的“认证”
const isAdmin = req.query.admin === 'true';
// AI‑生成的“数据库查询”
const user = await db.query(`SELECT * FROM users WHERE id = ${userId}`);
// AI‑生成的“文件上传”
const filename = req.file.originalname;
fs.writeFileSync(`./uploads/${filename}`, req.file.buffer);每段代码都是 textbook（教科书式）的安全失误：SQL 注入、路径遍历、通过查询参数提升权限。
它们能工作并通过手动测试，所以演示看起来很棒——直到真的有人尝试利用它们。
4. 调试噩梦
一位审查过 vibe‑coded 应用的开发者告诉我：
“调试 AI 生成的代码比手写代码还要困难。”
为什么？因为当你自己写代码时，你会在脑中构建它的工作模型。你知道为什么变量叫 tempBuffer，你记得在第 47 行处理的边缘情况。
而在 vibe‑coded 项目里，你在调试的是别人的代码——不过“别人”根本不存在。写代码的 AI 并不记得之前的对话。
我花了 6 小时 在一个 vibe‑coded 代码库里追踪一个 bug。问题出在两个几乎同名的函数（processUserData 与 processUserInfo）却执行完全不同的逻辑。一个在生产环境被调用，另一个才是实际能正确工作的那个。
AI 在不同时间生成了这两个函数，分别用不同方式解决同一个问题，而开发者根本没有注意到。
5. 意大利面雪崩
每个 AI 编码工具都有自己的“风格”。有的偏爱函数式写法，有的喜欢类。有人会生成注释，有的人则不写。有人使用 async/await，有人则用 .then() 链式。
当你在数周或数月内进行 vibe‑coding 时，最终的代码库看起来就像是 50 位从未交流过的开发者 合写的——因为这正是实际发生的情况。
ened.
我审查了一个 Next.js 应用，其中：
- 一些 API 路由使用 App Router 模式，另一些使用 Pages Router 模式
- 有些路由直接把原始 Express 中间件塞进了两个路由器
- 数据获取在不同组件中分别使用 SWR、React Query 和 原始
fetch
每个部分单独运行都没问题，但整体上难以维护。
数据不会说谎
让我们来看看研究实际显示了什么。
生产力神话
是的，AI 可以提升短期速度，但技术债务、安全事件和入职摩擦的长期成本往往超过收益。
| 指标 | 仅 AI（定义 1） | AI 辅助（定义 2） |
|---|---|---|
| 首次生产缺陷的平均时间 | 3 天 | 1 天 |
| 每 100 个仓库的安全事件数 | 12 | 3 |
| 开发者满意度（1‑10） | 4 | 7 |
| 维护成本增长（年度） | 45 % | 12 % |
替代方案
- 将 AI 视为配对程序员，而非魔法师。
- 执行审查清单（安全、错误处理、风格）。
- 在共享设计文档中锁定架构决策，供 AI 参考。
- 自动化 lint、测试和静态分析，捕获 AI 漏掉的低挂果实。
- 分配重构时间——不要把 AI 的初稿直接标记为“完成”。
TL;DR
Vibe coding 并非本质上邪恶，但 定义很重要。如果你只接受 AI 输出的任何内容，你最终会得到脆弱、不安全且难以维护的系统。使用 AI 来 加速样板代码，仍然审查所有内容，并 保持架构一致。否则，你将继续为后遗症付出代价。
辅助编码：现实检查
在受控研究中，辅助编码可以将开发时间缩短 25‑50 %。
但谷歌的 DORA 研究发现，在真实的企业环境中，严重依赖 AI 助手的团队在考虑调试和返工后，实际上显示出 交付时间更慢。
质量差距
- Microsoft 和 IBM 估计他们的代码中约 20‑30 % 已经是 AI 生成的。
- IBM 的 CEO 表示，这一比例将会 保持，因为 AI 代码的维护负担使得更高的比例不可持续。
1.5 万亿美元问题
行业分析师预测，到 2027 年，AI 生成代码将累计产生 $1.5 trillion 的技术债务。
这不是打字错误——trillion，带有 T。
那么到底有什么方法有效？
我并不是反对 AI 编码。我每天使用 Cursor 和 Claude Code，但我的使用方式与“vibe coding”梗所暗示的截然不同。
“AI 指挥家”方法
把自己想象成一位 指挥家，而不是乘客。
AI 应该做的事
- 生成你本来就会写的模板代码。
- 提出你可以评估的方案。
- 为你理解的逻辑编写测试。
- 解释你正在审阅的代码。
- 重构已有代码，使其更简洁。
AI 不应做的事
- 做出架构决策。
- 在未经审查的情况下处理安全关键路径。
- 生成你无法解释的代码。
- 编写你没有精确定义的业务逻辑。
30 秒规则
在接受任何 AI 生成的代码之前，问自己：
“我能在 30 秒内向一名初级开发者解释这段代码的作用吗？”
如果答案是 否，就不要合并，直接拒绝。
这条规则帮我避免了大约 80 % 本可能发布的 bug。
评审仪式
每段 AI 生成的代码都要经过：
- 通读 – 我是否理解每一行？
- 边界情况检查 –
null/undefined/空值/超大输入会怎样？ - 安全检查 – 用户输入是否得到安全处理？
- 架构匹配 – 这段代码是否符合我们代码库的整体设计？
整个过程只需 5 分钟，却为我省下了 数百小时 的调试时间。
关于初级开发者的真实对话
vibe‑coding 的热潮对初级开发者的伤害最大。
- 高级开发者 使用 AI 来外包 敲键盘，而不是思考。他们已经知道好代码的样子，并能凭多年经验对 AI 输出进行评估。
- 初级开发者 使用 AI 来外包 学习。他们跳过了理解 为什么 能工作的环节，导致技能差距日益扩大。
我面试过一些初级开发者，他们可以“用 AI 构建任何东西”，却解释不清
for循环是如何工作的。他们可以通过提示得到一个可运行的应用，却在出现问题时束手无策。
给新手开发者的建议：
先掌握基础。把 AI 当作工具，而不是拐杖。 那些在 2026 年及以后能够 thriving 的开发者，正是那些懂得何时 AI 出错的人。
结论
Vibe coding 本身并非好坏之分。它是一种工具，和所有工具一样，结果取决于使用它的人。
- 有经验的开发者 使用 AI 加速他们深刻理解的工作 → 很棒。你的生产力可能比以往任何时候都高。
- 交付你并未完全理解的 AI 生成代码 → 你在沙子上建房。后遗症即将到来。可能是下周，也可能是明年，但迟早会来。
问题不在于 AI 是否改变了我们的编码方式——它已经改变了。
问题在于你是把它当作 强力工具，还是当作 逃避困难部分的借口。
明智选择。
你在生产环境中使用 AI 生成代码的体验如何？
你是否已经感受到 vibe‑coding 的后遗症？在评论中分享你的恐怖故事（或成功案例）。