原文：https://docs.lovable.dev/prompting/prompting-one

这篇 Prompt 教程基本涵盖了我在开发和实践中遇到的所有场景，也融合了跟很多朋友交流后总结的技巧。可以说是 AI Coding 的最小必要技能集——不多不少，刚刚好够用。

强烈推荐给各位，能实实在在提升 AI Coding 的效率和质量。看完就能上手，不用再走弯路。

Prompting 1.1 - Lovable 提示词工程指南

温馨提示： 为了帮助您充分利用 Lovable，我们汇编了一系列提示词策略和方法。这些内容来自我们团队的经验以及社区成员的分享。由于 Lovable 依赖大型语言模型(LLMs)，有效的提示词策略能显著提高其效率和准确性。

什么是提示词？

提示词(Prompting) 指的是你给 AI 系统执行任务的文本指令。在 Lovable(一个 AI 驱动的应用构建器)中，提示词是你”告诉” AI 该做什么的方式——从创建 UI 到编写后端逻辑。

有效的提示词至关重要，因为 Lovable 使用大型语言模型(LLMs)，清晰、精心设计的提示词能大大提高 AI 构建应用的效率和准确性。

简而言之：更好的提示词带来更好的结果。

为什么提示词很重要

大多数人认为提示词只是向 AI 输入一个请求然后期待最好的结果——事实并非如此。

平庸的 AI 响应和让 AI 为你构建整个工作流程之间的差异，归根结底在于你如何提示。

无论你是开发者还是非技术人员，掌握 Lovable 中的提示词工程都能帮助你：

  • 自动化重复任务 - 通过精确指示 AI 要做什么
  • 更快地调试 - 利用 AI 生成的见解和解决方案
  • 构建和优化工作流程 - 一旦正确引导，让 AI 处理繁重的工作

最棒的是什么？ 你不需要成为专家程序员。通过正确的提示词技术，你可以释放 Lovable 中 AI 的全部潜力，而无需浪费时间进行试错。这份指南将带你从基础概念到高级提示词策略，让你能够有效地与 AI 沟通并更快地构建。

理解 AI 如何思考

与传统编程不同，使用 AI 需要清晰地沟通你的意图。

驱动 Lovable 的大型语言模型(LLMs)不会像人类那样”理解”——它们基于训练数据中的模式预测输出。

这对你应该如何提示有重要意义：

为了获得一致的结果，将你的提示词结构化为清晰的部分会有所帮助。推荐的格式（类似提示词的”训练轮”）使用标记的部分：Context（上下文）、Task（任务）、Guidelines（指南）和 Constraints（约束）。

提供上下文和细节

AI 模型除了你提供的内容外，没有常识或隐含上下文。始终提供相关背景或需求。

例如，不要只是说”构建一个登录页面”，而应指定细节：”使用 React 创建一个登录页面，包含邮箱/密码认证和 JWT 处理。”明确包含任何技术栈或工具（例如”使用 Supabase 进行认证”）。

明确指令和约束

永远不要假设 AI 会推断你的目标。如果你有约束或偏好，请说明它们。

例如，如果输出应使用特定库或保持在某个范围内，请预先告诉模型。AI 会字面上遵循你的指令——模糊性可能导致不想要的结果或 AI”幻觉”(编造信息)。

结构很重要(顺序和强调)

由于 transformer 架构，模型特别关注提示词的开头和结尾。

利用这一点，将最关键的细节或请求放在开头，必要时在结尾重申任何绝对要求。同时记住模型有固定的上下文窗口——过长的提示词或很长的对话可能导致 AI 忘记早期细节。保持提示词聚焦，必要时刷新上下文（例如，如果会话很长，提醒模型关键点）。

了解模型的局限

AI 的知识来自训练数据。它无法知道最近的事件或你未提供的专有信息。即使在猜测时它也会试图听起来很自信（这会导致幻觉）。对于事实性查询，始终提供参考文本或数据，或准备好验证其输出。

把提示词想象成告诉一个非常字面理解的实习生你到底需要什么。你的指导越清晰、越结构化，结果就越好。 接下来，我们将深入探讨使提示词有效的核心原则。

核心提示词原则：C.L.E.A.R. 框架

优秀的提示词遵循一套简单的原则。记住它们的便捷方法是 CLEAR：Concise（简洁）、Logical（逻辑）、Explicit（明确）、Adaptive（适应）、Reflective（反思）。在制作指令时将这些作为检查清单：

C - 简洁 (Concise)

清晰直达要点。多余的废话或模糊的语言会让模型困惑。使用直接的语言：

