Vibe Coding 踩坑实录：10个让 AI 编程翻车的常见错误

Vibe Coding 是 2025 年 Karpathy 提出的 AI 编程范式：用自然语言描述需求，AI 生成代码，你觉得"感觉对了"就直接用。这种方式极大提升了开发效率，但如果不知道边界在哪里，翻车只是时间问题。

过去半年，我见证了太多"Vibe Coding 翻车"的惨痛案例：开发环境跑得好好的，一上线就崩溃；AI 生成的代码华丽流畅，但安全漏洞百出。这些问题都指向同一个核心矛盾——效率红利与质量控制的冲突。

今天我要分享 10 个最常见的翻车场景，每个都是实战中踩过的坑，配上可操作的预防措施，帮你在享受 Vibe Coding 效率红利的同时，守住质量底线。

场景1：Promise.all 没有错误处理

问题：AI 生成的并发请求代码用了 Promise.all，但单个接口失败会导致整个请求链路崩溃。

翻车现场：

1
2
3
4
5
6
// AI 生成的代码
const results = await Promise.all([
  fetchUser(id),
  fetchOrders(id),
  fetchPreferences(id)
]);

一旦 fetchOrders 接口挂了，整个函数直接抛异常，前端页面白屏。

根本原因：AI 训练数据中大量的代码示例只展示"正常流程"，缺少异常处理的最佳实践。Promise.all 的"快失败"特性（任何一个 Promise reject 就立即 reject 整个集合）在实战中需要特殊处理。

预防措施：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
// 正确做法：用 Promise.allSettled
const results = await Promise.allSettled([
  fetchUser(id),
  fetchOrders(id),
  fetchPreferences(id)
]);

// 过滤出成功的请求
const successfulResults = results
  .filter(r => r.status === 'fulfilled')
  .map(r => r.value);

// 记录失败的请求（可选）
const failedRequests = results.filter(r => r.status === 'rejected');
if (failedRequests.length > 0) {
  console.error('部分请求失败:', failedRequests);
}

避坑关键点：

并发请求优先用 Promise.allSettled 替代 Promise.all
必须显式处理 rejected 状态，记录或降级
前端给用户明确提示"部分数据加载失败"

场景2：并发请求压垮后端服务

问题：AI 生成的批量操作代码没有限流，1000 个并发请求直接把服务打爆。

翻车现场：

1
2
3
// AI 生成的代码
const users = await getAllUsers();
await Promise.all(users.map(user => sendEmail(user.email)));

测试环境 10 个用户没问题，生产环境 1000 个用户时后端直接 502。

根本原因：AI 的"暴力美学"倾向——遇到批量操作就默认并发。但真实的后端服务有并发上限（如 Nginx 的 worker_connections、数据库连接池），超限直接拒绝服务。

预防措施：

1
2
3
4
5
6
7
8
9
// 使用 p-limit 限制并发数
import pLimit from 'p-limit';

const limit = pLimit(5); // 最多5个并发
const users = await getAllUsers();

await Promise.all(users.map(user =>
  limit(() => sendEmail(user.email))
));

避坑关键点：

批量操作必须加并发限流（推荐 3-10 个并发）
数据库批量插入优先用 INSERT ... VALUES (...), (...), ... 语法
外部 API 调用要考虑对方的速率限制

场景3：EventEmitter 内存泄漏

问题：AI 生成的监听器代码没有清理逻辑，长时间运行的 Node.js 服务内存持续增长，最终 OOM。

翻车现场：

1
2
3
4
5
6
7
8
// AI 生成的代码
app.get('/api/users/:id', (req, res) => {
  const user = users.find(u => u.id === req.params.id);
  
  user.on('update', (data) => {
    res.write(`data: ${JSON.stringify(data)}\n\n`);
  });
});

每次请求都注册监听器，但请求结束后监听器还在，内存不断泄漏。

根本原因：AI 的"单次思维"——只考虑"如何监听"，不考虑"如何清理"。真实的服务器会处理数万次请求，每个监听器都是内存占用。

预防措施：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
app.get('/api/users/:id', (req, res) => {
  const user = users.find(u => u.id === req.params.id);
  
  const updateHandler = (data) => {
    res.write(`data: ${JSON.stringify(data)}\n\n`);
  };
  
  user.on('update', updateHandler);
  
  // 关键：响应结束时清理监听器
  res.on('close', () => {
    user.off('update', updateHandler);
  });
});

避坑关键点：

所有事件监听器必须有对应的清理逻辑
使用 AbortController 管理请求取消
定期用 node --inspect 检查内存占用

场景4：SQL 注入漏洞

问题：AI 生成的数据库查询代码直接拼接字符串，导致 SQL 注入漏洞。

翻车现场：

1
2
3
// AI 生成的代码
const query = `SELECT * FROM users WHERE name = '${name}'`;
const result = await db.query(query);

