Lovable 或 Bolt 陷入修 bug 死循环？如何把你的 MVP 真正做完

你让构建工具修复登录。登录好了，可仪表盘却变空了。再发一个提示词恢复了仪表盘，登录又坏了。如果 Lovable 或 Bolt 一直在反复修同样的 bug，接下来真正有用的一步是：围绕某一个故障收集更好的证据。改动越多，并不等于进展越大。

为什么 AI 应用会陷入修复循环？

当改动只针对可见的症状、却没有查明并验证根本原因时，就会出现修复循环。多种不同的故障可能呈现出同一个界面，因此一个宽泛的请求会给构建工具留下太多“看似合理”的修改方向。

仪表盘为空，可能意味着请求失败、权限策略拦截、连错了数据库，或者确实没有数据。修改组件也许能把提示信息藏起来，但失败的请求依然原封不动。你的目标是找出是哪一层出了问题：浏览器、服务器、身份验证服务商、数据库，还是外部集成。

给自己定一条实用的止损规则：如果一次聚焦的修复尝试之后同样的症状又出现了，就别再重复那个提示词，转而收集另一类证据。这是一种工作习惯，而不是平台文档规定的限制。它能防止一个小项目在无人说得清问题所在的情况下，不断累积无关的改动。

是构建工具的预览坏了，还是你的应用坏了？

在重写代码之前，先把构建工具的环境和你的应用分开检查。平台故障或预览连接问题，并不能证明你的产品架构需要推倒重来。

Bolt 当前的预览故障排查指南建议：检查服务状态、收集浏览器控制台错误、尝试生产构建，并排查缺失的环境变量。指南还说明，在第一次尝试失败后，反复提交同样的预览修复提示词不太可能有帮助。

这张表用于决定下一步排查什么，而不是直接下诊断。失败的网络请求仍可能源自应用代码，白屏也可能有多种原因。在后续错误把它淹没之前，先抓住第一个有意义的错误。

再次尝试修复之前，应该保存什么？

保留最近一个有用的代码状态，并确认修复可能影响到哪些数据。代码历史和数据库备份解决的是不同的恢复问题。

Lovable 的版本历史文档介绍了如何预览、收藏和回退代码版本，并明确指出回退代码不会回滚数据库数据。在恢复某个版本之前，请检查之后的工作是否更改了记录、权限，或旧代码所依赖的数据库结构。

1. 标出主要流程最后一次正常运行的状态，附上时间戳或提交标识。
2. 记录当前的故障，并通过项目支持的工作流保存任何有用的未提交工作。
3. 在进行会改动数据或数据库结构的工作之前，创建合适的数据库备份或安全的测试副本。
4. 写明哪个项目和环境中有真实用户，以便在远离他们的环境里测试修复。

一个有用的修复提示词长什么样？

有用的修复提示词只点名一个可复现的故障，提供相关证据，并限定修改范围。在授权一个你无法评估的实现之前，先要求它解释原因。

Investigate one issue: a signed-in customer cannot save a booking.
Steps: create a fresh customer account, open /bookings/new, choose a date, and select Save.
Expected: one booking is saved and appears after refresh.
Actual: the request returns 403 and no booking is saved.
Evidence: [sanitized error, request path, and timestamp].
First explain the likely cause and the files or policies involved.
Do not change roles, remove access checks, redesign screens, or rewrite unrelated features.
Propose the smallest fix and how to test it with two ordinary accounts.

这个示例是假设的，请用你实际观察到的情况替换其中的细节。403 响应是访问失败的线索，而不是移除授权的许可。不要把密码、令牌、连接字符串和客户记录放进提示词或截图里。

对于 Lovable 项目，后端日志指南介绍了如何查看项目可用服务中的请求和错误。请把错误与操作发生的时间和环境对应起来。一条相关且已脱敏的日志，比一大堆未经筛选的日志转储更有用。

如何确认修复真的生效了？

当原始步骤得到预期结果，且重要的相邻流程依然正常时，修复才算生效。要在刷新后检查保存的状态，而不只是看那条临时的成功提示。

1. 用一个新账户和相同的输入重现原始故障。
2. 刷新或重新打开应用，确认结果已正确保存。
3. 用第二个普通账户重复操作，验证预期的数据归属边界。
4. 在安全的测试环境中尝试一种失败情形，例如无效输入或中断的请求。
5. 检查共用被修改代码的相邻流程，然后运行项目的相关检查和生产构建。

什么时候应该请开发者介入？

当你无法有把握地解释或验证对关键路径的修改，或者经过聚焦排查仍无法定位原因时，就该请开发者介入。支付权限、跨账户数据泄露以及反复的数据库改动尤其需要谨慎对待。

一次范围明确的审查可以回答：问题出在配置、一个小的实现缺陷，还是更大的设计问题。请要求对方给出诊断、拟修改的文件或服务、验收测试以及回滚方案。在同意重建之前，你可以先委托做这样一次审查。

一份好的交接材料包括：应用 URL、受支持的项目或代码仓库访问权限、复现步骤、一段简短的录屏、已脱敏的错误信息，以及最后一个可用版本。再补充下一个客户里程碑，以及必须保持不动的功能。只通过合适的密钥共享或账户授权流程来分享凭据。

你的下一个版本应该包含什么？

下一个版本应当修复一小组可衡量的故障流程。在这些流程于已发布的应用上测试通过之前，把新功能需求单独搁置。

修复完成后，可以用这份 12 项 MVP 上线检查计划找出相关的遗漏。如果应用在预览中正常、发布到 Replit 后却出错，请参考 Replit 部署检查清单。如需实际帮助，可在 Lovable 或 Bolt 页面选择你的起点并预约通话。带上出故障的流程；第一次沟通应当帮你明确一个有用的下一步。