当前产品总纲 · 2026-09-10。融合体检、微体检、吃动平衡、每日餐单、实际饮食与持续个性化提醒。个人体检明细不进入本文或共享原型；案例均为独立构造的产品示例。本轮完成材料核验与产品设计，尚未进行设备联调或健康效果验证。
01 产品主线：从知道问题，到每天改变，再回看结果
体检确定长期关注与医疗跟进；微体检观察近期变化；每天的吃动记录解释生活过程；AI据此调整下一餐和下一次行动。
完整流程是：健康评估 → 个人目标 → 每日餐单与活动安排 → 实际吃动记录 → 膳食结构差异 → 个性化提醒与调整 → 阶段复测和专业解读。
用户最终得到三样东西：自己的健康关注清单、今天可执行的吃动安排、看得见依据的阶段变化。AI运动营养师持续参与这个过程。睡眠仍然是每天打开产品的入口；运动营养仍然是核心专业视角。
原先建议的28天可以作为第一轮服务试点周期，20人可以作为候选规模；它们是运营设计，不应限制产品的长期跟进，也不构成28天健康改善承诺。检查、复查的周期以原报告及专业确认要求为依据。
02 三种健康数据各司其职
| 层次 | 主要回答什么 | 数据与来源 | 如何进入服务 |
|---|---|---|---|
| 体检 | 长期需要关注什么；哪些事项要就医/复查 | 医院报告、检验、影像、医生结论及建议 | 原样保存来源和日期；经核对提取关注事项、复查窗口与专业边界 |
| 微体检 | 近期某些指标有何变化；是否需要复核 | 已配置设备的体重、血压、人体成分等实际测量；按条件获得的其他检测 | 保留测量场景、设备和质量；同口径观察，不凭单次变化重写长期结论 |
| 日常状态 | 今天怎么过；有哪些行为线索 | 可穿戴的睡眠/活动、餐食记录、必要的主观反馈 | 用于安排今天、调整下一餐和选择提醒时机 |
“微体检”是低负担、可重复的状态观察服务，不等于把完整体检缩小，也不是靠一台体成分设备测出所有检验项目。血糖、血脂、尿酸等必须有对应检测模块、样本与操作条件；协议有字段不能证明设备能无创测量这些指标。
体检导入后应先分流：
- 医疗跟进：报告明确的进一步检查、专科评估、复查建议，独立成任务。AI帮助记住和整理，不能用餐单、运动或营养品替代。
- 生活方式支持：在适用范围和专业规则内，形成吃动目标与每日安排。
- 资料待核对：OCR不清、单位/参考范围缺失、报告日期与采样日期不同、结论矛盾时，先保留未知，不直接触发个体干预。
上传的个人报告包含明确的专业跟进意见，这说明产品必须保留上述分流。本文不公开具体结果，也不把一个人的体检情况写成所有用户规则。血压、体成分与实验室检验不得因名称相近就拼成无来源的统一分数。
03 两份上禾协议给我们的实际能力
已阅读V3.07检测上传协议和V1.0在线二维码协议。它们支持建立“测量上传—报告关联—本人授权—个人档案”的数据通路，但不是当前已联调成功的证明。
| 协议事实 | 产品设计决定 |
|---|---|
| 检测协议提供体重、人体成分、左右臂血压等字段；其他项目依设备选配上传，缺值可能不传 | 每台设备建立真实能力表；只呈现实测到的项目，缺值不补零 |
| 有血糖类型、血脂四项等字段 | 记录空腹/餐后等上下文；协议将随机与餐后2小时合为一类，无法区分时保留未知，不能冒充精确场景 |
| 正常测量增量上传，失败报告恢复时可重传整份数据 | 按机构/设备/报告/已核验人员关联处理，重复与补传不能重复累计或反复提醒；冲突留版本 |
| 二维码载荷包含报告、设备、用户及报告编号 | 扫码用于定位待领取报告；还要登录、核对归属及授权，不能“谁扫谁拥有” |
| 访问令牌需设备配置才会带上；二维码载荷使用约定加密方式 | 实际上线前核对鉴权与设备能力；加密载荷本身不等于本人身份或访问授权 |
| 协议中的walking、jogging等为“30min运动消耗”，dci为建议摄入量 | 这些不是用户真实运动事件或当天实吃热量，不能画进已发生的时间轴、不能累计为真实运动消耗 |
详细字段与页码见协议能力映射。协议原件、样例身份字段及密钥不复制到共享页面。特别要保留左右臂/单次与平均值、检测方法、来源时间与服务器到达时间的区别。
04 每日餐单和实际饮食，必须是两个独立对象
餐单表达“准备怎么吃”，饮食记录表达“实际吃了什么”。两者之间的差异，才是持续服务的依据。
每日餐单需要由六类输入共同形成：已经确认的健康关注与适用规则、个人阶段目标、今日活动计划、实际已吃内容、过敏/偏好/预算等条件、当天真实可供应菜单。医疗限制由适当专业人员确认，不由模型猜测。
每餐应包含：可供应菜品与替代项、适用的份量信息、食物类别构成、与个人目标的关系、依据及未知项。食材和菜谱资料完整时再计算营养估算；油盐或份量不明时，不展示虚假的精确热量、钠或营养缺口。
饮食记录使用如下独立状态：
已建议 → 已选择/下单 → 已取餐 → 实吃已确认或部分估计 → 剩餐/分享已修正。
下单不等于取到，取到不等于吃完。自动优先接入已有授权的菜品、取餐称重、交易和可用剩餐事件；外食、代取、分享或设备缺失时，只在必要处做一次轻量确认，或保留未知。不得把“没有记录”算成“没有吃”。
每条实吃记录至少保留来源、发生时间、食品/菜谱版本、份量口径、估计方法、可信状态和修订记录；后续餐单再引用它，不能覆盖它。
05 一个完整的一天：结构改变如何发生
以下是虚构的一般成人示例，演示产品逻辑，不是对上传报告所有者的个人处方；份量和限制仍需按实际情况确定。
| 环节 | 计划或现状 | 产品动作 | 可观察的结构变化 |
|---|---|---|---|
| 早餐规划 | 原习惯经常选择油炸主食和甜饮 | 提供燕麦/全谷主食、适用的奶或豆制品、蛋及水果等可行组合；先核对过敏、耐受和供应 | 看是否增加全谷/适用蛋白来源、减少甜饮出现，而非只比热量 |
| 午餐实际 | 餐单有蔬菜与清淡荤菜，但实际取餐偏高油、蔬菜较少 | 保留真实记录；如果没吃完，只确认必要的剩餐信息 | 计划和实吃分开比较，不能仍显示“午餐达标” |
| 晚餐调整 | 根据午餐已知记录，晚餐尚未选择 | 在适用目标和供应范围内提供蔬菜、豆制品/鱼禽等替代选择；不以跳餐或过量运动作为惩罚性补偿 | 改善全天食物构成；不声称晚餐可以抵消午餐所有影响 |
| 活动配合 | 设备记录到较长低活动区间，本人没有已知不适 | 按已审核规则与本人日程提供合适行动；已活动则取消重复提示 | 观察活动分布，不把低步数直接称为坐姿检测 |
| 次日/周末回看 | 有部分餐食与活动记录 | 比较实际选择、执行困难与来源覆盖；下次餐单据此调整 | 看习惯与结构趋势，不凭一天解释血脂或器官变化 |
这里的专业性是把“吃得合理”转成具体选择，并根据真实执行情况持续调整。食物类别与吃动原则以中国营养学会膳食指南八准则作为一般参考；疾病相关食养另使用适用指南及专业审核，不能只套用一般模板。
06 看膳食结构改变，不能只做热量加减
第一版建议先观察六组结构信息：
| 观察组 | 可展示内容 | 判定边界 |
|---|---|---|
| 主食结构 | 全谷/杂豆等实际出现的餐次与适用份量 | 分类与可食部/熟重口径清楚；不能把菜品名称直接当真实成分 |
| 蔬果与豆奶 | 各类食物实际出现频次、已知份量和缺失区间 | 适用人群与过敏/耐受有约束；没记录不算没摄入 |
| 蛋白来源 | 鱼禽蛋肉、豆制品、奶类等来源构成 | 不只看蛋白克数；不因来源变化自动推荐蛋白粉 |
| 高油、甜饮与酒精 | 有依据的食物/饮品出现记录 | 不知道烹调和份量时用类别观察，不伪造油盐精确值 |
| 餐次与活动配合 | 餐次规律、训练/活动前后安排、连续低活动 | 不把所有人统一成一个固定用餐或运动时刻 |
| 食动与阶段趋势 | 合理口径下的摄入/消耗估算，以及后续测量变化 | 活动与基础消耗不重复相加；体成分建议热量不当实测；相关变化不宣称因果 |
周报同时呈现计划结构、已记录的实际结构、与本人目标的差异、记录覆盖率。基线周与本周若缺失程度或数据来源差异过大，显示“暂不足以比较”。只看已确认餐次时必须写明分母；不能将外食未知日算成改善。
阶段结果分三层：行为有没有改变、身体测量怎样变化、是否按专业要求复查。体重下降不等于血脂改善，也不自动关闭医疗跟进事项。
07 个性化提醒：跟着一个人的目标持续调整
每个人拥有持续的“关注事项”，每次提醒只是这个事项在某一时刻的行动建议。个性化至少决定六件事：提醒谁、提醒什么、什么时候、说到什么程度、通过什么渠道、之后如何处理。
建议生成必须引用本人数据与规则版本。正常生活方式提示按用户授权和偏好控制，系统展示“为什么现在提醒我”和“一键稍后/不适合/关闭”。提醒频次阈值是待试点冻结的产品参数，不是医学标准。
| 人与情境（虚构） | 当前提醒 | 反馈后如何变化 |
|---|---|---|
| A关注餐食结构，午餐实吃与计划不同，晚餐还没选 | “按今天已记录的午餐，晚餐有这两个更贴近你目标的选择。” | 选好后结束本次提示；菜品售罄则给可供应替代，不再推原菜 |
| B已有明确训练安排，但部分饮食未知 | 先问一个会影响建议的必要问题，资料足够后才给安排 | 不知道摄入时不报精确缺口；已吃/已取消训练则更新计划 |
| C过去多次忽略提醒 | 在下次合适时机询问障碍，如时间不合适或菜品买不到 | 改时机、改选择或降低频次；不能简单增加推送数量 |
| D已稳定执行一段时间 | 减少同类提示，以每周回顾为主 | 有新的偏离或本人改目标时再评估，避免永久每天催促 |
| E有报告明确的复查要求 | 在专业确认的复查窗口前，按本人偏好提醒准备或预约 | 已预约则转准备任务；已完成须核对新报告，不能仅靠“看过提醒”判定结案 |
一次提醒的状态流程是：
发现变化 → 核对资料/适用性 → 生成候选 → 检查时机与频次 → 发送或抑制 → 等待反馈 → 完成、延后、调整或交专业人员 → 用新证据复评。
发送前必须再次检查：是否已完成、数据是否过期、是否睡眠/免打扰、是否已出现同一主题提示、渠道是否仍有许可。无法识别驾驶等场景时不能声称已准确避让，保守遵循用户设置。
实际完成与否来自有效行为记录或本人确认，不能拿点击率当完成率。无回复也不能自动判失败；多个渠道不轮番追催。迟到/修正数据需重新评估待发消息，已发内容如果失去依据应可追溯更正。
医疗跟进和普通行为提醒分开管理。紧急或超出服务范围的情形按专业审核的指引处理，不以平台后台实时运行作为安全保障。调节频次不能擅自取消医生要求的跟进。
08 两端页面如何承载
手机首页仍围绕今天：我的健康重点、今日餐单、实际吃动、下一步行动。睡眠是状态入口；关键建议可展开查看体检/微体检/近期记录的具体来源，不把完整体检明细暴露在通知锁屏上。
“我的一天”将计划餐单与实际事件分层，保留行为与能量视角；“我的方案”管理阶段目标、餐单调整和本人反馈；“我的”保存体检与微体检记录、结构趋势、专业报告、复查任务、授权及提醒偏好。
专业PC增加三类队列：报告与归属待核对、营养方案/结构变化待解读、持续无响应或超范围待处理。营养师看到计划与实际的差异及来源；运营只访问完成服务所需的最少信息，医疗明细和员工个人报告不因企业付费而默认开放。
康比特营养品仍只出现在经过适用性和现行标签审核的方案支路，普通食物优先；体检异常不能直接触发商品销售。阶段性讲座与数据解读由真实资源承接，AI负责日常整理和准备，不假装营养师每天都审核过。
09 本轮落地范围与接下来三项工作
保留原有“Oura体验主对标、自动记录优先、运动营养核心、多人专业PC”的方向。当前将第一版核心强化为体检/微体检档案、餐单与实吃双账本、持续个性化提醒。
- 数据与归属：用合成报文先验证上禾上传/补传/二维码关联契约；真机与授权就绪后实测。体检导入核对原文、单位和医生建议；不得先将个人PDF导入团队共享演示。
- 餐单与实吃：从一个真实供餐场景开始，确认菜谱、供应、份量和取餐/剩餐数据可得性。无条件自动到数的场景保留未知与轻量补录，不宣称全自动实吃。
- 持续提醒：先选“下一餐结构调整”“有依据的活动提示”“报告复查跟进”三类规则，完整实现发送、抑制、反馈、调整和终止条件，再扩大主题。
本轮仅形成设计与执行契约，没有发送真实通知、创建真实医疗提醒、接入个人账户或完成设备兼容验证。具体机型/报文、身份领取机制、菜谱口径、临床审核角色、提醒频率与渠道许可、性能目标均属于实现前待确认项。需求草案详见三个执行Use Case与验收矩阵。
10 来源、核验与历史
本轮新增来源：用户提供的体检PDF（30页，重点核验摘要、专家意见与相关结果；影像附件未作诊断解读）、上禾检测上传V3.07（2026-08-25版，22页）、在线二维码V1.0（2025-04-15版，2页）。协议规定是接入事实，菜单/提醒机制是我方设计，两者分开。
一般膳食结构参考中国营养学会八准则；国家卫健委已有分人群食养指南，具体疾病适用与复查方案需专业确认。国家卫健委发布通知。本次网络正文访问部分失败，通用原则核验到公开检索摘要，未将未读全文中的具体数值用于个人规则。
- 2026-09-09总纲历史版：保留此前28天服务建议，当前以本页新增要求为准。
- 康比特产品资源核验：原有14来源/14证据保留；不是本轮个人健康结果证据。
- 新增来源与核验记录：不含个人检查明细或原协议样例身份信息。