AI生成小程序原型，可以从“用户买什么、怎样下单、到哪里提货”开始描述。以社区团购为例，先做首页、商品列表、商品详情、购物车和订单五个页面，再补库存、截止时间与提货状态。把下面的需求输入墨刀AI原型工具，就可以开始组织第一版页面和交互。
这里制作的是用于讨论和演示的小程序原型。微信登录、真实支付、库存扣减和提货核销，需要在正式开发中另行实现；原型画得像小程序，不表示它已经可以提交平台审核。
社区团购的五个页面，各自解决什么问题
| 页面 | 用户要完成的事 | 不能缺的信息 |
|---|---|---|
| 首页 | 了解今天能买什么 | 当前提货点、活动截止时间、推荐商品 |
| 商品列表 | 筛选和比较商品 | 分类、规格、价格、售罄状态 |
| 商品详情 | 决定是否购买 | 商品规格、数量、提货时间与地点 |
| 购物车 | 核对商品与金额 | 数量、失效商品、总额和提交入口 |
| 订单 | 确认结果并提货 | 订单状态、明细、提货说明 |
第一版可以只做一个提货点和少量示例商品。多团长分佣、复杂优惠券、跨仓配送等规则会显著增加页面状态，应该等主要购买路径清楚之后再讨论。首页也不必把全部功能挤在一起，用户最关心的提货点应比装饰性Banner更容易找到。
把这段需求交给AI，先得到可讨论的初稿
设计一个社区团购小程序原型，面向附近居民。包含首页、商品列表、商品详情、购物车、我的订单五页。首页展示当前提货点和本轮截止时间；商品可选规格、数量并加入购物车；提交前核对商品总额和提货点。订单展示待提货、已完成和已取消状态。补充售罄、超过购买上限、活动已结束和空购物车。界面使用中文，采用清晰的商品卡片与底部导航，保留可编辑组件。使用示例数据，不接真实支付。
在墨刀AI中选择原型相关功能后输入需求。遇到需求确认时，说明哪些页面必须保留、哪些规则仍待决定。若AI加入了积分商城或配送追踪，可以明确要求删除，保持这一版只服务到店提货。
页面生成后，先核对商品和提货信息
用一件示例商品串起来检查：草莓500克，单价29.9元，选择2份，商品金额应为59.8元。这里假设不含优惠、运费和其他费用，仅用于说明原型中的信息一致性；实际项目应采用已经确认的计价规则。
从列表进入详情，再加入购物车，观察规格和数量有没有保留。回到详情修改数量时，也要决定是追加数量还是替换原数量，并把规则写进说明。价格字段不能只在页面里各填一个数，否则很容易出现列表和订单金额不一致。
提货点不能只藏在个人中心
用户在加入购物车前就需要知道能否到指定地点取货，因此首页和下单核对处都应显示提货点。若项目允许切换提货点，要讨论商品库存和提货时间是否随之变化，不能只把地址文字替换掉。
活动结束与商品售罄是两种状态
售罄针对单件商品，可以引导用户查看其他商品；活动结束针对本轮购买，应说明下一轮入口或返回首页。将两者都写成“暂不可购买”，会让用户不知道等待是否有用。
把购买流程接起来，再补失败后的去向
先在预览中完成“首页选商品、详情选规格、购物车核对、提交、查看订单”。如果页面只是展示，没有正确连接，可在原型编辑中为商品卡片、加入购物车和提交按钮补上跳转或状态变化。不要用一段说明文字代替可演示的关键操作。
接着走反方向：关闭规格弹窗是否回到原商品，订单页返回后能否继续浏览，空购物车有没有去选购的入口。小程序原型不仅要能向前点，也要让退出和返回有明确位置。需要更细的配置思路，可参考交互原型的触发、反馈与页面连接。
局部修改时，说清楚哪些页面不要动
例如“只修改购物车，将提货点放到商品列表上方；售罄商品独立分组，不计入本次提交；保留商品详情页和底部导航”。这种指令比“做得更像电商”更具体，也方便修改后逐项检查。
如果要增加退款功能，先确定允许退款的订单状态、处理方式和提示内容，再生成相关页面。不要让AI顺手补一个退款按钮，却没有对应的处理结果。尚未确定的规则可以暂存在PRD的待确认区，使用AI写PRD的方法把问题整理给业务方。
分享评审时，让团队真的试一次下单
原型可以用于产品、设计、研发和运营共同评审。通过当前可用的分享或原型转换入口，让同事查看页面并提出具体问题；分享范围与访问权限应先确认，示例中不要放真实手机号、住址或订单信息。
评审时分别安排正常下单、售罄商品、活动结束和切换提货点几种任务。问题应记录到页面和操作，例如“购物车切换提货点后，订单仍展示旧地址”，这样才能直接用于修改，而不是只评价颜色和风格。
小程序原型完成后，还要做什么
原型确认后，开发需要落实账号授权、服务端校验、订单与支付状态、库存及核销逻辑，并按目标平台的当前规范处理审核和发布。原型中的“支付成功”只是演示状态，不能作为支付已接入的证据。
如果你还在熟悉AI画原型的基本方法，可先看AI原型设计步骤。现在就可以在墨刀AI创建社区团购原型，先把一个提货点的购买流程做清楚，再扩展更多经营场景。
