原文：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 处理繁重的工作

理解 AI 如何思考

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

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

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

提供上下文和细节

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

❌ 不好： “构建一个登录页面”

✅ 好： “使用 React 创建一个登录页面，包含邮箱/密码认证和 JWT 处理，使用 Supabase 进行认证。”

明确指令和约束

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

AI 会字面上遵循你的指令——模糊性可能导致不想要的结果或 AI”幻觉”(编造信息)。

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

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

利用这一点：

  • 将最关键的细节或请求放在开头
  • 必要时在结尾重申任何绝对要求
  • 保持提示词聚焦，必要时刷新上下文

了解模型的局限

  • AI 的知识来自训练数据
  • 它无法知道最近的事件或你未提供的专有信息
  • 即使在猜测时它也会试图听起来很自信(导致幻觉)
  • 对于事实性查询，始终提供参考文本或数据

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

优秀的提示词遵循一套简单的原则。记住它们的便捷方法是 CLEAR：

C - 简洁 (Concise)

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

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

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

关键要点：

  • 避免填充词
  • 追求精确和简洁
  • 如果一个细节没有指导意义，它就是干扰

L - 逻辑 (Logical)

以循序渐进或结构良好的方式组织你的提示词。

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

✅ 好：

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

关键要点：

  • 将复杂请求分解为有序步骤或要点
  • 分离关注点
  • 逻辑流程确保模型系统地处理每个部分

E - 明确 (Explicit)

准确说明你想要什么和不想要什么。

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

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

关键要点：

  • 如果某事重要，拼写出来
  • 提供格式或内容的示例
  • 说明期望的输出风格
  • 把 AI 当作初学者：不要假设任何事情对它来说是显而易见的

A - 适应 (Adaptive)

不要满足于第一个答案——提示词可以迭代优化。

示例：

text
1
2
"你给出的解决方案缺少认证步骤。请在代码中包含用户认证。"

关键要点：

  • 如果初始输出偏离目标，调整你的方法
  • 在后续提示中澄清指令或指出错误
  • 通过迭代引导模型获得更好的结果
  • 你甚至可以要求 AI 如何改进提示词本身(元提示)

R - 反思 (Reflective)

在每次 AI 交互后花时间回顾什么有效、什么无效。

关键要点：

  • 注意哪些提示词措辞获得了好结果
  • 注意哪些导致了混乱
  • 在复杂会话后，可以要求 AI 总结最终解决方案或推理
  • 建立持续改进的 AI 沟通循环

提示词的四个级别

有效的提示词是一项随着实践而增长的技能。这里概述了四个级别的提示词掌握：

级别 1：结构化”训练轮”提示

当你刚开始或处理非常复杂的任务时，使用标记结构。

格式：

text
1
2
3
4
5
Context: [AI 的背景或角色设置]
Task: [你想实现的具体目标]
Guidelines: [首选方法或风格]
Constraints: [硬性限制或禁止事项]

示例：

text
1
2
3
4
5
6
7
8
Context: 你是一位世界级的 Lovable AI 编码助手

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

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

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

级别 2：对话式提示

随着你越来越熟练，你可以更自然地写作，类似于向同事解释任务。

关键： 在没有正式标签的情况下保持清晰和完整。

级别 3：元提示 (Meta Prompting)

要求 AI 帮助你改进提示词或计划。

示例：

text
1
2
3
"我试图让你构建一个用户仪表板，但结果不符合我的需求。
你能分析我的提示词并建议如何改进它以获得更好的结果吗？"

用途：

  • 当输出偏离基准时
  • 优化复杂的提示词
  • 学习更好的提示技巧

级别 4：反向元提示 (Reverse Meta Prompting)

在任务完成后使用 AI 来总结或记录发生的事情。

示例：

text
1
2
3
"总结我们刚刚解决的认证问题：根本原因是什么，我们采取了什么步骤来修复它？
以提示词的形式格式化这个总结，如果将来遇到类似问题我可以使用。"

用途：

  • 调试和知识捕获
  • 创建可重用的解决方案模板
  • 学习和记录最佳实践

