如何为 AI 应用构建工具撰写提示词（附前后对比示例）

给 AI 应用构建工具的好提示词描述的是产品，而不是代码：谁在使用它、他们一步步做什么、它保存什么数据，以及谁被允许查看什么。在第一版出现之后，每条消息只要求一项具体修改，说明哪些内容必须保持不变，并以“我做了 X，期望得到 Y，结果得到 Z”的方式描述问题。这三个习惯能解决大多数令人失望的结果。

本指南的其余部分会详细展示这些模式，并附上可以改编使用的前后对比示例。

为什么向应用构建工具提需求与和 AI 聊天不同

当你向聊天助手提问时，模糊的提示词会得到模糊的回答，你看一眼就过去了。而当你向 AI 应用构建工具提需求时，得到的答案是一个正在运行的程序。描述中的每一个空白都会被猜测填补，而这些猜测会变成代码、数据库表和界面，之后你要么接受，要么撤销。

因此，提示词的目标并不是显得聪明，而是尽量减少把重要决定交给运气的情况。为此你不需要专业术语，只需要具体说明那些只有你知道的事情：你的用户、你的工作流程以及你的规则。

第一条提示词应该包含什么

在动笔之前，先回答以下问题。每一个问题都会堵住一个 AI 否则会去猜测的空白。

最后一行常被低估。说明你不想要什么，可以防止 AI 添加你从未要求的博客、定价页面和订阅表单。

前后对比：第一条提示词

修改前：

帮我做一个健身房的应用。

构建工具必须猜测一切：是给会员还是员工用？是团课还是私教？有没有支付？最后你得到的可能是一个看起来像健身房网站、却没有你真正需要功能的东西。

修改后：

为一家小型瑜伽馆构建课程预约应用。会员可以查看本周的课程（课程名、老师、时间、剩余名额），预约名额，并可在开课前两小时取消。会员使用邮箱和密码注册。馆主登录后可以添加课程、查看预约人员名单，并标记出勤情况。将课程、会员和预约保存在数据库中。风格清新、明亮，在手机上使用体验良好。暂时不做支付。

修改后的版本仍然很简短，它只是回答了上表中的那些问题。

描述行为，而非实现方式

与其告诉 AI 怎么做，不如描述应该发生什么，这通常会得到更好的结果。

修改前：

添加一个 useEffect 来获取预约，再加一个用于编辑的弹窗组件。

修改后：

当馆主点击某个预约时，打开一个面板，让他们可以修改时间或取消预约。修改应立即显示在列表中。

第一条提示词把 AI 锁定在某种特定的技术方式上，而这种方式未必适合应用现有的构建方式。第二条则告诉它期望的结果，让它为已经写好的代码选择合适的方法。如果你是开发者，并且确实有强烈的偏好，可以说明，但要同时说明预期结果。

把规则说具体

业务规则是 AI 构建的应用最容易出错的地方，因为对你来说它们显而易见，对 AI 却不可见。请把它们写清楚。

• 限制：“每位会员最多只能有三个未来的预约。”
• 时间：“课程开始前两小时截止取消。”
• 边界情况：“如果课程已满，显示候补按钮，而不是预约按钮。”
• 权限：“老师可以查看自己课程的出勤情况，但不能查看其他老师的。”

每条规则只需一句话。遗漏任何一条，应用要么不执行这条规则，要么会自行发明一个版本。

第一版之后：每条消息只改一项

一旦预览中已经能运行，就从描述整个产品转为提出小的、可以检查的修改。

修改前：

设计不对，预约功能也不正常，我还想要日历视图和邮件。

修改后（拆成四条独立消息）：

1. 当我预订某个课程的最后一个名额时，该课程仍然显示“剩余 1 个名额”。它应该显示“已满”，并隐藏预约按钮。
2. 在课表页面添加周视图日历，每天一列。保留当前的列表视图作为选项。
3. 让课程卡片在手机上更紧凑：减小内边距，把老师姓名和时间放在同一行。
4. 会员预约后，向其发送确认邮件。

这样做有效的原因：

• 每项修改都足够小，AI 可以一次做对。
• 你可以在进入下一步之前逐项测试。
• 如果某一项出错，你可以只回退那一步，而不会丢失其他修改。

说明要保留什么

