提示库

提示策略和方法的列表。

欢迎来到提示库！ 这里我们收集了一系列可重用的提示模式和示例，适用于使用 AI 构建常见场景。把这些视为模板或灵感来源，你可以根据自己的项目进行调整。每部分都涵盖特定用例——从启动新项目到集成支付——并提供使用指导和示例提示。

随意复制这些提示，修改细节，并在 Lovable 或任何 AI 构建工具中使用。语气是正式却轻松的，就像和同事闲聊一样，每个提示都提供足够的背景，让 AI 能清楚该怎么做。

启动项目

使用时机：

在项目伊始。这条提示帮助 AI 理解高层级需求并开始构建基础。通过指定你正在构建什么、技术栈和核心功能，来启动一个新应用。它就是你的项目简报。

使用方法：

概述应用类型、关键技术（前端框架、后端、任何服务），以及主要功能或页面。然后，指导 AI 从哪里开始（通常是主页面或重要功能）。这确立了项目范围和初始焦点。

示例提示 – 启动新项目：

我需要一个**任务管理**应用，包含：  
- **技术栈：** Next.js 前端，Tailwind CSS 用于样式，Supabase 用于认证和数据库。  
- **核心功能：** 项目和任务创建、将任务分配给用户、到期日期提醒，以及仪表盘概述。  

从构建**主仪表盘页面**开始，其中包含：  
- 一个带有导航的头部，  
- 项目列表及其状态，  
- 以及一个创建新项目的按钮。  

现在先提供一些虚拟数据，并确保设计干净且响应式。  

创建一个名为 [ComponentName] 的新组件，包含这些功能：[列出功能]。使其响应式且可访问，包括正确的键盘导航。包含适当的 TypeScript 属性类型，并使用 Tailwind 进行样式。  

用简单术语解释这个函数的工作原理，突出其输入、输出和任何副作用：[粘贴函数]。它处理了哪些边缘情况或遗漏了哪些？如何改进它？  

这条提示遵循了新项目的最佳结构。它首先陈述应用类型和技术栈，然后列出核心功能，最后告诉 AI 从哪里开始（主仪表盘页面，并给出具体细节）。通过这样做，你为 Lovable 提供了一个清晰的路线图来启动项目。(专业提示：通常最好从空项目开始逐步构建，这样 AI 不会不堪重负。)

UI/UX 设计

使用时机：

任何时候你想优化应用的视觉效果而不改变其功能。这可能包括打磨 UI、调整布局或实现特定设计风格。

使用方法：

清楚指定设计变更的范围，并强调功能应保持不变。AI 在样式方面很擅长，但你应该指导它想要的“外观”（例如，现代、极简、匹配特定设计系统）。如果有多个变更，一次处理一个（例如，先布局，然后颜色）。始终提到 UI 中哪些部分不能在逻辑上被更改。

Lovable 默认就有不错的品位，但一个针对性的提示可以帮助实现特定美学风格或 UX 提升。例如，你可能想重新设计按钮、改善表单布局，或确保间距一致。

示例提示 – 仅 UI 变更：

应用的 UI 需要改进，**但不要改变任何功能**。  

- 保持所有现有逻辑和状态管理不变。  
- **视觉增强：** 更新仪表盘页面的样式：为每个项目列表使用现代卡片设计，提高颜色方案以获得更好对比度，并增加间距以获得更干净的布局。  
- 确保这些变更**不会破坏任何功能或数据流**。  

*目标：* 纯粹是视觉改进，让外观更精致，同时应用行为完全不变。  

增强这个组件的视觉吸引力：[粘贴组件]。添加动画、改善间距、创建精致外观，同时维护可访问性标准和响应式行为。  

为我的应用创建一个全面的设计系统，包括颜色调色板、字体比例、间距系统和组件变体。包含暗模式支持，并确保所有组件都可访问（符合 WCAG AA 标准）。  

设计一个响应式仪表盘布局，包含[描述关键指标/小部件]。它应在移动、平板和桌面设备上良好工作，并包含适当的布局调整。包括一个在移动设备上折叠的侧边栏导航。  

将这个仅桌面组件转换为移动优先设计，包含响应式断点：[粘贴组件]。优先考虑小屏幕的内容和交互，然后再增强大屏幕。  

为这个组件添加细微、高性能动画以提升用户体验：[粘贴组件]。包括进入/退出动画、悬停状态，以及不具干扰性的微交互以提供反馈。  

