Prompting 1.1：提示工程指南

提示结构、提示层级、元 / 反向元提示，以及带示例的基础策略。

前言
为了帮助您充分利用 Lovable，我们整理了一系列提示策略和方法。其中一些来自我们团队的经验，另一些则由社区成员分享。由于 Lovable 依赖大型语言模型（LLMs），有效的提示策略可以显著提高其效率和准确性。

提示是您给 AI 系统下达执行任务的文本指令。在 Lovable（AI 驱动的应用构建器）中，提示是您 "告诉"AI 该做什么的方式 —— 从创建 UI 到编写后端逻辑。有效的提示至关重要，因为 Lovable 使用大型语言模型（LLMs），因此清晰、精心设计的提示可以极大提高 AI 构建应用的效率和准确性。简而言之，更好的提示带来更好的结果。

为什么提示工程很重要

大多数人认为提示只是向 AI 输入请求并期望最好的结果 —— 事实并非如此。AI 响应平庸与让 AI 为您构建整个工作流之间的区别在于您的提示方式。无论您是开发人员还是非技术人员，掌握 Lovable 中的提示工程可以帮助您：

通过精确指示 AI 来自动化重复性任务
借助 AI 生成的见解和解决方案更快地调试

轻松构建和优化工作流，一旦正确引导，让 AI 处理繁重工作
最重要的是？您不需要成为专业程序员。通过正确的提示技术，您可以释放 Lovable 中 AI 的全部潜力，而无需浪费时间进行反复试验。本指南将带您从基础概念到高级提示策略，以便您能够有效地与 AI 沟通并更快地构建应用。

理解 AI 的思维方式

与传统编码不同，与 AI 协作的关键在于清晰传达您的意图。像 Lovable 背后的大型语言模型（LLMs）并不像人类那样 "理解"—— 它们基于训练数据中的模式预测输出。

这对您的提示方式有重要影响：为了获得一致的结果，将提示结构化为清晰的部分会有所帮助。推荐的格式（如提示的 "训练轮"）使用标记部分来包含上下文、任务、指南和约束：

==提供上下文和细节==

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

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

==明确说明指令和约束==

永远不要假设 AI 会推断您的目标。如果您有约束或偏好，请明确说明。例如，如果输出应使用特定库或保持在特定范围内，请事先告诉模型。AI 会从字面上遵循您的指示 —— 模糊性可能导致不想要的结果或 AI"幻觉"（虚构信息）。

==结构很重要（顺序和强调）==

由于 Transformer 架构，模型会特别关注提示的开头和结尾。利用这一点，将最关键的细节或请求放在开头，并在必要时在结尾重申任何绝对要求。

还要记住，模型有固定的上下文窗口 —— 过长的提示或非常长的对话可能导致 AI 忘记早期细节。保持提示专注，并在必要时刷新上下文（例如，如果会话很长，提醒模型关键点）。

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

将提示视为告诉一个非常拘泥于字面意思的实习生您的确切需求。您的指导越清晰、结构越合理，结果就越好。接下来，我们将深入探讨使提示有效的核心原则。

核心提示原则：[[CLEAR 框架]]

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

作为检查清单：

==简洁：清晰且切中要点

多余的内容或模糊的语言会混淆模型。使用直接的语言：例如，

不好的例子："你能写一些关于科学主题的东西吗？"
好的例子："写一篇 200 字关于气候变化对沿海城市影响的摘要。"

避免填充词 —— 如果某个细节没有指导意义，它就是干扰。在描述您想要的内容时力求精确和简洁。

==逻辑：按步骤或结构化组织

以分步或结构良好的方式组织您的提示。将复杂请求分解为有序步骤或项目符号，以便 AI 可以轻松跟随。不要使用单个冗长的请求，而是分离关注点。

不好的例子："给我构建一个用户注册功能，并显示一些使用统计数据。"
好的例子："首先，使用 Supabase 实现带有电子邮件和密码的用户注册表单。然后，成功注册后，显示一个显示用户数量统计的仪表板。"

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

==明确：准确说明想要和不想要的内容

如果某件事很重要，请明确说明。尽可能提供格式或内容示例。模型知识渊博，但不会读懂您的想法了解细节。

