Vibe-Coded应用修复还是重建？30分钟自检指南

你的 Lovable、Bolt 或 Cursor 原型已经有真实用户在用了。它每周都会出问题，而你打算花钱找人来解决。但在掏钱之前，你需要知道你的 vibe-coded 应用是应该修复还是重建，因为这个答案决定了你是在买几天的活儿，还是几个月的活儿。

大多数指南最后都会说"预约一次审计"。这篇文章让你免费获得审计的第一轮：8 项检查，大约 30 分钟，不需要开发者，最后给出一个判断。

大多数 vibe-coded 应用需要的是修复，而不是重建。常见问题包括暴露的密钥、缺失的数据库访问规则和脆弱的支付处理——这些问题每一个都可以单独修复。

你的数据模型决定了是否需要重建。如果你的数据库无法描述你的业务当前是如何运作的，那么修补各个页面并不能解决根本问题。

在你自己拥有的应用上运行下面的 8 项检查。打分，然后读出结论，把结果交给你要雇佣的人，这样你就不用为他们已经了解的东西付费了。

为什么 vibe-coded 应用在演示时能跑，用户一用就坏

AI 构建工具擅长让页面显示正确的内容。但生产环境需要更多。陌生人之间必须不能访问彼此的数据。支付必须在用户中途关闭标签页时继续正常工作。一个有 50,000 行的表格必须和只有五行时加载一样快。

安全研究量化了这个差距有多大。Veracode 测试了超过 100 个大语言模型生成的代码，发现 AI 生成的代码在 45% 的测试中引入了有风险的安全漏洞（Veracode GenAI Code Security Report）。最著名的例子是 CVE-2025-48757。一位研究人员扫描了 1,645 个 Lovable 构建的应用，发现 170 个（10.3%）存在数据库暴露，涉及 303 个漏洞端点。泄露的数据包括邮箱、电话号码、支付状态和 API 密钥（bleek.dev、Superblocks）。原因是缺失或弱化的 Row Level Security，也就是下面的检查 2。

这些并不意味着你的应用注定失败。演示证明了需求的存在。那些不可见的部分只是还没有构建，而下面的检查会告诉你有多少缺失。

30 分钟自我测试：8 项检查

只在你拥有或获得授权测试的应用上运行这些检查。大多数检查只需要你的浏览器和管理后台。为每项打分：通过（0）、警告（1）或失败（2）。

1. 浏览器包中的密钥（4 分钟）

你的应用发送给浏览器的任何东西都可以被访问它的任何人读取。

在 Chrome 中打开你的在线应用。按 F12 打开 DevTools，然后进入 Sources 标签页。

按 Ctrl+Shift+F（在 Mac 上是 Cmd+Option+F）在所有文件中搜索。

搜索 sk_live、sk_test、rk_live、sb_secret_、service_role 和 secret。

打开你的 Supabase 项目的 API 密钥页面。复制 secret / service_role 密钥的前 20 个左右字符，也搜索这些。旧版 Supabase 密钥是编码过的，所以 "service_role" 这个词可能不会以明文形式出现。

通过：你只找到可发布密钥（pk_live_、sb_publishable_、anon key）。Stripe 和 Supabase 都表示这些可以安全暴露（Stripe、Supabase）。失败：任何 secret、restricted 或 service 密钥出现。在做其他任何事之前，今天就轮换它。

2. Row Level Security（5 分钟）

Supabase 自己的文档直截了当：一个没有 RLS 的表"任何对其有 grant 角色的角色都可以读写"（Supabase RLS）。

在 Supabase 仪表板中，打开 Advisors → Security Advisor。查找类似 RLS Disabled in Public 或 Sensitive Columns Exposed 的错误（Supabase Advisors）。

运行两账户测试。以用户 A 身份注册并创建一条记录（发票、项目或消息），然后复制其 URL。然后以用户 B 身份在隐私窗口登录，打开那个 URL。

通过：顾问是干净的，用户 B 什么都看不到。警告：顾问显示警告，但两账户测试通过。失败：任何 RLS 错误，或者用户 B 能看到 A 的数据。一个注意点：Lovable 内置扫描器只检查策略是否存在，而不是它是否真正阻止了访问（Superblocks）。两账户测试才是证明它有效的方法。

3. 认证和会话处理（4 分钟）

登出，按返回键，然后重新加载一个隐私页面。你还能看到数据吗？

以普通用户身份登录，直接在地址栏输入 /admin（或你的管理路由）。

从头到尾运行一次密码重置。邮件收到了吗，链接在使用后是否过期？

通过：三者都正常。警告：重置流程不稳定。失败：普通用户能访问管理页面，或者已登出的会话仍然显示数据。

4. 支付 webhook（5 分钟）

Webhook 是 Stripe 在支付成功或订阅变更时发送到你的应用服务器的邮件。许多原型跳过了这一步，在浏览器到达"成功"页面时解锁付费功能，这意味着一旦有人关闭标签页就会出问题。

在 Stripe 中，打开 Workbench → Webhooks。是否注册了端点？打开 Event deliveries，查找标记为 Failed 或 Pending 的任何内容（Stripe webhooks）。

在沙箱中，开始结账，用测试卡支付，在重定向完成前关闭标签页。账户是否仍然升级了？

从 Stripe 仪表板取消那个测试订阅。应用是否收回了访问权限？

通过：端点存在，发送成功，两项测试都正常。失败：没有端点，发送失败，或者访问权限不跟随 Stripe 的状态。

