AI 建站安全体检 —— 用真实请求与响应作证据，验证你的 Lovable / Cursor / Claude Code 应用究竟向陌生人暴露了什么
结论：观望（需求已被 295 个仓库的扫描数据证实，但付费意愿弱、平台内建与先发者双重挤压，先用免费扫描器验证分发能力再投入）｜形态：SaaS
1. 产品定义与形态
输入一个线上 URL → 通过 DNS TXT 记录、HTML meta 标签或根目录文件验证所有权 → 从外部做只读、无侵入扫描：Supabase anon key 是否可越权读写、Firebase 规则是否 open、.env/config.js 是否可公开访问、API 是否可枚举、是否缺少鉴权中间件 → 输出真实 HTTP 请求与响应原文作为证据，并生成可直接粘贴进 Cursor / Claude Code / Lovable 的修复提示词。
形态选 SaaS（Web），不做插件。理由：安全扫描需要服务端发起请求，用户侧零安装才能覆盖非技术人群；插件形态无法验证"陌生人视角"。
2. 目标客户画像
- 核心：Vibe coding 出海的独立开发者与一人公司，用 Lovable / Bolt / v0 / Cursor 做出产品并已上线，有真实用户但无安全背景。
- 次核心（更可能付费）：1–3 人外包工作室，同时交付多个客户项目，怕"交付即背锅"。
- 边缘：企业内被临时指派负责 AI 实验项目的开发者。 共同特征：看不懂 Snyk 的 CVE 列表，但看得懂"我打开这个链接就能删你数据库"的截图。
3. 付费者与付费证据
来源帖给出了需求侧最硬的一段证据：
"I also ran the code checks over 295 public Lovable repos: 51% shipped at least one issue, 20% a critical one. The most common was a committed .env file."
以及产品自证的演示：
"it found 14 problems, including anyone bein"（原文截断）
但付费证据是缺失的：原帖标题是"I built a free checker"，免费是钩子不是定价验证；作者后续定价 $1/app/月，本身是付费意愿偏弱的信号。帖子评论区是否出现"我愿意付 $X"这类原话，当前证据中未见 → 待验证（需回原帖抓取评论）。
我的判断：真正掏钱的是"有客户责任"的人，不是 hobby 玩家。纯个人项目发现漏洞后的动作是"我自己改"，不会订阅；外包/工作室才会为"每单交付前跑一遍"付月费。这条假设必须在前 30 天验证。
4. 时机判断
- 顺风：AI 建站工具在 2024–2025 处于用户爆发期，大量非工程背景的人第一次部署带数据库的应用，安全意识几乎为零——这正是 51% 问题率的根因。
- 逆风：平台正在内建同类能力。Supabase 一直在强化 RLS 默认提示，Lovable 这类平台有强动机把"安全扫描"做成内置按钮，用来降低平台自身的责任风险。一旦内建，外部工具的价值会被压缩到"多平台统一视图 + 第三方背书"。
- 窗口判断：6–12 个月。这属于"寄生型"机会，与平台是共生还是被吞并取决于是否绑定多平台。
5. 市场前景
不引用任何市场规模数字。可执行的估算路径（全部待验证）：
假设法：用 GitHub Search API 统计 lovable、bolt.new、v0 相关公开仓库数量 N → 假设其中 20% 的仓库有线上部署 → 假设 3%–8% 会转化为付费（$3–9/月）→ 得出 MRR 区间。这条链上每一步都需要自己跑数据，不能拍脑袋写"百亿市场"。
结构性机会在于：安全是持续复购场景，不是一次性工具。应用会持续更新、持续新增接口，所以"每日监控"的订阅逻辑成立，LTV 天然高于建站类一次性工具。
6. 竞争格局
| 层 | 玩家 | 对本品的威胁 |
|---|---|---|
| 直接 | Shippable（来源帖作者，已上线且有数据背书） | 高，先发 + 有内容资产 |
| 传统 DAST | OWASP ZAP、Burp Suite、Probely、Intruder | 中，能力更强但面向安全工程师，非技术用户上手成本极高 |
| 代码/密钥扫描 | Snyk、Semgrep、GitGuardian | 中高，.env 泄露正是 GitGuardian 主场，但它是"仓库视角"，不是"线上真实暴露视角" |
| 平台内建 | Lovable / Supabase 自带提示 | 高，长期最大威胁 |
| 云厂商 | Vercel / Netlify 的安全检查 | 低，偏基础设施 |
差异化生存位：① 非安全语言报告 + AI 修复提示词（把"发现问题"和"修好"之间那道坎抹平）；② 多平台统一（Lovable + Bolt + 自建 Next.js 一起扫）；③ 极低门槛定价。单纯拼扫描深度会输给 ZAP。
7. 90 天路线图
- 第 1–2 周：所有权验证（DNS TXT + HTML meta 双通道，防滥用是合规底线）；10 条高确信规则（Supabase 匿名读写、开放 Firebase 规则、公开
.env、.git目录暴露、/api无鉴权、CORS 通配、调试端点、Source map 暴露、默认口令、敏感路径）。 - 第 3–4 周：报告引擎——每条发现附"curl 请求 + 响应片段"证据；生成器输出 Cursor / Claude Code 可直接吃的 prompt。上线免费版，只开放 3 条规则 + 完整报告付费。
- 第 5–6 周：发 r/SideProject、r/lovable、r/cursor、Hacker News（Show HN）、Product Hunt；在 Lovable / Bolt 的 Discord 里做"免费帮你看一眼"活动，收集 100 个真实 URL 做规则校准。
- 第 7–10 周：加每日监控与变更告警（新暴露的接口 → 邮件）；接入 Stripe；把 100 个 URL 的匿名化统计做成公开报告，作为长期内容资产。
- 第 11–13 周：做转化归因，决定是否继续（见第 11 节放弃条件）。
8. 获客与运营
- SEO 长尾（这类用户是搜"我该怎么修"进来的，不是搜"安全扫描"）：
supabase anon key exposed、supabase rls not working lovable、lovable app security、is my lovable app safe、firebase rules open to public、lovable .env leaked、cursor app security checklist、vibe coding security- 落地形式：每个关键词一篇"症状 → 证据截图 → 修复 prompt"的文章，正文直接给可粘贴的 prompt。
- 社区：r/SideProject（首发）、r/lovable、r/cursor、r/webdev、r/IndieHackers、Hacker News Show HN、Lovable 官方 Discord、Bolt Discord、Vercel Community。
- 内容钩子：把"51% 有漏洞"这类统计做成季度公开报告，是最容易被转发和引用的资产。
- 合作：找做 Lovable 教程的 YouTube 小博主，给他们一个带品牌的免费扫描链接。
9. 地域需求分析
- 首要市场：英语区（美/英/加/澳）——AI 建站工具的核心用户池、付费习惯最好、$3–9/月属于无决策成本区间。
- 次优：印度、东南亚、东欧——用户量大、外包工作室多，"交付前体检"的场景匹配度高，但对 $9/月 敏感，需低价档。
- 中文市场：需求存在但形态不同（微信小程序云开发、腾讯云开发、阿里云），且安全付费意愿显著更低；建议作为第 3 阶段的多平台扩展方向，不作为首发市场。该判断待验证。
10. 定价与收入模型
定价（修正来源帖的 $1/app/月，该定价过低，无法覆盖获客成本）： - Free：1 个应用、3 条规则、无监控 —— 纯获客钩子，不设限次数以换取病毒传播。 - Solo $9/月：3 个应用、全规则、每日监控、AI 修复 prompt。 - Studio $29/月：15 个应用、客户白标报告 PDF、优先扫描。 - 一次性深扫 $19：不订阅，出完报告即走（承接"只想上线前查一次"的人群）。
收入测算（纯假设，非预测）：假设 12 个月做到 600 个付费账号、ARPU $11 → MRR ≈ $6,600。该假设成立的前提是免费转付费率 ≥3%、月流失 ≤6%，两项均待验证。一人公司成本主要是扫描算力与域名，边际成本低，毛利率可维持 85%+。
11. 风险与放弃条件
- 平台内建（最高风险）：Lovable/Supabase 上线一键扫描 → 差异化坍缩为"多平台 + 第三方"。
- 法律与滥用：必须强制所有权验证，否则工具会变成攻击者的侦察器；只读、限频、遵守 robots，避免被云厂商封 IP。
- 误报摧毁信任：一次"你被黑了"的假警报就会失去用户，报告必须标注确信度分级。
- 付费意愿不足：51% 的问题率不等于 51% 的付费率。
- 先发者占位：Shippable 已有数据背书和内容资产。
量化放弃条件：① 上线 90 天内免费用户 → 付费转化 < 2%；② 第 6 个月 MRR < $300；③ 主要平台（Lovable 或 Supabase）发布功能等效的内建扫描。任一条触发即止损，保留免费扫描器作为引流资产转向审计服务或内容站。
12. 总评分卡
| 维度 | 权重 | 评分 | 加权 | 依据 |
|---|---|---|---|---|
| 个人匹配度 | 0.25 | 74 | 18.5 | 需要 HTTP/鉴权/Supabase 规则的实际理解，一人可做，但安全领域的规则维护是长期负担 |
| 时机 | 0.20 | 82 | 16.4 | AI 建站用户爆发 + 51%/20% 的问题率数据刚被公开，认知窗口打开 |
| 付费意愿 | 0.25 | 54 | 13.5 | 需求强证据，付费弱证据；作者自定 $1/月暴露定价信心不足，付费者更可能是工作室而非个人 |
| 竞争空间 | 0.15 | 52 | 7.8 | 先发者已有数据背书，上有 ZAP/GitGuardian，旁有平台内建 |
| 执行难度（越高越易） | 0.15 | 72 | 10.8 | MVP 规则集 2–4 周可跑通，难点在所有权验证与误报控制，非技术瓶颈 |
| 合计 | 1.00 | — | 67.0 | 需求真、付费假、窗口短 |
给创业者的最后一句：这个方向最值得做的不是"扫描器"，而是"漏洞 → 可粘贴的修复 prompt"这段转化——那才是非技术用户真正愿意付钱的地方。先用免费扫描器跑通分发，再决定是否把它做成公司。