不好的例子："告诉我关于狗的事情。"（过于开放）好的例子："列出金毛寻回犬的 5 个独特事实，用项目符号表示。"

同样，如果您有期望的输出风格，请说明（例如 "以 JSON 格式响应" 或 "使用随意的语气"）。将 AI 视为初学者：假设没有什么对它来说是显而易见的。

==适应：如果第一次答案不完美，不要满足

提示可以迭代改进 —— 这是 Lovable 的 AI（和一般 LLMs）的一大优势，您可以进行对话。

如果初始输出未达到目标，请调整方法：在后续提示中澄清说明或指出错误。

例如："您给出的解决方案缺少认证步骤。请在代码中包含用户认证。"

通过迭代，您引导模型获得更好的结果。您甚至可以询问 AI 如何改进提示本身（这是后面会介绍的元提示）。

==反思：每次 AI 交互后花时间回顾成功与失败之处

这更多是关于您而不是模型 —— 作为提示工程师，记录哪些提示措辞获得了良好结果，哪些导致了混淆。复杂会话后，您甚至可以要求 AI 总结最终解决方案或推理（我们很快会讨论反向元提示）。

反思有助于您在未来构建更好的提示，建立 AI 通信的持续改进循环。

在开发提示时请记住这些 CLEAR 原则。接下来，我们将看看从基础到高级的特定提示技术，包括如何构建提示和利用 AI 作为协作者。

四个提示层级

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

1. 结构化 "训练轮" 提示（明确格式）

当您刚开始或处理非常复杂的任务时，在提示中使用标记结构会有所帮助。

这充当训练轮，确保您提供所有必要信息。Lovable 中经过验证的格式是将提示分为以下部分：通过清晰标记每个部分，您几乎不会留下误解的空间。

例如，提示可能如下所示：
==上下文==：您是使用 Lovable 的专业全栈开发人员。
==任务==：使用 Supabase（电子邮件 / 密码认证）在 React 中创建安全登录页面。
==指南==：UI 应简约，并遵循 Tailwind CSS 约定。为每个步骤提供清晰的代码注释。
==约束==：仅修改 LoginPage 组件；不更改其他页面。确保最终输出是 Lovable 编辑器中的工作页面。

这种详细程度引导 AI 逐步进行。训练轮提示非常适合新手或复杂的多部分任务 —— 它迫使您思考确切需求，并通过结构化请求帮助模型。

2. 对话式提示（无训练轮）

当您变得熟练后，并不总是需要如此严格的结构。对话式提示意味着您可以更自然地向 AI 写作，类似于向同事解释任务，同时仍然保持清晰。

关键是在没有使用模版的情况下保持清晰度和完整性。

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

这是更自由形式的提示，但仍然逻辑有序且明确说明了要求。没有训练轮，但仍然有效。

对话式提示在您信任自己不会忘记重要细节时效果很好。它们使交互更自然，特别是在您正在迭代结果的持续聊天中。

即使在对话风格中，您也可以通过将不同方面的请求分成段落或项目符号来模拟结构。目标相同：清晰沟通。对于更快的任务或 AI 已经获得上下文的情况，您可能会使用这种风格。

3. [[元提示]]（AI 辅助提示改进）

这是一种高级技术，您实际上要求 AI 帮助您改进提示或计划。由于 Lovable 的 AI（如 ChatGPT）可以对语言进行推理，您可以使用它来完善您的指令。

如果您得到的输出偏离目标，这尤其有用 —— 这可能表明您的提示不明确。

例如：
"回顾我的上一个提示，找出任何模糊之处或缺失信息。如何重写它才能更简洁和精确？"

"重写此提示以使其更具体和详细：' 使用 Supabase 在 React 中创建安全登录页面，确保基于角色的认证。'"

AI 可能会返回结构更好或更详细的请求版本。这可以揭示哪些内容不明确。本质上，您让 AI 充当提示编辑器。在 Lovable 中，您可以在聊天模式中安全地执行此操作（因为聊天模式不会直接编辑您的项目）。

==元提示将 AI 转变为帮助您提出真正需求的协作者。这是提升提示工程技能的强大方式 ——AI 可以建议您未曾考虑过的改进。==

4. 反向元提示（AI 作为文档工具）

反向元提示意味着使用 AI 在任务完成后总结或记录发生的事情，以便您以后学习或重用。

