v0.3 饮食识别与体重监测：现有页面复用需求

最新用户决定：PC以指定演示系统zhct.yyangpt.cn/dist为准，优先复用已有页；手机AI运动营养师不改，仅作示意。已登录真实页面，确认store已有“膳食监控→个体监控→查看分析→膳食记录”，因此不新建菜单或一级页面，仅局部补充明细按钮与弹窗。

会议业务目标继续有效：100–200人持续3–4个月，所有进食照片与每周体测，最终饮食/体测两表；指标为能量、蛋白质、锌、镁（Jack已确认）。本轮完成设计原型，生产DoR: BLOCKED。

正确PC来源：store/public/static/src/view/dietaryMonitoring/personalMonitor/foodRecord.vue与personalMonitorCheck.vue；已有StaffInfo/FoodRecord接口及head_img头像字段。前两版ai_store式工作台、独立采集页不再指导本次实施。

系统Use Case Map：受试者沿既有手机上传→后台自动识别→可信跨系统人员映射→store既有膳食记录页查看三餐/加餐原图与结果→与既有体测表关联。自动关联不等于直接共用两套系统的人员ID，必须真实核验映射。

通用约束：角色为受试者、获授权项目人员；登录/组织/人员/图片权限在服务端验证；重试同一消息或照片事件不重复记餐；多张图与多次上传保留关联；非食物/普通咨询不算摄入；餐次不明待归餐；估计分量明示、缺失指标null不填0。后端4保留夜宵，三餐组内加餐/零食类型单独保存。真实性、准确率样本量及阈值、跨系统身份映射、数据留存、正式XLSX模板和云效负责人均待评审。

性能预算尚未批准，原型延迟不是SLA；真实并发、p95、错误率、识别准确率与导出耗时仍需定义和实测。设备侧开发与新手机页面不在范围。人物照片复用head_img，食物库图file_path不得冒充用户上传原图。

UC-DWM-001 沿用现有入口发送图片

Use Case ID: UC-DWM-001；版本v0.3；优先级P0；DoR: BLOCKED（相关未决项）。

参与者/范围：受试者/现有手机功能；限定已授权组织及对应人员。触发：受试者在已有AI问答、饮食或其他已具备图片能力的入口发送图片。

前置：已有登录与可信人员关系；不满足进入授权/映射异常，禁止写入错误人员。成功后置：原始消息/图像与处理状态可按人员回读；失败后置：原始图/消息/已有有效记录保留，不伪成功。

主流程

M1 受试者使用现有AI运动营养师的图片入口，手机页面与操作不改。
M2 沿用已有发送；用户可在文字中说明餐次与进食时间，已有饮食入口沿用mealId和selectDate上下文。
M3 图片/消息成功后由后台自动触发识别，不再让用户进入独立采集页。
M4 用户仍停留在原问答/饮食页面，显示现有回执及简洁处理状态。

分支流程

A1@M2 AI问答入口没有餐次上下文时，使用明确消息语义；不必每次强填新表单。
A2@M2 非饮食图片走原问答逻辑；用户上传锻炼/体检/其它照片不得一律记录成饮食。

异常/恢复

E1@M1 现有图片上传失败按原路径重试，不新增第二套上传器。
E2@M3 识别失败保留已上传原图/消息，不能要求重新上传。

恢复流程

R1@E1 复用上传失败反馈及重试。
R2@E2 复用消息/图片ID重试识别；不重复新增餐记录。

业务规则

BR-01 上传能力必须复用，入口位置未锁定；原型示例放现有AI问答。
BR-02 客户端不重新实现识别，也不要求手动选人。
BR-03 选择图片与真正发送不同；使用已发送消息/已提交饮食记录作为幂等识别事件，避免未发送草稿入账。

页面/API/数据

PAGE-DWM-01：现有AI运动营养师页面（本任务零改动，仅示意）；复用upload/image及现有消息发送；新增算法结果落餐契约需评审。数据对象：既有File/Message/User/Meal关联；采用既有结构向后兼容扩展。

验收标准

AC-DWM-101 保持原首页/主导航/AI问答布局，在已有发送操作后自动处理。
AC-DWM-102 普通文字问答与非食物图片不生成饮食记录。
AC-DWM-103 重复事件/重试只更新同一记录；已有图片上传能力不新增重写。

测试矩阵

E2E-DWM-V02-001 依上述AC验证现有界面与新增展示
API-DWM-V02-001 服务端事件幂等、权限、归餐及落库契约（待真实实施）

非功能：继承通用权限/幂等/空值/准确率/性能约束；生产均待测。通知：[不适用：没有新增真人通知要求]。新手机功能：[不适用：用户明确手机不改]。评审人及云效责任人待明确。

