给医院食堂做结算系统和给普通餐饮门店做收银在工程层面是完全两回事。普通收银系统面对的是单品条码扫描、支付、打印小票这条单链而食堂多模式结算系统要同时撑住窗口人工收银、AI视觉识别无感结算、称重传感自动计价、包间挂账消费四个场景的技术栈还得在底层打通卡、码、脸、现金、餐补、积分六种支付通道。去年我们给一家省级三甲医院上线这套系统的时候院方信息科的技术负责人问了一个很关键的问题你们的四种结算模式是在四套独立系统上各自跑还是一套底层引擎统一支撑这个问题问到了架构设计的核心——也是本文要拆解的重点。一、总体架构四条业务线、一套结算引擎好伙狮数字食堂的多模式结算系统在架构上采用业务线分层、结算引擎集中的设计思路。最上层是四条并行的业务线窗口收银业务线、AI视觉识别餐线、称重传感餐线、包间预订消费线。每条业务线有自己的前端交互逻辑和硬件驱动层但它们共享中层的统一结算引擎和最底层的数据仓库。统一结算引擎是整个系统的心脏负责接收各业务线上报的消费请求、执行账户扣款按预设规则分配餐补/自费/积分、调取支付网关完成第三方支付、生成结算流水写入数据仓库、实时推送到经营数据看板。引擎的设计要点是事务一致性和低延迟——一条消费请求从上报到扣款完成P99延迟控制在两百毫秒以内并发能力支撑午高峰四位数级别的TPS。这种架构的好处是当食堂需要增加新的消费模式时只需开发对应的业务线模块、接入结算引擎的标准化API底层账户逻辑和支付通道完全复用。一家医院的食堂从只有窗口收银升级到窗口加AI餐线技术侧的改造周期大约在两周左右。二、AI小碗菜视觉识别从图像到菜品的全链路拆解AI视觉识别结算的技术链路可以拆成四个阶段菜品注册、图像采集、特征提取与匹配、结果输出与结算触发。2.1 菜品注册阶段这是系统的冷启动环节。后厨每出一道新菜将其装碗后放到菜品录入终端顶部及侧面多角度摄像头拍摄菜品图像。系统使用的是端侧推理云端训练的混合架构端侧设备搭载轻量级推理模型做实时处理云端负责离线批量训练和模型迭代。图像采集后进入特征提取管线。这里用的是基于卷积神经网络的菜品识别模型骨干网络在ResNet架构基础上做了面向食堂场景的定制优化——重点是提升对相似菜品比如红烧肉和糖醋排骨在特定光照下的视觉混淆的区分能力。模型输出的不是简单的分类标签而是一组多维特征向量包括颜色直方图特征、纹理特征通过Gabor滤波提取局部纹理模式、形状描述子、以及全局语义特征。这组特征向量构成了菜品的视觉指纹存储到特征库中。菜品注册还包含非视觉属性菜品名称、价格、热量千卡、蛋白质克数、碳水化合物克数、是否为清真/素食标签等。这些属性在结算环节随识别结果一并输出。2.2 顾客端识别结算流程顾客取完小碗菜走到结算区时顶部摄像头以约三十帧/秒的速率连续采集托盘区域图像。系统不会拍一张就下结论而是对连续多帧图像做时序融合——同一碗菜在不同角度、不同帧的识别结果加权投票有效避免单帧误判。特征匹配环节的效率瓶颈在检索。一个食堂的菜品特征库可能包含数百道菜如果暴力比对会拉高延迟。系统采用的是近似最近邻检索配合分层索引的策略先用全局语义特征做粗筛把候选集缩小到二十个以内再用细粒度特征做精排。这个策略在实际部署中特征匹配环节的耗时控制在五十毫秒以内。识别出菜品后系统同步调取价格和营养数据汇总金额触发结算引擎执行扣款。整个链路——从顾客把托盘放到结算区到屏幕显示总金额——端到端耗时约零点五至零点八秒。识别准确率在标准光照条件下稳定在百分之九十五以上对菜品外观的合理变化同一天内不同批次菜品的色差有较好的鲁棒性。三、自选称重传感精度、采样、防作弊称重结算的技术难度不在能称而在称得准、称得快、不被干扰。每个菜盘底座内嵌的是电阻应变式称重传感器量程覆盖零到五千克精度分辨率达到±1克。信号经过仪表放大器放大后进入高精度模数转换器采样率设置在每秒八到十次。这个采样率看上去不高但因为称重是无感操作——顾客取菜、放回菜盘的整个过程大约是几秒钟——在时间维度上有足够的采样点做均值滤波。数据处理上做了三层过滤。第一层是硬件低通滤波滤除高频电路噪声。第二层是滑动窗口均值平滑用连续十次采样的均值作为当前读数把瞬时波动压到±0.5克以内。第三层是变化检测——系统不关心绝对重量只关心此次取菜行为的重量增量。具体做法是监控托盘重量的实时序列用一阶差分检测重量变化事件截取事件前后的稳定读数差值作为取菜克数。温度漂移是称重设备在热食环境中最大的精度杀手。传感器在二十摄氏度环境下标定但餐线周围的温度可能到四十到五十度。系统用两种手段对抗温漂硬件层面在传感器桥路中配置温度补偿电阻软件层面根据内置温度传感器的读数做二次线性补偿。实测环境下补偿后的称重误差在±2克以内满足计价精度需求。防作弊机制处理两个场景一是托盘频繁拿起放下的试探行为系统通过变化速率检测区分正常的取菜动作和作弊动作二是托盘重量累积——在连续取菜过程中系统每次变化检测后自动清零基准确保每一次取菜的克数计算都从正确的起点开始。四、卡码脸统一核身多通道身份认证与钱包清算这个模块的技术价值不在于每一种核身方式本身——刷IC卡、扫码、刷脸在各自领域都是成熟技术——而在于如何把它们抽象为一个统一的身份认证层并在认证之后正确路由到正确的钱包账户。架构上卡码脸统一核身模块是一个位于业务层和账户层之间的认证网关。上游业务线窗口终端、AI结算台、称重餐线、包间预订发来一个支付请求携带核身凭据——可能是IC卡UID、微信付款码Token、人脸特征向量、或者员工工号。认证网关做三件事凭据类型识别、凭据验证、账户映射。凭据类型识别根据请求字段自动判断核身通道。IC卡走Mifare卡号验证密钥校验刷码走微信或支付宝的付款码预授权接口拿到授权后完成Token置换刷脸走人脸识别算法比对活体检测通过后将人脸特征映射到职工工号。账户映射是关键的架构设计。同一个职工可能有多套凭据——一张IC卡、一个微信OpenID、一个支付宝UserID、一组人脸特征。这些凭据在系统中都映射到同一个职工钱包账户而该账户内部不是单一余额而是多余额池结构餐补子账户企业充值专款专用、自费子账户绑定微信/支付宝、消费时自动划扣、积分子账户按消费额累积、可用于兑换。扣款时结算引擎按预设规则做路由先扣餐补余额、餐补不足部分走自费支付、积分抵扣从积分池扣除。一笔消费可能从三个子账户分别扣款但对用户来说就是一次支付动作。这套多钱包清算架构的难点在于事务一致性——三个子账户的扣款要么全部成功、要么全部回滚不能出现餐补扣了但自费支付失败的情况。实现上采用的是分布式事务中的最终一致性模式扣款操作以结算流水为唯一事务锚点子账户扣款失败时触发补偿回滚。五、技术选型的几个决策点如果有同行正在做类似系统的技术选型几个决策点值得重点考虑。AI推理是端侧还是云端我们的经验是混合部署最合适。端侧对实时性要求高的识别环节顾客结算时的特征匹配GPU或NPU加速的边缘设备足以胜任延迟低且不依赖网络稳定性。云端做模型训练和定期下发更新不参与实时推理链路。这种架构也避免了食堂高峰期网络抖动导致结算系统不可用。称重传感器选型上电阻应变式在成本精度比上最理想。电磁力平衡传感器精度更高但成本是前者的数倍在食堂场景没有必要性。关键是选型后做好温度补偿和定期校准的设计。支付网关对接时建议在技术架构中预留多通道的抽象接口。微信和支付宝的支付接口版本会迭代——半年前微信支付升级了付款码接口的签名算法如果系统只针对具体接口做硬编码而没有抽象层升级的工程量和风险都会成倍放大。六、总结食堂多模式结算系统的技术复杂度不在于某个单一功能的深度而在于多条业务线在同一套底层引擎上的整合。AI视觉识别解决的是看到菜就知道是什么的问题称重传感解决的是夹了多少克算多少钱的问题卡码脸核身和多钱包清算解决的是谁付的、从哪个账户出的问题。三个子系统各自有技术纵深但要联合作战才构成一套可落地的堂食消费多模式方案。好伙狮数字食堂在这个架构上的实践已经跑通了多个医院食堂的交付验证技术方案从原型到稳定运行经历了一年以上的迭代打磨。写这篇文章的目的是让同行和潜在客户的技术团队能够从架构层面理解这套系统的设计逻辑——不是黑盒每一层都可以拆开来看。