用AI工具给莫氏鸡煲写了个餐饮取号小程序

此帖分享一下我使用腾讯云出品的WorkBuddy从产品PRD到UI设计再到前后端技术实现数据库设计的全流程。一、先给WorkBuddy交代背景我的输入Prompt是这样的背景顺德莫氏鸡煲最近火了据说早上拿号都要排队到晚上才有得吃。调研莫氏鸡煲目前还是传统的手写单号叫号模式并未用美团、客如云等餐饮收银叫号系统。构思开发一个多角色账号的叫号小程序客户端是核心的现场等号和预约排号功能。店家端是叫号、落座台号、过号等操作。然后我开始逐条向WorkBuddy交代功能细节功能细节以下是我的原始输入现场等号授权地理位置权限后扫码等号。主要用于已经到现场的用户使用。预约排号方便食客提前预约时间再到店避免空跑。店家也能根据预约数据合理安排食材。桌型简化调研发现莫氏鸡煲是常规的6-10人打边炉圆桌1期不做大中小桌区分。鸡煲占桌面空间大火锅类不拼桌就以最大10人圆桌为考量基础。号源分配调度逻辑这部分我思路比较粗需要WorkBuddy补充店家自由设置开店时间鸡煲一般坐台2-3小时。假设早上10点开店晚上10点关店前置推断8点停止叫号。工作时间10小时假设有50桌。当天第一批叫号是早上10点-12点50桌叫50个号。现场号源和预约号源分配情况店家可自由调度。假设默认五五分配10点-12点50桌25桌现场叫号25桌线上预约号。如若到点之后预约号源未满可顺延给现场号叫号。第一批叫满后第二批根据翻台情况灵活叫号。店家端按顺序往下叫号落桌后小程序填写桌号将叫号编号和桌号关联。如若过号点击过号继续叫下一号。此叫号逻辑是有调度算法逻辑的请开发工程师及算法同学帮忙补充完善。数据需求统计基础预约数据、到店数据通过落坐时间和下一桌落坐时间计算平均就餐时长和翻台率。版本迭代计划假设鸡煲只有1个基础套餐数据看板先算营业额菜系复杂则下一版本迭代菜单系统暂不在本次范围大中小桌不在本次迭代范围暂不开发店家管理后台本次采用后端程序写定模式。以下是workbuddy的输出二、WorkBuddy生成PRD我召唤的是write-a-prd这个Skill。我的指令「请帮我补充完善产品PRD方案、技术开发方案、测试用例。」WorkBuddy基于我上面的背景描述生成了完整的PRD文档我直接让它保存到了GitHub 项目地址[PRD-叫号小程序-v1.0.md](https://github.com/cyj4578/What-You-See-Is-What-You-Get/blob/main/PRD-%E5%8F%AB%E5%8F%B7%E5%B0%8F%E7%A8%8B%E5%BA%8F-v1.0.md)三、基于PRD生成UI设计PRD确定后我继续让WorkBuddy根据PRD输出UI设计稿。workbuddy很好的理解了我prd需求里要求的做多角色身份切换的需求。这一步主要是把文字需求转化为页面流程和视觉规范为后续开发提供依据。四、技术实现召唤高级开发工程师PRD和UI都 ready 后我召唤了WorkBuddy的高级开发工程师指定了技术栈要求使用小程序原生开发和Python作为后端数据库用MySQL。使用的Skills- 全栈开发- 微信小程序开发框架技术方案细节WorkBuddy补充完善的部分前端小程序原生开发| 模块 | 实现方式 ||------|----------|| 用户端 | 授权手机号登录 → 首页【现场等号/预约排号】→ 现场等号需地理位置授权扫码 || 店家端 | 本次先指定几个微信账号作为商家端白名单模式后期考虑SaaS多店管理 |预约排号规则日期 工作时间模式每个时段可约台数由店家设置。后端Python MySQL我对后端开发流程和数据库结构设计不太懂这部分完全由WorkBuddy补充完善。五、项目归档全流程走完后我让WorkBuddy把产物统一归档到GitHub形成可追踪的版本记录。六、Workflow总结我描述需求背景和功能细节↓WorkBuddy(write-a-prd) → 生成PRD文档↓我确认PRD后 → WorkBuddy生成UI设计稿↓我指定技术栈 → WorkBuddy(全栈开发微信小程序Skill) → 前后端代码实现↓存储项目归档核心经验不要期待AI一次性生成完美方案。我的角色是提供业务洞察和决策比如调研莫氏鸡煲的手写单号现状、决定一期不做大中小桌AI的角色是补充我欠缺的工程能力比如后端架构、数据库设计、算法逻辑完善。写在最后餐饮叫号系统本身不算什么新产品新技术。但从现实业务场景出发到版本迭代规划、功能取舍决策再到用AI补齐技术短板完成全链路落地——这是以往传统产品经理的工作流中很难实现的。期待大家更多AI工具使用 自我深度思考抽丝剥茧世界的底层逻辑。关于write-a-prd这是我常用的Skill之一感兴趣的朋友评论区留言我下个帖分享安装方法和我常用的Skills清单。