高级提示词技术

零样本 vs 少样本提示

零样本提示 (Zero-Shot)

在没有示例的情况下要求模型执行任务。

示例：

text
1
2
"将以下句子翻译成西班牙语：'我正在学习编码。'"

特点：

  • 高效
  • 适用于常见或描述清楚的任务
  • 依赖模型的一般训练

少样本提示 (Few-Shot)

在提示词中提供几个示例或演示。

示例：

text
1
2
3
4
5
6
7
8
9
10
11
12
将以下句子格式化为JSON：

示例1：
输入："John is 25 years old"
输出：{"name": "John", "age": 25}

示例2：
输入："Sarah lives in Boston"
输出：{"name": "Sarah", "city": "Boston"}

现在格式化："Mike works as a developer"

特点：

  • 显著提高特定格式的输出质量
  • 通过示例教学
  • 适用于不寻常或特定格式的任务

管理幻觉和确保准确性

AI”幻觉”是模型自信地编造不正确信息的时刻。减少幻觉的策略：

1. 提供基础数据

在 Lovable 中，始终利用项目的知识库：

  • 包含项目需求文档(PRD)
  • 用户流程
  • 技术栈详情
  • UI 设计指南
  • 后端规范

2. 提示中的引用

text
1
2
3
4
5
6
7
8
9
10
"使用下面给出的 API 响应格式，解析用户对象：
{
  "user": {
    "id": 123,
    "name": "John",
    "email": "[email protected]"
  }
}
"

3. 要求逐步推理

text
1
2
3
"在给出最终代码之前解释你的解决方案方法。
如果有任何不确定性，请说明。"

4. 指示诚实

text
1
2
3
"如果你不确定某个事实或正确的代码，不要编造——
相反，解释需要什么或要求澄清。"

5. 迭代验证

text
1
2
"确认上述代码遵循需求，并解释任何可能不符合规范的部分。"

利用模型洞察

聊天模式 vs 默认模式

聊天模式：

  • 头脑风暴
  • 讨论设计决策
  • 调试分析
  • 不会直接修改代码

默认模式：

  • 执行更改
  • 编写代码
  • 创建组件
  • 直接应用到项目

推荐工作流：

text
1
2
3
1. 在聊天模式中讨论和规划
2. 确定方案后切换到默认模式实施

令牌长度和响应

  • 对于大型输出(整个模块)，分解为更小的提示
  • 一次生成一个函数的代码
  • 注意截断警告

格式和代码偏好

text
1
2
3
4
5
"输出代码以 markdown 格式"
"遵循项目的 ESLint 规则"
"使用驼峰命名法"
"每个函数包含 JSDoc 注释"

额外的提示词技巧

从坚实的知识库开始

在编写提示词之前，设置项目的知识库：

  • 项目需求(PRD)
  • 用户流程
  • 技术栈细节
  • UI 设计指南
  • 后端细节

示例提示：

text
1
2
3
"参考项目知识库中的 PRD，特别是'不在范围内'部分，
确保不添加任何社交登录功能。"

具体明确，避免含糊

❌ 含糊： “让页面看起来更好”

