MVP 避坑实录：用 AI 做产品最容易翻车的 8 个地方

同样用 AI 做 MVP，有人两周上线，有人两个月还在改。旁观下来，差距几乎不在 AI 本身的能力——差距全在这 8 个坑踩了几个。

AI 能帮你写代码、生成逻辑、调接口，但它没办法帮你决定"应该做什么"、没办法帮你保管密钥、也没办法替你 commit。每个坑背后都有一个不能外包给 AI 的决定。下面逐个拆开来说。

---

坑一：追求大而全，不做减法

现象：功能列表越列越长——用户系统、多种登录方式、后台管理、数据看板、多语言支持……每一个感觉都"合理"，但三周后还在搭基础设施。

为什么翻：MVP 的 M 是 Minimum，不是 Mediocre。大量精力花在用户可能根本不在乎的功能上，真正需要验证的核心假设反而没跑出来。AI 在这件事上会帮倒忙——你说"给我加个"，它就真的加，不会主动替你砍。

怎么避：启动前写一句话："这个 MVP 要验证的一件事是____。"如果一个功能删掉不影响这个验证，就先不做。用 AI 从零做 SaaS 实战 里有一个从最小功能集倒推的方法，可以参考。

---

坑二：自己造鉴权/支付轮子

现象：一上来就自己写 JWT 生成、密码哈希、支付回调验签逻辑……结果写了一周，发现有漏洞，修洞又一周。

为什么翻：鉴权和支付是典型的"容易写出能跑的、难写出安全的"领域。AI 生成的代码在这两块特别容易产生看起来正确但存在安全缺陷的版本——比如没有防时序攻击的密码比对、不完整的 CSRF 防护。

怎么避：MVP 阶段直接用现成服务。鉴权用 Clerk、Auth.js、Supabase Auth；支付用 Stripe 官方 SDK 加 webhook 验签。这类服务的存在意义就是让你不用自己造轮子。让 AI 帮你集成现成服务，而不是从零实现安全敏感逻辑。

---

坑三：不写 spec，让 AI 瞎发挥

现象：开口就说"帮我做一个用户管理系统"，AI 洋洋洒洒生成一大堆代码，结果里面的表结构、字段命名、权限逻辑全跟自己想的不一样，改起来比重写还难。

为什么翻：AI 是个很会填空的工具，但前提是空得明确。你给的信息越模糊，它越倾向于做出"通用"的设计——而通用设计常常和你的实际需求差距很大。

怎么避：动手前花 20 分钟写一份简单 spec，包括：核心实体和字段、主要用户操作、不做什么。哪怕是一个 Markdown 文件丢进项目目录，让 AI 先读 spec 再写代码，生成质量会明显提高。关于怎么写可执行的 spec，SDD 规范驱动开发：Specify→Plan→Implement 这篇有完整方法论，值得在动工前读一遍。

---

坑四：一个超大 prompt 想一步到位

现象：写了一个 500 字的 prompt，把所有需求塞进去，指望 AI 一次生成完整的产品。结果要么输出一半就截断，要么生成了大量代码但逻辑错漏百出，调试比自己写还费劲。

为什么翻：AI 的生成质量和任务粒度强相关。任务越大，它能"想清楚"的概率越低，中间某个环节出错，后续全错。一次性生成的代码量越大，你能真正验证的概率越低。

怎么避：把大任务拆成小步骤，每一步验证后再继续。比如"先建数据库 schema"→验证→"再写 CRUD 接口"→验证→"再加鉴权"。Plan 模式：先想清楚再动手 里讲的分步策略直接适用。AI 的工作单元应该足够小，小到你能在 5 分钟内判断对不对。

---

坑五：不看 AI 改了啥就确认

现象：AI 说"我已经帮你更新了用户认证逻辑"，你直接按回车确认，继续做下一步。跑起来才发现它顺手把另一个文件里的某个重要函数也改了，而且改坏了。

为什么翻：AI 理解"改这里"的方式是上下文推断，有时候它认为"改这里"意味着同时改几个相关文件。大多数时候它判断得不错，但"大多数"不是"全部"。每次不看 diff 就确认，等于你给一个不是 100% 可信的人签了空白授权书。

怎么避：养成在确认前看 diff 的习惯。用 Claude Code 时，它在执行写操作前会展示变更内容，这时候真的花 10 秒扫一眼。或者在对话里说"先展示你计划改什么，我确认后再执行"。特别是涉及删除文件、修改数据库迁移这类不可逆操作，必看。

---

坑六：硬编码密钥进代码

现象：开发阶段图省事，直接在代码里写 const API_KEY = "sk-xxxxxx"，或者 DATABASE_URL = "postgresql://user:password@host/db"。push 到 GitHub 后才想起来，或者根本没想起来。

为什么翻：GitHub 上有专门爬取硬编码密钥的机器人，代码刚 push 几分钟就可能被扫到。泄露的后果轻则账号被盗、费用被刷，重则数据库直接被拖库。AI 生成示例代码时经常用占位符，但开发者自己替换时很容易直接填真值然后提交。

怎么避：所有密钥、连接字符串、API Key 一律放环境变量，代码里只读变量名。

# .env 文件（加进 .gitignore，绝不提交）
ANTHROPIC_API_KEY=sk-ant-xxxxxxxx
DATABASE_URL=postgresql://user:password@localhost/mydb
STRIPE_SECRET_KEY=sk_test_xxxxxxxx

// 代码里这样读，不要硬编码值
const apiKey = process.env.ANTHROPIC_API_KEY;
const dbUrl = process.env.DATABASE_URL;