当你要求修改一个已经正常工作的部分时，请告诉 AI 哪些内容绝对不能改变。这是防止回归（即编辑之后原本正常的功能又坏掉）最简单的方法。

重新设计首页的主视觉区域，标题更大，右侧放一张图片。导航、配色以及主视觉区域下方的所有内容保持完全不变。

数据同样如此：“给会员添加一个电话号码字段。不要删除或重命名任何现有字段。”

使用截图和准确的文字

“顶部那个东西”这类说法含糊不清。大多数 AI 应用构建工具都支持图片，附上截图并配一段简短说明，比用一段文字描述要快得多。

• 附上截图并说明“用红圈标出的按钮在手机上与菜单重叠”。
• 错误信息请直接粘贴原文，不要转述。
• 界面上的标签要准确引用：“设置页面上的保存更改按钮”。

针对错误，建议使用以下格式：

在预约页面，我点击了明天一项预约的取消按钮。我期望它从我的列表中消失。结果什么都没发生，刷新后预约仍然存在。请修复它，并检查取消功能是否正常。

我们关于如何调试 AI 构建的应用的指南对此有更深入的讨论。

大改动先做计划

对于涉及应用多个部分的改动——例如为原本没有账户的应用添加用户账户、添加支付、更改数据结构的方式——在任何代码改动之前，先要求提供计划。

在改动任何内容之前，先说明你打算如何添加团队账户：需要新增哪些数据表、哪些页面会改变，以及现有用户会受到什么影响。暂时不要修改代码。

仔细阅读计划。如果它误解了某些内容，修正一段文字的成本远低于修正一个已经完成的功能。许多构建工具都有专门的模式用于此；在 Mythex 中，这就是 Plan（计划） 模式，与 Build（构建） 和 Ask（提问） 并列。

需要避免的做法

关于 API 密钥：如果你需要支付或邮件服务，请把它的密钥放在项目的密钥设置中，而不是放在提示词里。如果你对此不熟悉，请参阅什么是环境变量和密钥。

可复用的提示词模板

将方括号中的内容替换即可改编使用。

新应用：

为[谁]构建一个[应用类型]。他们[主要流程，一步步写清楚]。[第二类用户]登录后用来[做什么]。将[数据]保存在数据库中。[外观和风格]。暂时不做[以后再说的内容]。

新功能：

在[页面]中添加[功能]。当[用户]执行[操作]时，[应该发生什么]。只有[谁]可以[做什么]。保持[现有内容]不变。

设计修改：

在[页面]上，将[具体元素]改为[具体修改]。保持[需要保留的内容]不变。检查它在手机宽度的屏幕上显示是否正常。

错误：

在[页面]上，我[操作步骤]。我期望[预期结果]。实际上[实际结果，附上准确的错误文字]。请修复并验证流程能够正常运行。

只提问、不修改：

不要修改任何代码。解释[应用的某个部分]是如何工作的，以及[数据]保存在哪里。

撰写更详细的规格说明

对于较大的项目，可以先写一份一页的简要说明，并把它作为开场提示词粘贴进去：包括用户、核心流程、数据、规则以及不做的内容。你甚至可以让 AI 帮你起草——我们关于如何用 AI 撰写产品需求文档的指南介绍了具体方法。只需把第一次构建的请求限定在核心流程上，其余内容再一步步添加。

在 Mythex 中撰写提示词

以上所有方法在 Mythex 中都适用。以下几点具体的功能会有所帮助：

• **Build、Plan 和 Ask 模式。**大型或有风险的改动使用 Plan，只想要解释而不修改时使用 Ask。
• **检查点。**每次成功修改后，Mythex 都会保存一个检查点，在某条回复上点击 Revert to this point（恢复到此处） 即可将项目回滚。你也可以编辑之前的消息并重新发送，从那一点开始尝试不同的提示词。
• **密钥卡片。**当智能体需要 API 密钥时，它会通过聊天中的卡片进行询问，因此该值会作为项目密钥保存，而不会被写入你的消息中。
• **图片。**附上截图或设计稿，智能体会查看它们。

文档中有一页简短的有效提示词，以及一页关于不重建即可迭代的内容。如果你从零开始，如何用 AI 构建应用会完整介绍一个项目的流程，而如何用 AI 设计好看的应用则涵盖了用于视觉打磨的提示词。

常见问题