AI面包君Learn · Build · Share
全部文章
Vibe CodingAI面包君

从玩具到上线：MVP 部署、安全与"AI 写的代码能用吗"

我加了三四个 Vibe Coding 的社群，时间长了我观察到一个很扎心的事：

2026-06-06约 10 分钟

Vibe Coding 指南 · 第 08 篇 · 系列收官

😶 一个让人脸红的统计

我加了三四个 Vibe Coding 的社群，时间长了我观察到一个很扎心的事：

90% 的人，做出了 demo。10% 的人，跑通了 MVP。1% 的人，让真用户用上了。

为什么？

因为大部分人到了 demo 阶段，就开始"再加个功能"——加完一个又一个，越加越多，最终累得没力气上线。或者，临到上线发现"咦，我的 API key 是不是裸露在代码里？"、"咦，鉴权好像没做"、"咦，要部署到哪？怎么搞域名？"——一连串问号，把上线的劲儿磨没了。

Demo 不是终点。能用、可用、有人在用——才是。

这一篇是系列的收官，专门讲怎么把你的 Vibe Coded 产品从"玩具"推到"真用户面前"。

包括三件事：

  1. MVP 收尾：怎么判断够了、别再加功能
  2. 安全 Pass：让 AI 帮你过一遍上线前的检查
  3. 部署落地：Vercel + 域名 + 数据库的最简栈

最后回应一个绕不开的争议——"AI 写的代码到底能不能用？"

🛑 MVP 收尾：管住"再加一个功能"的手

一个反直觉的规则

Vibe Coding 因为太爽了，会让你陷入一种**"加功能上瘾"**的状态。

你做出了登录、报告生成、PDF 导出。然后你想——"诶，要不要加个分享？"加完——"那协作呢？"加完——"加个 AI 自动总结？"

停。

按理说"加功能"是好事——但你忘了：每加一个功能，都会破坏你已经测试过的东西、引入新 bug、让上线时间往后推一周。

MVP 的 M 是 Minimum——最小可行。它的核心精神是"先让一个用户用起来，剩下的看反馈再说"。

怎么判断"够了"？

下面这张 checklist，每条都打勾，就上线：

[ ] PRD 里的 3 个 P0 功能全部跑通
[ ] 关键路径（用户从打开到完成核心动作）<30 秒
[ ] 没有阻塞性 bug（点了不响应、报错就崩）
[ ] 至少自己使用过 3 次，不感到痛苦
[ ] 有一个目标用户答应试用（你心里那个第一个用户）
[ ] 知道你想从用户那里学什么（最关键的反馈问题）

全部打勾 → 上线。不全 → 想办法补这几条，不要加新功能。

一个精妙的类比

MVP 上线就像给朋友请客。

  • 错误做法：菜准备 30 道，桌子布置 3 小时，结果客人已经饿走了
  • 正确做法：4 个菜 + 1 个汤，朋友坐下就吃，吃完聊"下次想吃啥"

你的第一个用户就是来吃 4 个菜的，不是来吃满汉全席的。

🖼️ 图片建议： 两幅对比图。左边："功能加成瘾"——一个程序员对着电脑加菜，桌上 20 道菜，朋友已经在门外离开。右边："MVP 上线"——4 道菜简单上桌，朋友愉快开吃，背景是"反馈→优化→再上"的循环箭头。

🛡️ 上线前的安全 Pass（这一节别跳过）

这是 Vibe Coding 最容易翻车的地方——因为 AI 不会主动帮你想安全。

你让 AI 写"用户登录功能"，它就老老实实写登录。但它不会跟你说：

  • "你这个 .env 文件没加到 .gitignore，API key 推到 GitHub 就泄露了"
  • "你前端直接调用了 OpenAI，用户 F12 就能看到你的 key"
  • "你的 admin 接口没鉴权，用户改个 URL 就能操作别人数据"

这些不是 AI 不智能，是 AI 在等你"问"。

上线前必跑的 5 个检查

打开你的项目，跟 AI 说这段话——这是一个非常好用的"安全审查咒语"：

