云开发怎么跟 AI 提需求？把「我想做个 App」拆成能干的活

摘要： 跟 AI 提需求的关键不是描述得多详细，而是拆得多准。把「我想做个 App」拆成页面、数据、权限、技术约束四层，再分阶段验收，AI 的产出质量会有明显差别。 开通环境动手练：云开发 CloudBase

同样用云开发 CloudBase 配 AI 工具，有人一句话就能跑出可用应用，有人改了三天还在白屏。差别不在工具，在提需求的方式。照着教程抄能成功，换个需求就不会提——这是卡住大多数人的真正门槛。本文给一套可复用的拆解方法：四层结构 + 分阶段验收 + 三类约束，附完整提示词模板。

一、为什么「做个商城小程序」这种需求必然失败

把这句话丢给 AI，它只能靠猜：商品怎么分类？要不要登录？支付走哪条路？库存怎么管？订单状态有几种？管理后台要不要？

AI 会按最常见的假设生成一套代码，等你发现哪儿哪儿都不对，就得一轮轮改。改到第五轮，它已经忘了第一轮的约定，开始推翻之前的设计。

问题的根源是：你给的是目标，AI 需要的是边界。目标只有一句，边界有几十条。不把边界讲清楚，AI 就会自己填，填错了你再纠正，成本比一开始讲清楚高得多。

二、四层拆解法：把一句话变成 AI 能干的活

拆需求按这四层走，顺序不能乱。

第一层：页面与跳转

列出所有页面，每个页面放什么、从哪进、点了去哪。

错误写法：「要有首页和详情页」

正确写法：「首页展示商品卡片列表（图片、名称、价格），点卡片进详情页；详情页展示大图、描述、规格、立即购买按钮」

判断标准：写完这层，一个没见过你产品的人应该能画出页面草图。

第二层：数据与字段

列出要存什么数据、分几个集合、每个集合有哪些字段。

错误写法：「要存商品和订单」

正确写法：「products 集合：name、price（单位分）、images（fileID 数组）、stock、status；orders 集合：orderNo、openid、productId、amount、status（pending / paid / shipped）、createTime」

判断标准：字段名和类型都写出来了，单位也标了。价格单位这种细节，不写 AI 就会猜，猜错了后面支付金额全是错的。

第三层：权限与身份

谁能读、谁能写、用什么识别用户。这层最容易漏，漏了的后果是数据裸奔。

正确写法：「登录走云开发身份，云函数里用 cloud.getWXContext().OPENID 认人，不自建账号体系；products 集合所有用户可读、仅创建者可写；orders 集合仅创建者可读写；订单金额和状态只能由云函数写入，前端不可直接改」

判断标准：每个集合都明确了读权限和写权限，敏感字段指明了只能服务端写。

第四层：技术约束

框架、UI 库、风格、代码组织方式。这层决定了生成的代码你能不能看懂、能不能继续改。

正确写法：「原生小程序 + 云开发，不引第三方 UI 库，浅色卡片风格、圆角、留白充足；图片统一用 wx.cloud.uploadFile 上传到云存储，数据库只存 cloud:// 开头的 fileID」

判断标准：技术栈唯一确定，没有「随便用什么都行」这种表述。

三、分阶段验收：防止 AI 一次写太多

四层写完别急着发。需求越大，AI 一次生成的代码越多，出问题越难定位。正确做法是明确要求分阶段交付，每阶段你确认后再继续。

在提示词末尾加这段：

开发阶段规划
注意：你每完成一个阶段，都需要让我本地体验确认后，再进入下一阶段。

阶段 1：基础框架
- 创建页面结构与路由
- 搭建基础 UI 骨架
- 建好数据库集合并设置权限

阶段 2：核心功能
- 实现列表展示与详情跳转
- 接通数据库读写

阶段 3：业务闭环
- 加入登录与身份识别
- 实现下单与状态流转

阶段 4：完善与部署
- 补充异常处理与空状态
- 部署并返回访问链接

这样做有三个好处：每阶段代码量可控，出问题容易定位；你能在早期发现方向不对，及时掉头；AI 不会因为单次任务过大而中途失去上下文。

四、三类必须写进提示词的约束

除了四层结构，有三类约束不写就会出问题，而且是反复出问题。

安全约束：哪些数据前端不能写。典型的是价格、库存、会员等级、订单状态——这些让前端能写，等于让用户能改。写法：「价格从数据库查，不信任前端传值；订单状态只能由云函数更新」。

