ARTICLE · 1159723

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

发布时间：2026-10-12 02:26:49 最近访问：2026-10-12 02:26:49

用 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（越权访问），做法土但有效：

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 及其可能收集的数据

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

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

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