❌ 不好： “你能写一些关于科学主题的东西吗？”

✅ 好： “写一篇 200 字的摘要，关于气候变化对沿海城市的影响。”

避免填充词——如果一个细节没有指导意义，它就是干扰。追求精确和简洁地描述你想要什么。

L - 逻辑 (Logical)

以循序渐进或结构良好的方式组织你的提示词。将复杂请求分解为有序步骤或要点，以便 AI 能轻松跟随。不要用单一冗长的请求，而是分离关注点。

❌ 不好： “给我构建一个用户注册功能，还要显示一些使用统计。”

✅ 好： “首先，使用 Supabase 实现一个包含邮箱和密码的用户注册表单。然后，在成功注册后，显示一个展示用户数量统计的仪表板。”

逻辑流程确保模型系统地处理你请求的每个部分。

E - 明确 (Explicit)

准确说明你想要什么和不想要什么。如果某事重要，拼写出来。如果可能，提供格式或内容的示例。模型有广泛的知识，但它不会读懂你关于细节的想法。

❌ 不好： “告诉我关于狗的事。”（太开放性）

✅ 好： “列出关于金毛寻回犬的 5 个独特事实，用要点形式。”

同样，如果你有期望的输出风格，说出来（例如”以 JSON 格式响应”或”使用随意的语气”）。把 AI 当作初学者：不要假设任何事情对它来说是显而易见的。

A - 适应 (Adaptive)

如果第一个答案不完美，不要满足——提示词可以迭代优化。Lovable AI（和一般的 LLMs）的一大优势是你可以进行对话。如果初始输出偏离目标，调整你的方法：在后续提示中澄清指令或指出错误。

例如，”你给出的解决方案缺少认证步骤。请在代码中包含用户认证。”通过迭代，你引导模型获得更好的结果。你甚至可以要求 AI 如何改进提示词本身（这是元提示，稍后介绍）。

R - 反思 (Reflective)

在每次 AI 交互后花时间回顾什么有效、什么无效。这更多是关于你而不是模型——作为提示词工程师，注意哪些提示词措辞获得了好结果，哪些导致了混乱。在复杂会话后，你甚至可以要求 AI 总结最终解决方案或推理（我们稍后会讨论反向元提示）。保持反思有助于你未来制作更好的提示词，建立持续改进的 AI 沟通循环。

在开发提示词时牢记这些 CLEAR 原则。接下来，我们将研究从基础到高级的具体提示词技术，包括如何结构化提示词以及利用 AI 作为协作者。

提示词的四个级别

有效的提示词是一项随着实践而增长的技能。这里我们概述了四个级别的提示词掌握，从结构化的”训练轮”到高级元技术。每个级别都有其用例——根据需要组合使用：

级别 1：结构化”训练轮”提示（明确格式）

当你刚开始或处理非常复杂的任务时，在提示词中使用标记结构会有所帮助。这充当训练轮，确保你提供所有必要信息。在 Lovable 中经过验证的格式是将提示词分解为如下部分：

  • Context（上下文）： AI 的背景或角色设置。（例如”你是一位世界级的 Lovable AI 编码助手。”）
  • Task（任务）： 你想实现的具体目标。（例如”构建一个包含用户登录和实时同步的全栈待办事项应用。”）
  • Guidelines（指南）： 首选方法或风格。（例如”前端使用 React，样式使用 Tailwind，认证和数据库使用 Supabase。”）
  • Constraints（约束）： 硬性限制或禁止事项。（例如”不使用任何付费 API。应用应在移动和桌面上工作。”）

通过清楚地标记每个部分，你几乎不留任何误解的余地。例如，一个提示词可能看起来像：

text
1
2
3
4
5
6
7
8
Context: 你是一位使用 Lovable 的专家全栈开发者。

Task: 使用 Supabase（邮箱/密码认证）在 React 中创建一个安全的登录页面。

Guidelines: UI 应该简约，遵循 Tailwind CSS 约定。为每个步骤提供清晰的代码注释。

Constraints: 只修改 LoginPage 组件；不要更改其他页面。确保最终输出是 Lovable 编辑器中的可工作页面。

这种详细程度逐步引导 AI。训练轮提示对于新手或复杂的多部分任务非常出色——它迫使你仔细思考你到底需要什么，并通过结构化请求帮助模型。

级别 2：对话式提示（无训练轮）

随着你越来越熟练，你不会总是需要如此严格的结构。对话式提示意味着你可以更自然地向 AI 写作，类似于你向同事解释任务的方式，同时仍保持清晰。关键是在没有正式标签的情况下保持清晰和完整。例如：

