医院数字食堂自选称重餐线技术拆解：电子秤接入、AI识别与多支付融合

医院食堂档口从按份卖、人工计价升级为按克卖、AI识别自动计价、多支付融合,本质上是把前端硬件、后端视觉推理、收银支付与数据中台打通的一条端到端链路。本文从技术视角,拆解自选称重智慧餐线的整体架构、关键模块与典型实现。一、整体架构自选称重智慧餐线在系统层面通常划分为四层:硬件接入层、视觉推理层、计价结算层、数据中台层。硬件接入层负责电子秤、AI摄像头、结算屏、刷卡/扫码设备的协议对接;视觉推理层负责菜品识别与重量读取;计价结算层负责按克累加、调取单价、调用支付通道;数据中台层负责订单沉淀、客流统计、营收分析与上游业务系统对接。从部署形态看,常见的方案有边缘部署与云端推理两种。边缘部署将识别模型放在档口的边缘网关,延迟低、不依赖公网;云端推理把识别请求发回中心机房,模型统一管理、迭代灵活。医院场景对稳定性要求高,主流方案倾向边缘为主、云端为辅的混合部署。二、电子秤接入电子秤是自选称重餐线的计量源。医院场景对精度的要求通常到克级,主流厂商选择串口或蓝牙协议对接,数据上传频率一般在10Hz以上,以保证托盘放下瞬间能稳定读取。常见的数据格式包括重量单位校验位,网关侧做协议解析、去抖、单位归一化后,推送给计价服务。下面是一段典型的电子秤接入代码(Python伪代码,展示协议解析与重量归一化流程):# -*- coding: utf-8 -*- 电子秤接入:串口读取 协议解析 重量归一化 import serial import threading import time class WeighingScale: 简易电子秤接入,假设协议: STX 重量(5位)单位(2位)ETX STX b\x02 ETX b\x03 def __init__(self, portCOM5, baud9600, callbackNone): self.ser serial.Serial(port, baud, timeout1) self.callback callback self._stop False def start(self): t threading.Thread(targetself._loop, daemonTrue) t.start() def _loop(self): buf b while not self._stop: chunk self.ser.read(1) if not chunk: continue if chunk self.STX: buf b continue if chunk self.ETX: self._parse(buf) buf b continue buf chunk def _parse(self, payload: bytes): try: text payload.decode(ascii, errorsignore) weight int(text[:5]) / 1000.0 # 单位:g - kg unit text[5:7] if unit.strip().lower() ! kg: return if self.callback: self.callback(round(weight, 3)) except Exception as e: print(f[scale] parse error: {e}) def stop(self): self._stop True self.ser.close() if __name__ __main__: def on_weight(w): print(f[scale] weight {w} kg) scale WeighingScale(portCOM5, baud9600, callbackon_weight) scale.start() try: while True: time.sleep(1) except KeyboardInterrupt: scale.stop()三、AI识别与计价AI摄像头负责在托盘放下的瞬间识别菜品种类。模型通常基于YOLO/CNN等检测网络,在边缘GPU或NPU上完成推理。识别结果与电子秤读数一起送入计价服务,服务按菜名→单价→重量→总价的链路完成累加,并在结算屏上渲染。整个识别计价渲染的端到端延迟通常控制在2秒以内。计价服务的核心是一个简单的累加逻辑,但要兼顾识别有错时的手动纠正:阿姨在结算屏上点击修正,系统把纠正后的菜名重新调单价并重算。这一步看似简单,实则是落地医院最看重的功能之一,直接决定了阿姨愿不愿意用、AI识别的小错会不会演变成大问题。四、多支付融合:刷脸/刷卡/扫码结算环节需要对接餐补钱包、实体卡、微信/支付宝/银联等多个支付通道。在医院场景,刷脸扣餐补是最高频的链路——人脸识别通过后,系统从该职工的餐补账户扣款;扣款成功则推送结算完成,扣款失败则回退到刷卡或扫码通道。下面是刷脸扣餐补的伪代码流程,展示了多支付通道的协同逻辑:# -*- coding: utf-8 -*- 刷脸扣餐补 多支付通道协同 import time from typing import Optional class PaymentResult: def __init__(self, ok: bool, channel: str, amount: float, msg: str ): self.ok ok self.channel channel self.amount amount self.msg msg def pay_by_face(user_id: str, amount: float, subsidy_balance: float) - PaymentResult: 刷脸扣餐补优先,余额不足则返回失败让上层走其他通道 if amount 0: return PaymentResult(False, face, amount, 金额异常) if subsidy_balance amount: return PaymentResult(False, face, amount, 餐补余额不足) # 真实场景这里调人脸识别SDK 餐补钱包扣款RPC time.sleep(0.3) # 模拟扣款耗时 return PaymentResult(True, face, amount, 扣款成功) def pay_by_card(user_id: str, amount: float) - PaymentResult: 实体卡支付 time.sleep(0.5) return PaymentResult(True, card, amount, 刷卡成功) def pay_by_qr(amount: float) - PaymentResult: 扫码支付(微信/支付宝/银联) time.sleep(0.6) return PaymentResult(True, qr, amount, 扫码成功) def settle(user_id: str, amount: float, subsidy_balance: float) - PaymentResult: 结算主流程:按优先级尝试各通道 channels [ (face, lambda: pay_by_face(user_id, amount, subsidy_balance)), (card, lambda: pay_by_card(user_id, amount)), (qr, lambda: pay_by_qr(amount)), ] for name, fn in channels: result fn() if result.ok: return result print(f[settle] {name} failed: {result.msg}, try next) return PaymentResult(False, , 0, 所有支付通道均失败) if __name__ __main__: res settle(user_1001, 18.5, subsidy_balance120.0) print(fchannel{res.channel}, ok{res.ok}, msg{res.msg})五、数据中台与上游对接每一笔结算都会沉淀到数据中台,形成订单流水、客流统计、菜品销量等多维数据。这些数据向上游的HIS、HRP、财务系统开放接口,同时为食堂的经营驾驶舱提供实时看板。中台的稳定性和开放性,直接决定了自选称重餐线能不能从单点改造升级为全场景闭环的一部分。六、踩坑与展望实际落地中常见的几个坑:一是电子秤与AI摄像头的时钟同步,识别与称重的时序错位会导致菜品重量对不上;二是刷脸通道在网络抖动时容易卡顿,需要做好本地兜底;三是后台数据模型要预留识别纠正字段,否则阿姨手动改的菜永远不入库,数据会越积越脏。展望未来,自选称重餐线会进一步与营养膳食模块打通——按克吃饭的每一餐自动累加营养素摄入,为患者陪护、慢病管理人群提供按需配餐的数字处方。届时,医院食堂就不只是吃饭的地方,而是后勤数字化、临床营养、食安监管共同交织的关键节点。好伙狮数字食堂基于上述架构,在多家三甲医院落地了自选称重智慧餐线方案,把电子秤接入、AI识别、刷脸支付、营收分析整合进统一平台,与病房订餐、营养膳食、进销存、智慧食安等模块形成全场景闭环,帮助医院在档口环节率先完成数字化升级。