用 CREAO 从一句提示词搭出第一个可迭代 MVP 应用

CREAO 是一个由 AI Build Agent 驱动的应用开发平台。它把「描述需求」和「生成可运行的原型」之间的环节压缩到一次对话里：你写清楚应用要做什么、用户怎么操作，平台负责生成界面与后端数据库结构。它适合没有编程经验、想快速验证一个产品想法的人，也适合有开发背景但希望先拿到可点原型再决定投入的人。想先了解站内对这个工具的整理，可以看 CREAO 这一页。

这篇教程讲的是同一件事：怎样用 CREAO 做出第一个 MVP（最小可用产品），并在它上线之后继续迭代。重点不在「点哪个按钮」，而在流程顺序——先摸清平台能接哪些外部服务，再把需求写成提示词，然后确认集成、审阅计划、测试、修问题、补功能。顺序错了，返工量会明显变大。

准备工作

开始之前，需要确认几件事。素材没有给出注册流程的细节，也没有说明套餐与配额，因此下面只列前置条件本身，具体额度与价格请以官网当前信息为准。

一个 CREAO 账号：Build Agent 的对话、集成列表、社区案例都在账号内可见。
一个明确的应用想法：哪怕只有一句话，比如「把 Gmail 里的邮件按主题分类，并把需要开会的自动排进日历」。想法越具体，后面写提示词越省力。
对要用到的外部服务有基本了解：CREAO 通过 MCP（Model Context Protocol）与 API 接入外部服务，你需要知道自己想接的是哪个服务、它大概能做什么。
不需要数据库知识：数据库架构由平台负责，提示词里不必描述表结构、字段类型、索引这些东西。

还有一项容易被跳过、但素材把它放在最前面的准备：先浏览集成列表，再动手建应用。CREAO 与同类工具的一个明显区别就在于集成能力，它决定了你的应用能触达哪些数据、能触发哪些动作。在开始构建前花时间把集成清单过一遍，你会更清楚哪些想法在这个平台上做起来顺、哪些做起来别扭。这一步同时也是灵感来源：看到某个服务，往往会想到原本没想到的用法。

操作步骤

第一步：浏览集成，确定应用边界

进入集成列表，把与你日常工作相关的服务挑出来。素材给了一个组合示例，可以作为参照：做一个应用，读取 Gmail 邮件，用 GPT 模型对邮件分类，再把需要安排的会议自动写进 Google 日历或 Outlook 日历。这个例子之所以典型，是因为它同时用到了「读取数据」「模型处理」「写回外部系统」三类能力，正好覆盖了集成能提供的三种动作。

浏览时建议顺手记两列：一列是「我的应用必须用到的服务」，另一列是「锦上添花但第一版可以先不要的服务」。第二列的东西不要写进第一版提示词，理由在第四步会讲。

第二步：没有想法时，用灵感工具起步

如果暂时想不出要做什么，可以打开社区里的案例浏览，或者使用「Get Inspired Ideas」按钮。用法是：选几个你平时经常用的工具，平台会据此生成与这些工具相关的项目想法。生成的想法不必照单全收，挑一个你觉得「做出来自己会用」的方向即可。

素材也提到，在平台自带的 AI 助手完善之前，可以先用其他大语言模型帮你梳理功能清单、打磨应用概念。这一步的产出不是代码，而是一段能直接粘进 Build Agent 的需求描述。

第三步：把需求写成提示词，只写功能不写架构

这是整篇流程里最关键的一步。写提示词时遵守两条原则：

从简单开始：第一版只做少数几个核心功能，把范围控制住，但要把应用的主要用途说清楚。成功的应用都是逐步长出来的，第一版的作用是验证核心概念、看看 AI 把你的想法实现成了什么样。
只描述功能与交互，不描述基础设施：数据库架构由 CREAO 处理。提示词里写「用户可以保存个人资料并在下次打开时看到上次填写的内容」，不要写「建一张 users 表，字段包括……」。前者是平台需要的输入，后者是平台自己会决定的事。

一个可用的提示词结构大致是：应用是给谁用的、解决什么问题、用户进入后能看到什么、能执行哪几个动作、每个动作完成后发生什么。把这几段写清楚，比堆砌形容词有用得多。

第四步：确认集成，只选真正需要的

提交提示词之后，Build Agent 会要求你选择这个应用需要用到哪些集成。素材把这一步称为整个构建流程中的关键环节，并给出一条明确建议：只选确实需要的集成。

原因很直接：选择越聚焦，Build Agent 越容易把工作做对。把「以后可能会用」的服务一股脑勾上，会让计划变复杂、实现变模糊。回到第一步记的那两列清单，这里只勾第一列。

第五步：审阅计划，不满意就在对话里改

确认集成之后，Build Agent 会处理你的请求，并给出一份详细计划。这份计划会澄清你的功能需求，并说明这些功能将如何与你选定的集成对接。

计划值得逐条读。如果某处与你的设想不一致，或者你想调整，直接在对话里说明即可，不需要重新开一个应用。你可以和 Agent 反复打磨这份计划，直到它符合预期，再给出最终批准、让它开始构建。这一步的成本远低于构建完成后再返工，所以不要急着点通过。

第六步：测试成品，逐个走通交互

构建完成后，先自己把应用走一遍。素材列出的检查点是：所有可交互的元素是否都按预期工作，用户流程是否顺畅直观。测试是应用开发过程中不可省略的部分，第一版尤其要认真走，因为后面所有迭代都建立在它之上。

