北京
一家餐厅每天要干两件事：把客人服务好，把新客人吸引来。麻烦在于，这两件事往往跑在两套互不相通的工具里——服务员靠嘴喊，经理靠表格记，促销内容靠临时想。TapWait AI 想做的，是把它们塞进同一个平台。
这个项目面向餐厅、酒吧、咖啡馆和餐饮服务商，由四块拼起来：给服务员用的 Flutter 移动端、给经理看的网页后台、实时后端服务，以及 AI 辅助的营销内容生成。技术栈上，后端是 Node.js 加 Express，MongoDB 存服务请求和促销记录，Socket.IO 负责实时通信，Firebase Cloud Messaging 负责推送通知。
服务员端：请求走流程，不靠喊
服务员在 Flutter 应用里接收并处理顾客的服务请求。请求按既定流程流转，员工能看到每条请求的状态，再决定怎么响应。实时更新靠 Socket.IO，推送通知靠 Firebase Cloud Messaging，在支持的环境下也包括后台通知。
这套设计的目标很直接：缩短从"顾客提出请求"到"有人响应"之间的摩擦。经理端则是一个网页后台，集中查看服务请求、跟踪进度、协调运营，不必完全依赖口头沟通。后台同时也是管理 AI 生成促销内容的入口。
MenuBoost：菜单本身就是素材库
菜单不只是菜品清单。每一道菜、每一个优惠，都可以变成拉客的由头。MenuBoost AI 调用谷歌托管的 Gemini API，基于已保存的菜单项、价格、选定的优惠、营销语气和目标平台来生成推广文案。
经理可以直接产出面向 WhatsApp、Facebook、Instagram 的内容，不用从空白页开始写。生成的内容锚定在餐厅自己的信息上，这是它试图比通用文案工具更实用的地方——面向的是没有专职营销团队的小店。
平台还接入了 WhatsApp Cloud API 的工作流，用来支撑餐厅消息和推广活动的管理。推广投递需要遵守订阅者同意、适用的消息政策以及 WhatsApp 的要求，设计上指向的是负责任的客户触达，而不是无差别群发。
Campaign Guard：生成之后，还得有人查
文案写得漂亮只是一半。餐厅还得确认促销内容确实对得上自己的菜单和优惠。Campaign Guard 这个实验用 Ollama 跑 Gemma 3 270M，把已保存的促销内容与关联的菜单、优惠信息做比对。
流程是：取出保存的促销记录，把内容和来源信息喂给本地模型，返回一份结构化审查结果，包含摘要、潜在问题和修改建议。
更关键的是可靠性设计。整体校验思路是把模型辅助审查和确定性的应用逻辑结合起来——价格、折扣、优惠条件应当对照可信数据和明确的业务规则来核，而不是只交给语言模型判断。这也是轻量开源权重模型在既有业务应用里做质量检查的一次探索。
混合架构：谁干什么，分得很清
整个平台在 AI 上走的是分工路线：
- Gemini 负责生成，用餐厅菜单项和选定优惠产出推广内容；
- Gemma 负责本地审查，Campaign Guard 通过 Ollama 跑 Gemma 3 270M，对照来源信息检查促销文本；
- 确定性校验负责兜底，应用代码对照可信记录核验价格、折扣等明确的业务规则；
- 架构上把生成、审查、业务规则校验拆开，各组件可以独立演进。
本地模型还能在应用配置为本地运行时提供另一条推理路径，但是否合适取决于硬件、延迟和审查质量。对餐饮企业来说，AI 要有用、可适配、并且扎在真实业务信息上。
谁掏钱，怎么收
目标客户包括想改善服务协调的独立餐厅、客流繁忙的酒吧和咖啡馆、需要更简单方式准备推广内容的小型餐饮商家，以及想把运营流程和营销工具打通的多门店餐饮集团。
商业模式上，设想包括按月订阅、按业务需求分层的套餐，以及面向多门店运营者和额外集成的高阶方案。项目强调的是通过更有条理的工作流、更省力的活动准备和更清晰的运营可见性来创造可衡量的价值，而不是承诺未经证实的收入增长。
目前，一家邻近的初创公司已表达使用意向，并给出了积极反馈。下一步是走向结构化的真实场景使用，收集反馈、观察工作流实际表现，找出 TapWait 能在哪里省时间。
一个 270M 的本地小模型，配一个托管的大模型，再加一层写死的业务规则——这套组合不炫技，但它把"AI 该干什么、不该干什么"划得比较清楚。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