text
1
2
让我们构建一个上传个人资料图片的功能。它应该包括一个带有图像文件输入和提交按钮的表单。提交时，它应该将图像存储在 Supabase 存储中并更新用户个人资料。请编写必要的 React 组件和此所需的任何后端函数，并确保优雅地处理错误（如文件过大）。

这是一个更自由形式的提示词，但仍然逻辑有序并明确了需求。没有训练轮，但它是有效的。一旦你相信自己不会忘记重要细节，对话式提示就能很好地工作。它们使交互更自然，特别是在你正在迭代结果的持续聊天中。

即使在对话式风格中，你也可以通过将请求的不同方面分成段落或要点来模拟结构。目标是相同的：清晰的沟通。一旦 AI 已经获得了上下文，你可以在更快速的任务中使用这种风格。

级别 3：元提示（AI 辅助的提示改进）

这是一种高级技术，你实际上要求 AI 帮助你改进提示词或计划。由于 Lovable 的 AI（如 ChatGPT）可以对语言进行推理，你可以用它来完善你的指令。如果你得到的输出偏离基准，这尤其有用——这可能表明你的提示词不清楚。例如：

text
1
2
审查我上一个提示词并识别任何模糊性或缺失信息。我如何重写它以使其更简洁和精确？

或者：

text
1
2
重写这个提示词使其更具体和详细："使用 Supabase 在 React 中创建一个安全的登录页面，确保基于角色的认证。"

AI 可能会回应你请求的更好结构化或更详细的版本。这可以揭示什么不清楚。本质上，你让 AI 充当提示词编辑器。在 Lovable 中，你可以在聊天模式中安全地做到这一点（因为聊天模式不会直接编辑你的项目）。元提示将 AI 变成一个帮助你询问你真正想要什么的协作者。这是一种强大的方式来启动你的提示词工程技能——AI 可以建议你没有考虑过的改进。

级别 4：反向元提示（AI 作为文档工具）

反向元提示意味着在任务完成后使用 AI 来总结或记录发生的事情，这样你可以学习或以后重用。把它想象成要求 AI 反思过程并为下次提供提示词或解释。这对于调试和知识捕获非常有用。例如，在你用 Lovable 解决棘手问题后，你可能会提示：

text
1
2
总结我们在设置 JWT 认证时遇到的错误，并解释我们如何解决它们。然后，起草一个我将来可以使用的提示词，以避免在设置认证时犯这些错误。

AI 可能会产生问题和解决方案的简明回顾，然后是一个模板提示词，如”Context: 构建认证… Task: 通过做 Y 来避免 X 错误…”。这种反向元方法帮助你建立一个可重用提示词和经验教训的个人库。在 Lovable 中，这可能是黄金：下次你面临类似任务时，你已经有了一个久经考验的提示词（或至少有一个清晰的检查清单要遵循）。

假设你花了一个小时调试为什么 API 调用失败。一旦修复，要求 AI 记录它。你不仅会加强你的理解，还会创建材料来输入知识库或未来项目，这样 AI 就不会重复同样的错误。

高级提示词技术

一旦你掌握了基础，就该利用更高级的策略来充分利用 Lovable 的 AI。这些技术有助于处理复杂场景、减少错误（如幻觉）并根据你的需求定制 AI 的输出。

零样本 vs 少样本提示

零样本提示 意味着你在没有示例的情况下要求模型执行任务。你依赖模型的一般训练来知道该做什么。这是大多数提示词的默认方式：你陈述请求，AI 纯粹根据它”知道”的和从你的提示词中理解的来生成答案。零样本高效，如果任务常见或描述清楚就能很好地工作。

例如：”将以下句子翻译成西班牙语：’我正在学习编码。’”是一个零样本提示——直接的命令，AI 使用其知识响应（不需要示例）。

少样本提示 意味着你在提示词中提供几个示例或演示，向 AI 准确展示你想要的格式或风格。本质上，你在提示词本身中通过示例教学。这可以显著提高特定格式或不寻常任务的输出质量。在少样本提示中，你可能会说：

text
1
2
3
4
5
纠正这些句子中的语法：
输入："the code not working good" → 输出："The code is not working well."
输入："API give error in login" → 输出："The API gives an error during login."
现在输入："user not found in database" → 输出：

通过给出两个输入-输出示例，AI 被引导为第三个继续类似的模式。当你需要特定风格的响应时（例如，某种格式的代码注释，或提交消息示例），少样本提示在 Lovable 中很有用。它确实消耗更多提示令牌（因为你包含了那些示例），但通常会产生更一致的结果。

