Lovable 提示工程最佳实践

原文出处：Lovable Tips & Tricks: Best Practices 目标：帮助所有 Lovable 用户——无论新手还是资深开发者——快速入门、避开常见误区，高效构建项目。

1. 打牢基础：善用 Knowledge 文件

为何重要： Knowledge 文件就像项目的大脑。它会随每次提示一并发送，帮助 AI 理解完整背景。
建议内容：
- 产品愿景（可类比 PRD）
- 用户旅程与角色画像
- 核心功能与特性
- 设计系统与 UI 指南
- 角色特定行为（如 Admin、User、Investor）
快速生成： 在 Chat 模式使用指令：

“基于我已经实现的功能，请在 T=0 为我的项目生成一份知识文件。”

原则： 提示越清晰、越详尽，AI 输出越好。把 AI 当工程伙伴，它只懂你给出的信息。
技巧：
- 明确页面与期望行为，例如 /dashboard。
- 使用自然语言描述需求。
- 补充截图，尤其是 Bug 或 UX 问题。
- 设定“不要动”的范围，例如：
  
  “请勿修改 /shared/Layout.tsx。”
- 重要指示在多条提示中重复，缓解记忆限制。
- 拆分任务，避免一次实现多个功能。每个模块用 Chat 模式验证后再继续，例如：
  功能拆分模板：
  
  新建页面
  
  添加 UI 布局
  
  连接数据
  
  补充逻辑与边界情况
  
  按角色逐一测试
- 若应用存在多角色，务必说明适用角色，避免共享逻辑带来的 Bug：
  
  “作为 Investor，我想查看公司仪表盘，但不应拥有编辑权限。请仅将此功能限定给 Investor 角色。”

定位： Chat 模式是 AI 副驾驶，便于调试、脑暴、规划，在你确认前不会改代码。
适用场景：
- 连续 2–3 次点击“Try to Fix”（尝试修复）失败
- 调试复杂逻辑或数据库问题
- 规划新功能
提示示例：

“请给出 3 种实现 X 的思路。”
工作流建议：
- 许多用户会将 60–70% 的时间用于 Chat 模式，只有在方案清晰时才执行“Implement the plan”（实施计划）。
- 若不常用 Chat 模式，可参考以下格式，提升输出一致性、避免误改：
  
  “在 /settings 页面实现 [功能]。期望行为是 [XYZ]。除非必要，请勿改动组件 A、布局 B 或共享逻辑。请遵循 Tailwind / Supabase / X 的最佳实践。”
- 防止意外代码改动：
  
  “先调查问题，不要立即写代码。” “请提供 3 种无需改动现有代码的解决方案。”
- AI 陷入循环时：切换到 Chat 模式，粘贴报错截图，并说明：
  
  “请在不破坏其他功能的前提下排查问题。必要时可回退到最后一个可用版本再进行修复。”

提醒： Supabase 不易干净回滚，版本回退可能导致数据库结构损坏。
最佳实践：
- 前端稳定后再连接 Supabase。
- 必须回退时，请 AI 先确认：
  
  “请检查 T=0 时的 SQL 架构，并确保没有破坏性变更。”
- 发布前务必测试所有与数据库相关的功能。

要点：
- 每次编辑都会生成提交。用 Pin 标记稳定版本，功能完成后立即 Pin。
- 出现 Bug 后，使用可视化对比，提示示例：
  
  “比较 T–1 与 T–0 版本发生了哪些变化，可能是哪些改动导致了问题？”
- 若改动过多，可回到稳定版本。
- 使用 GitHub 分支需谨慎。切回 Lovable 的 main 前不要删除分支，以免同步出问题。

经验： 很多用户发现第二次重建更快。
Remix 功能： 创建项目在 T=0 的干净副本。
- 用更好的提示与更清晰的知识重建
- 旧项目仅作参考
适用情景：
- 陷入难以解决的 Bug 循环
- 想重新开始并保留历史
- 需要断开 Supabase 尝试新路径（Remix 前需先断开 Supabase）