UC-DWM-002 后台自动识别并关联餐次

Use Case ID: UC-DWM-002；版本v0.3；优先级P0；DoR: BLOCKED（相关未决项）。

参与者/范围：系统与获授权PC人员；限定已授权组织及对应人员。触发：收到既有上传成功且消息发送成功/饮食记录提交成功事件。

主流程

M1 接收现有图片/消息ID与可信账号/组织上下文，解析是不是饮食记录。
M2 自动识别菜品、估计分量，匹配菜品库或食物成分库，产出四指标。
M3 确定实际进食日、餐次组、正餐/加餐/零食子类型及时间，并记录归餐依据。
M4 自动关联已有账号对应人员，保存原图引用、识别结果、状态及版本。
M5 PC立即能查到记录和处理状态；识别完成后展示明细，无需逐条人工点启动。

分支流程

A1@M2 菜品库未命中回退食物成分库；分量与营养成分不明确时标估算/缺失。
A2@M3 前端1/2/3餐次组包含对应加餐；后端4仍为夜宵。零食/加餐作为子类型，不覆盖现有枚举。
A3@M3 日期、餐次或食物是否实际摄入不明，进入待归餐/待补充；普通食物咨询不直接作为实际进食。

异常/恢复

E1@M2 算法超时失败，记录状态可见，保留原图与上传时间。
E2@M4 账号没有唯一人员映射，进入身份异常；不能随便绑定A/B。
E3@M3 “昨天/补记/仅图片”缺依据时不能只用上传时刻当实际用餐时刻。

恢复流程

R1@E1 用同一事件重试识别并保留attempt版本。
R2@E2 有权人员核对异常映射后恢复处理；常规数据不人工选人。
R3@E3 后台异常修正日期/餐次/类型/时间，记录原因与前后值。

业务规则

BR-04 用户确认四指标为能量、蛋白质、锌、镁；份量为估计时显式标识。
BR-05 同餐多次上传、同次多图、多食物项分别留存关联，不能以最后一张覆盖。
BR-06 不能把AI候选当实测，不能把缺失填0，不能把普通食物咨询当已吃记录。

页面/API/数据

PAGE-DWM-02：PC饮食上传明细状态；沿用RunAgent/既有算法流程，增加后端事件接续与持久化；不要新建上传API。数据对象：Message→Image→RecognitionResult→MealItem；采用既有结构向后兼容扩展。

验收标准

AC-DWM-201 发送后自动进入识别，无需手动启动；失败在PC仍可见原图。
AC-DWM-202 午餐+午加餐+午零食属于午餐组但为独立条目；夜宵仍为4。
AC-DWM-203 明确上下文优先；冲突或不明保留待归餐，不硬归早餐/午餐/晚餐。

测试矩阵

E2E-DWM-V02-002 依上述AC验证现有界面与新增展示
API-DWM-V02-002 服务端事件幂等、权限、归餐及落库契约（待真实实施）

UC-DWM-003 复用体重与体成分既有链路

Use Case ID: UC-DWM-003；版本v0.3；优先级P0；DoR: BLOCKED（相关未决项）。

参与者/范围：受试者/现有手机功能；限定已授权组织及对应人员。触发：受试者按既有方式测量/记录体重体成分。

主流程

M1 从现有体重管理/设备链路录入或同步，不新建专题体测表单。
M2 保留实际测量时间、来源、体重及设备实际提供的体成分。
M3 按既有人员映射关联，在现有体测管理及后续导表查看。

分支流程

A1@M2 仅体重秤不生成体脂；同周多次分别保留。

异常/恢复

E1@M2 设备断连或录入错误遵循既有恢复机制。

恢复流程

R1@E1 现有界面重试/修正；未验证的设备接入不承诺可用。

业务规则

BR-07 此轮改动重点是照片识别与PC展示，不扩大为体测重构。

页面/API/数据

PAGE-DWM-03：现有体重管理；复用user.userWeight/setWeight、wellandScale/add等已有入口，逐项验证。数据对象：既有测量事件/人员映射；采用既有结构向后兼容扩展。

验收标准

AC-DWM-301 现有体重入口与调用保持，独立专题体测页不再作为当前设计。
AC-DWM-302 未测体成分仍为空；每周频率不覆盖多次事件。
AC-DWM-303 真实设备接入仍需原项目验证。

测试矩阵

E2E-DWM-V02-003 依上述AC验证现有界面与新增展示
API-DWM-V02-003 服务端事件幂等、权限、归餐及落库契约（待真实实施）

UC-DWM-004 PC按人员照片与三餐加餐查看上传明细

Use Case ID: UC-DWM-004；版本v0.3；优先级P0；DoR: BLOCKED（相关未决项）。