ultrathink，请对项目做完整的上线前安全审查，
按以下 5 个维度列出所有发现的问题：

1. 【密钥泄露】
   - 检查 .env / .env.local 是否在 .gitignore
   - 检查代码里是否硬编码了 API key、密码、token
   - 检查前端代码里是否暴露了应该只在服务端的密钥

2. 【鉴权与授权】
   - 列出所有 API 路由，每个标注鉴权状态
   - 找出"未登录可访问"的接口（看是否真该开放）
   - 找出"用户 A 能访问用户 B 数据"的漏洞

3. 【输入校验】
   - 检查所有用户输入字段（form / URL params / body）
   - 标注哪些没做长度限制、类型校验、特殊字符过滤
   - SQL 注入 / XSS 风险点

4. 【依赖安全】
   - 跑 npm audit 看有没有已知漏洞的依赖
   - 列出大版本过旧的关键库

5. 【生产配置】
   - DEBUG 模式是否关闭
   - 错误信息是否还在向用户暴露内部细节
   - 速率限制 / 防刷是否到位

按【严重程度】排序输出，每个问题给修复建议。

AI 会给你一个长清单。 你按严重程度，从高到低修。

关键判断：所有"高"严重程度问题必须修。中和低的可以等上线后再修。

三个最常见的低级错误（我自己都犯过）

错误 1：.env 文件推到 GitHub

修复：

# 在 .gitignore 加一行
.env
.env.local

# 然后从 git 历史删除（如果已经推了）
git rm --cached .env
git commit -m "remove .env from tracking"

而且 API key 已经泄露的，必须去 OpenAI/Supabase 控制台轮换一次。

错误 2：API key 写在前端

如果你直接在 React 组件里写：

const response = await fetch('https://api.openai.com/v1/chat/completions', {
  headers: { 'Authorization': `Bearer ${OPENAI_KEY}` }
});

用户 F12 就能看到你的 key。每月几百美元的账单等着你。

正确做法：所有调用第三方 API 的代码必须在服务端（Next.js 的 API Routes / 后端函数）。前端只调用你自己的服务端 API。

错误 3：admin 接口不鉴权

你写了一个 /api/delete-all-reports 用来管理后台用。但没加鉴权——任何人构造 URL 都能调。

修复：所有 admin / 内部接口必须加鉴权中间件，检查 session 或 token。

🖼️ 图片建议： 一张"安全门"插画。一个房子门口贴着 5 个锁，每个锁标着一个检查项（密钥、鉴权、输入、依赖、配置）。门内是温馨的房间（你的应用），门外是一群黑帽小人物（"用户"）。色调一半危险红、一半安全绿。

🚀 部署：3 步把你的应用推上线

技术栈如果是 Next.js + Supabase（第 03 篇推荐的栈），部署超级简单：

Step 1：推 GitHub

# 在项目目录
git remote add origin https://github.com/你的用户名/项目名.git
git branch -M main
git push -u origin main

不会用 GitHub？让 AI 教你：

我从来没用过 GitHub。一步步教我：
1. 怎么注册 GitHub 账号
2. 怎么创建一个新仓库
3. 怎么把当前项目推上去
4. 把每步要敲的命令完整给我

Step 2：连 Vercel

  1. 打开 vercel.com，用 GitHub 账号登录
  2. 点 "Add New Project"
  3. 选你刚才推上去的仓库
  4. 不用改任何设置，直接 "Deploy"
  5. 等 2 分钟

完事了。你拿到一个 xxx.vercel.app 的网址，可以分享给任何人。

Step 3：配置环境变量

如果你用了 Supabase 或 OpenAI API：

  1. 在 Vercel 项目里，点 Settings → Environment Variables
  2. 把所有 .env.local 里的变量都加进去（OPENAI_API_KEY、SUPABASE_URL 等）
  3. 触发一次重新部署

Step 4（可选）：绑定自己的域名

  1. 在 Namecheap / Cloudflare 等域名服务商买一个域名（10 刀/年起）
  2. 在 Vercel 项目里 Settings → Domains 添加你的域名
  3. 按 Vercel 提示在域名服务商那边配 DNS 记录
  4. 等 10 分钟 - 几小时，域名就生效了