分析并优化[描述任务/目标]的用户流程。映射出每个步骤，识别摩擦点，并建议 UI 改进，以创建更直观的体验并减少步骤。  

审查这些组件的可访问性问题并建议改进：[粘贴组件]。检查正确的键盘导航、屏幕阅读器支持、足够的颜色对比度，以及适当的 ARIA 属性。  

在这个提示中，我们明确表示只做视觉增强，而不影响应用工作方式。这很重要——它告诉 AI“不要碰逻辑”。我们列出具体内容（卡片设计、颜色对比、间距），这样 AI 就知道哪些 UI 方面需要调整。这种提示非常适合在构建完功能后美化界面。

响应式设计

使用时机：

当你的应用的布局需要在不同屏幕尺寸（移动、平板、桌面）上正常工作时。如果你注意到桌面看起来不错但在移动设备上崩溃了，是时候使用响应式提示了。这也是在任何 UI 密集任务的最终步骤中明智的选择。

使用方法：

强调移动优先方法，并要求 AI 确保设计在所有标准断点上响应式。如果使用像 Tailwind 这样的 CSS 框架，提到使用其网格/弹性布局和内置断点。你还可以指示 AI 避免任何固定宽度或其他会阻止流畅调整的东西。如果有示例显示在小屏幕上崩溃的内容，提供它；否则，只需说“让一切优雅地适应小屏幕”。

示例提示 – 移动响应式：

我们的应用需要**完全响应式**，适用于移动、平板和桌面。  

- 采用**移动优先**策略：优先处理小屏幕布局，然后调整为大屏幕。  
- 使用现代 UI/UX 最佳实践进行响应式设计。（对于 Tailwind CSS，使用标准断点 `sm, md, lg, xl`——除非必要，不要自定义断点。）  
- 确保每个页面（尤其是仪表盘和项目详情页面）在小屏幕上正确重排：元素应堆叠或调整大小，文本保持可读，且没有内容溢出屏幕。  
- **不要改变核心设计或功能**，只需确保它灵活适应不同屏幕尺寸。  

完成变更后，请在 iPhone 12 尺寸和典型桌面宽度上双重检查布局。  

在这个提示中，我们明确指示 AI 让所有设计在每个断点上响应式，聚焦于移动优先。我们甚至引用了 Tailwind 的标准断点来指导实现。我们澄清设计和功能不应根本改变；它只需在小屏幕上良好工作。这设定了清晰的期望：结果在设计上应相同，但能流畅调整和重排以实现响应式。

 

(使用 Lovable 的图像上传？你可以附加一个崩溃的移动布局截图，并说：“让它在移动设备上看起来像这个。”视觉提示可以强化你的描述。)

重构

使用时机：

在开发过程中定期使用，尤其是当 AI 或你添加了很多代码，导致代码变得杂乱或缓慢时。重构意味着在不改变其功能的情况下清理代码——改善结构、可读性和性能。Lovable 可能会在检测到大量重复模式或长函数时建议重构。

使用方法：

识别范围：是单个文件、特定功能，还是整个代码库？对于单个文件或组件，你可以提示如“重构这个文件以提高清晰度和效率，但不要改变其功能或输出”。强调一切在重构后应保持相同。如果你想指定重点（例如，减少重复、改善变量名称、简化逻辑），可以说明。对于大规模重构，最好让 AI分步规划重构（见下一节规划），或先审计代码结构。

示例提示 – 安全文件重构：

重构**ProjectList 组件**，但**保持其行为和 UI 完全相同**。  

目标：  
- 改善代码结构和可读性（简化复杂函数，如果需要拆分成更小的函数）。  
- 删除任何未使用的变量或导入。  
- 确保文件遵循最佳实践并有良好文档。  

不要引入任何新功能或改变组件的用户工作方式——这纯粹是代码清理，以提高可维护性。如果代码的任何部分不清楚，请添加简短注释进行澄清。  

审查这个代码并建议可读性、性能和可维护性的改进：[粘贴代码]。聚焦于 TypeScript 最佳实践、适当错误处理，以及 React 模式。  

为[类型]应用建议文件夹结构，包含这些功能：[列出功能]。包括组织组件、钩子、实用工具和类型的指南，并确保适当的关注点分离。  

我遇到了这个错误：[粘贴错误]。这是相关代码：[粘贴代码]。你能帮我理解原因并修复它吗？请解释为什么这个解决方案有效。  

这个提示清楚陈述了要重构的组件和约束（不允许功能变更）。它优先考虑结构和可维护性。AI 会遍历文件，可能重新排序函数、重命名以提高清晰度、注释复杂部分等，但应用的输出应保持相同。这有助于避免“重构”意外破坏东西。