项目初始化时第一件事：建 .env.example（填变量名不填值），把 .env 加进 .gitignore。如果已经不小心提交了密钥，立刻去对应平台撤销重建，然后用 git filter-branch 或 BFG Repo-Cleaner 清理历史——但最好的情况是根本不走到这一步。

---

坑七：没版本控制，或者不 commit

现象：没用 git，或者用了但几天才提交一次。AI 改了一堆代码，发现方向不对想退回去，结果找不到"上一个能跑的版本"在哪，只能手动一个个撤销，或者干脆从头再来。

为什么翻：AI 辅助开发的节奏比手写代码快很多，几分钟就能生成大量变更。没有细粒度的 commit，相当于在没有存档的情况下打 Boss，死了只能重头。

怎么避：每完成一个小的可验证单元就 commit。不需要每次都写漂亮的 commit 信息，哪怕是"feat: 基础 CRUD 接口跑通"这种也比没有强。让 AI 帮你 commit 也行，Claude Code 会读 diff 生成有意义的 commit 信息。规则很简单：能跑了就存一下。特别是在 AI 要做较大重构之前，先 commit 当前状态。

# 每隔一个里程碑就存一下，哪怕只是：
git add src/
git commit -m "feat: 用户注册登录基础流程跑通"

---

坑八：只在本地能跑，没考虑部署

现象：本地开发得很顺，功能都跑通了，准备部署时发现：环境变量没配、数据库连接是 localhost、文件路径是 Windows 绝对路径、用了某个本地才有的服务……上线花的时间比开发还久。

为什么翻：AI 生成代码时默认你的运行环境和它的训练数据一致，对"本地开发"和"生产部署"的差异感知很弱。如果你在开发阶段没有主动说"这段代码要能在 Docker/Vercel/Railway 上跑"，它不会主动给你考虑这些。

怎么避：在项目启动之初就把部署环境定下来，告诉 AI。比如"这个项目要部署到 Vercel，后端 API 用 Edge Runtime"或"用 Docker 打包，跑在 Linux 服务器上"。这样它生成的代码、依赖选择、配置方式会更贴近目标环境。另外早一点在真实环境里跑一次——哪怕功能还不完整，先把部署链路通了，后面遇到环境问题可以及时暴露。

---

MVP 启动前自检清单

在开始写第一行代码之前，花 5 分钟过一遍这张清单：

#	检查项	说明	状态
1	写下了"这个 MVP 要验证的一件事"	一句话，明确	☐
2	砍掉了至少一个"合理但非必须"的功能	做减法	☐
3	鉴权/支付用了现成服务，不自己造	Clerk/Stripe 等	☐
4	有一份简单 spec 文档	哪怕一页 Markdown	☐
5	任务已拆分为可独立验证的小步骤	每步 ≤ 2 小时	☐
6	约定了"确认前看 diff"的习惯	特别是批量修改	☐
7	.env 已加入 .gitignore	在第一次 commit 前	☐
8	.env.example 已建好	填变量名，不填值	☐
9	git 仓库已初始化	第一个文件之前	☐
10	约定了 commit 频率（能跑就存）	不超过半天一次	☐
11	目标部署平台已确定	并告知 AI	☐
12	在真实环境跑过一次（哪怕空项目）	提前排查环境差异	☐

全部打勾，开始动工。漏掉的项，大概率会在后面某个地方让你多花几倍的时间补。

---

常见问题

Q：AI 辅助开发是不是比自己写更容易翻车？

不一定更容易翻，但翻的方式不一样。自己写翻车通常是能力边界问题；AI 辅助翻车更多是"AI 给了一个方向，人没有校验"。AI 加速了节奏，同时也放大了决策失误的影响。上面这 8 个坑，手写代码也存在，只是 AI 辅助时每个坑的规模会更大。

Q：spec 要写多详细？MVP 阶段有没有必要花时间在这上面？

MVP 阶段的 spec 不需要复杂，但需要"足够让 AI 做出正确选择"。通常 300-500 字，把核心实体、主要流程、明确不做的事情写清楚就够了。这个投入通常在第一天能收回来——省去后续大量"这不是我要的"的反复修改。

Q：密钥泄露到 GitHub 了，第一步该做什么？

第一步是立刻去对应服务撤销该密钥（不是等清理完 git 历史再撤销，是立刻）。Anthropic API Key 在 console.anthropic.com 撤销，Stripe 在 Stripe Dashboard，其他同理。撤销后再去处理 git 历史。如果不确定密钥已经被扫到，就当成已经被扫了处理。

Q：本地用 SQLite，线上用 PostgreSQL，这个问题 AI 会帮我处理吗？

它能帮你写兼容层，但前提是你告诉它。如果你没说，它通常只按本地环境写。最好的做法是开发阶段也用 PostgreSQL（可以用 Docker 跑本地实例），避免两套数据库带来的行为差异。或者选 Prisma 这类 ORM，把数据库差异屏蔽掉，让 AI 只针对 ORM 层写代码。

Q：这 8 个坑都有了，MVP 就一定能成吗？

这 8 个坑都是"让你在技术执行层面不翻车"的保障，但 MVP 能不能验证出有用的结论，还取决于你有没有找到真实用户、有没有问对问题。规避了技术坑，只是让你有资格跑到验证这一步——然后是产品判断的事，不是工程的事。

---

👉 看看我们的 AI 编程实战体系课，或逛 AI 编程教程大全 把基本功打扎实。