5. 数据模型合理性（5 分钟）

这是决定修复还是重建的检查。打开 Supabase 的 Table Editor，查找：

表名以屏幕命名（dashboard_data、page_two）而不是你的业务中的事物（customers、orders）。

同一事实存储在多个地方，比如客户的邮箱出现在四个表中。

列表被塞进一个文本或 JSON 列。

用户拥有的表没有一列说明谁拥有每一行。

你的业务现在做的事情而 schema 无法表达的，比如团队、多个地点或每个产品有多个价格。

通过：以上都没有。警告：有一两个，且是局部的。失败：最后一个子弹为真，或者其他大多数为真。

6. 错误监控（2 分钟）

当东西坏掉时，谁先发现——你还是你的用户？在 DevTools 中，在 Network 标签页搜索 sentry、logrocket 或 bugsnag，然后检查你是否真的收到过告警。

通过：错误自动到达你这里。失败：你的用户就是你的监控。

7. 真实数据下的页面加载（3 分钟）

用一个拥有最重数据的客户的数据量填充一个测试账户。在 DevTools 中设置 Network 限速为 Slow 4G，加载你最繁忙的页面。

通过：主要内容在约 2.5 秒内出现。Google 的 web.dev 将 Largest Contentful Paint 在 2.5 秒或以下视为"良好"，超过 4 秒视为"差"（web.dev）。警告：2.5 到 4 秒。失败：超过 4 秒，或者 Network 标签页显示页面一次下载了整个表。

8. 你拥有的版本控制中的代码（2 分钟）

你的代码在你的账户或组织名下的 GitHub 仓库中吗？Lovable 可以用双向同步在你的 GitHub 上创建一个私有仓库（Lovable docs）。Bolt 和 Cursor 项目也应该在仓库中。

通过：你拥有仓库，可以看到变更历史。警告：仓库存在但在一个自由职业者的账户下。失败：代码只存在于构建工具内部或一个人的笔记本电脑上。

评分：上线、修复、重构还是重建

加起来你的分数（最高 16 分）。这些阈值是我们的经验法则，来自这些问题通常如何分组。它们不是行业标准。

低分但检查 1 或 2 失败仍然意味着今天就行动。轮换密钥或打开 RLS，然后继续。

什么时候重建是对的（什么时候它是销售话术）

大多数顶级指南都同意，我们也是：数据模型是真正的测试。Axonbuild 认为重建只有在你的数据模型"无法表达业务现在做什么"时才合理（Axonbuild）。Appmatic 将数据模型健全时为重构，架构无法支持路线图时为重建（Appmatic）。

重建是对的，当：

• 检查 5 失败且你的下三个功能都需要改变 schema。
• 每次小的改动都破坏了不相关的东西，而且这已经持续了几个月。
• 你根本无法把代码从平台中拿出来。

它可能是销售话术，当：

• 有人在没有阅读你的代码或 schema 的情况下就报价重建。
• 理由是品味问题（"代码很乱"、"我们会用不同的框架"）。能工作的乱代码是重构工作。
• 暴露的密钥或缺失的 RLS 被作为理由。那些是修复，通常是小修复。

交给开发者什么

为了将 Lovable 应用（或者 Bolt 或 Cursor 的）交给开发者而不为发现阶段付两次钱，发送：

• 你的自我测试分数，以及任何失败内容的截图。
• GitHub 仓库、Supabase、Stripe、托管和你的域名注册商的 admin 或 collaborator 访问权限。使用邀请，永远不要共享密码。
• 来自用户报告的故障清单，带日期。
• 你需要的下三个功能，这样他们可以判断数据模型是否能应对。
• 你的用户和数据数字：活跃用户、最大账户、最大表。

如果你不想自己整理这些，Banxal 的维护和增长工作在其他任何东西之前首先进行相同的交接审查。

修复还是重建 vibe-coded 应用：每个选项涉及什么

修复、重构和重建 vibe-coded 应用在改变什么、保留什么以及成本方面有所不同。下面的成本范围是其他代理商公布的数据，不是我们的，你的应用可能不同。

Axonbuild 关于修复 vibe-coded 应用的建议很简单：数一下你的阻碍性问题，乘以每次修复的成本，然后与重建报价比较（Axonbuild）。Appmatic 列出的单独代码审计为 1-2 周，起价 $2,500（Appmatic）。

常见问题

如果安全顾问是干净的，我的 Lovable 应用是否生产就绪？ 不仅凭那一点。顾问发现缺失的 RLS，但它不能告诉你你的策略是否与你的业务规则匹配。运行两账户测试，还要检查支付和认证。

我可以自己运行 AI 构建应用的安全检查吗？ 你可以做第一轮。上面的检查 1-4 抓住了最佳已知事件背后的这些问题。开发者仍然需要审查 webhook 签名检查和服务器端逻辑，因为那从浏览器看不到。

修复 vibe-coded 应用需要多长时间？ 泄露的密钥或缺失的策略等孤立问题通常需要几个小时。上面公布的范围将更完整的加固工作放在数周。你的分数比任何平均数都是更好的指南。

如果你的分数说修复或重构，下一步是代码审查和交接对话。带上你的自我测试结果。Banxal 构建和加固 Web 应用和 SaaS 产品，并可通过持续维护之后照顾它们。如果重建不需要，我们会直说。联系我们讨论你的应用。

最初发表于 banxal.com。