对于更大规模的重构努力（比如多个文件或整个项目），考虑让 AI先分析代码库。你可以使用提示获取改进报告和位置（见调试部分的“完整系统审查”提示作为参考）。然后，逐步应用变更。以小块重构并测试，而不是一次性大改动。

应用类型

创建一个入门级电商商店，包含产品列表、搜索、过滤、购物车功能和结账流程。包括用户账户、订单历史和基本产品管理。聚焦于干净、转换导向的 UI。  

构建一个基本 CMS，用于管理博客文章或文章，包括管理仪表盘。包含创建、编辑和发布内容的功能，支持富文本格式、图像上传和基本 SEO 管理。  

创建一个项目管理应用，包含任务板、列表和卡片。包括任务分配、到期日期、标签、评论和进度跟踪功能。实现拖放功能和用户协作。  

构建一个社交媒体 feed 组件，包含帖子、评论、点赞和分享功能。包括用户资料、关注/取消关注机制，以及通知系统。确保设计响应式并支持无限滚动。  

创建一个分析仪表盘，包含多种图表类型（条形、线形、饼状）、数据过滤选项、日期范围选择和可导出报告。包括响应式设计和数据获取时的骨架加载状态。  

构建一个 SaaS 应用入门模板，包含用户认证、订阅管理、设置页面和基本仪表盘。包括基于角色的访问控制、账户管理和适合未来扩展的良好结构。  

创建一个聊天界面，包含一个 AI 助手，帮助用户处理[描述任务/目的]。包括对话历史、输入指示、消息线程，以及提供 AI 响应反馈的能力。  

构建一个工具，使用 AI 根据用户输入和参数生成[描述内容类型]。包括选项来优化生成内容、保存收藏和以不同格式导出。  

为[描述项目]实现一个推荐组件，基于用户行为和偏好。包括提供反馈的能力、查看推荐原因，以及发现新选项。  

增强[描述内容]的搜索体验，使用 AI 功能如自然语言理解、语义搜索和智能结果排名。包括搜索建议和自动完成。  

创建一个仪表盘，使用 AI 分析[描述数据]并以易懂方式呈现洞见。包括可视化、用通俗语言解释趋势，以及查询数据的能力。  

实现一个系统，根据行为和偏好个性化用户体验。包括可自定义 UI 元素、内容推荐，以及允许用户控制个性化的设置。  

React 开发

创建一个自定义 React 钩子，名为 use[Name]，处理[功能]。它应正确处理状态初始化、清理、值备忘化，以及 TypeScript 类型。包括示例使用和错误处理。  

将这个组件重构为使用 React Context 而不是属性传递：[粘贴组件]。创建一个合适的上下文提供者，包含类型化的状态和操作，并将业务逻辑与 UI 渲染分离。  

优化这个 React 组件以防止不必要的重新渲染：[粘贴组件]。在适当地方使用 memo、useMemo 和 useCallback，并添加解释性注释说明每个优化的必要性。  

为[描述表单字段和验证规则]创建一个带有验证的表单。使用 react-hook-form 和 zod 模式验证，包含适当错误处理和提交处理，包括加载状态。  

为[描述数据]实现数据获取模式，使用 React Query。包括适当的加载状态、错误处理、乐观更新和数据同步策略。  

为[描述元素]创建平滑过渡动画，当它[描述动作]时。使用 CSS 过渡或 Framer Motion，确保动画在各设备上良好运行且不影响性能。  

锁定文件/限制范围

使用时机：

有时你希望 AI 只关注项目特定部分，而不触及其他——本质上“锁定”某些文件或区域，以防止修改。如果你手动编写了某些代码或有稳定的组件，不想在 AI 处理其他内容时被更改。由于 Lovable 尚未有字面文件锁定功能，使用提示来限制范围是最佳替代。

使用方法：

在提示中，明确指示 AI 不更改某些文件或组件。例如，“不要编辑认证文件”，或“保持 HomePage 组件不变”。同时，清楚说明 AI 应关注哪里进行更改。此指令应在敏感期内的每个提示中包含，以提醒 AI 边界。

示例提示 – 限制变更范围：

请**只针对仪表盘页面**进行此更改。  

- **不要修改** `LoginPage.tsx` 或 `AuthProvider.tsx` 文件（认证部分工作正常，我们想保持不变）。  
- 只将代码编辑集中在 `Dashboard.tsx` 和相关仪表盘组件上。  

