Vibe Coding 陷阱

一位创业者朋友最近给我看了他用 Cursor 在一个周末搭出来的全栈 SaaS。两周后，他的数据库在上线当天彻底锁死。

过去一年里，软件创作的门槛不只是降低；它整个塌掉了。

有了对话式 IDE、前沿模型和自然语言提示，零正规软件工程训练的独立创始人正在一个周末里发布全栈 SaaS 应用。这套打法看起来毫无摩擦：画一个用户流程、用大白话描述数据模型、让 AI 智能体把 React、Next.js 和 API 层缝起来、接上 Stripe，然后上线。

在社交媒体上，这种现象被颂扬为 "vibe coding"。 早期创业者骄傲地宣布技术联合创始人已经过时："既然 LLM 每月花 20 美元就能搭出整条产品路线图，为什么要出让 50% 的公司股权、或者花 15 万美元请一位创始工程师？"

在上线之后令人兴奋的日子里，这套论点看似无懈可击。落地页转化良好。早期用户陆续进来。Stripe webhook 随着首批客户付款响个不停。创始人感觉自己像个 10 倍能人，经营着一家超精益的企业。

然后，第 45 天来了。

一位微型网红发帖介绍了这个工具。流量从 20 个并发会话飙到 1,500。

九十分钟内，数据库连接耗尽并锁死。云厂商和模型厂商的 API 账单一夜之间冲破五位数。客户涌入 Twitter 和邮件客服，投诉重复扣费、账号被删、会话令牌泄露。

惊慌之中，非技术出身的创始人把错误日志贴进聊天提示："服务器抛 500 错误。立刻修好。" AI 照做了，重写了数百行代码。补丁让服务器重新上线——同时悄悄从磁盘上删掉了六周的关系型客户交易历史。

这就是 Vibe Coding 陷阱。

构建软件从未如此之快、如此之便宜。但运营一家可靠的业务也从未如此危险。当 MVP 是在没有架构纪律的情况下生成的，创始人并没有消除技术债务——他们只是以掠夺性的复利利率为它融资。

1、幻象的经济学：当毛利率倒挂

vibe coding 哲学的根本缺陷，是把语法上的可用误当成运营上的可行。

LLM 的训练目标是预测统计上最可能的 token 序列，让代码在 localhost 上跑起来、不立刻抛语法错误。它不会为云成本效率、内存开销或长期单位经济性做优化。

要理解为什么 vibe coded 创业公司在规模化时会大出血，来看一个真实 SaaS 崩盘的财务解剖。

2、一桩 12,000 美元 MRR 的 AI SaaS 尸检

一位独立创始人构建了一个 AI 驱动的法律文档抽取与合同审查平台。

• 定价： 每月 39 美元，"无限合同分析"。
• 获客： 强劲。到第 2 个月，应用已有 310 位付费订阅者。
• 顶层收入： 12,090 美元 MRR。

纸面上，这像一门令人羡慕的自举软件生意。但看看第 2 个月结束时的实际运营资产负债表：

• 前沿模型 API（LLM）：10,850 美元
• 运营缺陷： 不分块、不缓存，把整份 PDF 文本原样塞进提示。
• 托管向量数据库与 Embeddings：1,650 美元
• 运营缺陷： 每一次搜索查询都对相同文档重新建索引。
• 计算与 Serverless 调用：1,280 美元
• 运营缺陷： 重型解析函数跑在未缓存、长时间运行的 Lambda 上。
• 支付网关与管理工具：450 美元
• 运营缺陷： 标准交易手续费与 SaaS 处理开销。
• 总运营成本（COGS）：14,230 美元
• 月度净烧钱：-2,140 美元

The Traditional Software Model:
Revenue:  ────────────────────────► Scales with Users
COGS:     ───────► Stays Near Flat (Gross Margins: 80% - 90%)

The "Vibe-Coded" AI Wrapper Model:
Revenue:  ────────────────────────► Scales Linearly
COGS:     ─────────────────────────────► Scales Super-Linearly (Negative Margins)