可以将其视为要求 AI 反思过程并为下次提供提示或解释。这对于调试和知识捕获非常有用。

例如，在使用 Lovable 解决棘手问题后，您可能会提示：
"总结我们在设置 JWT 认证时遇到的错误以及我们如何解决它们。然后，起草一个我将来可以使用的提示，以避免设置认证时的这些错误。"

AI 可能会生成问题和解决方案的简明摘要，然后是模板提示，如 "上下文：构建认证... 任务：通过执行 Y 避免 X 错误..."

这种反向元方法帮助您构建可重用提示和经验教训的个人库。

==在 Lovable 中，这可能是宝贵的：下次面对类似任务时，您有一个经过验证的提示（或至少是明确的检查清单）可供使用。==

假设您花了一个小时调试 API 调用失败的原因。修复后，让 AI 记录下来。您不仅会加强理解，还会创建可输入知识库或未来项目的材料，这样 AI 就不会重复同样的错误。

高级提示技术

掌握基础知识后，是时候利用更高级的策略来充分发挥 Lovable AI 的潜力了。

这些技术帮助处理复杂场景，减少错误（如幻觉），并定制 AI 输出以满足您的需求。

零样本与少样本提示

[[零样本提示]]意味着您要求模型执行任务时不提供示例。您依靠模型的一般训练来知道该做什么。

这是大多数提示的默认方式：您陈述请求，AI 纯粹根据它 "知道" 的内容和从您提示中理解的内容生成答案。

零样本高效，适用于常见任务或描述清晰的任务。例如："将以下句子翻译成西班牙语：' 我正在学习编程。'" 这是零样本提示 —— 直接命令，AI 使用其知识响应（无需示例）。

[[少样本提示]]意味着您在提示中提供几个示例或演示，向 AI 展示您想要的确切格式或风格。

本质上，您在提示本身中通过示例教学。这可以显著提高特定格式或不常见任务的输出质量。

在少样本提示中，您可能会说：
" 纠正这些句子的语法：
输入："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 就不会编造不同的内容。

==提示中的参考==

当询问事实问题或与外部系统交互的代码时，包含相关文档片段或数据。例如，"使用下面给出的 API 响应格式，解析用户对象...[然后包含一个小的 JSON 示例]。"

通过向 AI 展示真实数据或文档，它不太可能编造函数或字段。

==要求逐步推理==

有时您怀疑 AI 可能在敷衍。在这种情况下，提示它展示推理或验证过程。

例如，在聊天模式中您可以说："在给出最终代码之前解释您的解决方案方法。如果有任何不确定性，请说明。"

这种思维链提示使 AI 放慢速度并自我检查。它可以捕捉错误，或者至少在推理中揭示它们，您可以纠正。

==指示诚实==

您可以在提示中包含这样的指南："如果您不确定某个事实或正确代码，不要编造 —— 相反，解释需要什么或请求澄清。"

高级模型通常会遵循此类指令（它们可能会回答 "我不确定，但我假设 X..." 而不是给出错误答案）。这不是万无一失的，但可以减轻自信的错误输出。

==迭代验证==

AI 给出答案后，特别是对于关键内容（如计算、重要事实或复杂代码），执行验证步骤。您可以要求 AI 或使用其他工具进行双重检查。

例如："确认上述代码符合要求，并解释任何可能不符合规范的部分。" 这个提示让 AI 审查自己的工作，通常会发现是否偏离了您的指示。

在 Lovable 中，幻觉也可能意味着 AI 创建了您没有要求的文件或组件，或进行了未预期的创造性发挥。

始终审查 AI 生成的代码是否合理。如果某些内容看起来过于 "神奇" 或意外，要提出质疑。通过这些策略管理幻觉，您可以保持对项目的控制并确保准确性。

==利用模型见解（了解您的 AI 工具）==

并非所有 AI 模型都相同，即使是相同的模型在不同设置下行为也可能不同。

要获得专业级结果，了解 Lovable 中可用的工具会有所帮助：

聊天模式与默认模式

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

有意使用它们：
==聊天模式非常适合头脑风暴、讨论设计决策或调试== ——AI 可以自由生成想法或分析，而无需立即编码。

