# Vibe Coding 做出来的 App 上线检查清单

> AI 一个周末就能做出带登录、数据库、支付的 App，但它不会主动帮你查安全和合规。按密钥泄露、越权访问、成本与支付、稳定性、审核合规、上线后兜底六层，给出可直接复制的命令、SQL 和审计提示词。

- 原文链接: https://laojin.blog/blog/20261011_vibe_coding_prelaunch_checklist
- 作者: 老金
- 发布日期: 2026-10-11
- 标签: Vibe Coding, 上线检查, 安全, Supabase, App Store

---

![Vibe Coding 做出来的 App 上线检查清单](https://pic-1258874139.cos.ap-hongkong.myqcloud.com/laojinblog/posts/20261011/00_cover.png)

用 AI 做一个 App，一个周末就能把登录、数据库、支付、AI 对话全做出来，界面还挺好看。

但它写的代码有问题，你不问，它不会主动提；你不测，问题就一直留在那。

所以上线前，我会按"会出什么事"把检查分成 6 层，从最致命的往下查。每一层都给能直接复制的命令或提示词。

---

## 密钥有没有漏到了用户手里

这是 vibe coding 最高发、后果最直接的问题。

AI 为了让功能"先跑起来"，很容易把 API Key 直接写进前端代码。可前端代码和 App 安装包都是要发到用户手里的，谁都能打开看。

几个特别容易踩的坑：

| 场景 | 为什么会漏 |
|---|---|
| Next.js 里用了 `NEXT_PUBLIC_` 前缀的变量 | 这个前缀的意思就是"打包进浏览器" |
| Vite 里用了 `VITE_` 前缀 | 同上 |
| iOS / 鸿蒙 App 里写死了 OpenAI / Claude 的 Key | 安装包可以被解出来，`strings` 一下就能看到 |
| `.env` 被提交进了 Git 仓库 | 哪怕后来删了，历史记录里还在 |

自查命令：

```bash
# 1. 扫整个 Git 历史里有没有密钥（需要先 brew install gitleaks）
gitleaks detect --source . -v

# 2. 构建之后，扫一遍打包产物
npm run build
grep -rEn "sk-[A-Za-z0-9_-]{20,}|sk-ant-|AKIA[0-9A-Z]{16}" dist/ build/ .next/ 2>/dev/null

# 3. 确认 .env 没被 Git 跟踪
git ls-files | grep -E "\.env($|\.)"
```

第 3 条如果有输出，说明 `.env` 已经进仓库了。光删文件不够，**那把 Key 要直接去后台作废、换新的**。

所以规矩就一条：要用密钥的调用全放到后端或 Serverless 函数里，前端只调你自己的接口。

---

## 换个账号，能不能看到别人的数据

这一层是我觉得最危险的，因为它**完全不会报错**。功能一切正常，只是所有人的数据对所有人都敞开着。

### 1. 用 Supabase / Firebase 的，先看数据库规则

很多 vibe coding 教程都用 Supabase，前端直接连数据库。这时候前端的 `anon key` 是公开的，这本身没问题，安全全靠 RLS 兜着。

问题是：AI 建表的时候经常没开 RLS，或者开了但写了一条 `using (true)`——等于没开。

在 Supabase 的 SQL Editor 里跑一下：

```sql
-- 看哪些表没开 RLS
select tablename, rowsecurity
from pg_tables
where schemaname = 'public';

-- 看已有的策略写了什么
select tablename, policyname, cmd, qual
from pg_policies
where schemaname = 'public';
```

`rowsecurity` 是 `false` 的表，任何人拿着你的 anon key 都能读写整张表。`qual` 是 `true` 的策略，也要重点看。

Firebase 同理，去看 Firestore Rules 里有没有 `allow read, write: if true;`。

### 2. 有自己后端的，做一次"两个账号"测试

这个测试叫 IDOR（越权访问），做法土但有效：

1. 注册两个账号 A 和 B，各自创建一点数据
2. 登录 A，打开浏览器开发者工具，找到一个"获取我的数据"的请求，比如 `GET /api/notes/123`
3. 把 `123` 改成 B 的某条数据的 id，重新发送
4. 如果返回了 B 的数据——你就有大问题了

改和删的接口也要试，别只试查询。很多时候查询加了校验，删除没加。

---

## 钱：不会被刷爆，也不会少收

### 1. AI 接口的成本上限

带 AI 功能的 App，一定要做三件事：

- 在模型服务商后台设月度消费上限和告警，这是最后一道闸
- 每个用户每天的调用次数做限额，免费用户尤其要卡
- 限制单次输入长度，否则有人贴一本书进来，你一次就烧掉一大笔

这三件都没做，就等于把信用卡挂在门口。

### 2. 支付和订阅

支付是 AI 最容易"看起来写完了"的地方。上线前确认：

| 检查项 | 怎么测 |
|---|---|
| Webhook 有没有验签 | 让 AI 指出验签代码在哪一行；没有就是漏洞，别人可以伪造"支付成功"通知 |
| 同一个通知重复到达会不会重复发货 | 在 Stripe 后台手动重发同一个事件 |
| 退款 / 取消订阅后，权益有没有收回 | 沙盒里走一遍完整的"买→退"流程 |
| iOS 有没有"恢复购买"按钮 | 有内购的 App 审核会看，没有大概率被拒 |
| 订阅到期后状态对不对 | 沙盒的订阅周期是压缩过的，等几分钟就能看到续订和过期 |

成功那条路 AI 一般都写对了，出问题的基本是失败、重复、退款、过期这四种。

---

## 稳定性：在你没想到的情况下会不会崩

你自己测的时候，网络好、数据少、操作顺序对。真实用户全都反过来。

我会刻意测这几种情况：

- 断网和弱网：iOS 用"开发者 → Network Link Conditioner"，浏览器用开发者工具的 Throttling
- 空状态：新用户第一次打开，什么数据都没有，页面是不是一片空白或直接报错
- 大量数据：塞 1000 条数据进去，列表还流不流畅
- 奇怪的输入：超长文本、emoji、空格、粘贴进来的富文本
- 升级覆盖安装：装着旧版本的手机升级到新版本，本地数据还在不在、数据库迁移有没有跑

然后一定要接错误监控（Sentry 之类，免费额度够个人项目用）。没有监控，用户遇到崩溃只会默默卸载，你永远不知道。

---

## 合规与审核：别在最后一步卡住

AI 不会主动帮你做这些，因为它们不是"功能"。但审核一定会查。

### 上架 App Store

- [ ] 账号删除：支持注册的 App，必须能在 App 内发起删除账号（指南 5.1.1(v)）
- [ ] 隐私政策链接：App Store Connect 里要填，App 内也要能找到
- [ ] 隐私标签：如实填写收集了哪些数据。接了第三方 SDK（统计、广告），它们收集的也要算上
- [ ] 隐私清单 `PrivacyInfo.xcprivacy`：用到了"需声明原因的 API"就得有，第三方 SDK 也要带
- [ ] 审核演示账号：需要登录的 App，在审核备注里给一个能直接用的测试账号
- [ ] 第三方登录：如果接了微信、Google 等登录，要同时提供符合指南 4.8 的登录选项（通常就是加上 Sign in with Apple）
- [ ] 数字内容付费走内购：虚拟商品、会员，在 App 内引导去外部付款很容易被拒

### 国内上架（鸿蒙 / 安卓应用市场）

- [ ] App 备案：现在国内应用商店上架基本都要求先完成 App 备案
- [ ] 隐私政策 + 首次启动弹窗：用户同意之前，不能初始化会收集信息的 SDK
- [ ] AI 生成内容：如果是面向国内公众提供生成式 AI 服务，要提前了解相关备案和内容标识要求，不同情况要求不一样，建议上线前专门查一下或咨询

这部分规则一直在变，我列的是自己上架时踩过的点，具体以平台最新的审核指南为准。

---

## 上线后：出事了你能不能知道、能不能退回去

最后这层查的是你自己准备好没有：

- 有没有一个反馈入口：App 内放个邮箱或反馈表单，用户愿意告诉你的问题，比任何监控都准
- 数据库有没有自动备份：Supabase 免费版的备份策略要自己确认一下，重要数据自己定期导出
- 能不能快速回滚：Web 端保证上一个版本可以一键回退；App 端考虑做一个"强制更新"开关，留给严重 bug 用
- 核心埋点：至少知道每天有多少人打开、多少人走完了核心流程。没有数据，后面所有优化都是在猜

---

## 让 AI 帮你查，但别只让 AI 查

上面很多检查都可以先交给 Claude Code 跑一遍。这是我用的提示词，可以直接复制：

```
你现在是这个项目上线前的安全和质量审计员，不要写新功能，只做检查并输出报告。

请逐项检查并给出：问题位置（文件:行号）、风险等级（高/中/低）、修复建议。

1. 密钥：是否有 API Key、密码、Token 出现在前端代码、客户端代码或被 Git 跟踪的文件中
2. 权限：每个读/写/删接口是否校验了"当前用户是否有权操作这条数据"；如果用 Supabase/Firebase，列出所有表/集合的访问规则
3. 成本：所有调用付费 API 的地方是否在服务端，是否有用户级限流和输入长度限制
4. 支付：Webhook 是否验签、是否幂等，退款/取消订阅是否会收回权益
5. 错误处理：网络失败、空数据、异常输入时会不会白屏或崩溃
6. 合规：是否有账号删除功能、隐私政策入口；列出所有第三方 SDK 及其可能收集的数据

最后输出一张汇总表，按风险等级排序。不要修改任何代码。
```

注意最后一句"不要修改任何代码"。我的习惯是**先拿报告，自己看一遍，再挑着让它改**，否则它会顺手改一堆你没想到的地方。

但有两件事一定要自己亲手做：

1. 两个账号的越权测试。AI 读代码能找出大部分问题，但"真的发一个请求看返回什么"才是证据
2. 支付的完整流程。从买到退，自己在沙盒里走一遍

AI 写的代码，别全指望 AI 自己验收。

---

## 贴墙清单

上线前扫一遍，全打勾再发：

- [ ] `gitleaks` 扫过，打包产物里 grep 不到密钥
- [ ] 所有付费 API 调用都在服务端
- [ ] 数据库每张表都开了 RLS / 访问规则，并且看过规则内容
- [ ] 用两个账号测过越权，查、改、删都试了
- [ ] 模型服务商后台设了消费上限和告警
- [ ] 支付测过：成功、失败、重复通知、退款、过期
- [ ] 测过断网、空状态、大数据量、升级安装
- [ ] 接了错误监控
- [ ] 有账号删除、隐私政策、审核演示账号
- [ ] 有反馈入口、数据库备份、回滚方案

---

这张清单认真过一遍，一个下午差不多够了。比起上线后去处理数据泄露，或者收到一张几百美元的 API 账单，这个下午很划算。