尽管订阅增长强劲，创始人每个月仍亏损 2,140 美元。客户越多，公司离资不抵债越近。

3、为什么会这样？

• 上下文窗口暴食： AI 生成的后端被提示为"读文档、回答用户"。由于创始人不懂提示架构或 token 预算，代码在用户每一次追问时都传输整份 80 页合同（约 45,000 个 token），每条消息烧掉 0.15 美元，而不是检索定向的 300 token 片段。
• 语义缓存缺失： 60% 的用户查询是标准问题（"终止条款是什么？""有没有赔偿条款？"）。生产系统会把 embeddings 和历史查询存进 Redis 这类内存缓存。而 vibe coded 系统每次都按全价直打前沿 API。
• 变动算力上的固定费率定价： 创始人把固定收费的订阅（39 美元）与无上限、变动成本的基础设施配在一起。一位企业级重度用户一周内跑了 400 份合同，让创业公司花掉 680 美元算力费，自己却只付了 39 美元。

4、AI 常常摧毁的三大结构支柱

当资深软件架构师审计 AI 生成的代码库时，故障点很少在视觉表现层。React 组件看着光鲜，Tailwind CSS 样式渲染干净，动画干脆利落。

灾难潜伏在吃水线之下，横跨三个关键架构层。

The Vibe-Coded Architecture Iceberg:

▲    [ Slick UI / Landing Page / Auth Buttons ]   <-- Looks Production Ready
───────┼─────────────────────────────────────────────────────────────
       ▼    [ N+1 Query Loops & Unindexed Tables ]       <-- Latency Spike
            [ Unlocked Webhooks & Race Conditions ]      <-- Financial Leakage
            [ Zero RBAC / Vulnerable API Endpoints ]     <-- Compliance Disaster

4.1 数据库连接饥饿与未建索引的查询

关系型数据库引擎（PostgreSQL、MySQL）是受内存与磁盘 I/O 物理规律约束的机械系统，需要有纪律的连接管理。

当 AI 写 Next.js 或 Node.js 后端时：

• 它经常在每个 serverless API 路由里实例化一个新的数据库客户端，而不是维护池化连接。
• 50 个并发用户时，数据库耗尽可用连接槽，抛出 FATAL: remaining connection slots are reserved for non-replication superuser connections。
• 它生成数据库表却不定义 B-Tree 索引或外键约束。

本地开发时表里只有 100 行测试数据，SELECT * FROM orders WHERE user_id = 42 这样的查询 2 毫秒就跑完。

一旦营销活动成功、表里有了 500,000 行，同一条未建索引的查询就会触发顺序磁盘扫描。每一个 API 请求都迫使数据库把数百 MB 原始数据从磁盘读进 RAM，把 CPU 压到 100%，拖垮整个平台。

4.2 状态损坏与缺失的并发控制

localhost 上的软件逻辑顺序执行：请求 A 完成，然后请求 B 开始。

生产环境则处于绝对并行的混乱之中。数百个工作线程并发执行变更。

考虑一个简单的推荐奖励或钱包余额提现。一个典型的 AI 生成端点长这样：

// A typical AI-generated payment logic vulnerability
const user = await db.findUser(userId);

if (user.balance >= withdrawalAmount) {
  // Network delay or concurrent click occurs here
  await paymentGateway.sendFunds(user.payoutAddress, withdrawalAmount);

  const updatedBalance = user.balance - withdrawalAmount;
  await db.updateUserBalance(userId, updatedBalance);
}

在没有受过训练的人眼里，这段代码看起来完全合乎逻辑。

对攻击者来说，或者在网络延迟尖峰时，它就是一个敞开的金库。如果用户快速双击"提现"按钮，或者间隔 5 毫秒发出两个自动化 curl 请求：

• 请求 1 读取余额：100 美元。
• 请求 2 读取余额：100 美元。
• 请求 1 发出 100 美元，把余额设为 0。
• 请求 2 发出 100 美元，把余额设为 0。

客户收到 200 美元，公司损失 100 美元，而数据库里看不出任何错误迹象。

