Lovable 反复修不好时，先定位故障层

Lovable 遇到报错，连续点「Try to fix」，为什么最后连原本正常的页面也白屏了？作者的判断是：AI 可能一直没拿到真实错误，也可能在改前端时，试图解决数据库权限或密钥配置的问题。补丁越叠越多，排查反而更难。

这篇给出了一套恢复顺序：先收集证据，再限制自动修复次数，必要时回退版本，最后检查后端。它值得读的地方，是把「继续让 AI 改」拆成了几个可以判断、验证和止损的步骤。

为什么越点修复，坏掉的地方越多

作者列出的循环原因，可以分成四类。

第一类是盲目重试。每次修复都往现有代码上加补丁，真实问题可能被绕过去，却没有消失。作者援引 Lovable 文档，提醒连续盲修容易让代码越来越难排查。

第二类是信息断层。已经发布的网站报错、后端日志里的失败，不会自动进入编辑器上下文。你看到页面白屏，AI 看到的可能只有一句「页面打不开」。

第三类是找错了位置。Supabase 权限策略、缺失的 secret、过期的 API key，都可能让操作失败。这些问题不会因为重写页面而消失。

第四类是一次要求太多。范围宽泛的指令会牵动多个文件，故障可能出现在远离需求的位置。

反复失败时，先检查错误证据和故障位置，再决定要不要继续改代码。

作者建议在下一次提问前花 5 分钟，写清楚哪里坏了、期望发生什么、实际发生什么，并复制完整错误。前端问题看浏览器控制台，后端问题看 Supabase 日志。还要确认失败步骤是否涉及数据库、登录、支付或外部 API，因为这些流程经常需要检查页面之外的配置。

什么时候继续修，什么时候回退

作者采用的恢复顺序，先给自动修复设置上限：Try to fix 只尝试 1 到 2 次。文中转述 Lovable 文档称，账户包含 10 次免费修复，每次使用后会在 24 小时后恢复额度。额度是产品规则，实际使用时仍应以账户显示为准。

接下来，把模糊抱怨改成可定位的问题。原文这个提示词同时提供了触发动作、预期结果、完整错误和时间线：

The Projects page goes blank after I click "New project". Expected: the form opens.
Console error: TypeError: Cannot read properties of undefined (reading 'map')
This worked yesterday. Check what changed in the Projects page since then.

要留意最后一行：它让 AI 检查「昨天之后改了什么」，为排查提供了具体范围。不过，这仍是提示词示例，原文没有给出它修复真实项目的过程。

如果还没找到原因，就切到 Plan mode，要求先展示相关代码、解释根因，再提出修改方案。还可以追问已经尝试过哪些修复，避免重复失败路径。

如果补丁已经缠在一起，作者建议从版本历史恢复可用版本，或者编辑过去的消息，选择 Revert and resend。回退后，要告诉 Lovable 撤销了什么，让下一次尝试拥有正确上下文。

局部组件已经难以修补时，可以单独重建一个最小版本，先验证它能独立运行，再接回应用。登录、支付等敏感流程则应在提示词里明确要求：先阅读所有相关代码，限制修改范围。

页面恢复了，为什么还不能算修完

涉及保存数据、登录或调用外部服务时，作者要求直接检查后端。

具体包括：查看 Supabase 日志，核对相关表的行级安全策略（Row-Level Security，RLS），确认函数依赖的 secrets 确实存在于线上项目中。RLS 可以理解为数据库里决定「谁能读写哪些行」的规则。规则不允许，页面写得再正确，请求也可能失败。

验收也不能只看原来的报错是否消失。作者还要求检查周边的登录、保存、支付流程，确认修复没有破坏其他路径。

此外，文中建议扫描已发布网站，检查 JavaScript 中是否暴露密钥、是否缺少安全响应头；解决难题后，把原因与修复方式写进 project knowledge，供 Lovable 后续参考。项目还应连接 GitHub，让可用状态保存在编辑器之外。

作者认为多数项目只需修复少数区域，通常不必整套重写；通过 GitHub 协作后，也可以继续在 Lovable 中编辑。不过，原文没有提供项目样本或成功率。

我的判断

我赞同这套顺序，因为它把排查重心放回了证据、改动范围和恢复能力。对前端开发者来说，这和常规调试并不陌生：先复现、看日志、检查最近变更，再做局部修改。AI 编程增加了生成代码的速度，也更需要控制每轮修改的范围。

但「只试 1 到 2 次」是止损经验，不是经过对照实验验证的最佳次数。原文没有比较连续自动修复、人工定位和版本回退各自的耗时，也没证明写入 project knowledge 后能减少多少重复错误。

局部重建同样有前提：组件边界得足够清楚。若问题涉及共享状态、登录会话或数据结构，重建页面未必能隔离故障，仍要先查依赖。

文末推荐的 Launch Check 属于作者的工具推荐，原文没有说明扫描覆盖范围，也没有给出安全问题由修复循环引入的证据。扫描可以补充检查，但不能代替业务流程验收。

能拿来做什么

• 给下一次 Lovable 报错准备一份固定描述：页面位置、触发步骤、预期结果、实际结果、完整错误和最近改动，避免只发一句「修不好」。
• 自动修复连续失败后，切到 Plan mode，要求列出根因证据与已尝试方案，再决定修改还是回退。
• 遇到保存、登录或支付失败，先核对 Supabase 日志、RLS 和线上 secrets，确认故障所在层级后再修改页面。
• 每个提示词只安排一项改动，测试通过后保存可用版本；连接 GitHub，并把复杂故障的原因和修复方式记入 project knowledge。