我用 Vibe Coding 做了个 SaaS，聊聊踩过的坑

最近半年，Vibe Coding 这个词火得一塌糊涂。2025 年 2 月 Andrej Karpathy 发了条推特，说"最火的新编程语言是英语"，然后整个技术圈就炸了。到 2026 年，84% 的开发者已经在用 AI 辅助写代码了，但只有 29% 真正信任它生成的代码。

我就是那 84% 之一。

三个月前，我决定用 Vibe Coding 的方式从零做一个 SaaS 产品——一个面向独立开发者的 API 监控平台。Cursor + Claude Code 双管齐下，两周搞定了 MVP。上线第一天就有 50 个用户注册。

听起来很爽对吧？但接下来的一个月，我才真正体会到什么叫"Vibe Coding 的暗面"。

先说说什么是 Vibe Coding

简单说，就是用自然语言告诉 AI 你想做什么，让 AI 帮你写代码。你不关心语法，不关心实现细节，你只管描述需求，AI 来输出。

工具链很简单：

Cursor：基于 VS Code 的 AI 编辑器，内置 Composer 可以直接对话生成代码
Claude Code：终端里的 AI 编程助手，能直接操作文件系统
GitHub Copilot：老牌 AI 补全工具，写代码时实时建议

我的工作流大概是这样的：

1\. 描述需求："做一个用户认证系统，JWT + PostgreSQL"
2\. AI 生成代码
3\. Review → 提出修改意见
4\. 迭代直到满意
5\. 下一个功能

看起来很美好。但魔鬼在细节里。

坑一：代码能跑，但你不知道它在干嘛

Vibe Coding 最大的陷阱就是：代码看起来能工作，但你看不懂它的架构决策。

我让用户认证模块完全由 Cursor 生成。第一天跑得很好，注册登录都 OK。直到第三周我想加个"记住我"的功能，打开代码一看：

// AI 生成的认证中间件
const authMiddleware = async (req, res, next) => {
  const token = req.headers.authorization?.split(' ')[1];
  if (!token) return res.status(401).json({ error: 'No token' });

  try {
    const decoded = jwt.verify(token, process.env.JWT_SECRET);
    // 等等，这里为什么又查了一次数据库？
    const user = await db.query('SELECT * FROM users WHERE id = $1', [decoded.id]);
    if (!user.rows[0]) return res.status(401).json({ error: 'User not found' });
    req.user = user.rows[0];
    next();
  } catch (err) {
    // 这里把所有错误都当成 token 过期处理了
    return res.status(401).json({ error: 'Token expired' });
  }
};

问题一堆：

每次请求都查数据库，decoded 里已经有完整用户信息了
catch 块把所有错误统一处理成"Token expired"，包括签名验证失败
没有 token 刷新机制

这不是 AI 的错，是我的错。我告诉它"做个 JWT 认证"，它就做了。但"做好"和"做对"是两码事。

教训：Vibe Coding 生成的代码，review 比写更重要。 不能因为它能跑就觉得没问题。

坑二：安全漏洞是真的多

2026 年初有份研究扫描了 5600 个用 Vibe Coding 工具做的应用，结果触目惊心：45% 的 AI 生成代码存在安全漏洞。

我的 SaaS 上线第二周就被白帽朋友扫了一遍，发现三个问题：

1. SQL 注入漏洞

AI 给我生成了这样的代码：

// 危险！直接拼接用户输入
app.get('/api/logs', async (req, res) => {
  const { service, date } = req.query;
  const result = await db.query(
    `SELECT * FROM logs WHERE service = '${service}' AND created_at > '${date}'`
  );
  res.json(result.rows);
});

我让 Cursor 改成参数化查询，它改了一半，有些地方还是拼接的。AI 生成的安全代码往往"80% 对，20% 有洞"，而这 20% 足以致命。

2. 硬编码的密钥

# AI 在某个配置文件里"贴心地"放了默认值
REDIS_URL = "redis://localhost:6379"
JWT_SECRET = "your-secret-key-here"  # ← 这个直接上了生产
STRIPE_KEY = "sk_test_xxxxx"  # ← 测试密钥也没换

3. 缺少速率限制

登录接口没有 rate limiting，任何人都可以暴力破解。AI 觉得"这不是核心功能"就跳过了。

教训：上线前必须做安全审计，不能信 AI 的"默认安全"。 用 npm audit、Snyk 或者 CodeQL 扫一遍，比什么都管用。

坑三：技术债堆积如山

CodeRabbit 的研究显示，AI 辅助写的代码 bug 率是手写的 1.7 倍。不是因为 AI 笨，而是因为 Vibe Coding 的工作流天然导致技术债积累。