AI 编码模型很少配置原子事务（BEGIN ... COMMIT）、行级锁（SELECT FOR UPDATE）或幂等键，除非由已经懂数据库内部机制的工程师明确指示。

4.3 重复提示悖论（代码库纠缠）

最阴险的运营陷阱，是事情必然出错之后发生的事。

当专业工程师遇到应用 bug 时：

• 他们用分布式追踪和服务器日志隔离错误。
• 他们用确定性的单元测试复现 bug。
• 他们在保留现有接口的前提下修改底层系统逻辑。

当 vibe coding 创始人遇到 bug，他们复制终端错误、贴进聊天窗口："修复这个错误。"

LLM 并没有你整个系统架构的长期记忆。它只看到你提供的那片段。为了消除那个特定错误，它写一个绕过问题的快速补丁——往往是删掉一个认证守卫、禁用一条校验规则，或者硬编码一个环境变量。

The Death Spiral of Re-Prompting:

[Initial Bug: Webhook Fails]
           │
           ▼
 [Prompt AI for Fix] ──► AI rewrites handler, bypassing signature verification
           │
           ▼
 [New Bug: Unauthorized Access]
           │
           ▼
 [Prompt AI for Fix] ──► AI adds brittle regex, breaking mobile app sessions
           │
           ▼
 [Total Codebase Paralysis: Un-auditable Spaghetti Code]

四个月之内，代码库变成一团无法维护的烂摊子。

当创始人终于承认需要人类帮助、去找一位资深软件顾问时，他们得到的是一份令人崩溃的评估："这个代码库救不了。推倒重来、正确重建要花 4 万美元和两个月。"

5、创始人的运营手册：上线前的 4 道护栏

你不需要花四年学计算机，也不需要手写每一行代码。AI 工具是有史以来最强大的生产力放大器。

目标不是抛弃 AI；目标是停止 vibe coding，开始 architectural directing（架构指挥）。

在向头 100 位客户收款之前，用这四条工程指令过一遍你的创业公司：

5.1 施加有界的算力与成本护栏

绝不要部署这样的 AI 包装器或 SaaS 产品：第三方基础设施成本随用户行为无节制地扩张。

• 设定全局硬配额： 在你的 OpenAI、Anthropic 和 AWS 控制台配置硬性支出上限。如果月预算是 500 美元，就设 600 美元的硬顶，超了自动停掉非关键端点，而不是让信用卡暴露在无限计费循环里。
• 分级限流： 用边缘中间件（如 Upstash、Cloudflare Workers）按用户层级强制 token 和请求限额（例如每小时最多 10 次复杂查询）。
• 语义响应缓存： 绝不重复处理相同请求。把高频向量 embeddings 和模型补全存进内存缓存（Redis），TTL（生存时间）设 24 到 72 小时。

5.2 把状态与 AI 生成的代码隔离

用 AI 构建有韧性软件的黄金法则很简单：让 AI 构建表现层和工作流层；让久经考验的托管平台处理身份和资金状态。

• 绝不让 AI 构建自定义认证： 不要让 LLM 写你的会话管理、密码哈希或令牌校验逻辑。使用成熟的基础设施，如 Clerk、Supabase Auth 或 Auth0。
• 绝不让 AI 构建自定义计费引擎： 绝不用裸数据库表去计算剩余订阅、按比例计费或支付重试队列。使用托管计费引擎，如 Stripe Billing、Lemon Squeezy 或 Paddle。
• 强制数据库 Webhook 幂等： Stripe 的每条支付通知都带 event_id。在发放任何积分、代币或数字商品之前，你的数据库必须把该 ID 记录进一张带严格 UNIQUE 约束的独立表。如果网关重试请求，你的系统必须安全地丢弃重复项。

5.3 从"聊天提示"转向严格的 Schema 迁移

别再让 AI 工具用自然语言随意改动你的线上数据库 schema。

-- What an unconstrained AI model writes on the fly:
ALTER TABLE users ADD COLUMN billing_data JSON;

