调试提示指南（Prompting Debugging）

原文出处：Lovable Prompt Debugging

使用 AI 构建既快速又有趣——直到出现问题为止。报错、意外行为或“AI 做了奇怪的事”在所难免。本指南帮助你在 Lovable 中驾驭基于 AI 的调试工作流：如何迅速修复小问题、应对棘手 bug、利用 Lovable 的聊天功能进行调试，以及如何用提示配方系统性地消灭问题。与 AI 助手一起调试是项新技能，但只要结构清晰、提示得当，就能高效解决问题，甚至从中获得学习机会。

高阶调试提示（Advanced Debugging Prompts）

有时你需要更“重型”的提示来深入排查问题或检查项目健康状况。下面是一些用于深度调试或优化场景的结构化提示示例。可在聊天模式（Chat Mode）中使用，以获取详尽分析而不直接修改代码。

全面系统审查（Full System Review / Codebase Audit）

当项目规模增长或怀疑存在结构性问题时，可以让 AI 对整个代码库做一次审查。它会检查架构是否干净、模块化，以及是否有放错位置的代码，就像问它：“一切都井井有条吗？”

示例提示 — 代码库审计：

请对整个代码库执行一次全面的**架构审计**，确认结构是否干净、模块化且优化：

- 找出放错位置或可以更合理组织的文件、组件或逻辑。是否存在不应该出现在当前文件中的代码（逻辑错位）？
- 评估是否保持了清晰的关注点分离（例如数据处理 vs. UI vs. 状态管理）。指出任何耦合过深的代码。
- 标注过度复杂或不符合最佳实践的代码区域。
- 提供改进结构与可维护性的具体建议报告，**暂时不要进行代码修改**。

请将建议按重要程度排序，整理为一个有序列表，从最紧急到可选优化。

*（此次仅限阅读分析，不要在审计过程中修改代码。）*

这个提示虽然篇幅较长，但它会让 AI 充当代码审查员或架构师。我们要求它找出逻辑错位、检查模块化程度，甚至按优先级列出修复顺序。AI 可能回复：

将 API 调用与组件拆分：ProjectList 组件直接发起请求，建议把数据获取移到专用 hook 或 context，保持组件只负责 UI。
降低任务逻辑耦合：任务完成开关同时更新状态并写入 localStorage，应重构为单一事实来源。
归置工具函数：App.tsx 中的日期格式化函数应移动到 utils 目录。

这样可以帮助你从更高层次审视项目，尤其在你一直专注某个功能而忽略整体结构时。随后，你可以挑选其中的重构项，逐条提示 AI 实施。

避免使用泛泛而谈的提示：

什么都坏了，帮我修一下！

请让提示更加具体、详尽：

现在屏幕变成空白，我无法继续编辑。
能帮我检查发生了什么吗？

易碎场景的安全策略（Safe Approach for Fragile Updates）

当你知道即将修改的区域十分敏感（例如复杂的认证流程或核心算法），可以在提示开头加上一段警示性的指导语。这并非直接找 bug，而是提醒 AI 格外小心，避免引入新的问题。我们在提示词库中讨论过“锁定文件”的写法，这里给出一个聚焦“不要破坏现有逻辑”的版本。

示例提示 — 脆弱更新的安全提醒：

接下来的改动涉及应用的**关键模块**，请务必**极度谨慎**：

- 在修改之前，先仔细检查所有相关代码与依赖。
- **不要改动**任何无关的组件或文件。
- 如果有任何不确定之处，请先暂停并解释你的想法，再继续操作。
- 修改完成后务必充分测试，确认不会影响其他部分。

**任务：** 在现有邮箱/密码登录基础上，添 Google OAuth 登录，并确保两个流程都能正常工作。

*（请在实现过程中格外小心，逐步确认每一步。）*

通过斜体、粗体等强调，你实质上在设定 AI 的“心态”——保持谨慎。AI 可能先说明实施步骤，再动手添加 OAuth，同时明确保留了邮箱/密码流程。这个策略适用于认证、支付、数据迁移等容易“一着不慎、满盘皆输”的模块，是一种预防性调试措施。

性能优化检查（Performance Optimization Check）

如果应用能运行但感觉迟缓或资源消耗大，可以让 AI 帮你分析性能瓶颈。它会查看数据获取模式、渲染效率，提出缓存、memo、懒加载等优化建议，相当于问：“怎样让它更快更顺滑？”

示例提示 — 性能审计：

应用功能正常，但感觉**有点卡**。请**分析整个项目的性能瓶颈**并给出优化建议：

- 检查是否存在不必要的数据库或网络请求（例如重复请求、N+1 查询）。
- 找出可能频繁重新渲染或在主线程执行繁重任务的组件。
- 查看资源（图片、脚本）的使用情况：是否有体积过大的文件影响加载速度？
- 提出改进建议，例如缓存常用数据、在合适位置使用 React.memo 或懒加载，以及其他可提速的方法。

请以列表形式输出分析与建议，暂时不要改动代码，仅指出可改进的方向。

在聊天模式下运行此提示，可以获得诊断报告。AI 可能会建议：

数据获取： ProjectList 每次渲染都会请求数据，建议缓存或提升到更高层的 context，避免重复请求。
重新渲染： TaskItem 未做 memo，当父级状态改变时会全部重新渲染，建议使用 React.memo。
资源优化： 有一张 2MB 的 logo 图片，建议压缩或换用低分辨率版本。
打包体积： 页面都打进一个 bundle，考虑用动态 import() 做代码拆分。

