◆ geekjourney · docs
$⌘K
Vol. 5 · § 362026·05·04 · 0 words36
Ch. 5

Lovable 提示工程最佳实践

§ 36

从知识库、提示结构到版本管理的全流程经验总结

UPDATED
2026·05·04 · git dev
GROUP
LANG
zh

Lovable 提示工程最佳实践

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

§1. 打牢基础:善用 Knowledge 文件

  • ·

    为何重要: Knowledge 文件就像项目的大脑。它会随每次提示一并发送,帮助 AI 理解完整背景。

  • ·

    建议内容:

    • ·产品愿景(可类比 PRD)
    • ·用户旅程与角色画像
    • ·核心功能与特性
    • ·设计系统与 UI 指南
    • ·角色特定行为(如 Admin、User、Investor)
  • ·

    快速生成: 在 Chat 模式使用指令:

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

§2. 提示词最佳实践

  • ·原则: 提示越清晰、越详尽,AI 输出越好。把 AI 当工程伙伴,它只懂你给出的信息。
  • ·技巧:
    • ·

      明确页面与期望行为,例如 /dashboard

    • ·

      使用自然语言描述需求。

    • ·

      补充截图,尤其是 Bug 或 UX 问题。

    • ·

      设定“不要动”的范围,例如:

      “请勿修改 /shared/Layout.tsx。”

    • ·

      重要指示在多条提示中重复,缓解记忆限制。

    • ·

      拆分任务,避免一次实现多个功能。每个模块用 Chat 模式验证后再继续,例如:

      功能拆分模板:

      • ·新建页面
      • ·添加 UI 布局
      • ·连接数据
      • ·补充逻辑与边界情况
      • ·按角色逐一测试
    • ·

      若应用存在多角色,务必说明适用角色,避免共享逻辑带来的 Bug:

      “作为 Investor,我想查看公司仪表盘,但不应拥有编辑权限。请仅将此功能限定给 Investor 角色。”

§3. 充分利用 Chat 模式

  • ·

    定位: 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 模式,粘贴报错截图,并说明:

      “请在不破坏其他功能的前提下排查问题。必要时可回退到最后一个可用版本再进行修复。”

§4. 避免 Supabase 常见陷阱

  • ·提醒: Supabase 不易干净回滚,版本回退可能导致数据库结构损坏。
  • ·最佳实践:
    • ·

      前端稳定后再连接 Supabase。

    • ·

      必须回退时,请 AI 先确认:

      “请检查 T=0 时的 SQL 架构,并确保没有破坏性变更。”

    • ·

      发布前务必测试所有与数据库相关的功能。

§5. 使用 Visual Edit 快速优化 UI

  • ·优势: Visual Edit 免费又迅速,适合:
    • ·修改文字、颜色、字体、布局
    • ·同时调整多个小组件
    • ·进行安全、可撤销、免额度的提交

§6. 明智使用 GitHub 与版本控制

  • ·要点:
    • ·

      每次编辑都会生成提交。用 Pin 标记稳定版本,功能完成后立即 Pin。

    • ·

      出现 Bug 后,使用可视化对比,提示示例:

      “比较 T–1 与 T–0 版本发生了哪些变化,可能是哪些改动导致了问题?”

    • ·

      若改动过多,可回到稳定版本。

    • ·

      使用 GitHub 分支需谨慎。切回 Lovable 的 main 前不要删除分支,以免同步出问题。

§7. 实在不行就 Remix

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

§8. 保持耐心与冷静

  • ·心态: AI 时而神奇、时而令人挫折。最后 5% 的完善最耗时却最关键。
  • ·黄金法则:
    • ·慢慢写提示,反复检查。
    • ·将任务拆成可测试的小块。
    • ·输入越精准,输出越优秀。

§9. 善用文档与求助渠道

  • ·资源: 官方文档包含流程教程、模板、SEO 建议、集成指南等,并可直接向文档中的 AI 助手提问。
  • ·社区: 加入 Discord 社区互相支持。
  • ·展示: 准备就绪后,将项目提交至 Lovable Launch。

§10. 额外小贴士

  • ·

    使用语音输入提示(如 Mac 的语音听写)更快撰写长指令,尤其在疲惫或烦躁时。

  • ·

    尝试“我现在很沮丧……”之类的提示,让 AI 更专注。

  • ·

    大改后,务必重新检查各角色行为,尤其是含条件逻辑的部分。

  • ·

    保存稳定版本以便快速回溯。

  • ·

    避免过度通用的逻辑导致意外副作用,可明确要求:

    “请为 [角色 X] 单独创建组件,除非界定清晰,否则不要复用共享组件。”