何时使用哪种：

对于简单任务或当你信任模型的内置能力时，先尝试零样本。如果结果不是你想要的格式或深度，通过添加示例切换到少样本。例如，如果你要求一个函数而输出没有遵循你的首选风格，展示一个你喜欢的风格的示例函数并再次提示。少样本在复杂输出方面表现出色（如编写测试用例——提供一个示例测试，然后要求它编写更多）。总之，零样本用于快速直接答案，少样本用于受控风格或复杂指令。

管理幻觉和确保准确性

AI”幻觉”是模型自信地编造不正确的信息或代码的时刻。在像 Lovable 这样的编码平台中，幻觉可能意味着 AI 使用不存在的函数、调用不存在的 API，或在摘要中编造细节。虽然我们不能完全消除这个问题（这是 AI 的限制），但我们可以用减少幻觉的方式提示：

提供基础数据

你提供的可靠上下文越多，AI 需要猜测的就越少。在 Lovable 中，始终利用项目的知识库。在项目上下文中包含你的项目需求文档（PRD）、用户流程、技术栈等。这样，AI 的答案将”基于”你的应用的具体情况。例如，如果你的应用使用某个库或有定义的数据模型，将其放入知识库，这样 AI 就不会编造不同的。

提示中的引用

当提出事实性问题或与外部系统交互的代码时，包含相关文档片段或数据。例如，”使用下面给出的 API 响应格式，解析用户对象…[然后包含一个小的 JSON 示例]。”通过向 AI 展示真实数据或文档，它不太可能编造函数或字段。

要求逐步推理

有时你怀疑 AI 可能在即兴发挥。在这些情况下，提示它展示其推理或验证。例如，在聊天模式中你可以说：”在给出最终代码之前解释你的解决方案方法。如果有任何不确定性，请说明。”这种思维链提示使 AI 放慢速度并检查自己。它可以捕捉错误，或至少在推理中揭示它们，你可以纠正。

指示诚实

你可以在提示词中包含一个指南，如”如果你不确定某个事实或正确的代码，不要编造——相反，解释需要什么或要求澄清。”高级模型通常会遵循这些指令（它们可能会回应”我不确定，但我假设 X…”而不是只给出错误答案）。这不是万无一失的，但它可以减轻自信的错误输出。

迭代验证

在 AI 给出答案后，特别是对于关键事项（如计算、重要事实或复杂代码），进行验证步骤。你可以要求 AI 或使用另一个工具来双重检查输出。例如：”确认上述代码遵循需求，并解释任何可能不符合规范的部分。”这个提示使 AI 审查其工作，通常它会捕捉到它是否偏离了你的指令。

在 Lovable 中，幻觉也可能意味着 AI 创建了你没有要求的文件或组件，或采取了一些不打算的创造性自由。始终审查 AI 生成的代码的合理性。如果某些东西看起来太”神奇”或出乎意料，质疑它。通过用这些策略管理幻觉，你保持对项目的控制并确保准确性。

利用模型洞察（了解你的 AI 工具）

并非所有 AI 模型都相同，即使同一模型也可能因设置而表现不同。要获得大师级结果，了解 Lovable 中可用的工具会有所帮助：

聊天模式 vs 默认模式

Lovable 提供（截至本文撰写时）聊天模式（对话式 AI 助手）和默认/编辑器模式（直接应用更改）。有意识地使用它们。

聊天模式 非常适合头脑风暴、讨论设计决策或调试——AI 可以自由生成想法或分析而不立即编码。例如，你可以描述一个错误，在聊天模式中说，”让我们分析这个错误日志并找出出了什么问题。”AI 然后可以浏览潜在原因。

默认模式 另一方面，用于执行更改（编写代码、创建组件）。典型的工作流程可能是：在聊天模式中概述或排除故障，一旦你有了计划，切换到默认模式用直接的提示实现它（因为默认模式将修改你的项目文件）。知道何时使用每种模式可以保持你的开发流程高效和安全。

令牌长度和响应

注意响应长度。如果你要求非常大的输出（如整个模块的代码），如果超过令牌限制，AI 可能会截断或失去连贯性。在这种情况下，将任务分解为更小的提示（例如，一次生成一个函数的代码）。Lovable 的聊天或提示 UI 可能会在输出被截断时显示警告——这是一个信号，要求剩余部分或分工。

格式和代码偏好