任务：向仪表盘添加一个显示“本周到期任务”的新部分。确保从数据库获取相关任务。  

*(再次强调，不要更改登录或认证文件——这些是禁区。)*  

这里我们直接指定约束：“避免更改页面 X 或 Y，并只针对页面 Z 进行修改”。通过在提示中重复此要求，我们引导 AI 的注意力。任务本身（添加仪表盘部分）被指定，但我们用范围指令包裹。这大大降低了 Lovable 在添加仪表盘功能时意外触及登录系统的风险。

另一个场景是更新敏感功能。在这种情况下，可以结合范围限制和警示语气。例如：“这个更新很敏感；请小心操作，避免触及无关内容”。这会让 AI 以更谨慎的心态处理。

规划

使用时机：

在处理复杂或多步实现前，或当你有大功能需要分解为子任务时。规划提示也适用于让 AI 概述方法，然后你可以在执行代码前验证计划（避免在错误路径上消耗代码生成额度）。本质上，当策略不直观时，使用它来让 AI 帮忙思考。

使用方法：

要求 AI 生成计划或检查列表。你可以说，“概述 X 的分步计划”或“在编码前，列出实现 Y 的步骤”。这可以在聊天模式下进行，以确保 AI 在规划时不执行代码变更。获取计划后，你甚至可以讨论它（让 AI 解释每个步骤的必要性），然后逐步推进实施。规划提示是元操作——它们不直接构建应用，而是为顺利构建铺路。

示例提示 – 规划功能实现：

在编写任何代码前，**规划新通知功能的实现**。  

- 列出添加任务逾期时发送电子邮件通知所需的每个步骤。  
- 考虑前端（如果有 UI 变更）和后端（创建定时检查或触发器）方面。  
- 确保计划保持现有功能稳定——不能破坏任何内容。  
- 以有序列表（1、2、3...）形式提供计划，并简要解释每个步骤。  

概述计划后，请暂停以供审查。**不要进行任何代码变更。**  

这个提示让 AI 充当规划者。它要求为“任务逾期发送电子邮件通知”功能制定顺序计划。我们明确表示不要立即编码（这样我们可以在聊天模式下运行）。AI 可能回应类似：

1. 向任务添加时间戳字段（如果尚未存在）。
2. 创建服务器端函数（或定时任务）来定期检查逾期任务。
3. 集成电子邮件发送，使用电子邮件服务（例如 Resend 或 SMTP）在发现逾期任务时发送。
4. 更新 UI，允许用户为任务启用/禁用通知（可选设置）。
5. 测试流程，使用刚过期的任务确保电子邮件发送。

通过审查此类计划，你可以在编码前发现问题（也许我们意识到需要新数据库表，或步骤 4 超出范围等）。调整计划比重写错误代码容易得多。规划提示在复杂功能中节省时间，通过从一开始就正确制定方法。

Stripe 设置

使用时机：

当你想使用 Stripe 将支付集成到应用中时。Lovable 有 Stripe 集成点，但需要设置密钥、网络钩子和结账 UI。提示可以处理连接 Stripe API 的样板代码。在项目中添加商业功能（如销售产品或订阅）时使用。

使用方法：

提供 Stripe 所需细节：模式（测试或正式）、产品或定价信息，以及支付后重定向 URL。同时，指示 UI 的行为（例如，结账表单/模态）。关键是要提到敏感密钥将安全提供（不在提示中硬编码）——通常将它们存储在环境变量或 Lovable 的秘密存储中。所以你可以说“假设我已在环境中设置了 API 密钥”。这样，AI 会知道调用密钥，而不直接包含它们。此外，指定不要更改无关代码，以避免意外修改。

示例提示 – 集成 Stripe 支付：

我想**添加 Stripe 支付**到应用中。  

- 使用**测试模式**。  
- 我们有 Stripe 中的产品，ID 为 `prod_12345`，价格 ID 为 `price_67890`（一次性购买）。  
- 在**定价页面**上实现一个结账按钮，启动 Stripe 结账流程。  
- 支付成功后，重定向用户到 `/payment-success`。如果支付取消，重定向到 `/payment-cancelled`。  

重要：  
- 假设 API 密钥和网络钩子密钥已安全配置（不要硬编码它们）。  
- 不要修改与支付无关的其他页面或功能。  

完成操作后，提供任何网络钩子端点设置指令（例如，在 Stripe 仪表盘中添加的 URL，用于处理支付后事件）。  