例如，您可能描述一个错误，并在聊天模式中说："让我们分析这个错误日志并找出问题所在。"AI 然后可以逐步分析潜在原因。

另一方面，默认模式用于执行更改（编写代码、创建组件）。

==典型工作流可能是：在聊天模式中概述或故障排除，一旦有了计划，切换到默认模式用直接提示实现（因为默认模式将修改您的项目文件）。知道何时使用每种模式保持开发流程高效和安全。==

==标记长度和响应==

注意响应长度。如果您要求非常大的输出（如整个模块的代码），如果超过标记限制，AI 可能会截断输出或失去连贯性。

在这种情况下，将任务分解为更小的提示（例如，一次生成一个函数的代码）。

Lovable 的聊天或提示 UI 可能会在输出被截断时显示警告 —— 这表明需要请求剩余部分或划分工作。

==格式和代码偏好==

如果您说明偏好，AI 可以适应您的格式偏好。例如，告诉它 "以 markdown 格式输出代码" 或 "遵循项目的 ESLint 规则"（如果有的话）。

除非您在上下文中包含风格指南，否则它不会神奇地知道您的风格。如果您喜欢特定的命名约定或模式，可以在提示中提及（这是明确原则的一部分）。

随着时间的推移，当 AI 看到项目中一致的风格时，它会模仿 —— 但在提示中给出温和提醒可以加速这种对齐。

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

其他提示技巧

最后，让我们涵盖在 Lovable 平台中工作时的特定提示技巧和技术。这些最佳实践结合了一般提示工程概念和 Lovable 的功能，帮助您获得最佳结果。

从坚实的知识库开始

在编写提示之前，设置项目的知识库（在 Lovable 的项目设置中）。包含==项目需求（PRD）、用户流程、技术栈细节、UI 设计指南和任何后端规范==。

这作为 AI 始终拥有的持久上下文。例如，如果您的 PRD 明确列出 "超出范围：社交登录"，AI 就不太可能随机添加 Google 登录功能。

您还可以在开始时明确提示：
"在编写任何代码之前，阅读项目知识库并确认您理解应用的目的和约束。"

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

==具体明确，避免模糊==

模糊提示导致模糊结果。始终阐明您想要什么以及如何实现。

不要：创建用户输入表单
要：创建一个包含姓名（文本）、电子邮件（带验证）和消息（多行文本）字段的联系表单。添加提交按钮，点击时显示成功消息。使用 Tailwind CSS 样式使表单响应式。
后者提供了关于范围和预期结果的明确方向。

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

不要：
使用 Supabase 构建 CRM 应用，包含认证、Google Sheets 导出和数据丰富功能。构建我的整个电子商务应用，包含认证、产品列表和结账功能。

要：
这种逐步推进帮助 AI 保持专注和准确，并且您可以及早发现问题：
设置连接 Supabase 的 CRM 后端。
很好！请添加带有用户角色的安全认证流程。
谢谢！下一步是集成 Google Sheets 以导出记录。

另一个例子：
为用户信息设置数据库模式。
请开发一个 API 端点来检索用户数据。
包含约束和要求
不要犹豫，详细说明约束。如果某事必须或绝不能做，明确说明。添加约束：
"创建一个简单的待办应用，最多同时显示 3 个任务。包含添加、编辑和删除任务的功能。"
"最多使用 3 个 API 调用，并且确保不需要外部库。"
"页面一次应显示最多 3 个任务。"
这样的限制防止 AI 过度设计。添加如最大项目数或性能目标等约束可以使 AI 专注于重要事项。

==避免措辞模糊==

如果一个术语可以有不同解释，请澄清。您越清晰，AI 需要猜测的就越少。

不要：添加用户个人资料页面。
要：添加包含字段 X、Y、Z 的用户个人资料页面。

不要：表单提交时发送电子邮件通知。
要：当用户提交联系表单时，使用 SendGrid API 发送包含表单数据的电子邮件到 support@example.com。

==注意语气和礼貌==

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

例如：
"请不要修改主页，只关注仪表板组件。"
这读起来有礼貌，并明确告诉 AI 不要做什么。这与 AI 的感受无关 —— 与填充细节有关。（此外，友善总是好的！）

==有意使用 Lovable 的模式==

