中午一个窗口排三十人，阿姨边听边在纸上记？
交给食堂点餐小程序——同学自己扫码点，阿姨照着单子出餐，不用一边听一边记；写错了也不用倒回去找那张纸。每天的收支晚上自动对平。
学生端与阿姨端是两套完全独立的页面，共用同一份订单、菜单与库存。含每日菜单发布、套餐计价、按楼层归集打包与每日对账，3000+ 行前端跑在微信云开发上。
食堂每天就那几样菜，但要服务几十号人。原来的流程是：阿姨在群里发今天的菜单， 大家在群里报「三荤一素」，阿姨拿本子记，中午按楼层送上去，晚上再对着微信收款一笔笔核。
问题不在点菜，在两边看到的东西不一样。同学不知道自己选的还算不算数， 阿姨不知道到底要做多少份、谁还没给钱。所以这个小程序的第一步不是画界面， 而是先把「菜单—订单—收款」这三件事变成同一份数据，两个角色各看各的那一面。
同一个小程序，进来自动按身份分到两边。数据是同一份，视图完全不同。
下面都是真机截图，不是设计稿。同一份数据在两个角色眼里的样子。
22 秒录屏，没有剪辑。
这段录屏是上线之后直接发到用餐群里的，不是为案例补拍的。 从填饮食偏好开始，到 AI 配出一套菜，再到确认下单，一路到底。
食堂不是餐厅，不需要「一份土豆丝」。菜单按荤素分组，选的时候只管搭配数量， 价格由套餐档位说了算（两荤一素、三荤两素……）。阿姨端统计时拿到的是「几份几荤几素」， 直接对应要炒多少锅，而不是一长串单品。
阿姨真正要的是「哪层楼送几份」。所以打包页的主视图是楼层，进去才看到这一层有几单、
都是谁、哪单还没给钱。订单数 / 应收 / 未收 三个数放在最上面，
一眼知道今天还差多少钱没收到。
有人转账，有人发红包。硬要合成一个「已支付」字段，晚上对账就得靠回忆。 所以收款方式是个显式字段，收支页把转账和红包分开统计，明细里每笔都标着来源。
每天就那几样菜，选到最后大家都麻木。给一个「随便帮我配一套」的按钮， 按套餐档位和当日菜品直接生成组合，不满意再点一次。它替代的是「今天吃啥」这个决策， 不是替人下单。
这个小程序已发布，微信扫一下就能进去试。要改成你们单位的，聊一句就行。
微信扫码体验