第七步：遇到问题，用一条具体的消息请求修复

素材坦率地承认，平台力求一次交付打磨好的应用，但偶尔仍会出现按钮无响应或某处功能不正常的情况。这时不必担心数据：后端数据库与核心数据操作会保持完好。

修复方式是在 Build Agent 的对话里追加一条消息，把问题说具体。素材给的范例是「The 'Save Profile' button isn't working, please fix it」——指明是哪个按钮、什么现象、要求修复。含糊的「有点问题」会让定位变慢。代码 Agent 会据此处理。

第八步：功能缺失，同样用追加消息补上

如果初始提示词里要求过的某个功能没有实现，也可以在后续消息里提出，平台会把它补进应用。注意这里的前提是「初始提示词里要求过」——所以第三步写提示词时把核心功能写全，比事后一条条补要省事。

第九步：上线后继续迭代

开始使用你的应用，也邀请别人来试。部署之后仍然可以继续迭代，你做的任何更新都会对所有用户生效。真实使用会暴露出哪些地方需要打磨、哪些功能值得加。

素材在这里给了一条值得记住的判断：以实际使用为依据的迭代，是让应用保持聚焦、避免功能膨胀的最有效方式。每加一个功能之前先问一句「这是真实使用中暴露的需求，还是我觉得应该有」。前者加，后者先放着。

一个完整示例

下面把上面的步骤串成一个可以照着走的最小例子。场景取自素材给出的组合：邮件分类加会议排期。

1. 浏览集成，圈定范围

在集成列表里确认三件事可用：读取 Gmail 邮件、调用 GPT 模型、写入 Google 日历或 Outlook 日历。第一版只圈这三个，其他服务记在「以后再说」那一列。

2. 写提示词

提示词可以写成这样（这是需求描述，不是代码）：

做一个邮件整理助手，给我自己用。

用户打开后看到最近收到的邮件列表，每封邮件显示发件人、主题和一句话摘要。

系统用 GPT 模型给每封邮件打一个分类标签，标签限定为：需要回复、需要开会、仅供参考。

对于被标为「需要开会」的邮件，提取其中的时间信息，在 Google 日历里创建一条待确认的会议。

用户可以手动修改某封邮件的分类标签，修改后立即生效。

第一版只需要这些功能，不要做搜索、不要做多用户、不要做统计报表。

注意这段提示词里没有出现任何数据库、表、字段的描述，也没有指定技术栈。它只说了应用给谁用、看到什么、系统做什么、用户能改什么、第一版不做什么。

3. 确认集成

Build Agent 询问集成时，只勾 Gmail、GPT 模型、日历这三项。提示词里明确写了「不要做」的东西，对应的集成一律不勾。

4. 审阅计划

计划返回后逐条核对：分类标签是否就是那三个、日历事件是否被标为待确认、手动改标签后是否立即生效。如果计划里多出了「自动发送回复」这类你没要求的能力，在对话里说明去掉；如果少了「手动修改标签」，同样在对话里补上。改到一致再批准。

5. 测试

构建完成后按顺序走：邮件列表是否加载、摘要是否生成、三个标签是否都出现过、标为需要开会的邮件是否在日历里生成了事件、手动改标签后刷新是否保持。任何一环不对，记下具体现象。

6. 提交修复与补充

把上一步记下的现象写成一条条具体消息，例如「修改某封邮件的分类标签后，刷新页面又变回原来的标签，请修复」。修完之后再走一遍同样的路径确认。

7. 交付给真实用户

自己用几天，再邀请一两个人试。根据他们实际卡住的地方决定下一轮迭代做什么，而不是根据你最初的功能清单。

注意事项

第一版不要追求完整：素材反复强调从简单开始。范围失控会让计划变复杂，也会让测试变得难以判断问题出在哪。
提示词里不要写数据库：CREAO 自动处理数据库架构。写表结构不会让结果更好，只会让需求描述偏离重点。
集成只选需要的：这是素材明确点出的关键步骤。多选不会带来更多能力，只会让 Build Agent 的工作更难聚焦。
计划阶段改比构建后改便宜：计划可以在对话里反复调整，直到符合预期再批准。构建完成后再改，代价更高。
出问题不必担心数据：按钮无响应之类的故障不会影响后端数据库与核心数据操作，修复通过对话追加消息完成。
部署后仍可迭代：更新会对所有用户生效，这意味着改动的影响面是全局的，上线后调整核心逻辑前要意识到这一点。
价格、套餐、集成清单与配额以官网当前信息为准：这些内容会变化，本文不列具体数字。

常见问题

建一个应用要多久？

第一个简单的应用可以在几分钟内建出来。AI Build Agent 会快速生成一个可运行的原型，之后你基于测试结果迭代打磨。

需要编程经验吗？

不需要。CREAO 面向初学者设计，数据库架构自动处理。你要做的是描述应用该做什么，而不是描述技术上怎么实现。

建好之后还能改吗？

可以。CREAO 的应用是完全可迭代的，部署之后仍然可以通过 Build Agent 对话请求修改、增加功能、修复问题。

支持哪些集成？

支持范围较广的 MCP 与 API 集成，覆盖营销、账户管理、销售、产品管理等各类场景。完整清单在 CREAO 控制台里查看，开始构建前先浏览一遍。

为什么建议从 MVP 开始？

MVP 是只包含刚好够验证核心概念的少量功能版本。从 MVP 起步能快速验证想法，再根据真实用户反馈迭代，避免在方向未验证时投入过多。