数据存储约束：图片和文件怎么存。写法：「图片用 wx.cloud.uploadFile 上传到云存储，集合里只存 fileID，不存本地临时路径」。不写这条，AI 有一定概率存本地路径，真机上图片全不显示。

交付约束：做完要告诉你什么。写法：「生成完成后用微信开发者工具打开项目，并列出需要我手动完成的步骤」。这条能避免你以为全自动完成了，实际还有商户号没填、集合权限没设。

五、完整提示词模板

把前面几层拼起来，就是一份可直接用的模板。以「活动报名小程序」为例：

用云开发做一个活动报名微信小程序。

页面结构（底部 tabBar 三个入口）：
1. 活动列表：卡片展示活动（封面图、标题、时间、地点、剩余名额），点击进详情
2. 活动详情：大图、详细介绍、时间地点、已报名人数、立即报名按钮；名额满时按钮置灰显示「已满员」
3. 我的报名：展示当前用户报名过的活动，可取消报名

数据结构：
- activities 集合：title、cover（fileID）、desc、startTime、location、quota（总名额）、signedCount（已报名数）、status
- signups 集合：activityId、openid、name、phone、createTime、status（signed / cancelled）

权限与身份：
- 登录走云开发身份，云函数里用 cloud.getWXContext().OPENID 认人，不自建账号体系
- activities：所有用户可读、仅创建者可写
- signups：仅创建者可读写
- signedCount 只能由云函数更新，前端不可直接写
- 报名时在云函数里校验名额，超额则返回失败

技术约束：
- 原生小程序 + 云开发，不引第三方 UI 库
- 风格简洁，浅色背景、卡片圆角、留白充足
- 图片用 wx.cloud.uploadFile 上传云存储，数据库只存 cloud:// 开头的 fileID
- 报名按钮做防重复点击，提交中置为 loading

开发阶段规划
注意：你每完成一个阶段，都需要让我本地体验确认后，再进入下一阶段。
阶段 1：页面结构与数据库集合（含权限设置）
阶段 2：列表与详情展示，接通数据库读取
阶段 3：报名功能，含名额校验与防重复提交
阶段 4：我的报名页与取消报名，部署上线

生成完成后用微信开发者工具打开项目，并列出需要我手动完成的步骤。

这份模板换个场景就能复用——把活动换成课程、商品、预约，把字段改一改，结构不用动。

六、AI 跑偏时怎么拉回来

即使需求写得好，中途也可能跑偏。三种常见情况的处理方式不一样。

改一个功能坏了三个：说明单次改动范围太大。改法是把修改请求也拆小：「只改详情页的报名按钮逻辑，不要动列表页和数据库结构」。明确划定修改边界，比事后排查快。

反复改同一个地方改不好：停下来，不要继续让它试。把当前报错原文、相关代码、你的预期三样一起给它，让它先分析原因再动手：「这段代码报错是 xxx，我的预期是 yyy，先告诉我原因，确认后再改」。

生成的东西跟你想的不一样：多半是描述太抽象。补充具体细节，必要时截图标注。把界面截图、用画笔圈出问题区域，粘到对话里，比写一百字描述有效。

七、提需求的三个实用习惯

习惯一：先让 AI 复述需求。 发完提示词，加一句「先复述你理解的需求和实现方案，确认后再写代码」。能在写代码前发现理解偏差，成本最低。

习惯二：关键节点让它加日志。 「在报名提交、名额校验、数据写入三个节点加上调试日志」。后面出问题时，日志截图丢给它，定位速度快得多。

习惯三：素材自己准备。 图标、配图、品牌色这类素材，让 AI 自由发挥效果往往不稳定，风格容易不统一。提前准备好放进项目，AI 只负责逻辑和交互，整体更可控。

总结

跟 AI 提需求的核心是把目标翻译成边界：页面与跳转、数据与字段、权限与身份、技术约束，四层写清楚，AI 就不用猜。再加上分阶段验收和三类硬约束（安全、存储、交付），单次产出质量会有明显提升。跑偏时不要硬改，先缩小修改范围或让它分析原因。这套方法换任何场景都能复用，真正的门槛从来不是工具，是你能不能把想法讲成可执行的任务。

开通环境，拿模板练一个应用：云开发 CloudBase 购买页