参与者/范围：系统与获授权PC人员；限定已授权组织及对应人员。触发：项目人员打开现有人员工作台的饮食明细。

主流程

M1 从store演示系统现有个体监控进入人员分析，复用staff_uuid、personInfo.head_img和日期上下文。
M2 沿用膳食记录原图表和三餐卡片；在原页点击新增上传明细入口。
M3 明细弹窗显示每次上传原图、时间、来源，餐次内区分正餐/加餐/零食，夜宵/待归餐另列。
M4 查看各食物名称、估算份量、能量/蛋白质/锌/镁；点击原图放大。
M5 按当前筛选查看/导出；异常重试可见，新的业务纠错写入不在本原型范围。

分支流程

A1@M1 复用已存在的head_img；缺照片按原头像fallback显示，不新增头像上传。
A2@M2 加餐/零食独立条目可筛选，不并成三条日汇总；同餐多次全部保留。

异常/恢复

E1@M1 无权限不展示该人员详情与图片；人物照片和食物照片独立校验权限。
E2@M3 图片读取失败显示可重试状态，保留其它元信息。
E3@M5 更正日期/餐次/类型须原因、原值、新值和版本，防并发覆盖。

恢复流程

R1@E1 恢复明确授权后再加载。
R2@E2 重新取得受控图片引用，不伪装图片已显示。
R3@E3 重新读最新版本后修正；按正确日期重新查询可定位。

业务规则

BR-08 常规人员关联来自账号/业务映射，不要求上传后人工挑人。
BR-09 PC必须同时有人员照片位与对应上传原图；身份不是根据图片人脸判断。
BR-10 已有页能满足则复用：不新建页面或侧栏菜单，仅补明细按钮和弹窗。

页面/API/数据

PAGE-DWM-04：store 膳食监控→个体监控→查看分析→膳食记录（既有页局部补充）；复用/p/Ontoanalysis/StaffInfo与/p/Ontoanalysis/FoodRecord；新增明细契约保持原结构兼容。数据对象：PersonnelPhoto + MealGroup + IntakeEvent + FoodItem；采用既有结构向后兼容扩展。

验收标准

AC-DWM-401 现有store膳食记录页保留头像、日期、三餐卡片；按人查看同一staff_uuid的原图明细。
AC-DWM-402 原页入口打开明细弹窗，多次加餐/零食及多张图不丢失；不新增页面和菜单。
AC-DWM-403 原图缺失、待归餐和识别失败保留可见；重试同记录，缺失值不填0。

测试矩阵

E2E-DWM-V02-004 依上述AC验证现有界面与新增展示
API-DWM-V02-004 服务端事件幂等、权限、归餐及落库契约（待真实实施）

UC-DWM-005 导出按同一人员与餐次关联的饮食和体测数据

Use Case ID: UC-DWM-005；版本v0.3；优先级P0；DoR: BLOCKED（相关未决项）。

参与者/范围：系统与获授权PC人员；限定已授权组织及对应人员。触发：项目人员筛选阶段数据并导出。

主流程

M1 使用当前人员、日期、餐次/类型筛选条件。
M2 导出饮食上传明细，保留加餐/零食、原图引用、状态与四项指标。
M3 按同一人员编号导出既有体测数据，两表可关联。

分支流程

A1@M2 未识别/待归餐/缺分量不得静默丢失；导出保留状态，结果分析需按状态筛选。

异常/恢复

E1@M2 文件生成失败保留条件，禁止旧文件冒充。

恢复流程

R1@E1 按同一快照条件重新生成，遵循权限和版本。

业务规则

BR-11 正常自动识别结果即可展示，不以人工审核为PC可见或导出的前置条件。
BR-12 CSV/XLSX空值不写0，公式注入防护与受控图权限仍适用。

页面/API/数据

PAGE-DWM-05：沿用PC饮食/体测导出；扩展现有导出/报表，禁止新建与原人员餐次脱节的结果表。数据对象：同一人员、日期、上传记录和测量事件；采用既有结构向后兼容扩展。

验收标准

AC-DWM-501 当前PC饮食明细导出包含加餐/零食、上传时间、餐次和状态。
AC-DWM-502 未识别/待归餐不消失；非食物图片不计入饮食表。
AC-DWM-503 体测沿用既有导出能力评估，原型不伪称新增XLSX或设备实现。

测试矩阵

E2E-DWM-V02-005 依上述AC验证现有界面与新增展示
API-DWM-V02-005 服务端事件幂等、权限、归餐及落库契约（待真实实施）

当前交付与边界

store原页复用实施切片。新原型16项验证通过；这不等于所有生产AC完成，体测和正式两表仍按既有系统验证。业务代码仓库未修改；用户只读授权未用于演示环境写入。