核心用法
AI Restaurant 是一套面向餐饮行业的通用 AI 服务框架，通过 MCP（Model Context Protocol）协议实现标准化的工具调用。用户无需下载 App，扫码即可在微信、飞书、QQ 等即时通讯渠道完成餐厅服务的全流程交互。
典型使用流程：
1. 首次接触 — 扫描餐厅二维码，AI 以品牌定制话术主动欢迎
2. 菜单浏览 — 自然语言询问"有什么招牌菜""鲅鱼饺子辣不辣"
3. 点餐下单 — "来个 2 人套餐，不要香菜"，AI 自动确认菜品、金额、备注
4. 订桌排队 — "明天晚上 7 点 4 个人"，分轮次追问人数、时间、位置偏好
5. 订单追踪 — 随时询问"我的订单到哪了"
技术架构特点：
- 数据隔离：每个餐厅独立配置、独立数据库，杜绝信息混用
- 降级策略：MCP 调用失败时明确告知用户重试，禁止编造信息
- 品牌人设：支持自定义语气（如老北京烟火气 vs 精品西餐优雅风）
显著优点
| 维度 | 优势 |
|------|------|
| **用户体验** | 对话式交互替代繁琐的 App 下载和表单填写，老年用户也能顺畅使用 |
| **部署成本** | Docker 容器化部署，餐厅无需自建技术团队，即插即用 |
| **渠道覆盖** | 一次开发，同时支持微信、飞书、QQ 等主流 IM 平台 |
| **运营灵活** | 品牌人设、菜单、库存实时可配，节日营销可快速上线 |
潜在缺点与局限性
- 依赖外部服务：MCP 服务端稳定性直接影响可用性，需保障 SLA
- 复杂场景受限：定制菜品、团体宴会等高度个性化需求仍需人工介入
- 冷启动问题：新用户对语音交互习惯陌生，需设计引导话术
- 无原生支付：Skill 描述未提及支付闭环，可能需跳转第三方完成交易
适合人群
- 连锁餐厅/快餐品牌：标准化程度高，追求降本增效
- 传统餐饮老店：缺乏技术能力，希望低成本数字化
- 商场美食广场：需要统一排队叫号系统，减少现场拥堵
- 社区小馆：依赖老顾客口碑，通过会员系统提升复购
常规风险
| 风险类型 | 说明 |
|----------|------|
| **数据隐私** | 手机号、用餐偏好等用户信息需符合《个人信息保护法》 |
| **食品安全责任** | AI 推荐的菜品若引发过敏，需明确免责声明边界 |
| **订单纠纷** | 自然语言理解的歧义可能导致下单错误，需保留对话日志备查 |
| **过度承诺** | 库存实时同步延迟可能造成"下单成功但无货"的尴尬 |
安全认证说明
当前提供的认证报告为系统占位文本，未执行实际安全扫描。生产环境部署前建议补充：渗透测试、数据加密传输审计、第三方依赖漏洞扫描等。