-- What a resilient production system demands:
CREATE TABLE subscriptions (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    user_id UUID NOT NULL REFERENCES users(id) ON DELETE CASCADE,
    stripe_subscription_id VARCHAR(255) NOT NULL UNIQUE,
    status VARCHAR(50) NOT NULL,
    current_period_end TIMESTAMPTZ NOT NULL,
    created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);
CREATE INDEX idx_subscriptions_user ON subscriptions(user_id);

• 要求用声明式 schema 的 ORM（如 Prisma、Drizzle 或 Alembic）产出正式的迁移文件。
• 检查每一张建表语句：有主键吗？外键显式定义了吗？查询密集的列建索引了吗？
• 不要仅仅因为 AI 生成起来更省事，就把关键的关系型数据塞进非结构化 JSON blob 里。

5.4 60 分钟"飞行前"资深审计

早期非技术创始人能做的最划算的资金分配，是花一次、两小时请一位资深首席或 Staff 工程师做架构评审。

在你把毕生积蓄投进数字广告、或在 Product Hunt 公开上线之前：

花 500 到 1,000 美元请一位经验丰富的后端架构师做一次聚焦的技术评审。

请他们审三个具体领域：

• 数据库 Schema 与索引： 系统在 500 个并发连接下会不会趴窝？
• API 认证守卫： 用户 A 能不能通过篡改 URL 参数（/api/invoices?id=102）查看用户 B 的专有业务记录？
• Webhook 与并发处理器： 竞态条件会不会抽干你的 API 额度或重复分配服务？

两小时的审计会揭出任何 AI 模型永远不会提醒你的系统性架构风险——为你省下数月声誉受损的停机时间。

6、战略决策框架：什么该提示，什么该架构

落地页与营销站：

• 可 Vibe-Code 程度： 100%（零风险）
• 最佳方式： Webflow、Framer，或标准的 Next.js UI 提示。

管理后台与内部工具：

• 可 Vibe-Code 程度： 85%（低风险）
• 最佳方式： Retool、生成的 React 仪表盘，或内部管理模板。

核心业务前端 UI：

• 可 Vibe-Code 程度： 80%（低风险）
• 最佳方式： Tailwind CSS、shadcn/ui 和对话式组件提示。

数据抓取与文本转换：

• 可 Vibe-Code 程度： 70%（中等风险）
• 最佳方式： 配置了严格支出上限的 serverless 后台工作者。

用户认证与权限：

• 可 Vibe-Code 程度： 0%（致命风险）
• 最佳方式： 久经考验的托管供应商，如 Clerk、Supabase Auth 或 Auth0。

支付接入与 Webhook：

• 可 Vibe-Code 程度： 0%（致命风险）
• 最佳方式： 托管的 Stripe Checkout，配合严格幂等的处理器。

数据库 Schema 与索引：

• 可 Vibe-Code 程度： 0%（致命风险）
• 最佳方式： 经人工架构审计验证的严格声明式 ORM 迁移。

7、代码是充裕的。系统完整性才是真正的护城河

我们已经进入资本主义的一个变革时代。把抽象商业构想翻译成可运行软件的能力，不再只属于那些花十年掌握底层编程语言的人。

AI 是终极的力量倍增器。它让有远见的运营者、领域专家和草根自举者，得以与资金充足的工程组织竞争。

然而，软件开发受不可变法则支配。语法便宜；数据持久性昂贵。写代码是平凡的；在并发负载下维护状态是困难的。

在 AI 时代建立起持久的、风险投资规模的或高利润自举公司的创始人，不会是那些闭眼 vibe code 到上线日的人。

他们将是纪律严明的创业者：用 AI 加速执行，同时以应有的绝对敬意对待系统架构、运营单位经济性和数据完整性。

"AI 工具不可思议，你绝对应该用它们快速交付。只是要确保你没有为了省几个小时而牺牲你的数据库或用户的数据。"

原文链接: The Vibe Coding Trap: Why AI-Generated MVPs Are Quietly Bankrupting Early-Stage Startups

汇智网翻译整理，转载请标明出处