像看睡眠记录一样，看见身体的一整天
2026-09-09 · V0.4方向讨论。用户本轮明确要求全天24小时时间轴，此要求覆盖早期“不采用时间轴”的限制。现有V0.3原型保留为历史设计基础；本稿不是已完成的传感器接入或状态识别实现。
1. 收敛到一个核心体验
候选核心：自动生成身体的一天回放。 睡眠是首个有明确用户偏好证据的入口，再将夜间记录延伸到白天的活动、少动和进食。
用户已明确“记录睡眠最打动我”。这证明Jack的偏好，尚不能推导整个目标人群都愿意使用或付费。以下机制是产品推理：睡眠记录呈现本人难以直接观察的经历；无需每次打卡；每晚自然完成一个周期；结果与醒来的感受有联系。这些机制比再加一个健康功能列表更适合作为起点。
用户承诺的初稿：早上知道昨晚怎样度过，晚上看见身体这一天怎样被使用。 首版以事实回放建立信任，不承诺解释全部疲劳原因、精确预测恢复或替代医疗判断。
保留长期愿景“帮助身体跟得上在乎的生活”，但第一阶段的入门价值是一个用户每天愿意看的自动记录结果。个人Agent负责解释、处理例外和低负担跟进，不能成为一开始就要求用户学习的复杂工作台。
2. Open Health与相邻产品：分别借鉴什么
| 参考 | 本次已核验内容 | 可借鉴与不能直接认定的内容 |
|---|---|---|
| OpenAI的Health in ChatGPT | 可在本人授权下整合健康背景，理解睡眠/活动变化并提供有上下文的对话 | 借鉴连续背景、变化解释与数据控制；不能据此认定它提供连续传感器识别或实时热量吸收测量 |
| 开源OpenHealth（OpenHealthForAll/open-health） | README列出集中输入、自动解析、结构化数据及上下文对话；支持本地运行方案 | 借鉴数据标准化与私密部署思路；架构图画出穿戴设备不等于每个接口、全天采样和标签算法均已验证。只读README，未运行代码，未作功能/安全验收 |
| Garmin Body Battery | 官方描述基于心率、HRV、运动等信号估计全天精力状态，并解释休息/睡眠/活动影响 | 比“吸收与消耗”更接近用户口语里的“有电没电”；它是厂商算法估计，不是kcal，不应照搬分数或跨品牌混合 |
| Apple/Android健康与活动API | 提供睡眠区间、部分活动与能耗记录；Core Motion有活动类型与置信度 | 可作为事实输入；数据仓库不是传感器本身，日汇总不能还原分钟级轨迹；手机静止不能证明人在坐着 |
名称存在歧义，因此同时核对了OpenAI Health和独立开源OpenHealth，两者不是同一产品。当前对项目的建议不依赖某个开源项目的未核验能力。
来源： - OpenAI Health当前官方说明 - OpenHealth官方仓库README - Garmin Body Battery官方技术说明 - Apple Core Motion活动类型 - Health Connect睡眠体验指南
3. 行为视角：四个主标签加一个未知状态
| 用户看到的主标签 | 含义 | 需要的证据与边界 |
|---|---|---|
| 睡觉 | 被有效睡眠记录覆盖的时段 | 穿戴/已验证床侧数据；分期有则展开，没有则只显示睡眠记录；“在床”不直接等于睡着 |
| 走动 | 日常步行等已识别活动 | 可靠活动分类、步数区间与佩戴/携带上下文；不能把车辆位移当走路 |
| 锻炼 | 已识别的跑步、骑行、游泳或运动会话等 | 保留运动类型与来源；健走会话可属于锻炼，主轨道不再重复记为走动 |
| 少动 | 有效观测下的清醒低活动时段 | 有身份归属和有效观测；只有进一步姿态证据时才细分坐着、站着、躺着；不直接称已恢复 |
| 未知（系统状态） | 没佩戴、没带手机、权限/同步缺口、证据冲突或不足 | 用斜线灰色显示，明确原因；不能默认归少动、坐着或睡眠 |
四个主标签为了用户易懂，不代表能覆盖所有真实行为。乘车等可作为上下文附标，无法可靠归类时保留未知/待确认，不硬塞进走动。
Apple明确说明CMMotionActivity标志不互斥，例如停车等红灯时automotive和stationary可能同时为真。由设备事件生成互斥的人体状态必须有裁决层，不能直接把设备标签换成“坐着”。
主轨道只给同一时段一个主状态；进食、乘车和设备来源是可叠加事件/附标。已验证运动会话覆盖一般步行时优先展示锻炼；高可信冲突例如同时出现睡眠和运动不能盲目按固定优先级覆盖，必须标冲突并回读来源。
4. 连贯24小时不等于每一分钟都已识别
界面可以展示完整日框架，但需要区分已识别、未知和当前时刻之后尚未发生的部分。当天统计分母只到当前时刻，不能把未来算作漏测。自然日按用户时区边界处理；跨时区/夏令时的日长可能不是1440分钟。下面示例固定中国时区的普通24小时日。
| 时段（纯合成示意） | 主状态 | 时长min |
|---|---|---|
| 00:00–07:00 | 睡觉 | 420 |
| 07:00–08:00 | 走动 | 60 |
| 08:00–09:00 | 未知/通勤情境未确认 | 60 |
| 09:00–12:00 | 少动 | 180 |
| 12:00–13:00 | 走动 | 60 |
| 13:00–17:00 | 少动 | 240 |
| 17:00–18:00 | 锻炼 | 60 |
| 18:00–19:00 | 未知 | 60 |
| 19:00–23:00 | 少动 | 240 |
| 23:00–24:00 | 睡觉 | 60 |
示意合计1440分钟：睡觉480、走动120、锻炼60、少动660、未知120。进食点如07:30、12:10、19:00叠加在时间轴上，不再占用独立主状态时长。该图只是解释信息结构，不是产品实测结果，不意味着能无缝识别每个生活时段。
夜间跨日睡眠：日轴按日期裁剪展示；睡眠详情仍保留完整跨日session。午睡单独保留。设备事后生成睡眠阶段或补传时，只修订相应区间，并显示数据更新状态。
5. 能量视角：代谢收支与恢复精力分开
5.1 热量没有“停止消耗”状态
静息、睡眠仍维持生命活动；消化吸收也需要能量。可以表达“静息消耗、活动额外消耗、进食摄入估算”，不使用“没有消耗能量”。Cleveland Clinic基础代谢说明
有符合口径的分项时，总消耗可由静息与活动等组成解释；平台已提供总量时不再追加活动热量。并非每个平台都会单列食物热效应，不能擅自再加一项。仅有全天总量时只展示总量，不凭空画出小时或分钟消耗曲线。
5.2 吃进去、吸收中、吸收了多少是三件事
进食事件和食物热量可以记录或估算；人体消化后吸收营养是一个过程，消耗也在同时进行。普通穿戴记录不能自动提供某一时刻吸收了多少kcal的可靠测量。即使存在血糖数据，也不能直接等同于全部营养素的吸收率。NIDDK消化与吸收说明
首版用进食事件+摄入估算，不画看似精确的吸收曲线。后续若探索消化吸收模型，必须有明确模型假设、适用范围和验证，图中标为模拟而非实测。订单/取餐量仍不能替代实吃量。
5.3 睡眠恢复不等于热量充值
一个人睡着时仍耗能，但睡眠可以参与恢复。用户口语中的“精力”与kcal不是同一量，不能因为吃了一顿饭就直接把精力条加满，也不能把每次运动都标成有害透支。
恢复观察可在有合适生理数据、个人基线和验证模型后单独提供，并允许本人感受纠正。缺少数据时只展示睡眠时长/中断/规律等事实。不同设备HRV、压力和恢复分数不直接混算。
5.4 推荐同一时间轴的两种查看方式
- 行为：00–24小时主状态色带、进食等事件、点击片段看来源和置信说明。
- 代谢能量：对齐同一时刻的消耗记录或估算区间，叠加进食标记及摄入估算。没有时序数据就退回日汇总，不插值伪造曲线。
- 恢复信息作为睡眠详情或附加观察，不与代谢热量合成一个0–100总分。
6. “所有传感器”应变成可扩展的能力体系
| 输入层 | 首轮用途 | 限制 |
|---|---|---|
| 手机+已授权健康库 | 活动片段、步数区间、已有睡眠/运动会话 | 手机可能离身；健康库有记录不等于能实时拿到原始传感器流 |
| 已支持手表/手环 | 夜间睡眠与白天活动、生理样本、部分佩戴状态 | 充电/摘下/后台限制/品牌算法差异，必须逐型号验证 |
| 床垫、座椅压力、环境存在传感器等 | 在明确支持与身份绑定场景下补充姿态/在床/房间状态 | 人在房间或椅子受压不自动等于目标会员在坐着；同住者、访客、宠物和换座要处理 |
| 智慧食堂称重/取餐与营养资料 | 自动生成取餐和摄入候选记录 | 与实吃量有差距，不感知即时吸收 |
第一版优先验证一个用户已经拥有、我们可以获授权读取的手机+穿戴组合。设备品牌少一些，但自动到数、来源归属、连续片段与缺口要可信。新增传感器必须证明降低了关键误判或补上重要时段，不能仅按接入数量证明价值。
算法职责分层：传感器/平台原始事件→去重与时间统一→片段分类/冲突与缺口→可追溯时间轴→LLM解释。高频标签不由LLM凭摘要自由编造。每片段带开始/结束、来源、有效观测、原始ID、分类依据、置信表达和版本。
要先验证原生App后台采集与健康库读取粒度；仅小程序或只有日汇总，可能无法形成所需的全天行为细节。同步延迟应显示截至时间并允许补齐，不承诺实时急救监护。
7. 睡眠是入口，白天回放是延伸，食动关系是特色
候选产品名称/表达：“身体的一天”或“24小时身体回放”。第一句承诺暂定：不用打卡，也能回看昨晚的睡眠和白天的活动。 只有在目标设备后台验证通过后才可用于正式宣传。
最小体验分三步：
- 第二天早上：已经有一份可用的昨夜睡眠记录，并说明数据截至和缺口。用户不用先学会配置仪表盘。
- 点开昨日：睡眠、走动、锻炼、少动自动串成一天；用户能发现一个平时没留意、且能被证据支持的模式。
- 有足够历史后：把睡得较好/较差的日子与白天食动记录并排比较，只提供候选相关线索和下一次可验证的小调整，不下因果结论。
示例对白（虚构，不是研究结论）：“昨晚的睡眠记录已整理。昨天晚间有运动和进食记录；目前不能判断它们是否影响了睡眠，可以和你其他几天一起看。”避免“昨晚睡差就是因为那顿饭”“今天剩余精力只有23%”。
差异化尚待证明：已有平台也提供睡眠和全天精力估计。我们可能增加的价值是跨设备的连贯回放、真实餐食记录和可执行营养/活动服务。只把现成睡眠图复制一遍，不足以证明用户会长期留下。
8. 先验证能打动人的点，再扩展Agent
把首轮核心问题固定为：用户在无需额外打卡的情况下，是否愿意反复打开自动生成的身体回放，并觉得它比原有健康App多解释了一件有用的事。
| 验证维度 | 观察方式 | 不可替代的边界 |
|---|---|---|
| 进入价值 | 首次授权后，下一次打开是否已有可读回放 | 手动导入后生成不等于后台自动记录通过 |
| 自然回访 | 不靠强制推送/奖励，用户是否主动看晨间睡眠或晚间回放 | 打开率不等于健康改善 |
| 增量认识 | 用户能否指出一条可信的新发现 | 要与原有Apple/华为等App比较，不故意设弱对手 |
| 可信度 | 睡眠起止、活动/少动、来源归属误判，以及未知时段是否诚实 | 不能以覆盖率高奖励乱填；少动/睡眠的误判应分别统计 |
| 自动性与成本 | 后台自然到数、延迟、佩戴覆盖、耗电和权限复杂度 | 用实际目标机型测量，不以网页原型测试代替 |
| 情绪体验 | 是否减少困惑，是否增加睡眠分数焦虑 | 不用恐惧或羞耻留人 |
建议先与少量真实目标用户核验“为什么看睡眠”及其最近使用行为，再做目标设备上的短期日记/影子验证。本轮未招募、未联系用户、未使用真实健康数据。商业留存/付费和医疗准确性都尚未验证。
9. 候选Use Case与下一步边界
Use Case ID：UC-FM-011；状态：Draft；DoR: BLOCKED。 - 角色/目标：本人无需日常手动记录，打开全天身体回放；专业端仅能读取本人授权范围。 - 触发/前置：一个已验证设备组合，类型级授权、有效佩戴/携带观测及时间戳；后台新事件或本人打开页面触发更新。 - 主流程：M1取得增量原始事件；M2按身份/时区/来源去重；M3分段、判主标签并保留未知；M4展示日轴和完整睡眠session；M5切换同时间范围的能量视角；M6查看来源或纠正错误。 - 分支：A1只有睡眠则先交付睡眠，不伪造白天；A2只有日能耗则显示日总量；A3已识别乘车作上下文；A4健康库延迟补传后修订相应区间。 - 异常/恢复：E1未佩戴/无权限/没有粒度→显示具体缺口，恢复后回补；E2来源冲突→不强行归类并允许核验；E3身份不清→不写入某个人；E4能量不完整→不显示净盈余/亏空或即时吸收。 - 规则：四主标签+未知；每时间片一个主状态；进食/生理观察可叠加；不把未来时间算未知；不把kcal当精力；个人记录可纠正且不外发未授权数据。 - 验收/测试：AC/T19普通中国时区样例片段无重叠且合计1440分钟，未知保留；AC/T20跨日睡眠完整session可追溯；AC/T21冲突与离身不默认为坐着；AC/T22能耗/摄入/恢复分开，缺数据不插值造曲线；AC/T23目标真机后台自动到数和修正后回放一致。 - 非功能：原型概念图不做设备性能证明；生产需冻结可接受延迟/耗电、身份匹配和误判指标，并完成后端权限/删除/健康数据处理审查。 - 待确认：首发设备与可读粒度、四标签裁决及置信规则、睡眠评价口径、能耗数据源、实际用户回访证据；责任角色为产品/设备/算法/专业人员，负责人及验收阈值未指定。
本轮完成产品收敛分析，未把旧原型自动改成已验证全天时间轴，也未创建云效开发任务。下一步如进入原型改版，以本轮允许时间轴的新要求为准。