✅ 明确： “增加主标题的字体大小到 48px，使用粗体，颜色改为深蓝色(#1a365d)”

增量提示

不要这样做：

text
1
2
3
"构建一个完整的电商应用，包括产品列表、购物车、
结账、用户认证、管理面板和分析仪表板。"

应该这样做：

text
1
2
3
4
5
1. "首先创建产品列表页面"
2. "现在添加购物车功能"
3. "实现结账流程"
... 逐步进行

包含约束和需求

text
1
2
3
4
5
6
7
Constraints:
- 不使用任何付费 API
- 应用应在移动和桌面上工作
- 响应时间应低于 2 秒
- 使用 Tailwind CSS，不使用自定义 CSS
- 不修改现有的认证逻辑

避免措辞歧义

模糊： “添加一个模态框”

  • 哪种模态框？确认？表单？信息？

清晰： “添加一个确认删除模态框，包含’取消’和’确认’按钮”

注意你的语气和礼貌

虽然不会改变功能，但礼貌的语气可以帮助：

text
1
2
3
"请创建一个登录表单，包含邮箱和密码字段。
如果可能的话，添加表单验证。谢谢！"

利用格式优势

使用编号步骤或要点：

text
1
2
3
4
5
6
7
请按照以下步骤操作：
1. 创建一个新的 React 组件
2. 添加状态管理
3. 实现 API 调用
4. 处理错误情况
5. 添加加载状态

使用图像提示

Lovable 允许图像上传：

方法 1 - 简单方式：

text
1
2
3
[上传设计图]
"根据这个设计创建一个着陆页，匹配颜色、布局和排版。"

方法 2 - 详细方式：

text
1
2
3
4
5
6
7
[上传设计图]
"分析这个设计并：
1. 列出主要的视觉元素
2. 确定颜色方案
3. 描述布局结构
4. 然后用 React 和 Tailwind 实现它"

提供精确的编辑指令

使用选择功能：

  1. 在编辑器中选择/高亮组件
  2. 然后提示：”更改此组件的…”

明确指定文件：

text
1
2
3
4
"在 Header 组件中，将注册按钮的文本更改为'开始'
并将其移到导航栏的左侧。
不要修改任何其他组件或逻辑。"

锁定文件(变通方法)

text
1
2
3
4
5
"在进行更改时，不要修改以下文件：
- components/ProfilePage.tsx
- utils/auth.ts
- lib/supabase.ts"

设计和 UI 调整

纯视觉更改：

text
1
2
3
"使登录按钮变蓝(#3b82f6)并放大20%，
但不要改变其任何功能或 onClick 逻辑。"

响应式设计：

text
1
2
3
4
5
6
7
"优化着陆页以适配移动设备：
1. 使用移动优先方法
2. 使用 Tailwind 断点(sm, md, lg)
3. 在小屏幕上堆叠元素
4. 确保触摸目标至少 44x44px
5. 不改变任何功能，只调整布局"

重构和优化代码

强调行为不变：

text
1
2
3
"重构代码以提高清晰度和效率，
但应用程序的功能和输出必须保持相同。"

先要求计划：

text
1
2
3
"扫描 utils/ 文件夹并建议代码结构或重复的改进。
列出更改但先不要应用它们。"

分阶段进行：

text
1
2
3
4
5
6
1. "重构状态管理逻辑"
2. [测试]
3. "重构 API 调用"
4. [测试]
5. "优化渲染性能"

使用 AI 辅助调试

提供完整的错误上下文：

text
1
2
3
4
5
6
7
8
9
10
11
"这是错误信息：
[粘贴错误日志]

这是相关代码：
[粘贴代码片段]

预期行为：用户点击按钮后应该显示模态框
实际行为：没有任何反应，控制台显示上述错误

是什么导致了这个问题，我们如何修复它？"

使用对话式调试：

text
1
2
3
4
5
6
"修复没有起作用。状态在运行时仍然是 undefined。
让我们一起思考可能的原因：
1. 状态是否正确初始化？
2. 是否有时序问题？
3. 是否有依赖缺失？"

何时(以及何时不)涉及 AI

直接手动操作的情况：

  • 更改单个文本标签
  • 调整一个 padding 值
  • 修改颜色
  • 简单的格式调整

使用 AI 的情况：

  • 复杂逻辑
  • 样板代码生成
  • 多步操作
  • 不确定的任务
  • 需要研究的功能

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

在 Lovable 的构建器中

推荐工作流：

text
1
2
3
4
5
6
7
8
9
10
11
12
13
1. 开始：
"创建一个任务管理应用的基础结构"

2. 迭代功能：
"添加创建新任务的功能"
"实现任务完成切换"
"添加任务过滤(全部/活动/已完成)"

3. 改进：
"优化任务列表的性能"
"添加任务拖拽排序"
"实现任务搜索功能"

使用聊天模式：

text
1
2
3
4
5
6
7
8
[在聊天模式中]
"分析当前的应用结构，建议如何重构状态管理"

[AI 给出建议]

[切换到默认模式]
"根据上面讨论的计划，实现新的状态管理结构"

与 Make.com 或 n8n 集成

为自动化生成集成代码：

text
1
2
3
4
5
6
7
"创建一个 webhook 端点来接收来自 Make.com 的表单提交。
- URL 应该是 /api/webhooks/form-submission
- 期望接收 JSON 数据：{ name, email, message }
- 验证数据后，保存到 Supabase 的 'submissions' 表
- 返回成功/失败响应给 Make.com
- 在 Make.com 中使用的 webhook URL 格式应该是什么？"

边缘情况和外部集成

Stripe 集成示例：

text
1
2
3
4
5
6
7
8
"使用 Stripe Checkout API (v3) 为用户设置订阅计费：
- 这是我的 Stripe 可发布密钥：pk_test_...
- 创建三个价格等级：基础($9/月)、专业($29/月)、企业($99/月)
- 在结账后，将订阅状态存储在 Supabase 的 users 表中
- 添加 webhook 处理器来监听 Stripe 事件
- 处理订阅更新和取消
- 提供订阅管理页面供用户查看/更改计划"

GitHub 集成示例：

text
1
2
3
4
5
6
7
8
"实现 GitHub OAuth 登录：
- 使用我的 GitHub OAuth 应用凭据
- 客户端 ID: xxx
- 回调 URL: https://myapp.com/auth/callback
- 登录后，从 GitHub 获取用户的仓库列表
- 将用户数据保存到 Supabase
- 实现登出功能"

总结

关键要点

  1. 强大的提示在于清晰、结构和上下文
    • 无论是构建功能还是集成服务，都要描绘清晰的图景
  2. 从结构化开始，逐步演变
    • 新手：使用”训练轮”格式(Context/Task/Guidelines/Constraints)
    • 熟练后：采用更自然的对话风格
  3. 使用元技术持续改进
    • 元提示：让 AI 帮助改进你的提示
    • 反向元提示：让 AI 总结学到的东西
  4. 实践造就完美
    • 通过实践，AI 会感觉像你开发团队的延伸
    • 你将自然地获得你需要的确切输出

记住 C.L.E.A.R. 框架

  • Concise - 简洁：清晰直达要点
  • Logical - 逻辑：有序组织请求
  • Explicit - 明确：准确说明需求
  • Adaptive - 适应：迭代优化
  • Reflective - 反思：学习和改进

最佳实践速查

DO - 应该做：

  • 提供详细的上下文和约束
  • 使用具体的示例
  • 分解复杂任务为步骤
  • 迭代优化
  • 利用知识库
  • 明确你想要和不想要什么
  • 在聊天模式中先讨论再实施

DON’T - 不要做：

  • 过度依赖 AI 处理琐碎任务
  • 假设 AI 能读懂你的想法
  • 使用模糊或含糊的语言
  • 在一个提示中要求过多
  • 忘记测试 AI 的输出
  • 忽略错误消息和警告

附录：快速参考提示模板

基础任务模板

text
1
2
3
4
5
6
创建 [组件/功能]：
- 使用 [技术栈]
- 包含 [具体功能1, 功能2, ...]
- 遵循 [设计/编码标准]
- 不要 [约束/限制]

调试模板

text
1
2
3
4
5
6
7
8
9
10
11
12
13
14
我遇到了这个问题：
[描述问题]

错误消息：
[粘贴错误]

相关代码：
[粘贴代码]

预期行为：[描述]
实际行为：[描述]

请帮助诊断和修复。

重构模板

text
1
2
3
4
5
6
7
8
重构 [组件/模块]：
目标：[提高性能/可读性/可维护性]
要求：
- 保持功能不变
- [具体改进目标]
- 遵循 [编码标准]
注意：请先列出建议的更改，不要立即应用

UI 调整模板

text
1
2
3
4
5
6
7
8
调整 [组件] 的UI：
视觉更改：
- [颜色/大小/布局具体变化]
约束：
- 不改变任何功能
- 保持响应式
- 遵循 [设计系统]