如果你说明，AI 可以适应你的格式偏好。例如，告诉它”以 markdown 格式输出代码”或”遵循项目的 ESLint 规则”（如果你有）。它不会神奇地知道你的风格指南，除非你将其包含在上下文中。如果你喜欢某些命名约定或模式，你可以在提示词中提及（这是明确的一部分）。随着时间的推移，当 AI 在你的项目中看到一致的风格时，它会模仿它——但在提示词中给予温和的提醒可以加速这种一致性。

总之，将 AI 视为一个强大但字面的工具。了解你正在交互的模式和模型，并始终构建你的提示词以发挥它们的优势（结构化、详细的输入），同时防范它们的弱点（健忘、冗长、幻觉）。现在，让我们将这些原则转化为有效使用 Lovable 的具体最佳实践。

额外的提示词技巧

最后，让我们介绍在 Lovable 平台中工作时的具体技巧和技术。这些最佳实践将一般的提示词工程概念与 Lovable 的功能相结合，帮助你获得最佳结果。

从坚实的知识库开始

在你编写提示词之前，设置项目的知识库（在 Lovable 的项目设置中）。包含项目需求（PRD）、用户流程、技术栈细节、UI 设计指南和任何后端细节。这充当 AI 将始终拥有的持久上下文。

例如，如果你的 PRD 明确列出”超出范围：社交登录”，AI 就不太可能随意添加 Google 登录功能。你也可以在开始时明确提示：

text
1
2
在编写任何代码之前，阅读项目知识库并确认你理解应用的目的和约束。

这确保 AI 内化你的项目上下文，减少不相关的建议或幻觉功能。

具体明确，避免含糊

含糊的提示词导致含糊的结果。始终明确你想要什么以及如何做。

不要这样做：

text
1
2
让这个应用更好。

另一个示例：

text
1
2
为用户输入创建一个表单

应该这样做：

后者给出了关于范围和预期结果的明确方向。

text
1
2
重构应用以清理未使用的组件并提高性能，而不更改 UI 或功能。

另一个示例：

text
1
2
创建一个用户注册表单，包含用户名、邮箱和密码字段，并包含一个提交按钮。

增量提示

抵制在一个提示词中要求整个复杂应用的冲动。将你的开发过程分解为逻辑步骤，一次提示一个。

不要这样做：

text
1
2
3
4
使用 Supabase、认证、Google Sheets 导出和数据丰富构建 CRM 应用。

构建我整个电商应用，包括认证、产品列表和结账。

应该这样做：

这种循序渐进的进展帮助 AI 保持专注和准确，你可以及早发现问题：

text
1
2
3
4
5
6
设置连接 Supabase 的 CRM 后端。

太好了！你能添加一个带有用户角色的安全认证流程吗？

谢谢！下一步是集成 Google Sheets 来导出记录。

另一个示例：

text
1
2
3
4
为用户信息设置数据库模式。

请开发一个 API 端点来检索用户数据

包含约束和需求

不要羞于详细说明约束。如果某事必须或不能做，说出来。

添加约束：

text
1
2
3
4
5
6
7
8
9
创建一个简单的待办事项应用，一次最多显示 3 个任务。
包括添加、编辑和删除任务的能力。

优化这段代码，但确保 UI 和核心功能保持不变。记录你所做的每个更改。

最多使用 3 个 API 调用，并确保不需要外部库。

页面应该一次最多显示 3 个任务。

这样的限制防止 AI 过度设计。添加最大项目数或性能目标等约束可以使 AI 专注于重要的事情。

避免措辞歧义

如果一个术语可以以不同方式解释，澄清它。你越清楚，AI 需要猜测的就越少。

不要这样做：

text
1
2
3
4
添加个人资料功能

支持通知

应该这样做：

后者给出了关于范围和预期结果的明确方向。

text
1
2
3
4
添加一个用户个人资料页面，包含字段 X、Y、Z。

在表单提交时发送电子邮件通知。

注意你的语气和礼貌

虽然它不会改变功能，但礼貌的语气有时可以产生更好的结果。诸如”请”或尊重的请求之类的短语可以添加上下文并使提示词更具描述性，这可以帮助 AI。例如，

text
1
2
请不要修改主页，只关注仪表板组件。

这读起来很礼貌，它明确告诉 AI 不要做什么。这不是关于 AI 的感受——而是关于填充细节。（而且，礼貌一点总是没有坏处！）

有意使用 Lovable 的模式

如前所述，利用聊天模式进行规划，利用默认模式进行构建。例如，在开始新功能时，你可以进入聊天模式并头脑风暴组件分解：

text
1
2
我想在我的应用中添加一个博客部分。让我们讨论如何构建数据和页面。

AI 可能会回应一个大纲。一旦你满意，你可以切换到默认模式并说：