接着，你可以挑选其中的优化项，让 Lovable 分步实施，例如：“按照建议实现项目数据的缓存机制”。这样既能提升体验，也可能减少成本（更少请求、更少计算）。

处理顽固错误（Handling Persistent Errors）

有些错误会反复出现，原因是根本问题未被解决。例如你修复了表层症状，但深层逻辑依旧有问题，导致不同形式的报错反复出现。可以尝试以下策略：

询问 AI 已尝试的方案： 多次使用“Try to Fix”或手动调整后，往往不清楚做过哪些变更。可提示：“我们为这个错误尝试过哪些方案？”AI 会列出尝试过的办法，避免重复劳动。
让 AI 用简单语言解释错误： “请用通俗的话解释这个错误为何出现。”这样可以检查你和 AI 是否真正理解问题，也能发现潜在误解。
换一种实现思路： 询问：“既然这个错误总出现，有没有其他实现方式达到目标？”AI 可能提供绕开问题的替代方案。
回滚并重来： 情况极端时，可以回滚到早期版本（Lovable 支持恢复旧版本），再以更小的步骤前进。也可告诉 AI：“我们准备撤销刚才的修改，改为按更小的步伐推进。”这样能重置上下文，摆脱僵局。
隔离“死掉”的组件： 如果某个组件无论如何都不工作，可尝试通过提示新建一个最小版本，验证其独立运行，再逐步合并回项目。这类似“关机重启”，但针对代码。

整个过程中，务必保持与 AI 的对话，把它当作协作伙伴：“我们修好了 X，但 Y 又出问题。X 和 Y 有什么关系？前一个修复会影响到后者吗？”AI 往往能发现你未注意到的关联。

示例调试流程（Sample Debugging Flows）

为了更好地理解上述思路，以下以三个常见场景演示调试流程。

“陷入错误循环”

你刚提示了一段复杂改动，如今应用无法构建，且两次“Try to Fix”都失败。

切换到聊天模式。
提问：“这次构建错误的根本原因是什么？”
AI 解释是 API 调用的类型不匹配。
你继续问：“请展示相关代码和期望的类型。”
AI 展示函数期望收到数字 ID，却得到对象。
你提示：“修改代码，仅传入数字 ID，而不是整个对象。”
切回默认模式执行该提示，构建成功。
如果仍失败，则回去继续追问：“还有哪些可能导致这个错误？”

关键在于：明确描述错误、让 AI 确认它的理解，而不是盲目反复点击修复。

“功能无法正常工作”

你添加了通知功能，但邮件没有发出。

没有报错，于是你在聊天模式提问：“邮件通知没有生效——任务逾期时我没有收到邮件，我们该怎么调试？”
AI 建议检查服务器函数是否触发，以及邮件服务返回了什么响应。
你从（比如 Supabase）日志里看到权限错误。
把日志交给 AI：“日志显示发送邮件时出现 ‘permission denied’。”
AI 推测可能是邮件服务 API 密钥未配置或被阻止。
你在设置中修正密钥（或提示 AI 调整函数采用其他方案）。

通过描述期望（收到邮件）与实际（没有，附带日志），AI 可以指导排查步骤。

“UI 元素消失”

重构后，一个 UI 区块完全消失（“组件死了”）。

告诉 AI：“项目列表区块完全不显示了。它在上次编辑前还好好的。”
AI 检查组件是否仍被渲染，是否缺少 return。
它可能发现重构时，Dashboard 页面不再引用 ProjectList。建议重新引入。
AI 会给出排查思路：“数据还在拉取吗？组件有收到 props 吗？在渲染里加个 console.log 看看。”
你这么做后发现没有任何日志，说明组件根本没挂载。
于是提示：“请在 Dashboard 页的 JSX 中恢复 <ProjectList>（之前误删了）。”

在此案例中，关键是描述组件完全不见，AI 协助判断是未渲染还是渲染为空。

利用开发者工具与控制台日志：

我的应用无法运行，屏幕一片空白。
以下是开发者工具控制台的输出，请帮我排查：

Error occurred:
TypeError: Q9() is undefined at https://example.lovable.app/assets/index-DWQbrtrQQj.js:435:39117
index-DWQbrtrQQj.js:435:35112
onerror https://example.lovable.app/assets/index-DWQbrtrQQj.js:435

根因分析、回滚与渐进增强（Root Cause Analysis, Rollback, and Progressive Enhancement）

以下是一些收尾建议：

关注根因，而非症状

每次都问：“为什么会发生？”而不仅是“现在怎么办？”。AI 可以帮助你找到根因，从而彻底解决问题。例如它可能通过快速修补消除 Null 指针错误，但没有处理真正导致 Null 的逻辑。若你怀疑这一点，可以追问：

我看到你通过增加判空避免了 Null 指针，但它为什么会是 Null？能否解决根本原因？

这样才能得到更稳固的解决方案。

明智回滚

Lovable 支持恢复到旧版本。如果一连串修复把代码改得面目全非，不妨回到之前，再换个策略。从头来过时，可提醒 AI：

我已经把项目回滚到添加通知功能之前。现在让我们更谨慎地重新实现它。

这样 AI 会明白代码突然变化的原因，重新调整方案。

渐进增强（Progressive Enhancement）

尤其在引入复杂新功能时，尽量拆成小步实施。这样如果出问题，就能迅速定位是哪一步造成的。若发现自己准备写一个涵盖多个功能的大段提示，不妨拆分成多条。将问题切成小块也让调试更轻松。

添加失败的测试用例。
隔离问题，分析依赖关系。
在修复前记录发现的线索。

调试提示指南

目录