护士、医生、患者与食堂
青耕是大学期间参与的团队原型，围绕术后食疗场景设计不同角色入口：护士采集图片，医生查看与复核，患者进入点餐，食堂管理餐品和订单。这个场景要求算法输出能进入后续操作。我关注的是模型训练、推荐小程序和前后端衔接，让识别结果有具体的使用位置。
图像输入与识别结果
舌图通过 YOLOv5 推理生成类号，再映射成界面可显示的描述；小程序上传图片并读取服务返回的 message。项目另有 29 项问卷的独立规则入口，返回 result1。图像和问卷承担各自的信息任务，两条实现保持独立，没有将它们表述为已验证的融合模型。
推荐与排除规则
推荐逻辑先从体质对应表生成候选，再根据既往史和排除表移除不适用条目。把生成和排除分开，为后续业务条件留下明确的位置，也便于解释某一条推荐为什么出现或被移除。这里形成的是原型规则流程，规则来源和医学效果仍需要专业核验；合成餐单用于说明机制。
小程序里的使用过程
采集端选择图片、上传到 Flask 服务，接收识别描述并回显；推荐小程序按床号请求列表，再将条目带入点餐界面。我承担的工作由模型训练延伸到这些可操作步骤，在服务字段和界面状态之间建立对应关系。原型的价值在于呈现完整任务路径，而非只保留一张训练曲线。
算法服务和规则接口
识别服务处理图片与标签映射，问卷使用独立规则函数，推荐服务读取 CSV 资料与排除条件，多角色入口由团队分别建设。明确链路分工有助于定位问题和协同实现。案例展示归档接口与设计关系；线上可靠性、并发患者隔离和完整医生审批不由这些结构直接证明。
训练记录与指标
两组训练归档分别保存 100 轮结果、配置、权重与图表，末轮 mAP@0.5 为 0.40296 和 0.43615。这些数字是检测实验指标，不能转换为临床准确率。图中训练记录按各自口径呈现；现有数据副本存在训练与验证重叠，历史划分未核，因此不据此宣称泛化效果或模型提升。
我负责的模型与小程序
我负责舌象模型训练、食疗推荐小程序实现与前后端衔接，团队共同建设多角色系统。这段经历让我从训练参数走向产品接口：谁会读结果，下一步怎样使用，哪些规则需要解释。项目保留为大学团队原型；承担真实医疗场景责任，还需要专业复核、独立数据评价和完整运行验证。