text
1
2
根据上述计划创建 BlogPost 页面和 supabase 表或博客文章模式。

利用格式优势

适当时使用结构化列表或步骤。如果你想要 AI 输出列表或遵循序列，在提示词中枚举它们。通过编号步骤，你暗示 AI 也要这样响应。

text
1
2
3
4
5
6
7
让我们思考设置安全认证系统的过程：
1. 必要的组件是什么？
2. 它们应该如何交互？
3. 提供实现代码。

首先，解释方法。其次，展示代码。第三，给出测试示例。

利用示例或引用

如果你有目标设计或代码风格，提及它或提供示例。提供示例（图像或代码片段）给 AI 一个具体的参考来模仿。

设置上下文：

text
1
2
3
4
5
6
7
8
9
我们正在构建一个帮助团队跟踪任务的项目管理工具。
该工具应该具有以下功能：
 - 用户认证
 - 项目创建
 - 任务分配
 - 报告

现在，对于第一个任务，创建项目创建的 UI。

另一个示例：

text
1
2
我需要一个具有 Supabase 集成和安全认证流程的 CRM 应用。从设置后端开始。

另一个示例：

text
1
2
我们正在开发一个专注于环保产品的电商平台。生成一个带有类别和价格过滤器的产品列表页面。

使用图像提示

Lovable 甚至允许在提示词中上传图像，所以你可以展示一个设计并说”匹配这个风格”。

这里有两种主要方法。第一种是简单的提示方法。

简单图像上传提示：

你可以上传图像，然后添加类似这样的示例提示：

text
1
2
3
4
创建并实现一个尽可能与附加图像相似的 UI。

此截图显示了移动设备上的布局问题。调整边距和内边距使其响应式，同时保持相同的设计结构。

或者，你可以帮助 AI 更好地理解图像的内容以及关于它的一些额外细节。通过向上传的图像添加具体指令可以获得出色的结果。虽然一张图片胜过千言万语，但添加你自己的一些话来描述所需的功能可以大有帮助——特别是因为交互并不总是从静态图像中显而易见。

带详细指令的图像提示：

text
1
2
3
4
5
我希望你创建的应用尽可能与此截图中显示的应用相似。
它本质上是一个看板克隆。
它应该能够在每列中添加新卡片（票证），能够更改单列内这些票证的顺序，甚至在列之间移动这些卡片。
请随意使用 Pangea home dnd npm 包来实现拖放功能。

反馈整合

审查 AI 的输出并为改进提供具体反馈。

text
1
2
登录表单看起来不错，但请为邮箱字段添加验证以确保它包含有效的电子邮件地址。

强调可访问性

鼓励生成符合可访问性标准和现代最佳实践的代码。这确保输出不仅功能性强，而且用户友好并符合可访问性指南。

text
1
2
生成一个遵循可访问性最佳实践的 React 登录表单组件，包括适当的 ARIA 标签和键盘导航支持。

预定义组件和库

指定使用某些 UI 库或组件来保持项目的一致性和效率。这指导 AI 利用特定工具，确保兼容性和整个应用程序的统一设计语言。

text
1
2
使用 shadcn/ui 库和 Tailwind CSS 样式创建一个响应式导航栏。

多语言提示

在多语言环境中工作时，为代码注释和文档指定所需的语言。这确保生成的内容对说不同语言的团队成员可访问，增强协作。

text
1
2
生成一个计算斐波那契数列的 Python 脚本。用法语提供注释和文档。

定义项目结构和文件管理

清楚地概述项目结构，包括文件名和路径，以确保有组织和可维护的代码生成。这提供了关于新组件应该驻留在项目中何处的清晰度，保持连贯的文件组织。

text
1
2
创建一个名为 'UserProfile' 的新 React 组件并将其保存为 'components/user-profile.tsx'。确保它包括个人资料图片、用户名和简介部分。

提供精确的编辑指令（聚焦 AI）

默认情况下，当你要求 Lovable AI 更改某些内容时，它可能会重写整个文件或多个文件。为了避免意外更改，对更改的位置和内容要非常具体。你可以使用 Lovable 的”选择”功能突出显示组件或文件，然后仅对该选择进行提示。或者在提示词中明确命名文件/组件。例如：

text
1
2
在 Header 组件中，将注册按钮的文本更改为 'Get Started' 并将其移到导航栏的左侧。

这样，AI 知道专注于 Header 组件并只调整该部分。另一个技巧：告诉 AI 不要触碰什么。你可以添加，”不要修改任何与 header 无关的其他组件或逻辑。”这防止 AI 偏离并可能破坏其他东西。这种做法（有时称为”差异和选择”方法）确保最小的、有针对性的更改——导致更快的响应和更少的回归错误。

