AI 提示词库完整指南：从零到一构建 AI 应用的实战模板
为什么值得读这篇文章?
- 本文适合:前端开发者、全栈工程师、AI 应用构建者、技术团队负责人
- 如果你在问:“如何让 AI 编程助手更准确地理解我的需求?”、“怎样写出高质量的 AI 提示词?”、“如何避免 AI 修改不该改的代码?”
- 你将学到:一套经过验证的提示词模板库,涵盖从项目启动到生产部署的全流程场景
背景与问题
随着 AI 编程助手(如 Lovable、Cursor、GitHub Copilot)的普及,开发者面临一个新挑战:如何与 AI 有效沟通? 很多时候,我们给出的指令模糊不清,导致 AI 生成的代码偏离预期,甚至破坏现有功能。
比如:
- 你想优化 UI,AI 却重构了整个业务逻辑
- 你只想修改一个组件,AI 却改动了十几个文件
- 你需要规划一个复杂功能,AI 直接开始写代码而没有先设计架构
本文提供的**提示词库(Prompt Library)**正是为解决这些问题而生。它包含一系列可复用的提示词模板和示例,每个模板都针对特定场景精心设计,确保 AI 能够准确理解你的意图。
核心理念:好的提示词应该包含什么?
一个高质量的 AI 提示词通常包含以下要素:
1. 明确的上下文
告诉 AI 当前项目的技术栈、架构和关键信息
2. 清晰的目标
说明你要实现什么功能或解决什么问题
3. 具体的约束
明确什么能改、什么不能改,避免意外修改
4. 预期的输出
描述你期望的结果格式或行为
5. 循序渐进的步骤
对于复杂任务,分解为多个小步骤
提示词模板库:按场景分类
一、项目启动类
1.1 创建新项目
我需要一个 **任务管理** 应用,包含以下要求:
- **技术栈**: Next.js 前端,Tailwind CSS 样式,Supabase 提供认证和数据库
- **核心功能**: 项目和任务创建、任务分配给用户、截止日期提醒、仪表板概览
首先构建 **主仪表板页面**,包含:
- 带导航的页头
- 显示状态的项目列表
- 创建新项目的按钮
暂时使用模拟数据,确保设计简洁且响应式。
使用场景: 从零开始创建新应用时使用
为什么有效:
- 明确了技术栈,AI 不会猜测或使用错误的框架
- 列出核心功能给出了项目全貌
- 指定从哪里开始(仪表板),避免 AI 不知所措
- “暂时使用模拟数据”避免过早处理后端集成
1.2 创建单个组件
创建一个名为 [ComponentName] 的新组件,具备以下功能: [列出功能列表]。
要求:
- 响应式设计
- 可访问性支持(包括适当的键盘导航)
- 使用 TypeScript 定义 props 类型
- 使用 Tailwind CSS 进行样式设计
使用场景: 需要创建独立组件时
二、UI/UX 设计类
2.1 纯视觉优化(不改变功能)
改进应用的 UI,**不改变任何功能**。
- 保持所有现有逻辑和状态管理不变
- **视觉增强**: 更新仪表板页面的样式:
- 为每个项目列表项使用现代卡片设计
- 改进色彩方案以提高对比度
- 增加内边距以获得更清晰的布局
- 确保这些更改 **不会破坏任何功能或数据流**
**目标**: 纯粹的外观改进,应用行为与之前完全相同。
关键点:
- 多次强调”不改变功能”
- 具体说明要改什么(卡片设计、色彩、间距)
- 这防止了 AI 在美化 UI 时意外重构业务逻辑
2.2 响应式设计
我们的应用需要在移动端、平板和桌面端 **完全响应式**。
- 遵循 **移动优先** 策略:优先考虑小屏幕布局,然后适配大屏幕
- 使用现代 UI/UX 最佳实践进行响应式设计
- 对于 Tailwind CSS,使用标准断点 `sm, md, lg, xl`(除非必要,不使用自定义断点)
- 确保每个页面(尤其是仪表板和项目详情页)在小屏幕上正确重排:
- 元素应堆叠或调整大小
- 文本保持可读
- 内容不溢出屏幕
- **不改变核心设计或功能**,只确保能灵活适应不同屏幕尺寸
完成后,请在 iPhone 12 尺寸和典型桌面宽度下检查布局。
专业技巧: 明确提到 Tailwind 断点和”移动优先”策略,给 AI 具体的技术指导
2.3 设计系统创建
为我的应用创建一个全面的设计系统,包括:
- 色彩调色板
- 排版比例
- 间距系统
- 组件变体
要求:
- 支持深色模式
- 确保所有组件可访问(符合 WCAG AA 标准)
三、代码重构类
3.1 安全的文件重构
重构 **ProjectList 组件文件**,但 **保持其行为和 UI 完全相同**。
目标:
- 改进代码结构和可读性(简化复杂函数,必要时拆分为更小的函数)
- 删除任何未使用的变量或导入
- 确保文件遵循最佳实践且有良好的文档
- **不要** 引入任何新功能或改变组件对用户的工作方式 - 这纯粹是为了可维护性的代码清理
如果代码的任何部分不清楚,添加简短注释进行说明。
为什么重要:
- 明确了”只改结构,不改行为”的边界
- 避免了”重构”变成”重写”的常见陷阱
- 对于大型重构,建议先让 AI 分析代码库,生成改进报告,再逐步应用更改
3.2 代码审查与改进
审查这段代码并提出改进建议: [粘贴代码]
重点关注:
- 可读性、性能和可维护性
- TypeScript 最佳实践
- 适当的错误处理
- 遵循 React 模式
四、限制范围类(防止意外修改)
4.1 锁定文件
请 **只关注仪表板页面** 的更改。
- **不要修改** `LoginPage.tsx` 或 `AuthProvider.tsx` 文件(身份验证运行良好,我们希望保持完整)
- 将代码编辑集中在 `Dashboard.tsx` 和相关仪表板组件 **上**
任务: 向仪表板添加一个新部分,显示"本周到期的任务"。确保从数据库获取相关任务。
_(再次强调,不更改登录或认证文件 - 它们是禁区。)_
关键策略:
- 明确列出”不能碰”的文件
- 重复强调约束,确保 AI 理解
- 这在处理关键功能(如认证系统)时特别有用
4.2 谨慎模式
这次更新非常 **精细敏感**...
- 避免走捷径或做假设
- 如果不确定,花时间寻求澄清
- **精确性至关重要**
使用场景: 处理复杂或关键业务逻辑时,用这种语气让 AI 更加谨慎
五、规划类(先设计,后实现)
5.1 功能实现规划
在编写任何代码之前,**规划** 新通知功能的实现。
- 列出添加任务逾期电子邮件通知所需的每个步骤
- 考虑前端(UI 更改,如果有)和后端(创建定时检查或触发器)方面
- 确保计划保持当前功能稳定 - 我们不能破坏任何现有功能
- 将计划作为有序列表(1、2、3...)提供,每个步骤都有简要说明
概述计划后,暂停以供审查。**暂时不要进行任何代码更改。**
AI 可能的响应:
- 为任务添加截止日期时间戳字段(如果尚不存在)
- 创建服务器端函数(或定时任务)定期检查逾期任务
- 集成电子邮件服务(如 Resend 或 SMTP)在发现逾期任务时发送邮件
- 更新 UI 允许用户切换任务的通知开关(可选设置)
- 使用刚过期的任务测试流程,确保发送邮件
为什么先规划:
- 可以在编码前发现问题(比如发现需要新数据表)
- 更容易调整计划而不是重写代码
- 对复杂功能特别有效
六、支付集成类(以 Stripe 为例)
6.1 集成 Stripe 支付
我想为应用 **添加 Stripe 支付**。
- 暂时使用 **Stripe 测试模式**
- 我们在 Stripe 中有一个产品,ID 为 `prod_12345`,价格 ID 为 `price_67890`(一次性购买)
- 在 **定价页面** 实现一个结账按钮,为该产品启动 Stripe 结账
- 支付成功后,将用户重定向到 `/payment-success`。如果取消支付,重定向到 `/payment-cancelled`
重要提示:
- 假设 API 密钥和 webhook 密钥已安全配置(**不要** 硬编码它们)
- **不要** 修改任何与支付无关的其他页面或功能
完成后,提供我需要的任何 webhook 端点设置说明(例如,在 Stripe 控制台中添加的 URL 以处理支付后事件)。
安全要点:
- 明确说”假设密钥已配置”,避免 AI 在代码中暴露密钥
- 使用环境变量或配置文件引用密钥
- 提供所有必需细节(产品 ID、重定向路由等)
七、后端与数据库类
7.1 数据库模式设计
为 [描述你的应用] 设计数据库模式,包含以下实体关系: [描述关系]。
要求:
- 包含外键约束
- 为性能添加索引
- 使用适当的数据类型
- 考虑可扩展性
7.2 多租户 RLS 策略(Supabase)
为多租户应用创建行级安全策略,涉及以下表: [列出表]。
实现:
- 适当的用户隔离
- 基于角色的访问控制
- 处理分层数据访问
- 考虑性能优化
7.3 Supabase Edge Function
创建一个 Supabase Edge Function 来处理 [描述功能],包括:
- 适当的错误处理
- 输入验证
- 安全检查
- 速率限制
- 正确使用环境变量
八、React 开发类
8.1 自定义 Hook
创建一个名为 use[Name] 的自定义 React Hook,处理 [功能]。
要求:
- 正确的状态初始化
- 清理逻辑
- 值的记忆化
- TypeScript 类型定义
- 包含使用示例和错误处理
8.2 性能优化
优化这个 React 组件以防止不必要的重新渲染: [粘贴组件]
使用:
- memo
- useMemo
- useCallback
在适当的地方添加注释,说明为什么需要每个优化。
8.3 表单处理
创建一个带验证的表单,字段和规则如下: [描述]。
使用:
- react-hook-form
- zod 模式验证
- 适当的错误处理
- 提交处理(包括加载状态)
九、测试与部署类
9.1 测试策略
为 [组件/功能] 建议测试策略,包括测试什么和如何测试。
包括:
- 业务逻辑的单元测试
- 数据流的集成测试
- 关键用户流程的 UI 测试
- 模拟依赖项的最佳实践
9.2 部署管道
为此应用设置部署管道,包括:
- 预发布和生产环境
- 自动数据库迁移
- 特定环境配置
- 回滚能力
十、调试类
10.1 错误诊断
我遇到了这个错误: [粘贴错误]
相关代码: [粘贴代码]
请帮助我理解:
1. 导致错误的原因
2. 如何修复
3. 为什么这个解决方案有效
高级技巧:聊天模式 vs 默认模式
大多数 AI 编程助手提供两种工作模式:
默认模式(Default Mode)
- 适用场景: 有明确定义的功能要构建或更改
- 行为: 给出指令后,AI 会立即执行
- 示例: “在仪表板添加一个新的统计卡片”
聊天模式(Chat Mode)
- 适用场景: 想要讨论、分析或规划,而不立即修改代码
- 行为: AI 会回应分析或计划,不会自动修改文件
- 示例: “这段代码有什么潜在问题?”
推荐工作流:
- 在 聊天模式 中头脑风暴(获取计划或识别问题)
- 在 默认模式 中执行(应用更改)
实战示例:
假设你怀疑项目中有过时代码需要清理:
❌ 不好的方式(在默认模式中):
"查找并清理项目中所有过时的代码"
AI 可能会立即开始重构,可能破坏东西
✅ 好的方式(在聊天模式中):
"分析项目,识别哪些代码可能过时或需要清理,给我一个报告"
AI 会给出分析报告,你可以审查后再决定如何处理
构建知识库与 PRD(产品需求文档)
对于大型项目,强烈建议创建一个 知识库(Knowledge Base) 或 PRD,包含:
1. 概述与目标
项目是什么以及解决什么问题
2. 用户流程
用户如何导航或使用应用(例如:“用户注册 → 看到仪表板 → 可以创建任务等”)
3. 核心功能与范围
哪些功能在范围内(注明哪些超出范围以避免功能蔓延)
4. 技术栈
将使用哪些技术、API 和服务
5. 设计指南
任何特定的 UI/UX 指令 - 品牌、配色方案、布局、可访问性要求
6. 后端细节
概述数据模型、关键数据库表、Stripe 或 Supabase 等集成
使用示例:
项目开始时的第一个提示:
在编写任何代码之前,请审查知识库并分享你对我的项目的理解。
AI 可能的响应: “当然。根据知识库:你正在构建一个团队任务管理应用。应用流程是 用户注册 → 看到仪表板 → 创建项目和任务。技术栈是 Next.js 前端,Supabase 后端(身份验证和数据库)。核心功能包括项目创建、任务分配和报告仪表板。范围内功能:任务 CRUD、用户角色、电子邮件通知;超出范围:实时协作。设计应遵循干净的企业风格,使用 Tailwind CSS,需要响应式。后端使用 Supabase,带有行级安全性以实现多租户数据分离…”
为什么重要:
- 减少错误和 AI 幻觉
- 给 AI “长期记忆”
- 对大型项目特别有效
- 维护知识库可确保未来的提示考虑新信息
最佳实践总结
1. 结构化你的提示
- 上下文 → 目标 → 约束 → 预期输出
2. 越具体越好
- ❌ “改进 UI”
- ✅ “增加卡片间距至 16px,使用主题的蓝色作为按钮背景”
3. 使用约束保护代码
- 明确说明哪些文件或功能不能修改
- 重复重要的约束以确保 AI 理解
4. 复杂任务先规划
- 让 AI 先输出计划
- 审查计划后再开始实现
- 避免”边写边想”导致的返工
5. 利用知识库
- 为大型项目创建 PRD
- 让 AI 在每个会话开始时回顾知识库
- 保持知识库更新
6. 选择正确的模式
- 讨论和分析 → 聊天模式
- 执行和构建 → 默认模式
7. 增量式开发
- 不要试图一次性构建整个应用
- 先构建核心功能,逐步添加
- 每个步骤都测试验证
8. 明确安全要求
- 永远不要在提示中包含密钥
- 指示 AI 使用环境变量
- 对敏感操作使用”谨慎模式”
实战案例:构建任务管理应用
让我们看一个完整的流程示例:
第 1 步:创建知识库(聊天模式)
我想构建一个任务管理应用。请帮我创建一个知识库模板。
应用概述:
- 团队协作的任务管理工具
- 支持多项目管理
- 包含任务分配、截止日期、优先级
- 需要用户认证和权限管理
技术栈: Next.js 14, TypeScript, Tailwind CSS, Supabase
第 2 步:规划数据模型(聊天模式)
基于知识库,设计数据库模式。列出所有表及其关系,但暂时不创建。
第 3 步:开始构建(默认模式)
根据我们讨论的计划,开始构建:
1. 创建 Supabase 表定义
2. 设置认证流程(登录/注册页面)
3. 创建主仪表板布局(暂时不包含数据)
只做这三件事,不要添加额外功能。
第 4 步:逐步添加功能(默认模式)
为仪表板添加项目列表功能:
- 从 Supabase 获取当前用户的项目
- 显示为响应式卡片网格
- 每个卡片显示项目名称、任务数量、进度
- 添加"新建项目"按钮(暂时只是 UI,还不实现功能)
第 5 步:美化 UI(默认模式)
优化项目卡片的视觉设计,不改变任何功能:
- 添加柔和的阴影效果
- 使用渐变色作为卡片头部
- 增加悬停动画效果
- 改进间距和排版
确保保持响应式和可访问性。
第 6 步:调试(聊天模式)
项目列表有时显示为空,即使数据库中有数据。帮我诊断可能的原因。
相关代码: [粘贴组件代码]
这个流程展示了如何结合不同模式和提示类型,系统性地构建应用。
常见陷阱与避免方法
陷阱 1: 提示过于模糊
❌ “让应用看起来更好”
✅ “使用柔和的色彩方案,增加卡片间距至 24px,为按钮添加圆角(8px)“
陷阱 2: 没有设置边界
❌ “添加用户个人资料功能”
✅ “在设置页面添加用户个人资料编辑功能。只修改 SettingsPage.tsx 和相关组件,不要触碰认证逻辑”
陷阱 3: 一次性请求太多
❌ “构建完整的电商平台,包括商品管理、购物车、支付、订单管理、用户评论、推荐系统”
✅ 分解为多个步骤,每次只构建一个核心功能
陷阱 4: 在默认模式下探索
❌ 在默认模式:“这段代码有什么问题?” (AI 可能直接修改代码)
✅ 在聊天模式:“分析这段代码并告诉我潜在问题”
陷阱 5: 忽略安全性
❌ “使用 Stripe 密钥 sk_live_xxxx 集成支付”
✅ “集成 Stripe 支付,假设 API 密钥已在环境变量中配置”
延伸阅读与资源
- Prompt Library: 英文原版文档
- Prompt Engineering Guide: promptingguide.ai
- OpenAI Best Practices: OpenAI 官方文档
- Supabase 文档: supabase.com/docs
- Next.js 最佳实践: nextjs.org/docs
总结
AI 编程助手是强大的工具,但需要正确的沟通方式才能发挥其最大价值。这个提示词库提供了一套经过验证的模板,涵盖从项目启动到生产部署的各个场景。
关键要点:
- 📋 为大型项目创建知识库/PRD
- 🎯 使用具体、结构化的提示
- 🔒 通过约束保护关键代码
- 🗺️ 复杂功能先规划再实现
- 💬 选择正确的工作模式(聊天 vs 默认)
- 🔄 采用增量式开发方法
- 🔐 始终考虑安全性
记住:AI 不会读心术。你投入到提示词中的精力,直接决定了输出的质量。花时间编写清晰、详细的提示,将大大提高开发效率,减少返工时间。
现在,选择一个适合你当前任务的模板,开始构建吧! 🚀
参考资源: