过去6周我审查了14个用Lovable/Bolt/Cursor构建的MVP。相同的5个问题在线上生产中毁掉它们

这些大多是AI SaaS的创始人，他们用Lovable或Bolt快速交付产品，获得了首批30到50个用户，然后眼看着整个系统开始漏洞百出。模式几乎一模一样。行级安全策略写了一次，从未测试过。Supabase中的默认RLS策略在演示中没问题，但当拥有特殊角色的用户访问共享表时就会失效。14个中有4个的策略允许任何经过身份验证的用户读取其他租户的行数据。没人发现，因为没人编写一个伪装成错误用户的测试。身份验证流程看起来正常，直到刷新令牌过期。大多数只使用一个Supabase身份验证助手，从未处理刷新路径，并在60分钟后悄悄将用户登出。创始人以为他们遇到了用户流失问题，但实际上是个会话Bug。后台任务与应用程序共享同一连接池。一次邮件群发或一次CSV导入就会锁定数据库，影响所有人。14个中有6个如此。修复只需3行配置，但没人知道去看。数据库模式是通过提示构建的，而不是经过思考。表名像句子一样，缺少外键。JSONB列存放本应是关系型的数据。一旦有了500行真实客户数据，每次迁移都变成4小时的问题。任何涉及金钱或外部API的操作都没有幂等性。Stripe重试webhook时，你会重复收费，然后从Twitter投诉中得知。电子邮件发送、短信、第三方同步也是同样模式。这些都不是代码质量问题，而是设计问题——AI构建者看不到，因为AI还不了解你的业务。解决办法很少是“重写一切”，通常是2到3周有针对性的基础设施工作：真正的RLS测试、任务队列、正确的会话处理、模式清理、关键地方的幂等性键。