我的 SaaS 用了两个月，代码量从 3000 行涨到 12000 行。然后我发现：

同一个功能有三种实现方式：用户列表分页，一个模块用 offset，一个用 cursor，一个用内存切片
依赖版本冲突：AI 在不同时间建议了不同版本的库，package.json 里 lodash 既有 4.x 又有 3.x 的残留
没有统一的错误处理：有的地方用 try-catch，有的用 .catch()，有的直接忽略

# 我做了个简单统计
$ grep -r "TODO\|FIXME\|HACK\|XXX" src/ | wc -l
47

# 四十七个 TODO...三个月前的代码...

教训：每完成一个功能，花 20% 的时间重构。 Vibe Coding 适合快速原型，不适合长期维护。你得自己当架构师，不能把架构决策也外包给 AI。

坑四：上下文丢失，越聊越偏

Claude Code 和 Cursor 都有上下文窗口限制。当你聊了几十轮之后，AI 开始"失忆"。

有一次我让它优化数据库查询性能，聊着聊着它突然改了我的 API 路由格式。我问它为什么改路由，它说"你之前说要统一 API 风格"——那是五天前的需求，我早就放弃了。

更离谱的是，有一次它把我的测试数据当成了生产逻辑，硬是给一个只在开发环境用的 mock 用户加了权限校验。

解决方案：

用 CLAUDE.md 或 .cursorrules 文件固化项目上下文
每个功能开发前，先写技术文档，再让 AI 按文档实现
重要决策用 TODO 注释标记，防止 AI 擅自修改

# .cursorrules
## 项目约束
- 数据库：PostgreSQL 16，禁止拼接 SQL
- 认证：JWT + refresh token，不查数据库
- 错误处理：统一用 AppError 类
- 测试：每个 API 端点至少 3 个测试用例
- 禁止：硬编码任何密钥/URL

坑五：部署和运维是另一个故事

Vibe Coding 在开发阶段很爽，到部署就懵了。

AI 可以帮你写 Dockerfile，但它不知道你的服务器配置：

# AI 生成的 Dockerfile
FROM node:20
WORKDIR /app
COPY . .
RUN npm install
RUN npm run build
EXPOSE 3000
CMD ["npm", "start"]

看着没问题，但：

没有多阶段构建，镜像 1.2GB
npm install 没加 --production，开发依赖也打包进去了
没有 health check，容器挂了 Docker 不知道
没有非 root 用户，安全审计直接不过

后来我手写了一个：

FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --production=false
COPY . .
RUN npm run build

FROM node:20-alpine
RUN addgroup -g 1001 -S appgroup && \
    adduser -S appuser -u 1001 -G appgroup
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
COPY --from=builder /app/package.json ./
USER appuser
EXPOSE 3000
HEALTHCHECK --interval=30s --timeout=3s \
  CMD wget --spider -q http://localhost:3000/health || exit 1
CMD ["node", "dist/index.js"]

镜像从 1.2GB 降到 180MB。

那 Vibe Coding 到底值不值？

值，但有条件。

适合 Vibe Coding 的场景：

快速验证想法，MVP 阶段
写 CRUD、脚手架、测试用例
学习新技术栈时辅助理解
写文档、生成 schema

不适合的场景：

安全敏感的核心模块
性能关键路径
长期维护的基础设施代码
架构设计决策

我的结论是：Vibe Coding 是油门，不是方向盘。 它能让你跑得更快，但方向还是得自己把握。

我现在的最佳实践

先写 SPEC 再让 AI 写代码：用自然语言描述需求、约束、验收标准，AI 按 SPEC 实现
小步迭代：每次只让 AI 做一个小功能，做完 review 再继续
强制 Code Review：AI 写的每一行代码都要人过一遍，不能跳过
自动化安全扫描：CI/CD 里集成 Snyk + ESLint 安全插件
定期重构：每两周花一天时间清理 AI 产生的技术债
核心模块手写：认证、支付、权限这些，还是自己来

三个月下来，我的 SaaS 月活到了 2000，月收入 5 位数。Vibe Coding 帮我用 30% 的时间完成了 70% 的工作，但剩下那 30% 的关键部分，我花的时间一点都不比传统开发少。

一句话总结：Vibe Coding 是 2026 年最高效的生产力工具，但它不是银弹。用得好是加速器，用不好是灾难。

你也在用 Vibe Coding 做项目吗？欢迎在评论区聊聊你的踩坑经历。

我用 Vibe Coding 做了个 SaaS，聊聊踩过的坑