手机端：不改
使用现有AI运动营养师的图片入口与发送流程作示意。撤下前轮新增的手机图片交互，不新增表单。
REUSE THE EXISTING PAGE
已有膳食记录页，
就把明细补在这里。
PC复用你提供的演示系统；手机沿用AI运动营养师，不改页面。后台自动识别，上传结果对应到人和每一次进食。
已经登录实页并核对源码
膳食监控 → 个体监控
→ 查看分析 → 膳食记录
已有人员头像、日期筛选、九类分析标签、三餐卡片、食物图、重量与热量。
不新建菜单或一级页面；仅在原页增加上传明细入口及弹窗。
这次明确保留和补充什么
PC端：原页局部补充
保留白色顶栏、蓝色菜单、人员头像、日期和三餐卡片。点击“查看上传明细”，再看原图和各项数据。
后台：自动识别与对应
识别食物和四项营养，关联人员、日期和餐次。加餐、零食是独立上传；异常保留状态，不强行猜测。
看同一个页面的局部变化
顶部可切换“已有页面结构 / 查看局部补充”；三餐卡片结构保留。所有内容为合成样例，未修改演示环境。
两类用户流程
上传沿用原操作；PC在已有膳食记录内查看。保持自动识别和异常保留。
现有AI运动营养师上传与发送，后台自动处理；手机页面不改。
用例与执行说明
编号继续保留，PC实施位置更新为实际演示系统的已有页面。
UC-DWM-001沿用现有入口发送图片查看流程与验收 ＋
受试者在已有AI问答、饮食或其他已具备图片能力的入口发送图片。
主流程
- M1 受试者使用现有AI运动营养师的图片入口，手机页面与操作不改。
- M2 沿用已有发送；用户可在文字中说明餐次与进食时间，已有饮食入口沿用mealId和selectDate上下文。
- M3 图片/消息成功后由后台自动触发识别，不再让用户进入独立采集页。
- M4 用户仍停留在原问答/饮食页面，显示现有回执及简洁处理状态。
异常与恢复
- E1@M1 现有图片上传失败按原路径重试，不新增第二套上传器。
- E2@M3 识别失败保留已上传原图/消息，不能要求重新上传。
- R1@E1 复用上传失败反馈及重试。
- R2@E2 复用消息/图片ID重试识别；不重复新增餐记录。
确认时重点看
- 保持原首页/主导航/AI问答布局，在已有发送操作后自动处理。
- 普通文字问答与非食物图片不生成饮食记录。
- 重复事件/重试只更新同一记录；已有图片上传能力不新增重写。
正式开发待确认 Q01/Q03/Q04/Q05/Q06/Q07/Q08（按用例相关项评审）；v0.3补充跨系统人员映射P0
UC-DWM-002后台自动识别并关联餐次查看流程与验收 ＋
收到既有上传成功且消息发送成功/饮食记录提交成功事件。
主流程
- M1 接收现有图片/消息ID与可信账号/组织上下文，解析是不是饮食记录。
- M2 自动识别菜品、估计分量，匹配菜品库或食物成分库，产出四指标。
- M3 确定实际进食日、餐次组、正餐/加餐/零食子类型及时间，并记录归餐依据。
- M4 自动关联已有账号对应人员，保存原图引用、识别结果、状态及版本。
- M5 PC立即能查到记录和处理状态；识别完成后展示明细，无需逐条人工点启动。
异常与恢复
- E1@M2 算法超时失败，记录状态可见，保留原图与上传时间。
- E2@M4 账号没有唯一人员映射，进入身份异常；不能随便绑定A/B。
- E3@M3 “昨天/补记/仅图片”缺依据时不能只用上传时刻当实际用餐时刻。
- R1@E1 用同一事件重试识别并保留attempt版本。
- R2@E2 有权人员核对异常映射后恢复处理；常规数据不人工选人。
- R3@E3 后台异常修正日期/餐次/类型/时间，记录原因与前后值。
确认时重点看
- 发送后自动进入识别，无需手动启动；失败在PC仍可见原图。
- 午餐+午加餐+午零食属于午餐组但为独立条目；夜宵仍为4。
- 明确上下文优先；冲突或不明保留待归餐，不硬归早餐/午餐/晚餐。
正式开发待确认 Q01/Q03/Q04/Q05/Q06/Q07/Q08（按用例相关项评审）；v0.3补充跨系统人员映射P0
UC-DWM-003复用体重与体成分既有链路查看流程与验收 ＋
受试者按既有方式测量/记录体重体成分。
主流程
- M1 从现有体重管理/设备链路录入或同步，不新建专题体测表单。
- M2 保留实际测量时间、来源、体重及设备实际提供的体成分。
- M3 按既有人员映射关联，在现有体测管理及后续导表查看。
异常与恢复
- E1@M2 设备断连或录入错误遵循既有恢复机制。
- R1@E1 现有界面重试/修正；未验证的设备接入不承诺可用。
确认时重点看
- 现有体重入口与调用保持，独立专题体测页不再作为当前设计。
- 未测体成分仍为空；每周频率不覆盖多次事件。
- 真实设备接入仍需原项目验证。
正式开发待确认 Q01/Q03/Q04/Q05/Q06/Q07/Q08（按用例相关项评审）；v0.3补充跨系统人员映射P0
UC-DWM-004PC按人员照片与三餐加餐查看上传明细查看流程与验收 ＋
项目人员打开现有人员工作台的饮食明细。
主流程
- M1 从store演示系统现有个体监控进入人员分析，复用staff_uuid、personInfo.head_img和日期上下文。
- M2 沿用膳食记录原图表和三餐卡片；在原页点击新增上传明细入口。
- M3 明细弹窗显示每次上传原图、时间、来源，餐次内区分正餐/加餐/零食，夜宵/待归餐另列。
- M4 查看各食物名称、估算份量、能量/蛋白质/锌/镁；点击原图放大。
- M5 按当前筛选查看/导出；异常重试可见，新的业务纠错写入不在本原型范围。
异常与恢复
- E1@M1 无权限不展示该人员详情与图片；人物照片和食物照片独立校验权限。
- E2@M3 图片读取失败显示可重试状态，保留其它元信息。
- E3@M5 更正日期/餐次/类型须原因、原值、新值和版本，防并发覆盖。
- R1@E1 恢复明确授权后再加载。
- R2@E2 重新取得受控图片引用，不伪装图片已显示。
- R3@E3 重新读最新版本后修正；按正确日期重新查询可定位。
确认时重点看
- 现有store膳食记录页保留头像、日期、三餐卡片；按人查看同一staff_uuid的原图明细。
- 原页入口打开明细弹窗，多次加餐/零食及多张图不丢失；不新增页面和菜单。
- 原图缺失、待归餐和识别失败保留可见；重试同记录，缺失值不填0。
正式开发待确认 Q01/Q03/Q04/Q05/Q06/Q07/Q08（按用例相关项评审）；v0.3补充跨系统人员映射P0
UC-DWM-005导出按同一人员与餐次关联的饮食和体测数据查看流程与验收 ＋
项目人员筛选阶段数据并导出。
主流程
- M1 使用当前人员、日期、餐次/类型筛选条件。
- M2 导出饮食上传明细，保留加餐/零食、原图引用、状态与四项指标。
- M3 按同一人员编号导出既有体测数据，两表可关联。
异常与恢复
- E1@M2 文件生成失败保留条件，禁止旧文件冒充。
- R1@E1 按同一快照条件重新生成，遵循权限和版本。
确认时重点看
- 当前PC饮食明细导出包含加餐/零食、上传时间、餐次和状态。
- 未识别/待归餐不消失；非食物图片不计入饮食表。
- 体测沿用既有导出能力评估，原型不伪称新增XLSX或设备实现。
正式开发待确认 Q01/Q03/Q04/Q05/Q06/Q07/Q08（按用例相关项评审）；v0.3补充跨系统人员映射P0
剩余确认事项
手机不改、PC已有页复用已经明确；算法和跨系统映射单独确认。
算法分量与四指标如何验证？
后台自动识别并估计，明确标注估算/缺失，人工仅纠错；不强制逐条后台补量。
用户明确自动识别；准确率和分量依据仍需样本验证。
待确认角色：项目负责人+营养负责人 · 正式开发前AI运动营养师账号怎样对应store人员？
正常数据自动关联已有账号，但必须核实ai_app人员ID与store.staff_uuid的可信映射。
两个系统不能仅凭同名或手机号假定同人；缺映射进入异常，不能错绑。
待确认角色：项目负责人 · 正式开发前如何兼容三餐、加餐、零食和夜宵？
保留1/2/3餐次组和4夜宵，追加正餐/加餐/零食类型与独立上传事件；不明时待归餐。
代码事实：移动端1/2/3含加餐，服务端4为夜宵；具体字段与语义抽取优先级待技术/产品锁定。
待确认角色：项目负责人+设备负责人 · 正式开发前最终两张表的行粒度与字段模板？
饮食表按食物项一行（保留餐次ID，可聚合）；体测表按一次测量一行；正式交付XLSX。
人日汇总会丢失食物项和餐次；未知值留空并附缺失原因。
待确认角色：研究/数据负责人 · 正式开发前识别准确率用什么样本与门槛验收？
先建立有标注真实样本集，分别验菜品Top1、四指标误差、拒识与人工工作量。
样本、份量金标准、通过阈值缺失，不能承诺准确率或工期。
待确认角色：算法+营养+测试负责人 · 正式开发前同意授权、留存与项目访问规则？
项目内受试者编号关联，导出最小身份字段；原图私有；离组撤权。
原图、体测、映射是敏感项目数据，需明确留存期与处理权限。
待确认角色：项目负责人+数据负责人 · 正式开发前PC复用现有膳食记录页与头像
用户已明确优先复用；实页已找到，父页用personInfo.head_img，不新建菜单或页面。
改动限定原页明细按钮与弹窗；跨系统人员映射另列P0。
待确认角色：技术负责人 · 正式开发前需求负责人、性能门槛与真实交付日期？
先确认会议日期、云效负责人及准确率路线，再作排期。
下周五不能从当前日期推定；性能预算需评审，云效无唯一负责人暂未写入。
待确认角色：项目负责人+研发负责人 · 正式开发前