整个流程不到 30 分钟。 这就是 2026 年的部署难度——比你点外卖还简单。

🖼️ 图片建议： 一张"部署流水线"图。从左到右四个阶段：本地代码 → GitHub → Vercel → 你的域名。每个阶段下面标耗时（5 分钟 / 2 分钟 / 2 分钟 / 30 分钟）。最右边画一个手机屏幕显示你的网站，旁边几个小人物（用户）开始用。

🤔 那个绕不开的问题："AI 写的代码能用吗？"

这是 Vibe Coding 圈最大的争议。

我给你一个诚实的回答——分场景。

场景 1：小工具 / 个人项目 / 内部工具

完全能用。放心搞。

这种场景的特点：

  • 用户少（你自己 / 同事几个人）
  • 数据不敏感（不涉及钱、医疗、隐私）
  • 出问题影响小（最多重启一下）
  • 你能持续维护（出 bug 你能继续让 AI 修）

这类项目，Vibe Coding 写出的代码质量已经超过很多人工写的。我自己做了七八个，没一个翻过车。

场景 2：面向公开用户的产品

能用，但你必须做好"工程师"的部分。

这种场景的特点：

  • 用户量可能上百、上千
  • 涉及账号、支付、数据存储
  • 出问题影响品牌口碑

这种项目，AI 写完代码后，你必须额外做：

  • ✅ 完整的安全审查（前面那 5 个维度）
  • ✅ 错误监控（接入 Sentry 等工具，第一时间知道线上崩溃）
  • ✅ 数据备份（定期备份数据库，别让一次操作毁掉所有数据）
  • ✅ 日志记录（关键操作有日志，方便排查）
  • ✅ 测试覆盖（至少核心路径有测试）

做完这些，AI 写的代码也能跑生产。 但代价是——你得花相当于"再写一遍"的时间做工程化。

场景 3：金融 / 医疗 / 安全关键系统

不要 Vibe Coding，至少不要纯 Vibe Coding。

这类系统的特点：

  • 一个 bug 损失上千万 / 影响生命
  • 监管要求高（合规、审计）
  • 需要专业知识背景

这种你应该：

  • 让 AI 帮你写"工具型代码"（数据转换、内部脚本）
  • 核心业务逻辑必须人工编写或者人工逐行审核
  • 引入正式的代码审查流程

Belitsoft 的警告：亚马逊的 2026 教训

2026 年 10 月，Belitsoft 报道了一次大事件——亚马逊的一次大规模生产故障，事后查明根因是 GenAI 辅助修改的代码。

具体什么 bug 没披露，但圈里讨论：是 AI 写的代码在边界条件下表现异常，绕过了人工评审。

这是一个警示：再聪明的 AI，写生产代码都不能完全替代人工审核。

Vibe Coding 不是免责金牌。 你最终为产品负责。

🖼️ 图片建议： 一张三色风险等级图。左边绿色"个人工具"——AI 写、人来用，简笔画一个人在小机器人帮助下做小工具；中间黄色"公开产品"——AI 写、工程师审、监控兜底；右边红色"金融/医疗"——人写为主、AI 辅助，标注"高风险，慎用"。

🎁 上线之后：你要养成的 3 个习惯

部署完不是结束。下面这 3 个习惯能让你的产品越做越好：

习惯 1：每周看一次错误日志

接入 Sentry（免费版够用）或者用 Vercel 自带的 logs。每周固定时间扫一眼，发现有报错的功能立刻让 AI 修。

不看的代价：你的用户在默默忍受 bug，然后不告诉你就走了。

习惯 2：每月跟用户聊一次

如果你的产品有几个真实用户——每个月找其中一两个聊 15 分钟：

  • "你最近用这个工具几次？"
  • "最近一次用是为了啥？"
  • "有没有什么操作让你觉得卡？"
  • "你最希望多哪个功能？"

没用户反馈的产品就是闭门造车。

习惯 3：每季度技术债盘点

让 AI 帮你做一次：