如前所述，利用聊天模式进行规划，默认模式进行构建。例如，开始新功能时，您可能进入聊天模式并集思广益组件分解：

"我想在我的应用中添加博客部分。让我们讨论如何构建数据和页面结构。"

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

"根据上述计划创建 BlogPost 页面和 Supabase 表或博客文章模式。"

==利用格式优势==

适当时使用列表或步骤。如果您希望 AI 输出列表或遵循序列，请在提示中枚举它们。通过编号步骤，您暗示 AI 以类似方式响应。

" 让我们思考设置安全认证系统的过程：
需要哪些组件？
它们应如何交互？
提供实现代码。"
"首先，解释方法。其次，显示代码。第三，给出测试示例。"

==利用示例或参考==

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

" 我们正在构建一个帮助团队跟踪任务的项目管理工具。此工具应具有以下功能：
用户认证
项目创建
任务分配
报告
现在，对于第一个任务，创建项目创建的 UI。"

另一个例子："我需要一个带有 Supabase 集成和安全认证流程的 CRM 应用。首先设置数据库模式。"

==使用图像提示==

Lovable 甚至允许在提示中上传图像，因此您可以显示设计并说 "创建尽可能类似于附加图像的 UI"。这里有两种主要方法。第一种是简单提示方法。简单图像上传提示您可以上传图像，然后添加示例提示，如下所示：

"创建并实现与附加图像尽可能相似的 UI。"

或者，您可以帮助 AI 更好地理解图像内容和一些额外细节。通过为上传的图像添加具体说明，可以获得出色的结果。

虽然图像胜过千言万语，但添加一些您自己的描述来描述所需功能非常有帮助，特别是因为静态图像无法总是显示交互。

==反馈整合==

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

==强调可访问性==

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

==预定义组件和库==

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

==多语言提示==

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

==定义项目结构和文件管理==

清晰概述项目结构，包括文件名和路径，以确保生成有组织和可维护的代码。这明确了新组件应位于项目中的位置，保持连贯的文件组织。

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

默认情况下，当您要求 Lovable AI 更改某些内容时，它可能会重写整个文件或多个文件。

为避免意外更改，非常具体地说明更改位置和内容。您可以使用 Lovable 的 "选择" 功能突出显示组件或文件，然后仅提示该选择。或者在提示中明确命名文件 / 组件。

例如：
"在 Header 组件中，将注册按钮的文本更改为 ' 开始使用 '，并将其移到导航栏的左侧。"

这样，AI 知道专注于 Header 组件并仅调整该部分。

另一个技巧：告诉 AI 不要触碰什么。您可以添加：
"不要修改与头部无关的任何其他组件或逻辑。"

这防止 AI 偏离并可能破坏其他内容。这种做法（有时称为 "差异与选择" 方法）确保最小化、有针对性的更改 —— 导致更快的响应和更少的回归错误。

==锁定文件（解决方法）==

目前，Lovable 可能没有明确的文件锁定功能，但您可以通过提示措辞模拟它。如果有 AI 绝不应修改的关键文件（可能是一个工作正常的复杂组件），您可以在每个提示中重复如下指令：
"不要更改 authentication.js 文件。"

通过始终告诉 AI 避免，您减少了不必要编辑的机会。同样，如果您只希望 AI 在项目的一个部分工作，明确限制它：
"仅关注 ProfilePage 组件的更改；假设应用的所有其他部分保持不变。"

在提示中预先说明这一点有助于将 AI 保持在范围内。

设计和 UI 调整

在 Lovable 中提示 UI 更改时，清晰度至关重要，以免破坏功能：

如果您只需要视觉更改，请明确说明。

"将登录按钮设为蓝色并增大20%，但不要更改其任何功能或 onClick 逻辑。"

这确保 AI 在重新设计样式时不会意外重命名 ID 或更改逻辑。

==对于响应式设计（使设计适合移动设备），引导 AI 制定计划。==

例如：

"优化 landing 页面以适应移动设备：使用移动优先方法。首先概述每个部分在小屏幕上应如何重新排列，然后实施这些 CSS 更改。使用标准 Tailwind 断点（sm、md、lg），避免自定义断点。确保功能没有任何变化，只调整布局。"

通过提供这种详细指令，您可以获得彻底的移动适配，而不会破坏桌面布局。