锁定文件（变通方法）

目前，Lovable 可能没有明确的文件锁定功能，但你可以通过提示词措辞来模拟它。如果有 AI 绝不应该更改的关键文件（也许是一个运行良好的复杂组件），你可以在每个提示词中重复一个指令，如：

text
1
2
不要更改 authentication.js 文件。

通过一致地告诉 AI 避免，你减少了不必要编辑的机会。同样，如果你只想让 AI 在项目的一部分工作，明确限制它：

text
1
2
只关注 ProfilePage 组件的更改；假设应用程序的所有其他部分保持原样。

在提示词中预先说明这一点有助于保持 AI 在界限内。

设计和 UI 调整

在 Lovable 中提示 UI 更改时，清晰度至关重要，这样你就不会破坏功能：

  • 如果你想要纯视觉更改，说出来。”使登录按钮变蓝并放大 20%，但不要改变其任何功能或 onClick 逻辑。”这确保 AI 在重新设计样式时不会意外重命名 ID 或更改逻辑。
  • 对于响应性（使设计适合移动设备），通过计划引导 AI。例如：”优化着陆页以适配移动设备：使用移动优先方法。首先概述每个部分应该如何在较小屏幕上重新排列，然后实现这些 CSS 更改。使用标准 Tailwind 断点（sm、md、lg）并避免自定义断点。确保功能没有任何变化，只是布局。”通过提供这种详细的指令，你可以在不破坏桌面布局的情况下彻底适配移动设备。
  • 如果你心中有设计更改，描述期望的结果和任何约束（如”保持相同的 HTML 结构，只更新 CSS”）将帮助 AI 专注于正确的解决方案。在 AI 设计更改后始终测试应用以确认一切仍按预期工作。

重构和优化代码

随着项目的发展，Lovable 的 AI 可能会建议重构以提高性能或可维护性。提示重构是一个高级但有价值的用例：

  • 强调行为无变化： “重构代码以提高清晰度和效率，但应用程序的功能和输出必须保持相同。”这告诉 AI 重构不应该引入错误或功能更改。
  • 你可以先要求重构计划： “扫描 utils/ 文件夹并建议代码结构或重复的改进。列出更改但先不要应用它们。”AI 可能会给你一份改进报告。然后你可以决定提示实施哪些更改。
  • 对于大规模重构，分阶段进行。 一次提示一个模块，测试，然后继续。这与循序渐进的原则相结合。例如：首先重构状态管理逻辑，然后重构 API 调用，而不是一次性全部重构。
  • 重构后，明智的做法是提示快速后检查： “现在代码已重构，快速检查清单：UI 看起来是否相同，所有测试或关键流程是否仍然通过？”AI 可以自我验证或列出要手动检查的事项。

使用 AI 辅助调试

错误是不可避免的。Lovable 有”尝试修复”功能用于快速修复，但你也可以通过提示寻求 AI 的帮助：

  • 当错误发生时，将任何错误日志或消息复制到提示中（理想情况下在聊天模式中）并问：”这是错误和相关代码片段——是什么导致了这个问题，我们如何修复它？”详细的错误上下文帮助 AI 精确定位问题。
  • 在调试时使用 CLEAR 原则：明确代码应该做什么与实际发生的情况。有时只是向 AI 详细解释错误就会导致解决方案。
  • 如果 AI 的第一个修复不起作用，使用适应原则：澄清什么改变了或提供新错误，并要求它再试一次或建议替代方法。
  • 利用聊天模式讨论错误：”修复没有起作用。状态在运行时仍然是 undefined。还有什么可能出错？让我们思考可能的原因。”你可以来回讨论，直到找到合理的解决方案，然后在默认模式中应用它。
  • 对于 UI 错误，你甚至可以共享截图（如果 Lovable 在聊天中支持图像输入）或描述视觉问题。例如，”侧边栏应该在移动设备上隐藏，但它仍然可见。这是 CSS…为什么可能失败？”如果给予足够的信息，AI 可以对 CSS 或布局问题进行推理。
  • 修复后始终测试。如果有效，考虑使用反向元提示让 AI 总结根本原因是什么以及将来如何避免它，丰富你的知识库。

何时（以及何时不）涉及 AI

