用这些提示词模式，让 Coderblock 生成更好的应用

好的 Coderblock 提示词不需要写得像技术规格文档。你不必讨论框架、数据库、API 或架构，只需描述你想构建什么，让 AI 智能体将想法转化为真正的全栈应用，并使用 React、TypeScript、Tailwind CSS、身份验证，以及在必要时使用 Postgres 数据库。

但这并不意味着所有提示词的效果都一样。

你提供的上下文越清晰，智能体就越容易替你做出有用的决策。好的提示词并非描述每一个实现细节，而是明确说明：你要构建什么、为谁构建、它应该如何运行，以及必须遵守哪些规则。

接下来，你就可以让 Coderblock 完成其余工作。以下是一些能够改善生成结果、提高迭代效率的提示词模式。

从产品、用户和目标结果出发

“创建一个仪表盘”或“制作一个预约应用”这样的提示词足以让你开始，但也会留下许多未解答的问题。 谁会使用这款应用？用户需要完成哪些操作？你最希望实现的结果是什么？

要为智能体提供合适的上下文，可以从三个要素入手：

• **产品：**你正在构建哪种应用？
• **用户：**谁会使用它？
• **结果：**用户需要能够完成什么？

例如：

创建一个面向独立私人教练的预约平台。教练可以发布可预约的训练时段，客户可以浏览时间安排、创建账户并预约时段。提供一个仪表盘，让教练管理之后的预约。

有了这些信息，智能体便获得了具体的产品模型。你不需要指定路由或数据结构，它也能推断出主要页面、用户角色、数据库实体和导航方式。

如果你从 Coderblock 的某个模板开始，也可以用同样的方法说明想要修改或添加的内容。模板只是起点，你的想法将在其现有结构上实现。

描述完整流程，而不是孤立的功能

功能列表只能说明应用需要包含什么，而流程则能解释各项功能如何协同运作。 与其写“添加身份验证、个人资料、预约和电子邮件”，不如描述用户使用产品时会发生什么。

可以这样写：

新访客无需登录即可浏览教练资料。当访客选择某个训练时段时，要求其注册或登录并确认预约，随后在“我的预约”中显示该记录。教练只能查看与自己训练时段相关的预约。

现在，智能体已经了解用户路径：哪些内容公开、何时需要登录、预约后会发生什么，以及每种角色可以查看哪些数据。

智能体可以根据你描述的行为配置 Supabase Auth、受保护路由、会话、数据表和 Row Level Security。 因此，你不需要要求它实现自定义 JWT 逻辑、密码哈希或单独的密码表。更有效的做法是说明谁可以访问什么，再让 Coderblock 选择合适的实现方式。

区分必要条件与个人偏好

并非所有决策都同等重要。 好的提示词会清楚区分应用必须实现的内容，以及可以交由智能体灵活处理的部分。

例如：

必要需求：客户登录、教练资料、可预约时间、预约功能，以及面向客户和教练的独立视图。视觉偏好：轻松的编辑风格、温暖的中性色、宽松的留白和尽可能少的动画。卡片的具体布局可以由 UX 智能体决定。

这样既能确保核心功能不被更改，又能让 Agent Team 中的智能体自由决定设计和 UX 细节。

明确约束条件同样很有帮助。例如：

• 移动端优先或桌面端优先
• 页面公开访问，还是仅在身份验证后访问
• 必需的用户角色
• 货币与计费周期
• 每位用户都必须保持私密的数据
• 仅限管理员执行的操作

规则很简单：说明应用应该如何运行，但不一定要指定如何实现。

通过关系描述数据

构建应用时，你不一定要从数据表和迁移的角度思考。

描述现实世界中存在的关系通常更加自然。

Coderblock 会为标准 Web 应用分配专用的 Supabase 项目，其中包含 Postgres 和 Row Level Security。因此，你可以直接说明数据应如何组织，而不必手动编写数据库结构。

例如：

每位教练可以创建多种训练类型。每种训练类型包含时长、价格和说明。可预约时段属于某位教练，并且最多只能有一条已确认预约。客户只能查看自己的预约，教练只能查看与自己时段相关的预约。

与简单地说“添加预约表”相比，这段描述为智能体提供了更多信息：存在哪些实体、它们如何关联、必须遵守哪些约束，以及谁可以访问这些数据。