用户输入 name = "admin' OR '1'='1" 就能绕过登录验证。

根本原因：AI 的"简单优先"策略——拼接字符串比写参数化查询简单 5 倍，所以优先输出简单方案。但安全不是"简单优先"能解决的问题。

预防措施：

1
2
3
4
5
6
7
8
// 使用参数化查询
const result = await db.query(
  'SELECT * FROM users WHERE name = ?',
  [name]
);

// ORM 框架自动防护
const user = await User.findOne({ where: { name } });

避坑关键点：

所有数据库查询必须用参数化或 ORM
CI/CD 流程中集成 sqlmap 自动扫描
使用 TypeScript + Zod 做输入类型校验

场景5：XSS 跨站脚本攻击

问题：AI 生成的渲染代码直接输出用户输入，导致 XSS 攻击。

翻车现场：

1
2
<!-- AI 生成的代码 -->
<div>{{ user.bio }}</div>

用户输入 <script>document.cookie='hacked'</script> 就能执行任意 JS。

根本原因：AI 的"功能优先"思维——先实现"能渲染"，再考虑安全。但真实世界的用户输入充满恶意代码。

预防措施：

1
2
3
4
5
6
7
8
<!-- React/Next.js 自动转义 -->
<div>{user.bio}</div>

<!-- 手动转义 -->
<div dangerouslySetInnerHTML={{ __html: escapeHtml(user.bio) }} />

<!-- 使用 DOMPurify 清洗 -->
<div dangerouslySetInnerHTML={{ __html: DOMPurify.sanitize(user.bio) }} />

避坑关键点：

永远不要用 dangerouslySetInnerHTML，除非经过 DOMPurify 清洗
CSP（Content Security Policy）设置白名单域名
使用 DOMPurify 的 SANITIZE_NAMED_PROPS 选项

场景6：接口超时没有重试机制

问题：AI 生成的 HTTP 请求代码没有超时和重试，偶发的网络抖动导致功能不可用。

翻车现场：

1
2
// AI 生成的代码
const response = await fetch('https://api.example.com/data');

网络抖动一次，整个请求失败，用户看到"网络错误"提示。

根本原因：AI 的"理想化假设"——假设网络永远稳定、接口永远可用。但真实世界的网络充满了不确定性。

预防措施：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
// 使用 axios-retry
import axios from 'axios';
import axiosRetry from 'axios-retry';

const api = axios.create();
axiosRetry(api, {
  retries: 3,
  retryDelay: axiosRetry.exponentialDelay,
  retryCondition: (error) => {
    return axiosRetry.isNetworkOrIdempotentRequestError(error);
  }
});

const response = await api.get('https://api.example.com/data', {
  timeout: 5000
});

避坑关键点：

所有外部请求必须设置超时（推荐 3-5 秒）
幂等操作要重试（GET、PUT、DELETE），非幂等操作不要重试
重试间隔用指数退避（1s → 2s → 4s）

场景7：没有边界条件检查

问题：AI 生成的代码假设"数据永远正常"，遇到空数组、空对象直接崩溃。

翻车现场：

1
2
3
// AI 生成的代码
const firstUser = users[0];
console.log(firstUser.name);

users 是空数组时，firstUser 是 undefined，访问 .name 直接抛异常。

根本原因：AI 的"流程思维"——只考虑"正常流程"，不考虑异常分支。但真实世界的数据总是充满了边界情况。

预防措施：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
// 使用可选链操作符
const firstName = users[0]?.name;

// 显式检查边界
if (users.length === 0) {
  return { error: 'No users found' };
}

// 使用 Zod 做运行时类型检查
const userSchema = z.object({
  name: z.string(),
  age: z.number()
});

避坑关键点：

所有数组/对象访问都要用可选链 ?.
TypeScript 的类型是编译时检查，运行时仍需 Zod 验证
单元测试覆盖空数组、空对象、null、undefined 场景

场景8：文件上传没有大小限制

问题：AI 生成的文件上传代码没有大小限制，用户上传 1GB 文件直接打爆服务器。

翻车现场：

1
2
3
4
// AI 生成的代码
app.post('/upload', upload.single('file'), (req, res) => {
  res.send('File uploaded');
});

用户上传 1GB 视频，磁盘瞬间被占满，服务崩溃。

根本原因：AI 的"功能优先"——先实现"能上传"，不考虑存储限制。但服务器的磁盘是有限的。

预防措施：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
// Multer 配置文件大小限制
import multer from 'multer';

const upload = multer({
  limits: {
    fileSize: 10 * 1024 * 1024 // 10MB
  },
  fileFilter: (req, file, cb) => {
    const allowedTypes = ['image/jpeg', 'image/png'];
    if (!allowedTypes.includes(file.mimetype)) {
      return cb(new Error('Invalid file type'));
    }
    cb(null, true);
  }
});

避坑关键点：

