适用场景
这套流程适合两类人：一类是能说清业务但不想从零搭前端、配数据库的产品同学或运营同学；另一类是会写一点代码、但每次做全栈项目都要花半天折腾脚手架和环境变量的开发者。目标很直接——把一句自然语言需求，变成一个带登录、带数据库、有公网地址的真实应用。
核心思路是把 Lovable 当成一个"能写代码也能连后端的实习生"：你负责拆需求和验收，它负责写页面、建表、配权限。全程浏览器操作，不装环境也能跑通。
环境与前置条件
- 浏览器：Chrome / Edge / Safari 的较新版本，推荐 Chrome，开发者工具好用
- 账号：
- Lovable 账号（支持邮箱或 GitHub 登录）
- Supabase 账号（提供 Postgres 数据库、认证、存储，免费额度对开发和早期项目够用，具体额度以官方页面为准）
- 一个 GitHub 账号，用来做代码同步和部署
- 本地环境（可选，但强烈建议准备）：
- Node.js 的 LTS 版本，具体版本号以官方文档当前版本为准
- Git
- npm 或 pnpm 任选一个
- 硬件：纯浏览器操作时，普通办公笔记本就够，不需要独立显卡。如果要在本地跑
npm install，建议内存 8GB 以上，磁盘留出几 GB 给node_modules - 心理准备：一次只让它改一件事。vibe coding 翻车的主因不是模型不行，而是提示里塞了十个需求
分步骤部署
第 1 步：把"一句话需求"写成合格的第一条提示
"做个读书打卡工具"这种需求，生成出来大概率是个漂亮的空壳。把提示按四段式写清楚：
```
做一个给 10 人以内小团队用的读书打卡工具。
核心流程：
用户用邮箱注册登录后，在首页点"打卡"，填写书名和一句感想并提交；
首页按本周打卡次数从高到低展示成员排行榜。
数据字段：
打卡记录需要 书名、感想、打卡时间、所属用户；
每条记录只能被它自己的创建者修改和删除。
页面：
登录/注册页、首页（排行榜 + 打卡按钮 + 我的记录列表）。
样式：
简洁干净的卡片风格，移动端优先。
本轮先只做前端和本地假数据，跑通交互后下一步再接数据库。
```
最后一句很关键：明确告诉它分阶段。第一轮只要前端能点、能看，验收成本最低。
成功标志：右侧预览区出现页面，点"打卡"能弹出表单，提交后列表里能看到假数据。
第 2 步：用"选中元素"做小步迭代
Lovable 的编辑器支持直接在预览区点选某个组件，然后针对这个组件下指令。这比用文字描述"页面左上角那个按钮"准确得多。
迭代节奏建议：
1. 点选中某个组件 → 提一句具体的修改要求 → 回车
2. 等它改完 → 在预览区实际点一遍 → 满意就继续，不满意先回滚再改
3. 一次只改一件事，不要在一次提示里同时改布局、改逻辑、加功能
遇到"这个功能该怎么实现"这类拿不准的问题，先在聊天模式里讨论方案，聊清楚了再让它动手改代码。讨论不消耗改动次数，也不会把已经跑通的页面改坏。
成功标志：连续几次小改动之后，页面没有出现新的报错，历史版本记录里能看到每一步。
第 3 步：接后端——数据库、登录、权限
前端跑顺之后，再让它接 Supabase。通常在项目里能找到集成入口，按引导授权即可；也可以手动把 Supabase 项目的 URL 和 anon key 填进去。
接着用提示词让它建表和配权限：
```
把打卡记录从前端假数据改成 Supabase 数据库存储。
新建 checkins 表：id、title（书名）、note（感想）、created_at、user_id。
开启行级安全（RLS），策略要求：
- 登录用户只能读取自己的记录；
- 插入时 user_id 必须等于当前登录用户；
- 只能更新和删除自己的记录。
同时接上邮箱密码登录，未登录时自动跳转到登录页。
```
如果它生成的策略不完整，可以到 Supabase 的 SQL Editor 里自己补：
```sql
alter table public.checkins enable row level security;
create policy "select own checkins"
on public.checkins for select
using (auth.uid() = user_id);
create policy "insert own checkins"
on public.checkins for insert
with check (auth.uid() = user_id);
```
关于密钥的红线：anon key 出现在前端代码里是正常的，它受 RLS 保护；service_role key 拥有绕过 RLS 的全部权限，任何时候都不能写进前端。需要用到它的场景（发邮件、调第三方付费接口、批量任务），一律走服务端函数或 Edge Function，密钥放在服务端环境变量里。
成功标志：在预览里注册一个账号、提交一条记录，然后打开 Supabase 的表编辑器，能看到这条数据，且 user_id 字段有值。
第 4 步：同步到 GitHub
把项目连到 GitHub 仓库，双向同步。这一步带来三个好处：代码有了版本备份；可以在本地跑起来做深度调试；可以直接对接 Vercel、Netlify 这类平台的自动部署。
成功标志：GitHub 仓库里能看到完整源码、package.json 和配置文件。
第 5 步：本地跑一遍（可选但推荐）
```bash
git clone <你的仓库地址>
cd <项目目录>
npm install
npm run dev
```
在项目根目录建一个 .env 文件，把 Supabase 的连接信息填进去。Vite 项目里常见命名是：
```
VITE_SUPABASE_URL=你的项目URL
VITE_SUPABASE_ANON_KEY=你的anon key
```
注意：如果本地 .env 里的变量名和代码里读取的名字对不上，页面会白屏或者一直卡在加载中。
成功标志：终端输出本地访问地址（通常是 http://localhost:5173），浏览器打开后功能跟线上预览一致。
第 6 步：上线部署
两条路，按需要选：
方案 A：用平台自带的一键发布。点发布按钮后会得到一个公开访问地址，可以绑定自定义域名（自定义域名的可用性以官方页面为准）。适合快速给同事或客户看效果。
方案 B：用 GitHub + Vercel / Netlify。在部署平台里导入仓库，构建设置通常能被自动识别（Vite 项目的构建命令是 npm run build，产物目录是 dist）。记得在平台的 Environment Variables 里把 Supabase 的两个变量配上，否则线上会因为读不到配置而白屏。之后每次 push 都会自动重新部署。
无论走哪条路，最后都要回到 Supabase 后台做一件事：在认证配置里把线上域名加进允许的回调地址（Site URL 和 Redirect URLs），否则登录邮件里的链接点开会报错。
成功标志：线上地址能打开，注册登录流程完整走通，数据能落库。
验证部署是否成功
按下面的顺序走一遍，全部通过才算真的上线了：
1. 黄金路径：打开线上地址 → 注册新账号 → 收邮件确认（如果开了邮箱验证）→ 登录 → 创建一条数据 → 刷新页面，数据还在
2. 权限隔离：用浏览器无痕窗口注册第二个账号，确认看不到第一个账号的数据；再尝试直接访问详情页 URL，应该被挡住
3. 退出登录：点退出后回到登录页，回退浏览器历史也不能进入需要登录的页面
4. 控制台检查：按 F12 打开开发者工具，Console 无红色报错，Network 里没有持续出现的 401 或 403
5. 数据核对：在 Supabase 的表编辑器里，能看到数据、字段完整、user_id 正确
任何一条不通过，先别急着加新功能，回头修它。
常见报错与解决
报错 1：页面能打开，但列表一直转圈 / 控制台大量 Failed to fetch 或 new row violates row-level security policy
- 原因：表开了 RLS 但没建策略，或者策略里的
auth.uid()和表里的用户字段对不上，也可能表名在代码里写错了 - 解决：到 Supabase 的 SQL Editor 里补策略并确认字段名
```sql
-- 先看策略现状
select schemaname, tablename, policyname from pg_policies where tablename = 'checkins';
alter table public.checkins enable row level security;
create policy "select own checkins"
on public.checkins for select
using (auth.uid() = user_id);
create policy "insert own checkins"
on public.checkins for insert
with check (auth.uid() = user_id);
create policy "update own checkins"
on public.checkins for update
using (auth.uid() = user_id);
create policy "delete own checkins"
on public.checkins for delete
using (auth.uid() = user_id);
```
报错 2：本地或线上白屏，控制台提示 supabaseUrl is required / supabaseKey is required
- 原因：环境变量没配置，或者变量名与代码里读取的名字不一致
- 解决：核对代码中读取变量的写法，把
.env或部署平台的变量名改成完全一致（Vite 项目必须以VITE_开头），改完重新部署，改环境变量不会自动生效
```bash
本地确认变量已注入
npm run build
grep -r "import.meta.env" src | head
```
报错 3：登录后立刻跳回登录页，或者邮件确认链接打不开
- 原因：Supabase 认证配置里的允许跳转地址没有包含线上域名，回调被拒绝
- 解决：在 Supabase 后台的认证 URL 配置里，把 Site URL 设为线上域名，并把本地地址和线上地址都加进 Redirect URLs 白名单
报错 4：发布失败，提示构建错误 / TypeScript 类型报错
- 原因：AI 生成的代码引用了不存在的依赖，或改动引入了类型不匹配
- 解决：把完整报错原文贴回编辑器让它修；如果反复修不好，先在本地复现
```bash
npm install
npm run build
```
把本地报错行号一起贴给它，定位会准很多。
报错 5：改一个地方，另外三个页面崩了
- 原因：一次让它改动的范围太大，超出了它能稳定掌控的边界
- 解决：从版本历史回滚到上一个能正常运行的版本，然后把需求拆成两三次小改动重新提
后续维护
备份
- 代码层面：GitHub 仓库本身就是代码备份，本地再
git clone一份到别的机器 - 数据层面：定期在 Supabase 后台导出数据库；付费档一般提供自动备份和时间点恢复，具体能力以官方页面为准
- 配置层面：把 RLS 策略、Edge Function 源码、环境变量清单整理到一个私有文档里。环境变量丢了最难恢复
升级
- 依赖升级尽量在本地做：改完
package.json、跑npm install、npm run build通过后再 push，让部署平台重新构建 - 在 Lovable 里改代码时坚持小步走，改完立刻验收
- 平台功能和模型能力会持续更新，遇到行为变化先看官方公告
日志与监控
- Supabase 后台的日志和报告页能看数据库、认证、API 的请求情况，出问题先看这里
- 部署平台的部署日志能看每次构建的完整输出，构建失败必看
- 前端错误建议接一个错误上报服务，否则用户遇到的报错你不会知道
- 关注用量：数据库存储、带宽、认证月活，以及 AI 工具的额度消耗
定期检查
- 每隔一段时间回看一遍 RLS 策略，确认新增的表都开了权限控制
- 密钥轮换：怀疑泄露时立刻在 Supabase 后台重置 key，同步更新部署平台的变量
- 把线上域名的回调配置和自定义域名绑定状态纳入检查清单
最后一句实话：vibe coding 的效率来自"小步快跑 + 及时验收"，不是来自一次生成一个大而全的应用。把需求拆细、每步都亲手点一遍，返工率会低很多。