讨论了绑单机退网和退款功能迁移至现场设备（分支流程），完善 450/460 逃单功能，AI 结算
台接入支付宝碰一碰支付（通用接口），菜品识别暂延用三方算法，消费机增加离线订单手动
同步。另需梳理人员同步逻辑，解决卡脸信息割裂及锁卡状态同步问题，避免离线场景下异常
消费。

产品功能规划与分支流程完善
保盘机分支流程补充
• 餐厅现场人员需在保盘机上直接操作处理异常（如取餐克重问题），因 P 端操作不现实，需
  补充分支流程。
• 此前主流程已上线，但未考虑分支场景，现需完善以支持现场快速处理。
450/460 单双称逃单功能迁移
• 410 项目的逃单功能已在项目中验证，需迁移到 450、460 等新机型，属于主流程的延伸完
  善。
• 当前 450 单双称及 460 设备的逃单功能尚未完全补充。
个性化需求与标准产品边界
• 华为重庆环卫项目提出“推荐取用量提示”及“累计取用量”功能，属个性化需求。
• 肖姐曾提议可能将其纳入标准产品，但团队对其是否应标准化存在疑问。
• 张总建议将此类定制化页面设计做成可配置开关，置于后台管理界面。
AI 智能结算台支付对接
• 需对接支付宝“当面付”碰一碰功能，属三权项目需求。
• 支付通过统一后端接口调用，前端仅需触发，支持微信与支付宝自动识别，无需重复开发。
• 所有消费类设备（含绑盘机）需适配该支付能力，但绑盘机上的码非消费码，不支持消费
  功能。
菜品识别算法演进
• 当前使用嬴哥提供的第三方算法进行菜品识别。
• 未来计划切换至自研 AI 模型识别，但因优先级低，暂不排期，仅保留事项记录。

离线订单与设备管理
离线订单手动同步功能
• 消费机需增加离线订单的手动同步管理功能，用于处理未上传的交易数据。
• 此为补充分支流程，需结合 206 等典型离线场景，与市委等业务方沟通确认完整方案。
• 发言人 1 强调产品设计需系统化，避免“想到一点做一点”，导致团队反复返工。

人员信息同步架构问题
卡脸割裂导致同步异常
• 历史遗留问题：人员信息拉取时，卡片与人脸分别拉取，形成两次独立操作，逻辑割裂。
• 双屏消费机能通过清仓服务端兼容实现基本同步，但 AI 识别秤、称重设备等尚未适配。
• 存在信息覆盖风险，需重新梳理完整同步逻辑。
离线锁卡状态同步机制
• 当前仅同步卡号，未同步卡状态（如是否锁定）。
• 提出改进方案：通网时同步卡状态位（0/1），离线刷卡时消费机可本地判断并拒绝已锁卡
  交易。
• 离线期间产生的已锁卡消费记录，应仍能上传至云端，并在订单异常列表中标记，而非直
  接丢弃。
• 当前策略为支付失败即丢弃，导致异常数据无法追溯，存在业务漏洞。
架构与流程可视化要求
• 要求开发侧绘制当前人员同步的系统架构图与业务流程图，明确卡脸同步、锁卡处理、离
  线上报等环节。
• 通过图示暴露逻辑漏洞，便于产品与技术共同评审并制定解决方案。

待办事项
• @发言人 2 补充 450/460 机型的逃单功能，完成主流程迁移
• @发言人 2 实现消费机离线订单手动同步功能，并与业务方对齐 206 场景完整方案
• @发言人 2 梳理人员信息同步逻辑，绘制系统架构图与业务流程图
• @发言人 2 制定锁卡状态在离线场景下的同步与异常订单处理方案
• @发言人 2 提供重庆华为项目与现有系统的界面截图，用于需求对齐

会议分析
• 核心主旨: 围绕保盘系统在餐厅现场的实际使用痛点，完善分支流程、支付对接、离线能力
  及底层人员同步机制，提升产品健壮性与交付效率。
• 逻辑分析: 讨论从具体功能缺失（如逃单、退款）出发，逐步深入到底层架构问题（卡脸同
  步割裂），体现出“现象→功能→架构”的排查逻辑。尤其在离线锁卡场景中，通过正向
 （本地拒刷）与反向（异常上报）两个维度构建闭环处理思路。
• 关键重点: 1. 分支流程必须系统化设计，避免碎片化开发；2. 支付接口需统一抽象，支持
  多平台免重复接入；3. 离线业务必须保障状态同步与异常可追溯，不能简单丢弃数据。
• 潜台词与趋势: 团队已意识到过往“救火式”开发模式不可持续，开始强调架构文档化与流
  程可视化。未来产品迭代将更注重基础能力复用与边缘场景覆盖，AI 能力（如菜品识别）
  虽被提及但短期内难落地，重心仍在夯实核心链路。