一位大师级提示者知道有时你根本不需要提示。如果更改非常小或你已经知道如何快速做（例如，更改文本标签，调整一个内边距值），在代码编辑器中手动做可能更快。对琐碎任务过度依赖 AI 会减慢你的速度并消耗你的提示配额。在 AI 增加价值的地方使用它——复杂逻辑、样板代码生成、多步操作或你不确定的事情。对于更简单的问题，你可以：

  • 使用你自己的知识或快速搜索（或甚至在 Lovable 外问 ChatGPT）来弄清楚，特别是如果它避免在 AI 可能误解的事情上浪费提示。
  • 利用开发者工具：打开浏览器 DevTools 控制台来检查元素或实时调试 JavaScript 错误。一旦你确定了修复，你可以直接实施它或通过提示确认。

如果你注意到一个按钮的颜色错误，自己修复 CSS 类可能比向 AI 描述问题并冒险它更改超过预期的风险更快。另一方面，如果你需要从头开始实现一个新功能，那是 AI 的完美工作——你描述什么和为什么，它在代码中弄清楚如何做。

记住，Lovable 的 AI 就像一个助理开发者。你通过给出清晰的任务和监督来管理它。它可以大大加快开发速度，但你仍然是审查和指导工作的负责人。

在不同工具中应用这些策略

上述提示词原则不仅适用于 Lovable 的聊天，而且适用于你与 AI 或自动化工具交互的任何地方：

在 Lovable 的构建器中

你主要会在 Lovable 聊天界面中使用这些提示来构建和完善你的应用。

  • 从一个宽泛的项目提示开始，然后逐个功能迭代。
  • 当你需要讨论或调试而不更改代码时使用仅聊天模式。

使用 Make.com 或 n8n（工作流自动化）

你可能不会以同样的方式用自然语言提示这些平台，但设计自动化仍然受益于清晰的 AI 指令。

例如，你可以让 Lovable 生成集成逻辑：

text
1
2
当表单提交时，将数据发送到 Make.com webhook 以进行 Slack 通知。

事实上，Lovable 可以通过与 webhooks 集成来帮助设置自动化。如果你的应用需要移交任务（如发送电子邮件、更新 CRM），你可以提示 Lovable 使用 Make 或 n8n。

text
1
2
在应用中用户注册后，触发一个在 Salesforce 中创建记录的 Make.com 工作流。

Lovable 将编写调用该 webhook 或 API 的代码。保持提示词结构化确保 AI 确切知道如何将 Lovable 与这些外部服务连接。

边缘情况和外部集成

Lovable 与许多服务（Stripe、GitHub、Supabase 等）集成。当提示这些时，将集成细节作为上下文/约束的一部分。例如，

text
1
2
将表单连接到 Stripe（测试模式）进行支付。成功后，重定向到 /thank-you。

明确外部服务应该做什么。对于使用 n8n（自托管自动化）也是如此——你可以写，

text
1
2
在表单提交后向 n8n webhook URL 发送 POST 请求，并等待其响应以显示确认消息。

这里的清晰度是关键，这样 AI 才能产生正确的调用。

总结

强大的提示在于清晰、结构和上下文。无论你是告诉 Lovable 构建一个功能，还是编排一个 Make.com 场景，目标都是描绘出你想要什么的画面。

  • 如果你不确定，从结构化提示开始，随着信心增长演变为更对话的风格。
  • 使用元技术从每次交互中改进和学习。
  • 通过实践，你将像引导开发团队的延伸一样引导 AI——而且感觉自然地获得你需要的确切输出。

结论

到现在为止，你应该对如何制作清晰、有效且针对 Lovable AI 定制的提示词有了扎实的掌握。从基础的 CLEAR 原则到少样本示例和元提示等高级策略，这些技术使你能够从 AI 获得你需要的确切内容——不多不少。

你已经学会了如何结构化请求、提供上下文、避免幻觉等陷阱，以及利用 Lovable 特定的功能（知识库、聊天模式等）来简化你的工作流程。

大师级提示是一个游戏规则改变者：它将 AI 从噱头变成可靠的队友。 通过实践，你会发现你可以更快地构建应用，减少调试的挫折感，甚至通过简单地提出正确的问题和给出正确的指导来探索创造性的解决方案。关键是在你的指令中保持聪明、简洁、直接和适应——就像一个经验丰富的工程师与他们的团队沟通一样。

最后，始终从每次交互中学习（那个反思习惯）。每个提示/响应都是你进一步完善技术的反馈。当你继续在 Lovable 中构建时，你将培养出一种直觉，知道 AI 需要听到什么才能产生出色的结果。将其与你自己的创造力结合起来，几乎没有什么是你无法实现的。

专注于你的宏大想法——一旦你清楚地告诉 Lovable 的 AI 要做什么，就让它处理执行细节。

祝你提示愉快，构建愉快！