这个提示提供了 Stripe 的关键细节：测试模式、产品 ID、成功/取消重定向，以及按钮位置。它明确表示不要触及其他内容。AI（以及 Lovable 的 Stripe 集成助手）将使用此信息搭建集成。后台，Lovable 可能创建无服务器函数（如果使用 Supabase）来处理网络钩子等，但你不需要单独提示——这里的指令通常足以进行基本设置。

注意： 我们包含了关于 API 密钥安全的说明，因为我们从不希望密钥出现在提示中。文档提醒：“在 Supabase Edge Function 秘密中使用你的 Stripe 密钥，并避免在提示中包含它们”。所以，通过告诉 AI“假设已配置”，确保代码会引用环境变量或配置，而非明文密钥。

运行此提示后，使用 Stripe 的测试卡号测试支付流程。如果有问题（例如，网络钩子不工作），Lovable 可能会显示错误，你可以用另一个提示调试或完善。

Supabase & 后端

增强这个组件的视觉吸引力：[粘贴组件]。添加动画、改善间距、创建精致外观，同时维护可访问性标准和响应式行为。  

为[描述你的应用]设计数据库模式，包含这些实体关系：[描述关系]。包括外键约束、性能索引，以及适当的数据类型，并考虑可扩展性。  

创建一个服务，从[API 名称]获取数据，并实现缓存、错误重试逻辑和请求节流。设置适当的 TypeScript 接口用于响应数据，并优雅处理 API 版本。  

为多租户应用创建行级安全策略，针对这些表格：[列出表格]。实现用户隔离、基于角色的访问，以及处理分层数据访问，并考虑性能。  

创建一个 Supabase Edge Function 来处理[描述功能]，包含适当错误处理、输入验证和安全检查。包括速率限制和正确使用环境变量。  

使用 Supabase 订阅实现[描述功能]的实时数据同步。处理连接管理、离线时的优雅降级，以及冲突解决。  

为[描述内容类型]实现一个稳健的搜索功能，包含过滤、排序和匹配术语高亮。包括类型ahead 建议、最近搜索，以及处理无结果场景。  

为[描述数据]创建一个数据表格/网格，包含排序、过滤、分页、列调整和行选择。包括导出数据和自定义可见列的功能。  

构建一个系统，用于导入和导出[描述数据]，支持各种格式（CSV、JSON 等）。包括验证、进度指示、错误处理，以及导入时的字段映射。  

使用 Recharts 为[描述数据/指标]创建一组交互式图表。包括不同可视化类型（条形、线形、饼状）、时间段选择、钻取功能和响应式行为。  

实现一个策略，用于在连接恢复时同步离线数据变更与后端。处理冲突解决、乐观 UI 更新，并提供同步状态视觉指示。  

创建一个多步表单向导，用于收集[描述数据]，包含验证、进度跟踪、保存草稿，以及提交前的总结审查。处理基于先前答案的条件字段。  

工作流

将这个 Lovable 项目连接到 GitHub，并设置良好的贡献工作流。包括分支保护规则、PR 模板，以及 CI/CD 工作流配置，支持自动预览部署。  

将这个大型组件重构为更小、更易管理的组件：[粘贴组件]。提取可重用部分，实现适当属性传递、维护状态管理，并确保重构不破坏现有功能。  

为[组件/功能]建议测试策略，包括测试内容和方法。包含业务逻辑的单元测试、数据流的集成测试，以及关键用户流程的 UI 测试，并遵循最佳实践模拟依赖。  

为这个异步函数实现全面错误处理：[粘贴函数]。包括重试逻辑、后备机制、适当错误报告、用户友好错误消息，以及调试日志。  

为这个应用设置部署管道，包括 Staging 和生产环境、自动数据库迁移、环境特定配置，以及回滚能力。  

分析并优化这个用户流程：[描述流程]。建议改进用户体验、减少摩擦点、实现渐进式增强，并确保整个流程的可访问性。  

使用聊天模式 vs 默认模式

使用时机：

Lovable 有两种提示模式：默认模式（立即将更改应用到项目）和仅聊天模式（更像是对话，不会更改代码，除非你指定）。知道何时使用每种模式可以简化你的工作流程。对于直接编码任务，使用默认模式；对于 brainstorm、调试或讨论更改前，使用聊天模式。

使用方法：

• 默认模式 适合有明确功能要构建或更改时。你给出指令，Lovable 会一次性完成。
• 聊天模式 则用于你想来回讨论或分析内容（例如，“为什么这个不工作？”或“做 X 的最佳方式是什么？”），而不立即修改代码库。在聊天模式下，AI 会以分析或计划形式回应，你通常需要明确说“去实现”时才执行。

