缺失,不等于正常
信号缺失会降低置信度,并触发保守建议;系统不会把没有采集到的数据当成“状态良好”。
CONFIDENCE ↓
ALBERT XIE
Say hello
Product system / 03 iPhone + Apple Watch

它不是另一块健康数据看板,而是一套决定何时可以行动、何时应该停下的本地训练系统。


UI capture / sample preview data
01 / The question
睡眠、HRV、静息心率和训练负荷都可以被记录,但“今天该不该练、练多少、什么时候加重量”仍然需要判断。只把数字排成一块漂亮的面板,并不会自动产生可信的建议。
Kris 把问题重新定义成一条决策链:先确认数据是否足够,再由确定性规则守住安全和进阶边界,最后才让 AI 把依据解释成人能理解的教练简报。
02 / Product decisions
信号缺失会降低置信度,并触发保守建议;系统不会把没有采集到的数据当成“状态良好”。
CONFIDENCE ↓准备度门禁、安全边界和进阶条件由确定性逻辑负责;AI 只解释已有证据,不自由开处方。
RULES FIRST只有实际完成的训练与明确反馈才能进入负荷计算,避免“安排过”被错误地当作“做过”。
REAL EVENTS03 / Decision pipeline
iPhone 直接读取本地健康信号。
清洗时间窗、缺失值与数据新鲜度。
判断准备度、限制条件与是否允许进阶。
把可追溯依据解释成今日行动。
训练结果和主观反馈回到下一次判断。
04 / Real interface
以下来自当前 Preview 构建,用样例数据展示界面结构,不代表任何人的实时健康状况。
把准备度、今日限制和训练入口放在同一视线里,先回答“现在做什么”,再展开指标。

05 / A boundary worth keeping
BASELINE BUILDING7 / 42 天负荷模型在历史不足时会明确保持 baseline_building,不会急着给出“恢复良好”或“可以加量”的确定结论。
重量进阶也不是一次表现好就触发。gated_double_progression_v1 要求两次可比较的成功训练,并且主观反馈处于可接受范围,才允许增加负荷。
Kris 不是医疗诊断工具,也不会用薄弱证据自动调整热量或训练重量。
06 / Evidence
以下结论来自项目内已有测试、Preview 构建与视觉验收记录。它们证明当前原型的范围,不代表已经完成商业发布。
Swift 单元与 UI 验证通过。
今日、健康、训练、趋势、设置通过视觉 QA。
当前版本完成 Preview 构建验证。
真机交互、长期数据与商业发布门禁仍待完成。
适合继续做真机交互验证;不宣称 App Store 就绪,也不把预览值包装成真实用户结果。
07 / My angle
我在这个项目里关注的不是“让 AI 像教练一样说话”,而是产品规则、状态定义、证据链和安全边界如何共同决定一次建议是否可信。
下一阶段是把真实设备交互、数据新鲜度和长期负荷变化放进同一套验收门禁,再决定哪些能力值得进入可发布版本。
Discuss this case ↗