作为医院信息科，评估一套食堂结算系统时，我们最关心的从来不是"能不能刷脸"，而是三件事：识别准不准、账目清不清、和现有系统能不能接得上。最近我们对接了一家数字食堂服务商，把AI菜品识别结算台跑通了，本文把这个过程中的技术要点和踩坑记录下来，供同行参考。
整体架构：识别、计价、支付三段解耦
AI结算台的核心链路可以拆成三段：视觉识别（认菜）、计价聚合（算账）、多钱包支付（收钱）。三段之间通过统一的订单结构解耦，任何一段的升级都不影响其余部分。
sequenceDiagram
participant U as 就餐者
participant V as 视觉识别模块
participant O as 计价聚合服务
participant W as 多钱包支付
U->>V: 托盘放入识别区
V->>V: 摄像头采集 + 目标检测
V->>O: 菜品ID列表
O->>O: 拉取价格 + 汇总 + 营养计算
O->>U: 返回总价与营养成分
U->>W: 选择核身方式(卡/码/脸)
W->>W: 钱包清分 + 扣款
W-->>O: 支付回调
O-->>U: 出票完成视觉识别：检测 + 分类两段式
识别模块的思路并不复杂，本质是"检测到菜品区域，再对区域做分类"。检测端负责在托盘图像中定位每一个碗碟的位置，分类端把裁剪出来的小图与菜品图像库做匹配。菜品上新时需要先做一次"拍照学习"，把新菜的样张录入特征库，之后才能稳定识别。
# 伪代码：识别与计价聚合流程
def settle(tray_image):
dishes = detector.detect(tray_image) # 1. 检测碗碟区域
order = []
for region in dishes:
dish_id = classifier.match(region) # 2. 匹配菜品
price = price_service.get(dish_id) # 3. 拉取价格
nutrition = nutrition_service.get(dish_id)
order.append({"id": dish_id, "price": price, "nutrition": nutrition})
total = sum(item["price"] for item in order)
return order, total这里有个容易踩的坑：同一道菜，不同批次的外观差异可能很大（比如红烧肉的色泽、青菜的码放），如果只用单一角度采集的样张，识别准确率会明显下降。我们当时的做法是，让后厨在上新时多角度、多批次拍照，扩充特征库，实际识别准确率才稳定下来。
多钱包支付：清分逻辑是重点
比识别更考验系统设计的是支付。医院食堂的资金来源很杂：职工餐补、家属充值、院内挂账、签单......如果把这些钱都记在一个账户里，月底对账就是灾难。这套系统的做法是建立多钱包体系，不同来源的资金进入不同钱包，支付时按规则自动清分。
从信息科视角看，这个设计有两个好处：一是账目可追溯，每一笔消费都能定位到具体钱包和来源；二是对接清晰，餐补钱包可以和院方的HR数据、补贴政策做接口联动，职工身份一变，钱包规则自动调整。
# 钱包清分伪代码：按优先级扣款
WALLET_PRIORITY = ["subsidy", "recharge", "reward", "credit"]
def deduct(user, amount):
for wallet in WALLET_PRIORITY:
balance = get_balance(user, wallet)
if balance >= amount:
debit(user, wallet, amount)
return {"wallet": wallet, "amount": amount}
debit(user, wallet, balance)
amount -= balance
raise InsufficientBalance("多钱包余额不足")与现有系统的对接
这套结算系统最终要落到医院信息化体系里，绕不开两件事：一是身份统一，二是数据互通。职工的人脸特征、卡号、餐补额度需要与院内身份系统对齐；结算流水则要能回流到财务或后勤平台做对账。我们评估的重点之一，就是对方是否提供标准化的接口，而不是要求二次开发去"硬接"。
总结一下，如果你们医院也在评估AI结算台，建议重点关注三个维度：识别端的特征库维护机制、支付端的多钱包清分规则、以及接口的标准化程度。这三块做扎实了，系统才不是"上得去、用不好"的摆设。本文代码部分由AI辅助生成，已人工验证。