如果您有设计更改想法，描述期望的结果和任何约束（如 "保持相同的 HTML 结构，只更新 CSS"）将帮助 AI 专注于正确的解决方案。AI 设计更改后，始终测试应用以确认一切仍按预期工作。

==重构和优化代码==

随着项目的发展，Lovable 的 AI 可能会建议重构以提高性能或可维护性。

提示重构是一个高级但有价值的用例：

强调行为不变
"重构代码以提高清晰度和效率，但应用的功能和输出必须保持完全相同。"

这告诉 AI 重构不应引入错误或功能更改。

首先请求重构计划
"扫描 utils 文件夹并建议代码结构或重复方面的改进。列出更改但不要应用它们。"

AI 可能会给您一份需要改进的报告。然后您可以决定提示实施哪些更改。

大规模重构分阶段进行
分阶段进行。一次提示一个模块，测试，然后继续。这与分步原则一致。例如：首先重构状态管理逻辑，然后重构 API 调用，而不是一次全部完成。

重构后检查
重构后，明智的做法是提示快速检查：
"代码重构后，快速检查清单：UI 看起来相同吗？所有测试或关键流程仍然通过吗？"

AI 可以自我验证或列出需要手动检查的内容。

使用 AI 辅助调试

错误是不可避免的。Lovable 有 "尝试修复" 功能用于快速修复，但您也可以通过提示让 AI 参与：

发生错误时，将任何错误日志或消息复制到提示中（理想情况下在聊天模式），并询问：

"这是错误和相关代码片段 —— 原因是什么，我们如何修复？" 详细的错误上下文帮助

AI 精确定位问题。

调试时使用 CLEAR 原则：明确说明代码应该做什么与实际发生了什么。有时向 AI 详细解释错误会引导它找到解决方案。

如果 AI 的第一个修复不起作用，使用适应原则：==澄清更改内容或提供新错误，并要求它再试一次或提出替代方法==。

利用聊天模式讨论错误：

"修复不起作用。运行时状态仍然未定义。还有什么可能出错？让我们思考可能的原因。"

您可以进行来回讨论，直到找到合理的解决方案，然后在默认模式中应用。

对于 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 生成集成逻辑：实际上，Lovable 可以通过集成 webhook 帮助设置自动化。如果您的应用需要移交任务（如发送电子邮件、更新 CRM）您可以提示 Lovable 使用 Make 或 n8n。

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

边缘情况和外部集成
Lovable 与许多服务集成（Stripe、GitHub、Supabase 等）。提示这些时，将集成细节视为上下文 / 约束的一部分。例如：
"将表单连接到 Stripe（测试模式）进行支付。成功后，重定向到 /thank-you。"

明确说明外部服务应做什么。使用 n8n（自托管自动化）也是如此 —— 您可能会写道：
"表单提交后向 n8n webhook URL 发送 POST 请求，并等待其响应以显示确认消息。"

这里的清晰度是关键，以便 AI 生成正确的调用。

总结

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

如果不确定，从结构化提示开始，并随着信心增强发展为更对话式的风格。

使用元技术改进和从每次交互中学习。

通过练习，您将像指导开发团队的延伸一样引导 AI—— 获得所需的确切输出将变得自然。

结论

到目前为止，您应该已经扎实掌握了如何构建清晰、有效且适合 Lovable AI 的提示。

从基础的 CLEAR 原则到高级策略如少样本示例和元提示，这些技术使您能够从 AI 获得恰好需要的东西 —— 不多不少。

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

专业级提示是改变游戏规则的：它将 AI 从噱头转变为可靠的队友。

通过练习，您会发现可以更快地构建应用，减少调试挫折，甚至通过提出正确的问题和给予正确的指导来探索创造性解决方案。

关键是在指令中保持聪明、简洁、直接和适应性 —— 很像经验丰富的工程师与团队沟通。

最后，始终从每次交互中学习（那种反思习惯）。

每个提示 / 响应都是您改进技术的反馈。当您继续在 Lovable 中构建时，您将培养一种直觉，知道 AI 需要听到什么才能产生出色的结果。

结合您自己的创造力，几乎没有什么是您无法实现的。专注于您的大想法 —— 一旦您清楚地告诉 Lovable AI 该做什么，让它处理执行细节。

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