示例用例 – 默认 vs 聊天：
假设你怀疑项目中有过时代码需要清理。在默认模式下，你可能直接提示：

 

审查应用并告诉我哪里有过时代码。

Lovable 可能试图识别并可能开始重构。但如果你想小心，只获取建议，则切换到聊天模式，并问类似：

 

我看到一些已弃用库警告。代码哪些部分可能过时，以及如何更新？

现在 AI 会_讨论_这个问题，而不是立即重写文件。

同样，如果你有错误想让 AI 分析，聊天模式更安全。你可以复制错误消息并问：

 

这个错误是什么意思，以及如何修复？

AI 会解释并提出解决方案。一旦同意，你可能切换到默认模式或明确指示应用修复。

总之，使用默认模式进行直接构建（“为我做 X”），使用聊天模式进行故障排除或设计讨论（“为什么或如何做 X？”）。一个具体工作流是：在聊天中 brainstorm（获取计划或识别问题），然后在默认模式下执行。这种方法被推荐：例如，使用聊天模式让 AI 在进行更改前分析错误。这就像使用 ChatGPT 寻求建议，然后应用更改，一旦你有信心。

(如果在设置中看不到聊天模式，请在 Labs 下启用。这确保 AI 不会写入项目代码，除非你指定，适合安全实验。)

编写知识库和 PRD

使用时机：

在项目开始时，以及当你有更多上下文需要提供时，而这些内容无法放入单个提示。在 Lovable 中，知识库是项目设置中的特殊位置，用于存储背景信息、需求和指南，这些会持续存在于各提示中。项目需求文档 (PRD) 是应用目标和规范的全面摘要——本质上是构建蓝图。使用这些工具来防止误解，并让 AI 与项目大局保持一致。

使用方法：

首先，在 Lovable 中填充知识库，包含项目关键信息。这可以包括：

• 概述与目标： 项目是什么，以及它解决的问题。
• 用户流程： 用户导航或使用应用的描述（例如，“用户注册，然后看到仪表盘，可以创建任务等”）。
• 核心功能与范围： 哪些功能在范围之内（并注明任何超出范围，以避免功能蔓延）。
• 技术栈： 将使用的技术和服务。
• 设计指南： 任何特定 UI/UX 指令——品牌、颜色方案、布局、可访问性要求。
• 后端细节： 概述数据模型、关键数据库表、如 Stripe 或 Supabase 的集成等。

这听起来很多，但写下来是值得的。AI 会使用这些信息在每个提示中保持与项目需求的一致。这就像为 AI 提供长期记忆关于你的应用。你通常只需设置一次（并根据需要更新）。

填充知识库后，你可以告诉 AI 使用它。例如，你的第一个提示可能是：“在编写任何代码前，请查看知识库并确认你理解项目。” 这让 AI 总结或确认上下文，你可以检查是否遗漏。

示例提示 – 使用知识库：

用户：在你编写任何代码前，请查看知识库并分享你对我的项目的理解。  
AI（可能回应）： “好的。根据知识库：你正在构建一个团队任务管理应用。应用流程是用户注册 -> 看到仪表盘 -> 创建项目和任务。技术栈是 Next.js 前端、Supabase 后端（认证和数据库）。核心功能包括项目创建、任务分配和报告仪表盘。在范围内的功能：任务 CRUD、用户角色、电子邮件通知；超出范围：实时协作。设计应遵循干净的企业风格，使用 Tailwind CSS，并确保响应式。后端使用 Supabase，并为多租户数据实现行级安全...”（依此类推）。  

这种 AI 总结确认它正确摄取了你的规范。如果你有误解，可以在聊天模式下更正。一旦确认，你继续构建（AI 现在“知道”整体计划）。

编写 PRD 和填充知识库可能需要额外前期工作，但它在整个开发过程中带来回报。它减少错误和 AI 幻觉，因为 AI 总有参考来了解应用该做什么。特别适合大型项目，无法在一两个提示中完成。将它视为为 AI 播种相同的理解，就像你脑海中的一样。

最后，随着项目演进，维护知识库。如果你添加主要功能或更改范围，更新 PRD/知识库文档。这样，未来提示会考虑新信息。比每次都重新解释上下文容易得多。本质上，知识库 + PRD 是你的 AI 项目手册——它让大家（你和 AI）对构建什么和如何构建保持一致。