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

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

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

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

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

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

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

几个特别容易踩的坑：

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

自查命令：

# 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 里跑一下：

-- 看哪些表没开 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（越权访问），做法土但有效：

注册两个账号 A 和 B，各自创建一点数据
登录 A，打开浏览器开发者工具，找到一个"获取我的数据"的请求，比如 GET /api/notes/123
把 123 改成 B 的某条数据的 id，重新发送
如果返回了 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 及其可能收集的数据

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

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

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

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

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

贴墙清单

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

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