随着产品演进，你仍然可以从行为角度描述变更：

为预约添加取消原因和取消日期与时间。客户最晚可以在训练开始前 24 小时取消预约，但只有教练可以将预约标记为已完成。

这样，智能体就能更新现有结构，而无需从头重建应用。

每次只做一项修改，并确保结果可观察

Coderblock 实时预览最实用的功能之一，就是让你快速看到每项修改带来的效果。 因此，在完成第一次生成后，最好继续提出针对性明确的后续请求，而不是每次都重写完整需求说明。

例如：

在桌面端固定导航栏，但在移动端保持页眉紧凑。

在教练仪表盘中，将今天的训练安排显示在每周日历之前。

为“我的预约”添加空状态，并提供一个返回教练搜索页面的按钮。

每项请求都会产生可以立即在预览中验证的具体结果。 这样，你就能更轻松地判断哪些修改有效、哪些地方需要纠正，以及下一步应该做什么。

对于范围更大的变更，也可以要求智能体分阶段完成：

首先添加教练角色和仅限教练访问的受保护路由。然后创建可预约时间编辑器。最后，将可预约时段连接到客户预约流程。

这样，即使是复杂功能，也会变成一系列容易验证的步骤。

不要忽略各种状态和边界情况

应用不会只运行在理想路径中。 尚无预约的用户会看到什么？付款失败时会发生什么？如果某个时段已不可用怎么办？用户尝试访问受限区域时又会看到什么？

你可以直接在提示词中描述这些场景：

• “当用户没有预约时，显示实用的空状态。”
• “禁用不可预约的时段，并说明无法选择的原因。”
• “提交预约期间显示加载指示器。”
• “如果非管理员用户打开管理路由，将其安全地重定向。”
• “提供具体的验证错误信息，并将其显示在相关字段旁边。”

这些细节看似微小，却决定了应用是一个勉强可用的原型，还是一个真正像是已经准备好投入使用的产品。 你还可以要求负责 UX 或安全的专用智能体分析现有流程，并提出或直接实施改进建议。

添加支付功能时，描述商业规则

集成支付功能时，你不需要解释 Stripe 的工作原理，而要说明你在销售什么，以及付款后会发生什么。 至少应提供以下信息：

• 产品或服务
• 价格
• 货币
• 计费模式
• 购买后可使用的功能

例如：

允许客户以每月 €9.99 的价格订阅。订阅用户可以预约高级训练、在账户中管理订阅，并查看当前计费状态。首先使用 Stripe 测试模式。

在默认的托管模式下，智能体会先询问国家和企业名称等基本信息，然后创建托管的 Stripe 账户。它可以继续配置产品、价格、结账流程和 webhook；之后，你可以通过 Stripe 托管的入驻链接完成收款设置。

如果更希望使用自己的 Stripe 账户，可以要求启用 BYOK 模式。智能体会通过安全的环境变量提示框请求 STRIPE_SECRET_KEY，并自动配置 webhook。

密钥始终保留在服务器端，不会被写入聊天记录或生成的代码中。

最后使用审核提示词

发布之前，可以要求智能体对整个使用体验进行最后一次检查。 例如：

分别以首次使用的客户、教练和管理员身份检查应用。检查导航、移动端易用性、权限、空状态和完整预约流程。在不改变视觉方向的前提下修复明显问题。

这类提示词之所以有效，是因为它明确规定了需要模拟哪些角色、检查哪些内容，以及必须遵守哪些限制。 检查预览结果后，你可以使用发布功能，将应用部署到对应的 coderblock.app 地址；也可以前往设置 → 域名连接自定义域名。

最好的提示词会为 AI 留出发挥空间

要通过 Coderblock 获得理想结果，并不需要编写特别冗长的提示词。 你只需向智能体提供真正重要的信息：谁会使用产品、用户需要完成什么、流程应该如何运行、哪些数据必须关联、哪些规则不能违反，以及不同场景下应该发生什么。

其余部分可以通过迭代逐步完成。 先给出清晰的需求说明，查看生成结果，测试应用，然后继续提出范围小、内容具体且可以验证的请求。

这正是与 AI 编程智能体协作的真正优势：你不需要提前知道如何构建产品，只需要知道自己想构建什么。