Agents
智能健身教练 PEAS 模型分析
通过智能健身教练案例深入理解 PEAS 模型的应用，包括性能度量、环境描述、执行器、传感器及环境特性分析
原始需求
智能健身教练是一个复杂的个人健康助理系统，具备以下核心能力：
- 通过可穿戴设备实时监测用户生理数据（心率、运动强度等）
- 根据健身目标（减脂/增肌/提升耐力）动态调整训练计划
- 运动过程中提供实时语音指导和动作纠正
- 评估训练效果并给出饮食建议
1. 商业层
1.1 商业模式画布
| 模块 | 内容 |
|---|---|
| 客户细分 | 减脂白领（25-35岁，久坐）、增肌爱好者（18-30岁，健身老司机）、康复训练用户（术后/慢病，需医嘱）、企业客户（员工健康管理B2B） |
| 价值主张 | 「7×24小时随身私教」——实时监测降低受伤风险，AI个性化计划比通用课程更有效，数据驱动看见进步 |
| 渠道通路 | App Store/应用市场、智能手表预装（Apple Watch/Garmin合作）、健身房B端合作、企业HR采购、KOL健身博主推荐 |
| 客户关系 | 自动化个性化服务（主）+ 社群打卡激励 + 人工客服兜底（安全/投诉） |
| 收入来源 | 订阅制（个人Pro版￥29/月、家庭版￥49/月）、智能硬件分成（手表/心率带）、企业健康管理SaaS年费、高级课程/饮食计划单购 |
| 核心资源 | 运动医学知识图谱、用户行为大数据、AI模型（姿态识别+生理信号分析）、医疗合规资质 |
| 关键活动 | AI模型持续训练优化、医疗安全审核、用户增长与留存运营、硬件生态合作 |
| 重要伙伴 | 可穿戴设备厂商（数据接入）、健身房/工作室（场景落地）、医院/康复中心（背书与转诊）、保险（健康险联动） |
| 成本结构 | AI研发（算力+人才，40%）、硬件补贴/分成（25%）、获客成本（20%）、医疗合规与保险（10%）、运营（5%） |
关键洞察：传统健身App卖"内容"，智能健身教练卖"安全+效果"——医疗级监测能力是差异化壁垒，也是成本中心。
1.2 价值主张画布
用户画像（以"减脂白领"为例）
| 用户任务 | 痛点 | 收益 |
|---|---|---|
| 想减肥但没时间去健身房 | 不知道练什么、怕受伤、难坚持、看不到效果 | 省时（碎片训练）、安心（实时监控）、有效（数据见证变化） |
| 跟着视频练但没反馈 | 动作错了没人纠正、强度不适合自己、没人鼓励 | 实时语音纠正、个性化强度、AI"陪聊"鼓励 |
| 尝试多次但反弹 | 计划太激进难坚持、没养成习惯、缺乏长期规划 | 渐进式计划、习惯养成游戏化、生活方式而非短期冲刺 |
产品-市场匹配（PMF）验证点
- 问题-方案匹配：用户核心痛点是"不知道练什么"和"怕受伤"，而非"缺课程"——市面上免费课程已过剩
- 商业模式匹配：订阅制依赖留存，但健身是"反人性"的，必须通过效果数据（体脂下降曲线）证明价值
- 渠道匹配：高净值用户通过Apple Watch生态获取，价格敏感用户通过免费增值（Freemium）转化
1.3 业务能力地图
基于PEAS推导的核心业务能力：
能力-系统映射：核心域能力对应技术系统的"感知-分析-决策-执行"pipeline，支撑域能力对应后台管理、合规、运营系统。
1.4 客户旅程地图
关键洞察：旅程中情绪低谷出现在"平台期"和"受伤/中断"，传统App在这两个节点流失率高。智能健身教练的核心价值是通过实时监测预防受伤，以及通过数据解释平台期（身体成分在改善即使体重没变）来平滑情绪曲线。
2. 产品层
2.1 用户画像（Persona）
关键设计冲突：减脂小白要「简单无脑」，数据控要「专业可调」，康复用户要「安全保守」——同一产品如何平衡？ → 策略：通过首次问卷动态分流，提供「模式切换」而非「统一界面」。
2.2 用户故事地图
Backbone（主干流程）：制定计划 → 执行训练 → 复盘调整
┌─────────────────────────────────────────────────────────────────────────────┐
│ 制定计划 执行训练 复盘调整 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │填写目标 │ │开始训练 │ │查看数据 │ │
│ │与约束 │ │ │ │与报告 │ │
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ │
│ │ │ │ │
│ ┌────▼─────┐ ┌────▼─────┐ ┌────▼─────┐ │
│ │AI生成 │ │实时监测 │ │AI分析 │ │
│ │初始计划 │ │生理数据 │ │训练效果 │ │
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ │
│ │ │ │ │
│ ┌────▼─────┐ ┌────▼─────┐ ┌────▼─────┐ │
│ │确认或 │ │接收实时 │ │调整下周 │ │
│ │调整计划 │ │指导反馈 │ │计划 │ │
│ └──────────┘ └────┬─────┘ └──────────┘ │
│ │ │
│ ┌────▼─────┐ │
│ │完成训练 │ │
│ │记录感受 │ │
│ └──────────┘ │
└─────────────────────────────────────────────────────────────────────────────┘
详细用户故事（按优先级分层）
泳道 1：减脂焦虑白领（MVP重点）
| 优先级 | 用户故事 | 验收标准 |
|---|---|---|
| P0 | 作为减脂用户，我希望能输入我的目标和身体数据，让AI生成适合我的训练计划 | 问卷<2分钟，计划包含动作视频、预计消耗卡路里 |
| P0 | 作为减脂用户，我希望训练时能通过手表实时看到心率和消耗 | 心率更新延迟<3秒，消耗卡路里实时累计 |
| P0 | 作为减脂用户，当我动作不标准时，希望能听到语音纠正 | 姿态识别准确率>85%，语音反馈延迟<5秒 |
| P1 | 作为减脂用户，我希望能看到每周的体重/体脂变化曲线 | 支持Apple Health同步，图表支持多时间维度 |
| P1 | 作为减脂用户，当我心率过高时，希望AI自动让我休息 | 心率阈值根据年龄自动计算，预警提前10秒 |
| P2 | 作为减脂用户，我希望完成训练后能分享到朋友圈 | 生成精美分享图，包含消耗卡路里和坚持天数 |
泳道 2：数据控极客（进阶功能）
| 优先级 | 用户故事 | 验收标准 |
|---|---|---|
| P1 | 作为数据控，我希望能导入我的历史训练数据 | 支持CSV/Excel导入，支持Strava等第三方同步 |
| P1 | 作为数据控，我希望AI基于我的HRV建议今天是否适合高强度训练 | 集成Whoop/Oura数据，提供「练/轻量/休息」建议 |
| P2 | 作为数据控，我希望自定义训练计划的周期化参数（如负荷递增率） | 支持线性/波动/波浪等多种周期模型 |
| P2 | 作为数据控，我希望看到每次训练的「训练负荷（TL）」和「急性:慢性负荷比（ACWR）」 | 自动计算RPE×时长，预警ACWR>1.5 |
泳道 3：术后康复用户（安全优先）
| 优先级 | 用户故事 | 验收标准 |
|---|---|---|
| P0 | 作为康复用户，我希望在输入病史时明确哪些动作绝对禁止 | 禁忌动作清单由医生审核，用户需确认已阅读 |
| P0 | 作为康复用户，当我的动作幅度超过安全范围时，希望AI立即停止训练 | 关节角度阈值可配置，紧急停止延迟<1秒 |
| P1 | 作为康复用户，我希望家人能收到我的训练日报（是否完成、是否有异常） | 支持微信/短信推送，异常时立即通知 |
| P2 | 作为康复用户，我希望AI能根据我的恢复进度自动调整计划难度 | 每周基于完成度和疼痛反馈调整，医生可审核 |
2.3 用例模型
核心用例图（简化）
┌─────────────────┐
│ 健身用户 │
└────────┬────────┘
│
┌───────────────────┼───────────────────┐
│ │ │
▼ ▼ ▼
┌────────────────┐ ┌────────────────┐ ┌────────────────┐
│ UC1: 制定 │ │ UC2: 执行 │ │ UC3: 查看 │
│ 训练计划 │ │ 实时训练 │ │ 训练效果 │
└────────┬───────┘ └────────┬───────┘ └────────┬───────┘
│ │ │
▼ ▼ ▼
┌────────────────┐ ┌────────────────┐ ┌────────────────┐
│ 输入目标/约束 │ │ 监测生理数据 │ │ 生成周报告 │
│ AI生成计划草案 │ │ 识别动作质量 │ │ 展示趋势图表 │
│ 用户确认/调整 │ │ 实时语音指导 │ │ 提供调整建议 │
└────────────────┘ │ 风险预警/干预 │ └────────────────┘
└────────────────┘
│
┌───────────────────┼───────────────────┐
│ │ │
▼ ▼ ▼
┌────────────────┐ ┌────────────────┐ ┌────────────────┐
│ 可穿戴设备 │ │ AI推理引擎 │ │ 云端存储 │
│ （传感器） │ │ （模型服务） │ │ （数据湖） │
└────────────────┘ └────────────────┘ └────────────────┘
关键用例详述：UC2 - 执行实时训练
参与者：健身用户、可穿戴设备、AI推理引擎 前置条件：用户已选择今日训练计划，设备已连接且校准完成 后置条件：训练数据已记录，用户疲劳状态已更新
主流程：
- 用户点击「开始训练」，系统开始记录训练会话
- 系统通过可穿戴设备实时采集心率、加速度数据（每秒）
- 用户开始第一个动作，摄像头/传感器采集姿态数据
- AI模型实时分析姿态质量，计算关节角度
- 若姿态标准，系统语音鼓励「动作标准，保持呼吸」
- 若姿态偏差>阈值，系统语音提示「注意膝盖不要超过脚尖」
- 系统持续监测心率，若进入无氧区间，提示「心率偏高，建议放慢」
- 用户完成规定次数，系统自动进入组间休息倒计时
- 重复步骤2-8直到完成所有训练项
- 系统生成训练摘要，用户记录主观疲劳度(RPE)
备选流程：
- 4a. 设备断开：提示重新连接，提供「仅计时模式」继续训练
- 5a. 心率异常（>180或<50）：立即暂停训练，询问用户感受，建议就医/休息
- 6a. 动作危险（如腰部过度弯曲）：立即停止训练，语音警告「危险动作，请停止」，解锁需确认
- 8a. 用户主动暂停：倒计时暂停，恢复后继续
异常处理：
- 用户跌倒检测 → 触发紧急联系人通知
- 连续3次动作识别失败 → 切换到「仅心率监测模式」，建议查看视频示范
- 业务规则 / 决策模型
核心决策表：训练强度动态调整
规则集 1：基于心率的实时强度调节（安全红线）
| 条件 \ 动作 | 心率 < 60% HRmax | 60-80% HRmax | 80-90% HRmax | > 90% HRmax |
|---|---|---|---|---|
| 减脂目标用户 | 提示「可适当加快速度」 | 维持当前强度 | 提示「即将进入无氧区，注意呼吸」 | 强制休息2分钟 |
| 增肌目标用户 | 组间休息缩短 | 维持当前强度 | 正常训练区间 | 提示「最后一组，注意动作质量」 |
| 康复用户 | 正常区间 | 提示「心率接近上限，建议放慢」 | 强制停止，联系医生 | 紧急预警，解锁需医生确认 |
| 有心脏病史 | 正常区间 | 提示「请降低强度」 | 强制停止 | 紧急联系人通知 |
HRmax = 220 - 年龄；减脂目标通常维持在60-70% HRmax区间
规则集 2：基于动作质量的风险干预
| 风险等级 | 触发条件 | 系统响应 | 解锁条件 |
|---|---|---|---|
| 🟢 提示 | 关节角度偏差 10-20% | 语音提示正确动作要领 | 自动，下一动作继续 |
| 🟡 警告 | 关节角度偏差 20-30% 或 代偿动作 detected | 暂停计时，要求观看示范视频 | 用户确认「已理解」后继续 |
| 🔴 强制停止 | 关节角度偏差 >30% 或 脊柱风险动作（如负重弯腰） | 立即停止训练，记录风险事件 | 需人工客服/医生确认后解锁 |
| 🚨 紧急 | 跌倒检测 / 心率异常+用户无响应 | 触发紧急联系人通知，保留现场数据 | 人工介入 |
规则集 3：基于HRV的今日训练建议（数据控用户）
| 7日平均HRV vs 基线 | 睡眠评分 | 建议训练类型 | 计划自动调整 |
|---|---|---|---|
| > 100%（恢复良好） | > 80 | 「今日状态佳，可尝试挑战新重量」 | 负荷 +5% |
| 90-100%（正常） | 60-80 | 「按计划进行」 | 标准负荷 |
| 80-90%（轻度疲劳） | < 60 | 「建议减量训练或瑜伽拉伸」 | 负荷 -20%，替换为低强度有氧 |
| < 80%（过度训练风险） | 任意 | 「强制休息日」 | 今日训练锁定，推荐冥想/散步 |
规则引擎设计考量：
- 规则分层：硬编码安全红线（不可覆盖）+ 可配置业务规则 + AI学习规则
- 个性化：规则参数（如心率阈值）根据用户档案动态计算
- 可追溯：每次规则触发记录日志，用于医疗责任界定
3. 领域层（DDD）
3.1 战略设计：子域与限界上下文
子域划分
┌─────────────────────────────────────────────────────────────────────────────┐
│ 智能健身教练领域划分 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ 核心域（Core Domain） │ │
│ │ 差异化竞争优势，需要投入最好的人才和资源 │ │
│ │ │ │
│ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │
│ │ │ 实时训练 │ │ 个性化推荐 │ │ 风险预警 │ │ │
│ │ │ 会话域 │ │ 与计划域 │ │ 与安全域 │ │ │
│ │ │ (Live │ │ (Adaptive │ │ (Safety │ │ │
│ │ │ Coaching) │ │ Planning) │ │ Guard) │ │ │
│ │ └──────────────┘ └──────────────┘ └──────────────┘ │ │
│ │ │ │
│ │ • 多模态实时交互 • AI动态计划生成 • 生理异常检测 │ │
│ │ • 动作识别与纠正 • 周期化负荷管理 • 危险动作拦截 │ │
│ │ • 毫秒级反馈决策 • 效果评估与迭代 • 紧急响应流程 │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ 支撑域（Supporting Domain） │ │
│ │ 业务必需但非差异化，可部分外包或使用成熟方案 │ │
│ │ │ │
│ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │
│ │ │ 用户与档案 │ │ 内容与知识 │ │ 通知与通信 │ │ │
│ │ │ 域 │ │ 域 │ │ 域 │ │ │
│ │ └──────────────┘ └──────────────┘ └──────────────┘ │ │
│ │ │ │
│ │ • 注册认证 • 动作库/课程视频 • 推送通知 │ │
│ │ • 用户画像 • 运动科学知识图谱 • 语音TTS │ │
│ │ • 偏好设置 • 营养/康复知识库 • 紧急联系人通知 │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ 通用域（Generic Domain） │ │
│ │ 基础设施，直接采购或使用开源方案 │ │
│ │ │ │
│ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │
│ │ │ 支付与计费 │ │ 数据分析 │ │ 平台集成 │ │ │
│ │ │ 域 │ │ 域 │ │ 域 │ │ │
│ │ └──────────────┘ └──────────────┘ └──────────────┘ │ │
│ │ │ │
│ │ • 订阅管理 • 数据仓库/BI • 可穿戴设备API │ │
│ │ • 退款处理 • A/B测试平台 • Apple Health │ │
│ │ • 发票税务 • 用户行为分析 • 第三方登录 │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
限界上下文（Bounded Context）划分
| 限界上下文 | 职责 | 核心概念 | 团队规模 |
|---|---|---|---|
| Live-Coaching BC | 实时训练会话管理 | 训练会话、动作组、实时状态、反馈指令 | 8-10人（核心） |
| Adaptive-Planning BC | 智能计划生成与调整 | 训练计划、周期模板、负荷计算、目标追踪 | 6-8人（核心） |
| Safety-Guard BC | 安全风险监控与干预 | 风险规则、异常事件、紧急流程、医疗档案 | 4-6人（核心+合规） |
| User-Profile BC | 用户管理与档案 | 用户、档案、偏好、设备绑定、隐私授权 | 3-4人 |
| Physio-Data BC | 生理数据处理与存储 | 心率数据、姿态数据、睡眠数据、数据质量 | 3-4人 |
| Knowledge-Base BC | 运动科学知识管理 | 动作库、规则库、知识图谱、课程视频 | 2-3人 |
| Billing BC | 订阅与支付 | 订阅、订单、优惠券、退款 | 2人（外包/采购） |
关键设计决策：
Live-Coaching BC与Physio-Data BC分离：实时训练只需要「处理后的信号」（如姿态质量评分），原始传感器数据在Physio-Data中存储，避免实时链路被大数据拖慢Safety-Guard BC独立：安全规则需要医疗专家审核，与业务逻辑解耦，支持快速响应监管变化
上下文映射（Context Map）
┌─────────────────┐
│ 可穿戴设备 │
│ （外部系统） │
└────────┬────────┘
│ 原始传感器数据
▼
┌──────────────┐ ┌─────────────────┐ ┌──────────────┐
│ User-Profile │◄────────────►│ Physio-Data │─────────────►│ Knowledge │
│ BC │ 用户档案 │ BC │ 特征提取 │ -Base │
│ │ │（数据管道+存储） │ │ BC │
└──────┬────────┘ └────────┬────────┘ └──────┬───────┘
│ │ │
│ 用户偏好 │ 心率/姿态特征 │ 动作标准
│ ▼ │
│ ┌─────────────────┐ │
│ │ Live-Coaching │◄──────────────────────┘
│ │ BC │ 动作纠正规则
│ │（实时训练引擎） │
│ └────────┬────────┘
│ │
│ 目标/约束 │ 会话完成
│ ▼
│ ┌─────────────────┐
└──────────────────────►│ Adaptive-Planning│
│ BC │
│（AI计划引擎） │
└────────┬────────┘
│
│ 计划调整
▼
┌─────────────────┐
│ Safety-Guard │◄─── 医疗档案（严格隔离）
│ BC │
│（风险规则引擎） │
└─────────────────┘
集成模式说明：
- Live-Coaching ↔ Physio-Data：发布-订阅（Pub-Sub），实时流数据
- Live-Coaching ↔ Adaptive-Planning：异步消息队列，会话结束后触发计划评估
- 所有BC → Safety-Guard：安全事件通过独立总线优先传输，确保低延迟
- Knowledge-Base → Live-Coaching：开放主机服务（OHS），提供REST API查询动作标准
3.2 战术设计：聚合、实体与值对象
核心聚合设计
聚合 1：TrainingSession（训练会话）
聚合根：TrainingSession
├── 实体：SessionId（唯一标识）
├── 值对象：TrainingGoal（本次训练目标）
├── 值对象：TimeRange（开始/结束时间）
├── 实体列表：ExerciseSet[]（动作组集合）
│ ├── 实体：ExerciseSetId
│ ├── 值对象：ExerciseType（动作类型，引用知识库）
│ ├── 值对象：TargetLoad（目标负荷：重量/次数/时间）
│ └── 实体列表：Rep[]（单次重复）
│ ├── 值对象：RepNumber（第几次）
│ ├── 值对象：FormQuality（姿态质量评分 0-100）
│ ├── 值对象：HeartRateSnapshot（心率快照）
│ └── 值对象：VideoClip（视频片段URL，可选）
├── 值对象：SessionRPE（主观疲劳度 1-10）
└── 领域事件：
├── TrainingSessionStarted
├── ExerciseSetCompleted
├── RiskAlertTriggered（当FormQuality<阈值或心率异常）
└── TrainingSessionCompleted
一致性边界：
- 一个TrainingSession包含完整的训练过程数据，是数据一致性的边界
- 心率数据可能每秒10次，但Rep级别的质量评估是聚合内部的计算结果，不对外暴露原始数据
- 会话进行中，ExerciseSet可以逐个添加；已完成的Set不可修改（审计要求）
聚合 2：AdaptivePlan（自适应训练计划）
聚合根：AdaptivePlan
├── 实体：PlanId
├── 实体：UserId（归属用户）
├── 值对象：Goal（长期目标：减脂/增肌/康复）
├── 值对象：Constraints（约束：伤病史、可用器械、每周频率）
├── 值对象：PeriodizationModel（周期化模型：线性/波动/波浪）
├── 实体列表：TrainingWeek[]（周计划）
│ ├── 实体：WeekNumber（第几周）
│ ├── 值对象：TargetLoadRange（本周负荷区间）
│ └── 实体列表：SessionTemplate[]（训练日模板）
│ ├── 值对象：DayOfWeek
│ ├── 值对象：FocusArea（训练重点：胸/背/有氧等）
│ └── 值对象：ExerciseSequence（动作序列）
├── 值对象：PlanEffectiveness（计划有效性评分，AI计算）
└── 领域事件：
├── PlanGenerated（首次生成）
├── PlanAdjusted（基于反馈调整）
└── GoalAchieved（目标达成）
聚合 3：SafetyProfile（安全档案）
聚合根：SafetyProfile（每个用户一份，严格隔离）
├── 实体：ProfileId
├── 实体：UserId
├── 值对象：MedicalHistory（病史：心脏病/高血压/术后等）
├── 值对象：Contraindications（禁忌动作清单）
├── 值对象：HeartRateThresholds（个性化心率阈值，非公式计算）
├── 值对象：EmergencyContact（紧急联系人）
├── 实体列表：RiskEvent[]（风险事件历史）
│ ├── 实体：EventId
│ ├── 值对象：EventType（Fall/HeartRateAbnormal/DangerousForm）
│ ├── 值对象：Severity（Low/Medium/High/Critical）
│ └── 值对象：HandlingResult（处理结果）
└── 领域事件：
├── RiskAlertRaised
├── EmergencyContactNotified
└── SafetyLockTriggered（锁定训练，需医生解锁）
重要设计：SafetyProfile单独一个聚合，且物理存储隔离（加密），满足医疗数据合规要求。
领域服务（Domain Services）
服务 1：LoadCalculator（负荷计算器）
// 计算今日建议训练负荷，基于HRV、睡眠、历史表现
interface LoadCalculator {
calculateTodayLoad(
userId: UserId,
plannedLoad: Load,
physiologicalReadiness: ReadinessScore // 基于HRV等计算
): LoadRecommendation {
// 规则：HRV < 80%基线 → 负荷减少20%
// 规则：睡眠<6小时 → 替换为低强度有氧
// 规则：连续3天高强度 → 强制休息日
}
}
服务 2：FormAnalyzer（姿态分析器）
// 调用AI模型分析姿态质量，封装模型细节
interface FormAnalyzer {
analyzeForm(
exerciseType: ExerciseType,
sensorData: SensorData,
videoFrame?: VideoFrame
): FormAnalysisResult {
// 返回：关节角度、与标准动作偏差、风险等级
// 内部调用：姿态识别模型（如MediaPipe/自研模型）
}
}
服务 3：RiskEvaluator（风险评估器）
// 评估实时风险，触发预警
interface RiskEvaluator {
evaluateRealTimeRisk(
currentHeartRate: HeartRate,
formQuality: FormQuality,
safetyProfile: SafetyProfile
): RiskAssessment {
// 综合判断：心率异常+动作质量差+有心脏病史 = Critical
// 返回：风险等级 + 建议动作（继续/暂停/停止/紧急通知）
}
}
3.3 领域事件（Domain Events）
| 事件 | 发布者 | 订阅者 | 触发场景 |
|---|---|---|---|
TrainingSessionStarted | Live-Coaching BC | Physio-Data BC, Analytics | 用户点击开始训练 |
HeartRateThresholdExceeded | Physio-Data BC | Live-Coaching BC, Safety-Guard BC | 心率超过安全阈值 |
PoorFormDetected | Live-Coaching BC | Live-Coaching BC(自身), Safety-Guard BC | 姿态识别质量低于阈值 |
TrainingSessionCompleted | Live-Coaching BC | Adaptive-Planning BC, Analytics | 用户完成训练 |
PlanAdjustmentRecommended | Adaptive-Planning BC | Notification BC | AI建议调整下周计划 |
RiskAlertRaised | Safety-Guard BC | Live-Coaching BC, Notification BC | 触发安全预警 |
EmergencyContactNotified | Safety-Guard BC | -（外部SMS服务） | 紧急事件通知家属 |
GoalAchieved | Adaptive-Planning BC | Notification BC, Gamification | 用户达成阶段目标 |
事件流示例：风险预警场景
用户训练时深蹲姿势危险（膝盖过度前移）
│
▼
Live-Coaching BC: 调用 FormAnalyzer.detectForm()
│
▼
检测到 deviation > 30%，发布 PoorFormDetected 事件
│
├──────────────────────┬──────────────────────┐
▼ ▼ ▼
Live-Coaching BC Safety-Guard BC Physio-Data BC
(立即语音警告) (记录风险事件) (存储异常片段)
│ │
▼ ▼
用户未纠正，继续危险动作 评估Severity = HIGH
│ │
▼ ▼
再次触发 PoorFormDetected 发布 RiskAlertRaised
│
├──────────────┬──────────────┐
▼ ▼ ▼
Live-Coaching Notification (Audit Log)
(强制停止训练) (通知教练/家属)
3.4 统一语言（Ubiquitous Language）
| 术语 | 定义 | 使用上下文 | 避免混淆 |
|---|---|---|---|
| 训练会话 (Training Session) | 用户从开始训练到结束的完整过程，包含多个动作组 | Live-Coaching | 不等于「训练计划」或「单次动作」 |
| 动作组 (Exercise Set) | 同一动作的连续重复，如「深蹲 3组×12次」中的1组 | Live-Coaching, Planning | 行业内也简称「组」或「Set」 |
| 重复 (Rep) | 单次动作执行，如1次深蹲 | Live-Coaching | 避免与「组」混用 |
| 训练计划 (Training Plan) | 周期性训练安排，通常4-12周 | Adaptive-Planning | 不等于「单次会话」 |
| 周期化 (Periodization) | 有计划地变化训练负荷，避免平台期 | Adaptive-Planning | 用户通常说「课程表」 |
| 负荷 (Load) | 训练强度量化，可以是重量、次数、或RPE | Live-Coaching, Planning | 用户可能说「重量」或「难度」 |
| RPE (Rating of Perceived Exertion) | 主观疲劳度 1-10分，用户自我评估 | Live-Coaching | 内部术语，对外说「今天感觉怎么样」 |
| HRV (Heart Rate Variability) | 心率变异性，反映恢复状态 | Safety-Guard, Planning | 对外说「身体恢复分数」 |
| 姿态质量 (Form Quality) | AI评估的动作标准程度 0-100分 | Live-Coaching | 避免说「分数」，对外说「动作标准度」 |
| 风险事件 (Risk Event) | 训练过程中触发的安全警告记录 | Safety-Guard | 不等于「事故」，是「潜在危险」 |
| 禁忌动作 (Contraindicated Exercise) | 因用户病史禁止的动作 | Safety-Guard | 必须明确告知用户「绝对不能做」 |
| 训练准备度 (Readiness Score) | 基于HRV、睡眠等计算的今日训练适宜度 | Adaptive-Planning | 对外说「今日状态评分」 |
跨边界术语映射：
| 用户语言 | 产品语言 | 技术/领域语言 |
|---|---|---|
| 「今天练什么」 | 今日训练安排 | SessionTemplate |
| 「我做得标准吗」 | 实时动作反馈 | FormQuality > 80 |
| 「会不会练伤」 | 安全风险评估 | RiskEvaluation |
| 「有没有进步」 | 训练效果评估 | PlanEffectiveness |
| 「强度够不够」 | 负荷匹配度 | Load vs TargetLoad |
设计原则：
- 对外（用户界面）：使用用户语言，如「今天状态不错，可以尝试挑战」
- 对内（产品文档）：使用业务术语，如「ReadinessScore > 80，建议负荷+5%」
- 对技术（代码）：使用精确的领域语言，如
loadCalculator.calculate(physiologicalReadiness)
4. 技术层
4.1 整体技术架构
分层架构 + 事件驱动混合模式
┌─────────────────────────────────────────────────────────────────────────────┐
│ 接入层（Edge Layer） │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ 手机App │ │ 智能手表 │ │ Web端 │ │ 智能器械 │ │
│ │ (Flutter/ │ │ (Wear OS/ │ │ (Vue3 + │ │ (蓝牙/WiFi) │ │
│ │ React Native)│ │ WatchOS) │ │ WebRTC) │ │ │ │
│ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │
│ │ │ │ │ │
│ └─────────────────┴────────┬────────┴─────────────────┘ │
│ │ │
│ ┌────────▼────────┐ │
│ │ API Gateway │ │
│ │ (Kong/AWS ALB) │ │
│ │ • 认证鉴权 │ │
│ │ • 限流熔断 │ │
│ │ • 协议转换 │ │
│ └────────┬────────┘ │
└────────────────────────────────────┼────────────────────────────────────────┘
│
┌────────────────────────────────────┼────────────────────────────────────────┐
│ 应用层（Application Layer） │
│ │ │
│ ┌─────────────────────────────────▼─────────────────────────────────────┐ │
│ │ 实时服务集群（Real-time Services） │ │
│ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │
│ │ │ Live-Coaching│ │ Physio-Data │ │ Safety │ │ │
│ │ │ Service │ │ Pipeline │ │ Guard │ │ │
│ │ │ (Node.js/ │ │ (Flink/ │ │ (Rust/Go) │ │ │
│ │ │ Go) │ │ Kafka) │ │ │ │ │
│ │ │ │ │ │ │ │ │ │
│ │ │ • WebSocket │ │ • 实时流处理 │ │ • 规则引擎 │ │ │
│ │ │ 连接管理 │ │ • 特征提取 │ │ • 亚毫秒响应 │ │ │
│ │ │ • 会话状态 │ │ • 数据清洗 │ │ • 紧急事件 │ │ │
│ │ │ 维护 │ │ │ │ 优先队列 │ │ │
│ │ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │ │
│ │ │ │ │ │ │
│ │ └─────────────────┴────────┬────────┘ │ │
│ │ │ │ │
│ │ ┌────────▼────────┐ │ │
│ │ │ Event Bus │ │ │
│ │ │ (Redis/RabbitMQ)│ │ │
│ │ └─────────────────┘ │ │
│ └────────────────────────────────────────────────────────────────────────┘ │
│ │
│ ┌───────────────────────────────────────────────────────────────────────┐ │
│ │ AI服务集群（AI Services） │ │
│ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │
│ │ │ 姿态识别 │ │ 计划生成 │ │ 风险评估 │ │ │
│ │ │ Model Svc │ │ Model Svc │ │ Model Svc │ │ │
│ │ │ (Python/ │ │ (Python/ │ │ (Python/ │ │ │
│ │ │ PyTorch) │ │ PyTorch) │ │ PyTorch) │ │ │
│ │ │ │ │ │ │ │ │ │
│ │ │ • MediaPipe/ │ │ • Transformer│ │ • 时序模型 │ │ │
│ │ │ 自研模型 │ │ • 强化学习 │ │ • 异常检测 │ │ │
│ │ │ • 边缘推理 │ │ • 知识图谱 │ │ • 可解释性 │ │ │
│ │ │ +云端增强 │ │ 融合 │ │ 输出 │ │ │
│ │ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │ │
│ │ │ │ │ │ │
│ │ └─────────────────┴────────┬────────┘ │ │
│ │ │ │ │
│ │ ┌────────▼────────┐ │ │
│ │ │ Model Registry │ │ │
│ │ │ (MLflow) │ │ │
│ │ └─────────────────┘ │ │
│ └───────────────────────────────────────────────────────────────────────┘ │
│ │
│ ┌───────────────────────────────────────────────────────────────────────┐ │
│ │ 业务服务集群（Domain Services） │ │
│ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ ┌───────────┐ │ │
│ │ │ User-Profile │ │ Billing │ │ Notification │ │ Analytics │ │ │
│ │ │ Service │ │ Service │ │ Service │ │ Service │ │ │
│ │ │ (Java/Go) │ │ (Java) │ │ (Node.js) │ │ (Go/ │ │ │
│ │ │ │ │ │ │ │ │ Python) │ │ │
│ │ └──────────────┘ └──────────────┘ └──────────────┘ └───────────┘ │ │
│ └───────────────────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────────────────┘
│
┌────────────────────────────────────┼────────────────────────────────────────┐
│ 数据层（Data Layer） │
│ │ │
│ ┌─────────────────────────────────▼─────────────────────────────────────┐ │
│ │ 实时数据流（Streaming） │ │
│ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │
│ │ │ Apache Kafka │ │ Apache Flink │ │ Redis │ │ │
│ │ │ • 传感器数据 │ │ • 实时特征 │ │ • 会话状态 │ │ │
│ │ │ • 领域事件 │ │ 计算 │ │ • 热数据缓存 │ │ │
│ │ │ • 日志流 │ │ • 窗口聚合 │ │ • 分布式锁 │ │ │
│ │ └──────────────┘ └──────────────┘ └──────────────┘ │ │
│ └────────────────────────────────────────────────────────────────────────┘ │
│ │
│ ┌───────────────────────────────────────────────────────────────────────┐ │
│ │ 持久化存储（Persistence） │ │
│ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │
│ │ │ PostgreSQL │ │ ClickHouse │ │ MinIO │ │ │
│ │ │ • 用户数据 │ │ • 时序数据 │ │ • 视频/图片 │ │ │
│ │ │ • 训练记录 │ │ • 聚合分析 │ │ • 模型文件 │ │ │
│ │ │ • 交易数据 │ │ • 实时报表 │ │ • 备份 │ │ │
│ │ └──────────────┘ └──────────────┘ └──────────────┘ │ │
│ │ │ │
│ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │
│ │ │ Elasticsearch│ │ Neo4j │ │ InfluxDB │ │ │
│ │ │ • 动作库搜索 │ │ • 知识图谱 │ │ • 传感器时序 │ │ │
│ │ │ • 日志检索 │ │ • 关系推理 │ │ • 高性能写入 │ │ │
│ │ └──────────────┘ └──────────────┘ └──────────────┘ │ │
│ └───────────────────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────────────────┘
架构决策说明
| 决策 | 选型 | 理由 |
|---|---|---|
| 实时通信 | WebSocket + gRPC | WebSocket用于客户端实时数据传输，gRPC用于服务间高效通信 |
| 流处理引擎 | Apache Flink | 支持毫秒级延迟的复杂事件处理（CEP），适合姿态识别后的风险规则判断 |
| AI推理 | 边缘+云端混合 | 姿态识别首帧在本地（MediaPipe）保证低延迟，复杂分析在云端（PyTorch） |
| 会话状态 | Redis + 本地缓存 | Redis保证分布式一致性，本地缓存减少网络往返（<10ms） |
| 时序数据 | InfluxDB + ClickHouse | InfluxDB处理高频写入（10Hz心率数据），ClickHouse支撑分析查询 |
4.2 数据架构
数据流架构图
┌─────────────────────────────────────────────────────────────────────────────┐
│ 数据采集层 │
│ │
│ 智能手表 ──────┐ │
│ (10Hz心率) │ │
│ │ │
│ 手机传感器 ────┼──► 边缘预处理 ────► Kafka Topic: raw.sensor.data │
│ (加速度/陀螺仪)│ (降噪/压缩) │
│ │ │
│ 摄像头 ────────┘ │
│ (视频流) │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────────────────┐
│ 实时处理层（Flink） │
│ │
│ ┌───────────────────────────────────────────────────────────────────┐ │
│ │ 特征提取作业 │ │
│ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │
│ │ │ 心率特征 │ │ 动作特征 │ │ 融合特征 │ │ │
│ │ │ • 当前HR │ │ • 关节角度 │ │ • 疲劳指数 │ │ │
│ │ │ • HRV计算 │ │ • 运动轨迹 │ │ • 风险评分 │ │ │
│ │ │ • 区间占比 │ │ • 速度/加速度│ │ │ │ │
│ │ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │ │
│ │ │ │ │ │ │
│ │ └─────────────────┴────────┬────────┘ │ │
│ │ │ │ │
│ │ ┌────────▼────────┐ │ │
│ │ │ 窗口聚合 │ │ │
│ │ │ (5s滑动窗口) │ │ │
│ │ └────────┬────────┘ │ │
│ └────────────────────────────────────┼──────────────────────────────┘ │
│ │ │
│ ┌────────────────────────────────────▼──────────────────────────────┐ │
│ │ 规则引擎作业（CEP） │ │
│ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │
│ │ │ 心率规则 │ │ 动作规则 │ │ 复合规则 │ │ │
│ │ │ HR>180持续 │ │ 姿势偏差>30% │ │ HR高+姿势差 │ │ │
│ │ │ 10s → Alert │ │ 连续3次 → Warn│ │ → Critical │ │ │
│ │ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │ │
│ │ │ │ │ │ │
│ │ └─────────────────┴────────┬────────┘ │ │
│ │ │ │ │
│ │ ┌────────▼────────┐ │ │
│ │ │ 触发动作 │ │ │
│ │ │ • 语音提醒 │ │ │
│ │ │ • 紧急停止 │ │ │
│ │ │ • 通知家属 │ │ │
│ │ └─────────────────┘ │ │
│ └───────────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────────────────┐
│ 存储层 │
│ │
│ 热数据路径（实时查询） │
│ ┌──────────────┐ │
│ │ Redis │ ◄──── 当前会话状态、实时心率（TTL: 24h） │
│ └──────────────┘ │
│ │
│ 温数据路径（近期分析） │
│ ┌──────────────┐ ┌──────────────┐ │
│ │ InfluxDB │ │ PostgreSQL │ │
│ │ • 传感器原始 │ │ • 训练记录 │ │
│ │ 数据(7天) │ │ • 用户档案 │ │
│ └──────────────┘ └──────────────┘ │
│ │
│ 冷数据路径（长期归档） │
│ ┌──────────────┐ ┌──────────────┐ │
│ │ S3/MinIO │ │ ClickHouse │ │
│ │ • 视频录像 │ │ • 聚合分析 │ │
│ │ • 模型版本 │ │ • 趋势报表 │ │
│ └──────────────┘ └──────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
数据分层策略
| 层级 | 存储 | 数据类型 | 保留策略 | 查询场景 |
|---|---|---|---|---|
| 热数据 | Redis | 当前会话状态、实时心率 | 24h TTL | 毫秒级实时反馈 |
| 温数据 | InfluxDB + PostgreSQL | 7天传感器数据、训练记录 | 7-30天 | 训练复盘、周报表 |
| 冷数据 | S3 + ClickHouse | 历史视频、聚合指标 | 永久（归档） | 趋势分析、模型训练 |
4.3 部署架构
混合云 + 边缘计算部署
┌─────────────────────────────────────────────────────────────────────────────┐
│ 用户侧（Edge） │
│ ┌───────────────────────────────────────────────────────────────────────┐ │
│ │ 边缘计算节点（可选） │ │
│ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │
│ │ │ 手机本地推理 │ │ 智能手表 │ │ 智能家居 │ │ │
│ │ │ • MediaPipe │ │ 计算 │ │ 网关 │ │ │
│ │ │ 姿态识别 │ │ • 心率分析 │ │ • 数据汇聚 │ │ │
│ │ │ • TTS语音 │ │ • 异常检测 │ │ • 本地缓存 │ │ │
│ │ └──────────────┘ └──────────────┘ └──────────────┘ │ │
│ │ │ │
│ │ 决策：首帧姿态识别 < 50ms 必须在本地完成，网络不稳定时降级运行 │ │
│ └───────────────────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────────────────┘
│
▼ (HTTPS/WSS)
┌─────────────────────────────────────────────────────────────────────────────┐
│ 云端（AWS/阿里云） │
│ │
│ ┌───────────────────────────────────────────────────────────────────────┐ │
│ │ K8s集群（EKS/ACK） │ │
│ │ │ │
│ │ ┌─────────────────────────────────────────────────────────────────┐ │ │
│ │ │ 实时服务Pod（HPA自动扩缩） │ │ │
│ │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │ │
│ │ │ │ Live-Coaching│ │ Safety-Guard │ │ Flink Task │ │ │ │
│ │ │ │ Pod x3 │ │ Pod x2 │ │ Manager │ │ │ │
│ │ │ └──────────────┘ └──────────────┘ └──────────────┘ │ │ │
│ │ │ │ │ │
│ │ │ 扩缩策略：CPU>70%扩容，<30%缩容；Safety-Guard最小2副本保可用 │ │ │
│ │ └─────────────────────────────────────────────────────────────────┘ │ │
│ │ │ │
│ │ ┌─────────────────────────────────────────────────────────────────┐ │ │
│ │ │ AI推理服务Pod（GPU节点） │ │ │
│ │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │ │
│ │ │ │ 姿态识别 │ │ 计划生成 │ │ 风险评估 │ │ │ │
│ │ │ │ (NVIDIA T4) │ │ (NVIDIA T4) │ │ (NVIDIA T4) │ │ │ │
│ │ │ └──────────────┘ └──────────────┘ └──────────────┘ │ │ │
│ │ │ │ │ │
│ │ │ 资源限制：单Pod限2 GPU，推理延迟<200ms P99 │ │ │
│ │ └─────────────────────────────────────────────────────────────────┘ │ │
│ │ │ │
│ │ ┌─────────────────────────────────────────────────────────────────┐ │ │
│ │ │ 基础服务Pod │ │ │
│ │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │ │
│ │ │ │ User/Billing │ │ Notification │ │ Kafka │ │ │ │
│ │ │ │ (按需) │ │ (按需) │ │ (3 brokers) │ │ │ │
│ │ │ └──────────────┘ └──────────────┘ └──────────────┘ │ │ │
│ │ └─────────────────────────────────────────────────────────────────┘ │ │
│ └───────────────────────────────────────────────────────────────────────┘ │
│ │
│ ┌───────────────────────────────────────────────────────────────────────┐ │
│ │ 托管服务（PaaS） │ │
│ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │
│ │ │ RDS │ │ ElastiCache │ │ S3 │ │ │
│ │ │ (PostgreSQL) │ │ (Redis) │ │ (对象存储) │ │ │
│ │ └──────────────┘ └──────────────┘ └──────────────┘ │ │
│ └───────────────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
多区域部署策略
| 区域 | 部署内容 | 数据同步 | 故障切换 |
|---|---|---|---|
| 主区域（华东） | 全量服务 + 主数据库 | - | 故障时切到备区 |
| 备区域（华北） | 实时服务 + 只读副本 | 异步复制（<1s延迟） | 只读模式 |
| 边缘节点（各省） | CDN + 推理缓存 | 静态资源预热 | 降级到云端 |
4.4 关键技术选型对比
| 技术领域 | 候选方案 | 最终选型 | 选型理由 |
|---|---|---|---|
| 实时通信 | WebSocket vs gRPC-Web vs MQTT | WebSocket + gRPC | WebSocket兼容性好，gRPC服务间效率高 |
| 流处理 | Flink vs Spark Streaming vs Kafka Streams | Flink | 毫秒级延迟CEP，适合安全规则判断 |
| 姿态识别 | MediaPipe vs OpenPose vs 自研 | MediaPipe + 自研微调 | MediaPipe轻量可跑在端上，自研提升准确率 |
| 时序数据库 | InfluxDB vs TimescaleDB vs TDengine | InfluxDB | 生态成熟，写入性能高，与Grafana集成好 |
| AI框架 | PyTorch vs TensorFlow vs ONNX | PyTorch | 研究到生产链路顺畅，动态图调试友好 |
| 模型服务 | Triton vs TorchServe vs 自研 | Triton | 多模型并发、动态批处理、GPU利用率优化 |
| 向量数据库 | Milvus vs Pinecone vs pgvector | Milvus | 动作相似度搜索、知识图谱嵌入存储 |
4.5 非功能性需求（NFR）
性能指标（SLA）
| 指标 | 目标 | 测量方法 | 降级策略 |
|---|---|---|---|
| 心率到反馈延迟 | < 200ms (P99) | 端到端Tracing | 本地规则兜底，延迟容忍到1s |
| 姿态识别延迟 | < 100ms (首帧) | 模型推理耗时 | 降低分辨率/帧率 |
| API响应时间 | < 50ms (P95) | APM监控 | 缓存加速 |
| 系统可用性 | 99.95% | 健康检查 | 多可用区容灾 |
| 并发用户 | 10万同时训练 | 压测 | 排队+限流 |
安全架构
┌─────────────────────────────────────────────────────────────┐
│ 分层安全防护 │
├─────────────────────────────────────────────────────────────┤
│ L1: 传输安全 │
│ • TLS 1.3 全链路加密 │
│ • 证书 pinning（防中间人攻击） │
├─────────────────────────────────────────────────────────────┤
│ L2: 认证授权 │
│ • OAuth 2.0 + JWT（短时效access token + refresh token） │
│ • 设备绑定（防账号共享） │
│ • 生物识别（指纹/人脸）二次确认（敏感操作） │
├─────────────────────────────────────────────────────────────┤
│ L3: 数据安全 │
│ • 医疗数据AES-256加密存储（SafetyProfile隔离） │
│ • 字段级加密（身份证号、病历） │
│ • 数据脱敏（日志、分析报表） │
│ • 隐私计算（联邦学习，数据不出域） │
├─────────────────────────────────────────────────────────────┤
│ L4: 运行安全 │
│ • 模型对抗攻击防护（姿态识别防欺骗） │
│ • 输入校验（防传感器数据注入） │
│ • 限速熔断（防DDoS） │
└─────────────────────────────────────────────────────────────┘
合规要求
| 法规 | 要求 | 技术实现 |
|---|---|---|
| GDPR | 数据可删除、可导出 | 软删除+异步清理任务；数据打包导出API |
| 网络安全法 | 数据本地化存储 | 国内云服务、跨境传输审批 |
| 医疗器械法规（如适用） | 可追溯、可审计 | 完整审计日志、版本控制、风险评估报告 |
| 等保2.0 | 三级等保 | 堡垒机、WAF、数据库审计、日志留存6个月 |
4.6 技术债务与演进路线
当前版本（MVP）vs 目标架构
| 维度 | MVP（0-6月） | V2（6-12月） | V3（1-2年） |
|---|---|---|---|
| 姿态识别 | MediaPipe云端推理 | 端云协同（首帧本地） | 端上全量推理（隐私优先） |
| 计划生成 | 规则模板+简单ML | 个性化Transformer模型 | 强化学习（长期优化） |
| 数据架构 | 单一PostgreSQL | 引入InfluxDB分离时序数据 | 数据湖（训练素材积累） |
| 部署 | 单可用区 | 多可用区容灾 | 边缘推理节点 |
已知技术债务
- 实时性与成本权衡：Flink集群在低峰期利用率<30%，需引入Serverless流处理（如AWS Kinesis Analytics）
- 模型版本管理：当前手动部署，需建立MLOps流水线（Kubeflow/MLflow）
- 多租户隔离：当前逻辑隔离，大B客户需要物理隔离（资源成本↑）
- 遗留数据迁移：早期JSON格式训练记录需迁移到结构化Schema
5. PEAS 完整描述
Performance（性能度量）
| 维度 | 具体指标 |
|---|---|
| 健身效果 | 目标达成率（减脂量/肌肉增长/耐力提升）、体脂率变化、VO₂ Max 提升 |
| 安全性 | 运动损伤率、异常心率预警准确率、过度训练预防成功率 |
| 用户依从性 | 训练计划完成率、用户留存率、长期习惯养成 |
| 用户体验 | 语音指导满意度、动作纠正准确率、建议可执行性评分 |
| 系统效率 | 计划调整响应速度、实时反馈延迟（< 200ms）、能耗管理 |
核心优化目标：在确保安全的前提下，最大化用户的健身目标达成率和长期坚持率。
Environment（环境）
| 环境要素 | 描述 |
|---|---|
| 物理环境 | 健身房、家庭、户外、办公室等多样化运动场景 |
| 用户生理状态 | 心率、血氧、体温、疲劳度、睡眠质量、压力水平 |
| 用户行为 | 当前动作、动作质量、运动强度、休息时长、饮食记录 |
| 外部条件 | 天气（户外运动）、设备可用性、时间约束、社交因素 |
| 历史数据 | 过往训练记录、身体变化趋势、偏好设置 |
| 知识库 | 运动科学、营养学、解剖学、康复医学知识 |
Actuators（执行器）
| 执行器类型 | 具体形式 | 功能 |
|---|---|---|
| 语音输出 | TTS 引擎、耳机/扬声器 | 实时指导、鼓励反馈、风险提示 |
| 视觉输出 | 手机屏幕、智能手表、AR 眼镜 | 动作示范视频、数据可视化、姿势对比 |
| 触觉反馈 | 智能手表震动 | 节奏提示、阈值警告、动作节拍 |
| 数字接口 | App 推送、消息通知 | 训练计划更新、饮食建议、进度报告 |
| 设备控制 | 智能器械（跑步机、哑铃等） | 自动调节阻力、速度、坡度 |
| 数据记录 | 云端存储 | 训练日志、身体数据、计划历史 |
Sensors（传感器）
| 传感器类型 | 数据来源 | 采集信息 |
|---|---|---|
| 生理传感器 | 智能手表/手环、心率带 | 心率、心率变异性(HRV)、血氧(SpO₂)、皮肤温度 |
| 运动传感器 | 加速度计、陀螺仪、GPS | 运动轨迹、步频、配速、位移、海拔变化 |
| 视觉传感器 | 摄像头、深度传感器 | 身体姿态、动作幅度、关节角度（用于动作纠正） |
| 用户输入 | 语音、触屏、按钮 | 主观疲劳度(RPE)、疼痛感、训练感受反馈 |
| 环境传感器 | 温度计、气压计、光感 | 环境温度、湿度、光照（影响户外运动决策） |
| 第三方数据 | 健康 App API、医疗记录 | 睡眠质量、日常活动量、饮食摄入、病史 |
环境特性分析
特性判定总表
| 特性 | 判定 | 分析 |
|---|---|---|
| 完全/部分可观察 | ⚠️ 部分可观察 | 无法直接观测用户肌肉疲劳度、关节内部压力、真实代谢状态、情绪变化，只能通过间接指标推断 |
| 确定性/随机性 | ⚠️ 随机性 | 同强度训练在不同天的效果不同；用户对相同计划的反应存在个体差异和随机波动 |
| 静态/动态 | 🔴 动态性 | 用户体能、疲劳度、情绪、环境条件持续变化；智能体行动会改变环境（训练后疲劳累积） |
| 离散/连续 | 🔴 连续性 | 心率、运动强度、时间、位置都是连续变量；动作空间（阻力、速度调节）也是连续的 |
| 单/多智能体 | ⚠️ 混合 | 主要是单智能体，但涉及多用户社交场景（排行榜、组队训练）时变为多智能体 |
| 已知/未知 | ⚠️ 部分已知 | 运动科学规律已知，但个体生理响应模型需要持续学习；新用户的特性最初未知 |
| 回合式/序贯 | 🔴 序贯决策 | 当前训练影响下次训练状态；需要长期规划而非孤立决策 |
关键特性详解
部分可观察性（Partially Observable）
传感器无法直接测量关键状态：
- 肌肉微损伤程度 → 只能通过 HRV、主观疲劳度推断
- 糖原储备水平 → 间接通过运动表现和饮食记录估算
- 动作质量细节 → 依赖视觉传感和算法推断，存在误差
应对策略：维护内部信念状态（Belief State），建立用户生理模型，持续更新对用户状态的"最佳猜测"。
动态性（Dynamic）
时间尺度上的变化：
- 秒级：心率随运动强度实时波动
- 分钟级：组间休息时的恢复曲线
- 日级：隔夜疲劳累积/恢复
- 周级：训练周期（负荷累积/减载周）
- 月级：身体适应性变化（体能提升）
连续性（Continuous）
状态空间和动作空间均为连续：
- 心率：40-200 bpm 的连续值
- 运动强度：0-100% 1RM 的连续负荷
- 调整建议：负荷微调（2.5kg vs 5kg）、语音语调强度
随机性（Stochastic）
不确定性来源包括生理波动、测量误差、用户行为不一致、环境因素等，需要概率建模和鲁棒决策。
多目标优化（Multi-objective）
需要权衡的冲突目标：
- 短期效果 ←→ 长期可持续性
- 训练强度 ←→ 损伤风险
- 计划严格 ←→ 用户依从性
- 专业指导 ←→ 用户愉悦感
环境复杂度评估
┌──────────────────────────────────────────────────────┐
│ 智能健身教练环境复杂度 │
├──────────────────────────────────────────────────────┤
│ 部分可观察 ████████████████████░░░░ 高 │
│ 随机性 █████████████████░░░░░░░ 中高 │
│ 动态性 █████████████████████░░░ 很高 │
│ 连续性 ███████████████████████░ 很高 │
│ 多智能体 ██████░░░░░░░░░░░░░░░░░░ 低（主要单） │
│ 多目标 ███████████████████████░ 很高 │
└──────────────────────────────────────────────────────┘
综合难度：🔴 高难度任务环境
设计启示
基于以上分析，智能健身教练需要：
| 设计要素 | 策略 |
|---|---|
| 信念状态管理 | 使用概率模型（如卡尔曼滤波、粒子滤波）持续估计用户真实状态 |
| 鲁棒决策 | 采用安全边界的保守策略，优先预防损伤 |
| 自适应学习 | 在线学习用户个体模型，从新用户通用模型迁移到个性化模型 |
| 分层控制 | 底层：毫秒级安全监控；中层：分钟级训练调控；高层：周/月级周期规划 |
| 人机协作 | 关键决策（如伤病判断）引入人工确认，不完全自主 |
Agent 的智能决策与快慢思考
Agent 在教练系统中的核心作用
在智能健身教练系统中，Agent 不是简单的"规则执行器"，而是扮演动态决策中枢的角色：
| 决策层级 | Agent 作用 | 典型场景 |
|---|---|---|
| 实时感知-行动循环 | 毫秒级融合多源信号，做出即时判断 | 心率突增时立即降低强度建议 |
| 上下文理解 | 理解当前训练情境，而非孤立看数据 | 同样的180bpm心率，新手是危险，马拉松选手是正常 |
| 长期策略优化 | 从周/月时间尺度优化训练计划 | 识别用户进入平台期，自动调整周期化方案 |
| 异常处理 | 面对未见过的情境做出合理推断 | 用户报告"膝盖不适"，推断可能动作模式并调整 |
| 个性化权衡 | 在冲突目标间找到用户最优解 | 在"严格按计划"与"保护用户积极性"间动态平衡 |
Agent 的核心价值在于将静态规则转化为动态智能——不是告诉用户"深蹲要做3组12次"，而是根据今天的状态决定"这组做到力竭，下一组减轻重量"。
卡尼曼的快慢思考模型
丹尼尔·卡尼曼在《思考，快与慢》中提出人类认知的双重系统理论，这与智能健身教练的架构设计高度契合：
┌─────────────────────────────────────────────────────────────────┐
│ 智能健身教练的双重决策系统 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────────────────┐ ┌──────────────────────────┐ │
│ │ 系统1：快思考 │ │ 系统2：慢思考 │ │
│ │ (System 1 - Fast) │ │ (System 2 - Slow) │ │
│ ├──────────────────────────┤ ├──────────────────────────┤ │
│ │ │ │ │ │
│ │ • 直觉式、自动化 │ │ • 分析式、有意识 │ │
│ │ • 低认知负荷 │ │ • 高认知负荷 │ │
│ │ • 毫秒级响应 │ │ • 秒级到分钟级 │ │
│ │ • 基于模式识别 │ │ • 基于逻辑推理 │ │
│ │ │ │ │ │
│ └────────────┬─────────────┘ └────────────┬─────────────┘ │
│ │ │ │
│ ▼ ▼ │
│ ┌──────────────────────────┐ ┌──────────────────────────┐ │
│ │ 实时生理监控 │ │ 训练计划生成 │ │
│ │ • 心率异常检测 │ │ • 周期化负荷计算 │ │
│ │ • 动作姿态识别 │ │ • 长期目标拆解 │ │
│ │ • 疲劳信号预警 │ │ • 效果评估与调整 │ │
│ │ • 紧急安全干预 │ │ • 营养建议推理 │ │
│ │ │ │ │ │
│ │ 实现方式： │ │ 实现方式： │ │
│ │ • 轻量级CNN（姿态） │ │ • LLM + 知识图谱 │ │
│ │ • 规则引擎（心率阈值） │ │ • 强化学习（策略优化） │ │
│ │ • 边缘计算（低延迟） │ │ • 云端推理（复杂规划） │ │
│ └──────────────────────────┘ └──────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
系统1（快思考）负责的决策
特点：必须在 < 200ms 内完成，依赖预训练的模式识别
| 决策类型 | 输入信号 | 决策逻辑 | 输出动作 |
|---|---|---|---|
| 心率异常预警 | 实时心率流 | 规则：>180bpm 或 <50bpm 或 上升斜率异常 | 立即语音警告+建议休息 |
| 动作危险检测 | 关节角度（膝盖/腰部） | CNN识别危险姿态模式 | 立即叫停+语音提示纠正 |
| 呼吸节奏提醒 | 动作阶段（向心/离心） | 预设呼吸模式匹配 | "吸气下沉，呼气推起" |
| 鼓励时机 | 完成次数+历史数据 | 用户通常在第8次力竭，第6次给予鼓励 | "还有3次，你可以的！" |
| 组间休息倒计时 | 当前心率恢复速度 | 心率回到120bpm或时间先到 | 震动提示"开始下一组" |
技术实现：
- 姿态识别：MediaPipe/自研轻量CNN，本地边缘运行
- 心率分析：简单规则引擎 + 滑动窗口统计
- 响应延迟：P99 < 100ms
系统2（慢思考）负责的决策
特点：可在 秒级到分钟级 完成，需要综合推理与规划
| 决策类型 | 输入信息 | 推理过程 | 输出结果 |
|---|---|---|---|
| 今日训练建议 | HRV、睡眠质量、昨日训练负荷、用户目标 | 综合评估恢复状态，推理"今天该练什么" | 调整后的训练计划草案 |
| 动作替代建议 | 用户报告"膝盖不适"+ 当前计划 | 推理：深蹲 → 腿举/箱式深蹲（减少膝剪切力） | 替代动作方案 |
| 平台期突破策略 | 4周数据：力量停滞+体脂不降 | 分析：可能过度训练或饮食问题 | 调整周期化模型或转介营养师 |
| 长期计划调整 | 8周训练效果 vs 初始目标 | 评估进度，预测达成时间 | 下一阶段训练重点调整 |
| 风险-收益权衡 | 用户想冲极限重量但睡眠<6小时 | 推理：收益有限但受伤风险高 | "建议今天保守一些，明天状态好再挑战" |
技术实现：
- 计划生成：LLM + 运动科学知识图谱
- 效果评估：时序预测模型（LSTM/Transformer）
- 个性化推理：用户画像 + 强化学习策略优化
快慢思考的协作机制
┌─────────────────────────────────────────────────────────────────┐
│ 典型场景：深蹲训练中的决策协作 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 用户开始深蹲训练 │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ 系统1（快思考）持续监控（每100ms） │ │
│ │ • 检测膝盖角度：当前85°（正常范围）→ 绿灯 │ │
│ │ • 检测心率：165bpm（正常）→ 绿灯 │ │
│ │ • 检测腰部曲度：轻微弯曲 → 黄灯，准备提醒 │ │
│ └──────────────────────────────────────────────────────────┘ │
│ │ │
│ │ 发现异常模式：第5次重复时腰部曲度持续增大 │
│ ▼ │
│ 系统1触发：语音提示「注意收紧核心，背部挺直」 │
│ │ │
│ │ 用户未纠正，腰部曲度继续增大（危险阈值） │
│ ▼ │
│ 系统1触发紧急停止：「停止！腰部压力过大，请起立休息」 │
│ │ │
│ ▼ │
│ 数据上报 → 系统2（慢思考）分析 │
│ │ │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ 系统2推理（约1-2秒）： │ │
│ │ • 用户历史：有轻度腰肌劳损记录 │ │
│ │ • 可能原因：今天负荷偏大 + 核心疲劳 + 动作技术不足 │ │
│ │ • 调整建议： │ │
│ │ 1. 本次剩余组数改为箱式深蹲（减少腰部负荷） │ │
│ │ 2. 下周计划加入核心强化训练 │ │
│ │ 3. 建议观看「深蹲腰部保护」教学视频 │ │
│ └──────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ 语音输出：「检测到您腰部压力较大，建议改为箱式深蹲，需要我为您 │
│ 演示动作吗？」 │
│ │
└─────────────────────────────────────────────────────────────────┘
核心洞察：智能健身教练的 Agent 不是取代人类的"全知全能者"，而是快慢结合的认知增强器——系统1确保"不出事"，系统2追求"练得好"，两者协作实现安全且有效的个性化训练。