ultrathink，盘点当前项目的技术债：
1. 哪些文件超过 300 行，需要拆？
2. 有哪些"临时"代码已经变成"永久"？
3. 哪些依赖该升级了？
4. 安全审查复跑一次，有新问题吗？

按严重程度排序，给出修复建议。

每季度花一天清一次债。这是产品长寿的秘诀。

🧘 系列收尾：我想说的真心话

8 篇文章写完了，我想对你说点真心话。

Vibe Coding 不是让你不学编程

很多人以为 Vibe Coding 是"不学编程就能写代码"。

不是。 它是让你学的重点变了——

  • 你不用学 for 循环、Hook、Webpack
  • 你要学：怎么把需求讲清楚、怎么拆模块、怎么读代码大致结构、怎么 debug

这些恰恰是工程师里最稀缺、最值钱的能力。

Vibe Coding 让普通人能直接学这些"上层能力"——这是真正的解放。

Vibe Coding 不是银弹

如果你是抱着"我什么都不学，AI 替我搞定一切"的心态来——会失望的。

AI 是放大器。你脑子里清楚想要什么，AI 把你的想法放大 10 倍交付出来；你脑子里一团糟，AI 把你的混乱放大 10 倍砸到屏幕上。

所以最重要的能力还是——想清楚。

Vibe Coding 让"造软件"回到了普通人手里

最后说一件让我有点感慨的事。

在过去 20 年里，"造软件"是少数人的特权——必须懂代码、懂框架、懂部署。普通人有想法，只能写需求文档求工程师怜悯。

2026 年的今天，这个特权被打破了。

我见过：

  • 一个语文老师做了一个给自己班用的作文批改工具
  • 一个 HR 做了一个面试评估打分系统，HR 部门全员都在用
  • 一个母婴博主做了一个辅食制作灵感生成器，几千粉丝在用
  • 一个独立设计师做了自己的作品集网站，把"找前端的钱"省了

这些人，在 2024 年都不可能办到。

这就是 Vibe Coding 真正的意义。

它不是关于 AI、不是关于代码、不是关于效率——

它是关于让所有人，都能把自己的想法变成现实。

🎬 给读者最后的一句话

如果你看完了这 8 篇，但还没动手——那就白看了。

今晚就开始。

  1. 想一个你脑子里挂了很久的小工具
  2. 装 Cursor 或 Claude Code
  3. 按第 03 篇跑一遍 PRD
  4. 按第 05 篇跑一遍循环
  5. 哪怕只做出一个简陋的 demo——你都已经超过 90% 的人了

别等"哪天有空"。"哪天"永远不会来。

📚 系列回顾

8 篇文章，路径完整：

#标题核心
01Vibe Coding 到底是个啥概念 + 心法
02Vibe Coding 工具地图四层工具栈
03规划就是一切三份文档
04AGENTS.md 与记忆库AI 的项目记忆
05结对编程实战Plan-Execute-Verify 循环
06Prompt、Skills、MCP三大外挂
07Debug、回滚、上下文爆炸8 个救命技巧
08从玩具到上线（本篇）MVP 收尾 + 部署 + 心态

收藏起来，每隔一段时间回头看一看。 你每次重读，都会有新理解——因为那时候你的实战经验已经更多了。

🙏 写在最后

谢谢你能看到这里。

这个系列写下来差不多 3 万字，是我把过去一年所有翻车、所有顿悟、所有压箱底的实战经验拿出来的总和。

没有任何保留。

如果它能帮你在 2026 年做出一个让你自豪的小项目——那就值了。

后会有期。

——面包君

🖼️ 图片建议： 一张"启程"风格的最终图。一个人背着行囊，站在山顶。脚下是 8 块石头组成的台阶（每块标一篇文章名），通向远方的城市（"你的第一个上线作品"）。天空有一行字："Vibe On, Friend." 色调温暖、明亮，带一点告别但更多希望。

上一篇Vibe Coding 到底是个啥？为什么 2026 年人人都该会一点下一篇 规划就是一切：把想法变成 AI 能听懂的"上下文包"