文件大小限制在 10MB 以内（超过 10MB 建议用对象存储）
文件类型白名单（只允许必要格式）
上传前前端做预校验（大小、类型）

场景9：依赖项版本冲突

问题：AI 生成的代码安装了最新版本的依赖，但 API 不兼容导致项目无法运行。

翻车现场：

1
2
# AI 生成的安装命令
npm install react@latest

安装了 React 19（最新版），但项目中的 UI 组件库只支持 React 18，直接报错。

根本原因：AI 的"最新即最好"假设——认为最新版本最稳定、功能最全。但真实世界的依赖升级往往伴随着 Breaking Changes。

预防措施：

1
2
3
4
5
6
7
8
# 锁定主版本号
npm install react@^18.0.0

# 使用 package-lock.json 锁定精确版本
npm ci  # 严格按 package-lock.json 安装

# 使用 npm-check-updates 检查升级风险
npx ncu --interactive

避坑关键点：

依赖版本锁定主版本号（^18.0.0 而非 latest）
CI/CD 流程中用 npm outdated 检查依赖过期
重大升级前先在新分支测试

场景10：环境变量硬编码

问题：AI 生成的代码把数据库密码、API Key 写死在代码里，推送到 GitHub 导致泄露。

翻车现场：

1
2
3
4
5
6
// AI 生成的代码
const db = mysql.createConnection({
  host: 'localhost',
  user: 'root',
  password: '123456' // 密码泄露！
});

代码推送到 GitHub，密码被扫描器发现，数据库被攻击。

根本原因：AI 的"快速原型"思维——先跑通再说，不考虑安全规范。但生产环境的配置泄露是灾难性的。

预防措施：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
// 使用环境变量
const db = mysql.createConnection({
  host: process.env.DB_HOST,
  user: process.env.DB_USER,
  password: process.env.DB_PASSWORD
});

// 使用 .env 文件（不提交到 Git）
// .env.example 提供模板
DB_HOST=localhost
DB_USER=root
DB_PASSWORD=your_password

// .gitignore 中排除 .env
.env

避坑关键点：

所有敏感配置必须从环境变量读取
GitHub Secret 扫描自动检测密码泄露
使用 dotenv-safe 确保 .env 文件完整性

避坑清单：可操作的行动指南

基于以上 10 个翻车场景，我总结了一份可操作的避坑清单，你可以直接集成到开发流程中：

开发前检查（AI 生成代码后）

所有并发请求用 Promise.allSettled 替代 Promise.all
批量操作必须加并发限流（p-limit）
所有事件监听器都有清理逻辑（AbortController）
数据库查询用参数化或 ORM
用户输入渲染用 DOMPurify 清洗

代码审查 Checklist

有没有硬编码的密码、API Key？
外部请求有没有超时和重试机制？
数组/对象访问用了可选链 ?.？
文件上传有没有大小限制？
依赖版本是否锁定主版本号？

CI/CD 流程集成

用 sqlmap 扫描 SQL 注入漏洞
用 xsser 扫描 XSS 漏洞
用 npm audit 检查依赖安全问题
GitHub Secret 扫描自动检测泄露

生产环境监控

APM 工具监控接口响应时间
内存泄漏告警（node --inspect）
错误日志集中收集（Sentry）

正确的 Vibe Coding 工作流

Vibe Coding 不是"完全不看代码"，而是"接受代码无需逐行理解的事实，聚焦于结果是否符合预期"。以下是正确的 Vibe Coding 工作流：

需求描述：用自然语言清晰描述业务意图（“我要一个用户列表页，支持搜索、分页”）
AI 生成：让 AI 生成初步代码（Cursor Composer、Claude Code）
快速验证：在开发环境运行，验证功能是否符合预期
安全加固：用上面的 Checklist 检查并修复常见漏洞
自动化测试：写单元测试覆盖核心逻辑和边界条件
生产部署：集成监控和告警，上线后观察指标

核心原则：

Vibe Coding 适合"快速原型、内部工具、非核心业务"
核心生产系统需要"Vibe 生成 + 人工审查 + 测试覆盖 + 安全扫描"
开发者的职责从"亲手写代码"转向"定义目标 + 质量把关"

总结

Vibe Coding 极大提升了开发效率，但这不意味着可以放弃质量底线。上述 10 个翻车场景的共同特征是：AI 的"快速原型"思维与生产环境的"质量要求"不匹配。

建立正确的 Vibe Coding 工作流，关键在于：

接受代码无需逐行理解，但必须用 Checklist 把控质量
集成自动化工具（安全扫描、测试框架）减少人工审查成本
区分"可 Vibe 场景"（原型、内部工具）和"需审查场景"（核心业务）

记住：Vibe Coding 是效率工具，不是免死金牌。守住质量底线，才能真正享受 AI 编程的红利。

关注 varkm，一起学习，一起成长。