夜雨聆风小赵的 AI 工具实践
我用 AI 工具做出一个
全家共用的点餐小程序
从一个家庭需求，到真实上线的小工具
这个小程序的起点很简单：家里点菜一直靠微信群，谁想吃什么就发一句，但消息多了以后，很难看清楚谁点了什么、总共要准备多少。
所以我想做一个家里人都能打开的点餐小程序，把常做的菜整理成菜单，分好分类，点完之后还能留下订单记录。
它叫“赵大厨的私房菜”。下面主要记录我是怎么把这个想法一步步搭起来的。
从一个想法，到能点开的原型
最开始，我给 AI 工具描述的是一个很粗的需求。
我要有菜单，要能分类；点菜时可以选规格，比如辣度、份量；菜品最好有图片；家里人点完之后，要能看到订单记录。
AI 工具先帮我做了一个网页版原型。这个阶段最有用的地方，是我可以直接看效果，而不是停留在脑子里想象。
我看到页面之后，就能立刻判断：这个分类顺不顺手，购物车是不是好理解，下单流程会不会让家里人觉得麻烦。
确认基本思路后，再把同样的逻辑迁移到微信小程序版本里，陆续加上购物车、下单确认、订单记录和后台管理。
第一版功能大概长这样：
01菜单分类：把家里常做的菜按类型整理出来
02菜品详情：展示图片、规格和可选项
03购物车：点完之后统一确认
04订单记录：看谁点了什么、总共多少钱
05后台管理：维护菜单、图片和订单数据
这一阶段给我的感受很明显：AI 工具最适合把一个模糊想法快速推到“能看、能点、能试”的状态。
但从“能跑”到“能给全家人稳定用”，才是真正的第二关。
把它做成全家共用的小程序
网页原型跑通之后，我开始把它整理成真正能给家里人使用的微信小程序。
这一步的重点不是再加很多炫酷功能，而是把“全家共用”这件事做出来。菜单不能只存在我自己的手机里，订单也不能只在某个人的本地缓存里。
所以我把菜单、菜品图片、订单记录这些数据接到云端，让家里人打开小程序时看到的是同一份菜单、同一份订单记录。
我搭建时按这个顺序推进
1先定场景：家里人打开后，可以直接看菜单、选菜、下单。
↓
2再做菜单结构：按肉类、海鲜、蔬菜、主食等分类整理菜品。
↓
3补充点餐交互：加入搜索、加菜、选配料、购物车和下单确认。
↓
4接入共享数据：把菜单和订单放到云端，保证多人看到同一份记录。
↓
5做后台维护：后续可以继续添加菜品、调整分类、查看订单。
我觉得这一步很像把一个“页面”变成一个“产品”。页面只要能展示就行，但产品必须考虑谁来用、怎么维护、数据是不是一致、后面还能不能继续扩展。
对这个家庭小程序来说，最重要的不是功能数量，而是家里人打开后不用学习太多，就能知道怎么点菜。
从内测到上线，才知道“小程序发布”也有流程
功能能跑之后，我又开始处理上线问题。
这一步和写代码不太一样。它更像是在完成一套产品发布流程：微信认证、ICP备案、代码审核、正式发布，每一步都有自己的要求。
备案没有完成之前，小程序即使能跑，也更像是测试版本。真正要让家里人和朋友都能顺利打开，还要等备案通过，再重新发布正式版。
上线流程，我最后是这样推进的
1先内测：确认菜单、下单、订单和后台管理能正常跑。
↓
2做认证和备案：完成微信小程序发布需要的账号和合规流程。
↓
3提交审核：把代码提交到微信官方审核。
↓
4生成二维码：让大家扫码直接进入菜单页。
到这里，我才感觉它从一个“我自己能跑的项目”，变成了一个家里人真的能打开、能使用的小工具。
AI 工具在这个过程里承担了什么
这次搭建里，我和 AI 工具的分工很清楚。
我负责把需求说清楚：家里人为什么要用、菜单应该怎么分、点菜流程要多简单、上线后怎么让大家打开。AI 工具负责把这些需求变成代码和可测试版本。
每一版出来之后，我会在手机上看实际效果，再继续调整。哪里不顺手，就把具体感受反馈回去；哪里需要补功能，就重新说明使用场景。
这次最有价值的，不是“AI 替我做完”。
而是我可以用更快的节奏，把一个生活里的小需求，反复变成可以测试、可以修改、可以上线的版本。
这个过程让我更清楚地看到，AI 工具适合做开发搭档，但项目方向、使用体验和上线判断，还是要回到真实的人和真实场景。
最后，它真的被家里人用起来了
现在，“赵大厨的私房菜”已经正式上线。
家里人打开小程序，看到的是同一份菜单、同一份订单记录。谁点了什么、总共多少钱，都能直接看清楚。
它不是一个多复杂的系统，但它完整走过了一个产品从 0 到 1 的过程：从生活里的小需求，到原型，到小程序，到云数据库，到认证备案，再到正式发布。
AI 工具让我意识到：当工具越来越强，人更需要学会把需求说清楚，把过程拆清楚，把边界定清楚，再用真实反馈去验证它。