审计12个AI付费MVP：4类致命漏洞

【这是什么】

一份公开的审计复盘：一个做了 8 年 MVP 外包的团队，把过去一年收到的 12 个「由 AI 构建、且已经有付费用户」的项目翻了一遍引擎盖，公布反复出问题的位置。

四类故障是共性的：

1. 认证能用，授权不能用。 注册登录 12 个都没问题，但几乎没有做过「你请求的东西是不是你的」这层校验。家教市场平台改一下 URL 末尾的数字，就能看到另一个家教的学生，包括家长 phone numbers；另一个项目在个人资料更新请求里多加一个字段，就能把自己变成管理员。帖子里点出了根因：单账号测试时一切正常，授权漏洞只有存在第二个人时才会暴露。
2. 每次重新生成都让代码更糟。 一个代码库里有 4 个不同的日期格式化函数，每个都是某次不同修复塞进去的；几个项目同一个 bug 在两个地方修了，第三个地方还是坏的。AI 倾向于在旧代码旁边加新代码，而不是改旧代码。
3. 支付只处理了「有人付款」那一刻。 取消订阅后永久保留付费计划（从没收到取消通知）；直接输入成功页地址就解锁付费（加载页面本身就是授权动作）；失败的续费最阴险——卡过期、Stripe 重试一阵，应用继续给已经停止付款数月的人访问权限。
4. 密钥被打包进浏览器。 通常因为变量名以 NEXT_PUBLIC 或 VITE 开头。任何打开开发者工具的人都能找到。

【背景 / 谁做的】

发帖人 /u/Warm-Reaction-456，团队主营 MVP 开发，8 年。客户画像在最近一年发生了位移：过去是「做不出来」的人来找他们，现在是「自己已经做出来、并且有付费用户」的人来找他们——用 Lovable 或 Cursor 做完，跑到某个地方着火，再来找人看。

这个背景比结论更重要。它说明 vibecoding 工具已经能把一个产品推到「有付费用户」这一档，但推不过「第二个人开始用它」和「第二个月还在扣款」这两道关。帖子里那句对照很扎眼：他们很多有开发团队的老客户，都没做到有付费用户。

【怎么获客】

这篇帖子本身就是获客装置，结构值得抄：

• 先给足诚意，再留钩子。 开头先夸「在没有开发团队的情况下做到有付费用户，这很了不起」，然后才展示具体案例。案例选得极准——改 URL 看别人学生和家长的电话、请求里加字段变管理员——都是能让读者立刻代入自己产品的画面。
• 给可执行动作，不给焦虑。 每条问题后面都跟一句当天能跑的操作：再建一个账号、在隐私窗口登录、把主账号里某个私密内容的地址粘贴进去;如果它能加载，你就有这个问题。Supabase 用户检查每个表是否开启行级安全，包括上个月新加的表。
• 给命令级细节。 Stripe 测试模式有故意拒付的卡，stripe CLI 可以发失败付款事件（stripe trigger invoice.payment_failed）；两件事都做一下，看用户的访问权限会怎样。构建后的 JavaScript 里搜索 sk- 和 sk_live，找到了今天就轮换密钥。
• CTA 明确到时间。 TLDR 结尾：这个星期就去建第二个账号，并取消一个测试订阅。
• 留下「修不好」的出口。 标题就是「以下是几乎每一个都出问题的地方」，读者读完对照自己的项目，发现自己中了两条以上，下一步动作自然是找人。

整套逻辑是：把审计能力免费展示，把审计工时收费。

【验证情况 / MRR】

• 需求侧验证成立：12 个 项目全部已经跑通付费，样本不是想法阶段。
• 收入质量存疑：取消后不降权、成功页直连解锁、失败续费继续放行——这三条意味着账面付费用户和实际付费用户之间有一层漏损，卡过期几个月的人还在用付费功能。
• 帖子没有给出任何具体 MRR 数字，能确认的只有「有付费用户」这一档。
• 服务方自身的验证：8 年 MVP 业务在跑，且手上有一批「有开发团队」的老客户作为对照基线。

【对一人公司的可复制性】

高，而且门槛低。

审计清单可以直接变成产品。 四类检查项已经足够具体：第二个账号测授权；Supabase 每个表开 RLS（含上个月新加的表）；每次改提示词前先 git commit，某个修复让情况更糟就回滚而不是在它上面再要一个修复；同一个 bug 回来两次就停手读代码，或者找人读。

服务可以固定范围。 「上线前审计」按次交付，一个人能做；后续接「救火」月费。范围清楚、交付物清楚，正好适合一人公司。

内容模板可以照抄。 真实案例 + 一条能跑的命令 + 一句带时间点的 CTA。这是 OPC 最容易复制的获客结构，比写方法论有效得多。

顺手加一层发布流水线检查。 构建产物 grep sk- / sk_live，命中就轮换密钥；把密钥留在服务端，不要依赖变量名前缀来判断安全性。

【风险与机会】

风险

• 审计和救火是人力生意，规模被时间封顶，很难脱离本人交付。
• 平台会补课：Supabase 若把行级安全做成默认选项、支付服务商把 webhook 覆盖做得更好，需求会被压缩。
• 「AI 生成的代码不安全」这个卖点会衰减——工具方正在把授权检查、密钥处理内建。
• 样本有选择性偏差：12 个 里来找他们的人，本来就是已经出事的。真实故障率不能从这批样本外推。

机会

• 把清单自动化。 一个只做三件事的扫描器就有市场：构建产物密钥扫描、Supabase RLS 覆盖检查、Stripe webhook 事件覆盖对照（创建、续费成功、付款失败、取消四类是否都处理了）。目标客户和这篇帖子读的是同一批人。
• 模板与 SOP 变现。 RLS 基线配置、支付生命周期事件清单，做成付费模板或短课，边际成本接近于零。
• 同期社区信号值得注意。 ImapKit 把老框架 Hoodiecrow 复活成内存版 IMAP 服务器，专门用来测试邮件客户端；Abyss 在做 ACP agent 隔离与中间件；Jevman 在试 AI 决策模型。这些都在填同一块坑——「AI 构建的应用，怎么被验证」。这让「构建之后」的服务带，正在从零星接活变成一个可以成形的品类。

信息来源：Reddit、Hacker News