AI 健身产品完整调研报告

1.1 原始材料#

1.2 合并原则#

本报告区分五类内容：

• 事实快照：原材料引用的产品公开能力、价格、平台文档或研究结论；可能随时间变化。
• 用户线索：应用商店、社区与产品评论中出现的问题；用于提出假设，不代表发生率。
• 产品判断：多份材料共同或分别推导出的方向。
• 设计方案：尚未通过真实用户验证的界面、功能、指标和路线。
• 长期愿景：当前未必适合开发，但构成产品边界与未来形态的能力。

“求并集”不等于把互相冲突的观点同时当成最终决定。本文会完整保留分歧，并注明它适合哪个阶段。例如：一份材料建议首版同时支持居家、健身房和轻饮食，另一份材料建议只做商业健身房力量训练；两者都保留，最终作为“广义产品边界”和“首发切口”分别使用。

2.1 产品本质#

六份材料共同指向的终局不是一个“AI 健身聊天应用”，而是一套 Personal Training OS / Gym Operating System / Autonomous Fitness OS：

它覆盖一条完整闭环：

目标与身体状态
    ↓
训练计划与营养方向
    ↓
今天的时间、地点、器械与恢复状态
    ↓
训练执行、组间决策与低摩擦记录
    ↓
训练结果、饮食、体重和恢复数据
    ↓
归因、复盘与下一次调整
    └──────────────────→ 回到下一次行动

2.2 真正的刚需#

“训练记录、饮食记录、计划饮食”是功能语言；用户真正购买的是：

• 今天到底练什么；
• 这一组和下一组做多重、几次、休多久；
• 器械被占、时间不足、出差、漏练或状态差时怎么办；
• 最近有没有进步，为什么没有进步；
• 今天还应该怎么吃；
• 如何用尽可能少的时间、认知和记录成本持续获得身体变化。

因此，最关键的产品判断是：

2.3 市场机会#

市场已经从内容和日志向算法与智能教练演进：

内容/课程 → Tracker → Planner → Adaptive Coach → Autonomous Fitness OS

计划生成、动作库、拍照识餐和聊天都已高度商品化。真正仍值得竞争的是：

1. 训练中几秒内完成的低摩擦交互；
2. 稳定计划中的透明、小步、可撤销调整；
3. 商业健身房真实器械与现场冲突的处理；
4. 训练、饮食、恢复和身体结果之间谨慎的长期归因；
5. 中国语言、器械、外卖、食堂和 Android 生态的本地闭环；
6. 从建议到选择、实际执行和后续结果的个体响应数据。

3.1 训练与身体变化的底层模型#

原材料从生理与产品两个层面描述了同一件事。

训练层面：人体通过外部负荷打破既有稳态，再在恢复中发生适应。力量和增肌的关键刺激包括机械张力、足够的训练量与渐进超负荷。一个最简化的训练容量表示是：

Volume = Σ（负荷 × 重复次数）

它只是粗略代理，不足以表达动作差异、活动范围、速度、技术质量、RIR、器械力学和个体反应。因此产品不能把“总吨位更高”自动解释为“训练更好”。

体重和体成分层面，长期变化受能量平衡影响：

能量存储变化 = 摄入能量 − 总能量消耗
TDEE = BMR + TEF + NEAT + EAT

但单日摄入、体重和手表消耗都存在噪声。产品应观察足够长的摄入与体重趋势，再更新能量估计，而不是把公式或腕表当天读数当成绝对真相。

3.2 产品价值模型#

产品能够直接改变的不是肌肉本身，而是安排、执行、记录、学习和调整。材料中两种表达可以合并为：

长期结果 ≈ 有效刺激 × 恢复 × 营养 × 执行一致性 × 时间

用户净价值 ≈ 更好的下一步决策
             − 输入成本
             − 认知负担
             − 不信任与错误风险

这是一个乘法系统：计划再科学，如果用户无法持续执行，价值接近零；记录再完整，如果不能改变下一步，也只是一份档案；AI 再会聊天，如果会污染数据或给出不可解释建议，反而降低信任。

3.3 产品应回答的五个问题#

所有核心功能都应至少回答一个问题：

1. 今天练什么？
2. 下一组做多少？
3. 现实条件变了怎么办？
4. 训练是否有效，为什么？
5. 训练之外，饮食或恢复要改变什么？

不能改变行动的分数、日报、徽章、泛泛鼓励和聊天内容，都不应成为首要功能。

4.1 广义用户分层#

训练指导深度与饮食记录深度应独立选择。同一个人可以训练很专业，但完全不愿意记录饮食；也可以需要饮食教练，却只做简单跟练。不能用一个“新手/高手”开关包办所有偏好。

4.2 首发滩头用户#

材料中最明确、最适合小团队验证的 ICP 是：

• 中国商业健身房用户；
• 每周力量训练 2–5 次，已持续至少 8 周，典型经验为 3–18 个月；
• 目标是增肌、力量或减脂保肌；
• 知道基础动作，但不真正懂 programming，或不愿持续维护表格；
• 当前使用训记、Strong、Hevy、表格、笔记，或因麻烦/无反馈放弃过记录；
• 没有长期私人教练；
• 愿意接受建议，但要求知道为什么并保留控制权；
• Android 优先。

首版暂不纳入医疗康复、疾病处方、孕产、专项竞技备赛、药物相关建议、完全依赖视频跟练的零基础用户、实时多人课程和教练工作室 SaaS。

4.3 为什么不是“所有想健康的人”#

纯新手需要大量内容、动作教学和安全支持，且流失率高；超级高手已有成熟计划、表格或教练，对算法容错低；规律训练但不会系统编程的人已经有高频行为和历史数据，又持续面临“下一步怎么做”的问题，更容易形成日常工具和付费价值。

5.1 八类核心问题#

5.2 四类基础摩擦#

• 物理与器械摩擦：配重跨度、不同品牌器械、器械占用、空间和噪声限制。
• 认知与交互摩擦：组后疲劳、湿手、手套、呼吸未平、注意力切换，却还要解锁、查动作、输入数字。
• 营养记录摩擦：称重、搜索、混合餐、油脂、份量与外卖信息不完整，造成记录疲劳。
• 反馈与心理摩擦：身体变化以月或季度发生，而用户需要即时反馈；遗漏或未达目标容易触发“已经失败”的破窗效应。

5.3 关键时刻地图#

6.1 训练记录#

力量训练记录是基础设施。完整能力包括：动作、热身组、工作组、递减组、超级组、Rest-pause、AMRAP、单侧动作、重量、次数、RPE/RIR、休息时间、PR、e1RM、容量、备注、器械设置、盘片计算、单位和负荷口径。

但“能记录”没有竞争优势。需要做到：

• 自动带出同动作、同器械下的最近记录；
• 区分计划值与实际值；
• 点一次保存并开始休息；
• 原地修改、撤销误触；
• 训练中断后恢复；
• 离线优先；
• 支持导入、导出和长期数据所有权；
• 从手动输入逐步演进到预测、确认、语音、穿戴和视觉自动采集。

6.2 训练计划与渐进超负荷#

计划不是一张固定表，而是稳定周期内不断处理现实变化的系统。完整能力包括：

• 自建计划、模板计划和外部计划导入；
• 目标次数区间、双进阶、RIR/RPE 调节；
• Top set + back-off；
• 周训练量、频率、完成率和动作趋势；
• 连续退步、平台期和减载提示；
• 按实际完成推进，不机械绑定自然周；
• 临时变化与长期计划修改分开；
• 所有变化保留原因、版本和撤销入口。

系统不应输出“唯一正确重量”，而应给出受约束的候选、依据和不确定性。用户覆盖建议不是错误，而是个体响应数据。

6.3 现场动态重排#

这是材料中最一致的高价值方向之一：

• 器械被占；
• 当前器械损坏；
• 换了健身房或回家训练；
• 只剩 20/30/45 分钟；
• 不适或疼痛；
• 漏练、出差、生病后回归；
• 忘带护具或场地有噪声限制。

替换不能只按同肌群匹配，应同时考虑动作模式、稳定需求、阻力曲线、训练目标、前序疲劳、当前器械、个人历史与技术熟悉度。不同器械之间通常不能直接宣称重量等效，应提供保守起始值和首组校准。

计划变化至少区分：

• 单次替换；
• 当周重排；
• 长期计划修改。

6.4 Adherence Engine 与最低有效训练#

原材料提出了两个重要且不应丢失的方向：

• Adherence Engine：现实打乱计划时，重排本周而不是把用户标记为失败。例如漏掉 Pull 日后，将 Push/Pull 合并为 46 分钟上肢训练，删掉重复孤立动作，保留主要刺激。
• Minimum Viable Workout：用户今天不想练或时间极少时，给出 15–20 分钟的最低有效版本，优先保住最重要动作和本周连续性。

这比连续打卡火焰更符合长期坚持。产品目标不是让用户每次完成原计划全部内容，而是在现实约束下仍完成足够有意义的训练。

6.5 Progress 与平台期诊断#

进步页不应只是图表集合。完整输出应包括：

• 同动作、同器械、同口径的重量与次数趋势；
• e1RM、容量、频率、完成率和 RIR 趋势，并标明估计属性；
• 自重动作的变式、活动范围与质量；
• 有氧的时长、强度和可比条件；
• 体重趋势、围度和自愿照片；
• 肌群层面的进展、停滞和可能原因；
• “Why?” 入口：展示某项建议引用了哪些事实。

Plateau Detective 的理想输出不是“检测到平台期”，而是按训练、营养、恢复、执行和数据质量逐项排查，然后建议最小实验。例如增肌期体重三周未上升、两个主项停滞、训练完成率良好时，才把能量盈余不足作为候选原因，并先小幅增加热量、保持训练不变进行观察。

6.6 饮食记录与 Nutrition Copilot#

饮食不是对所有用户都相同强度的刚需，但对减脂、增肌和体重管理人群很重要。产品应提供三档精度：

输入并集包括照片、语音、文字、条码、营养标签、历史食物、订单/菜单截图和批量食谱。正确流程是：

照片或描述
→ 食物候选
→ 个人实际份量
→ 营养数据匹配
→ 不确定项追问
→ 用户确认
→ 结构化记录

系统应表达最大误差来源，如油、酱汁、肉类脂肪比例和碗深；输出区间而非个位数千卡的假精确。

6.7 下一餐、备餐与现实饮食计划#

饮食产品真正应回答“下一顿吃什么”，而不是只显示“还剩 720 kcal”。完整形态包括：

• 下一餐助手：根据剩余热量、蛋白质、训练时间、口味和可购买条件给 2–3 个选项；
• 外卖选择助手：将麦当劳、沙县、麻辣烫、海南鸡饭等现实选项组合到当天目标内；
• 食堂模式：记住档口、个人碗盘和常吃份量；
• 家庭合餐：区分整盘与个人摄入；
• 自炊/备餐：生重熟重、成品总量、分餐比例和采购清单；
• 火锅/烧烤：承认高不确定性，只给粗估和后续结构建议；
• 约束模板：例如“早餐 30–40g 蛋白 + 一份水果”，而不是固定鸡胸肉西兰花七日菜单。

产品不应用羞辱或补偿逻辑处理一顿偏离，不因吃多一餐要求惩罚性有氧或第二天极端节食。长期采用 MacroFactor 式的顺应中立原则：根据足够长的体重与摄入趋势逐周调整。

6.8 训练与营养联合#

长期差异化在于把训练与饮食联系起来，但必须避免错误归因。联合复盘顺序应是：

1. 检查记录完整度和单位；
2. 确认动作、器械和技术条件是否可比；
3. 检查生病、中断、睡眠、压力和主观状态；
4. 观察体重和摄入趋势；
5. 一次只改变一个主要变量；
6. 用 1–2 周后续数据判断调整是否有效。

不能把手表消耗机械加回可吃额度，也不能因为一次训练下降就断言热量不足。

6.9 动作库、器械库与 Gym Profile#

动作库是入场券，不是单靠数量形成的壁垒。每个高质量条目应包括：

• 标准名称、中文俗称、英文别名和用户私人别名；
• 单双侧和负荷口径；
• 器材、座椅、靠垫、握把和起始位置；
• 10–25 秒真实示范、多角度、静音字幕；
• 最多三个关键提示和常见错误；
• 动作模式、主/次肌群和稳定需求；
• 按原因组织的替代：器械被占、疼痛、居家、技术难；
• 不同替代的不等价之处；
• 用户自己的设置、重量、备注和历史表现。

Gym Profile 需要记录不同场地的真实设备、哑铃范围、最小增量、配件、空间、固定点和噪声限制。用户可以有主健身房、公司健身房、小区健身房、家和酒店配置。选择场地后，训练立即按真实器械重新计算。

器械识别分三步演进：

1. 用户从常见模板勾选“我的健身房”；
2. 扫描二维码或铭牌，匹配品牌和型号；
3. 图片辅助识别设备类别、配重单位与可调范围，始终允许人工修正。

仅凭外观不能断言阻力曲线、滑轮倍率或等效自由重量。识别的终点不是给出名称，而是让用户能设置、使用，并与当前计划连接。

6.10 导入、导出与长期记忆#

迁移成本是用户换产品的核心障碍。完整导入范围包括：

• CSV、Excel、Strong/Hevy 等导出文件；
• 截图、PDF、教练发来的计划；
• 文字、微信聊天、纸质训练本照片；
• 外部健康与设备活动。

AI/OCR 负责结构化草稿，动作别名和单位映射后由用户确认。无法匹配的内容暂存，不应静默丢弃。

长期记忆必须区分：

• 事实：上次训练记录；
• 偏好：不喜欢某动作、常吃某餐；
• 临时情况：今天没睡好、今天没有哑铃；
• 模型推断：可能更适合某个次数区间。

所有记忆可查看、编辑和删除；AI 推断不能未经确认永久固化。

6.11 社交、问责和教练协作#

传统 Feed 不适合首版，但社交需求并非不存在。合理演进顺序是：

1. 两个朋友之间的训练提醒和“一起练”；
2. 训练伙伴复制计划；
3. 教练查看训练记录、异步点评和修改计划；
4. 在真实协作关系上自然生长社区。

社交应默认可关闭，不能干扰只想训练和记录的用户。

7.1 为什么力量训练适合语音#

一场 6 个动作 × 4 个工作组的训练可能要求用户几十次拿手机、解锁、定位字段和输入数字。问题不只是每次几秒，而是每组都发生注意力切换。

训练上下文高度明确：系统知道当前动作、当前组、计划重量、目标次数、上一组和休息状态。因此用户无需每次说完整句子：

第一组：“80，8 个。”
第二组：“9 个。”
第三组：“8 个，RIR 1。”
第四组：“7 个，力竭。”

7.2 完整命令并集#

支持两种使用模式：

• Live Mode：每组后即时说短命令；
• Dump Mode：训练后一次口述整场，系统生成结构化记录供确认。

7.3 Workout State Machine#

语音能力的核心不是 LLM，而是训练状态机：

WorkoutSession
├── currentExercise / currentSet / currentWeight
├── targetReps / targetRIR
├── previousSet / previousSession
├── restTimer / exerciseQueue / supersetGroup
└── equipment / unit / loadSemantics

处理链路为：

Push-to-talk
→ VAD / ASR
→ 数字、单位与别名归一化
→ 注入 Workout Context
→ 规则优先的 Intent / Entity Parser
→ 置信度与合理性校验
→ WorkoutCommand
→ Workout State Machine
→ 本地数据库
→ Progression Engine

规则无法确定时才使用 LLM fallback。LLM 只能输出受 schema 约束的命令，不能直接写数据库。

7.4 中文领域难点#

• 同一个重量可能说成“三十二点五”“32.5”“三二点五”“三十二半”；
• “下拉”在背部日可能是高位下拉，在三头日可能是绳索下压；
• 用户会使用“小飞鸟”等私人别名；
• “哑铃 30 公斤”通常指每只，但容量统计必须明确；
• 辅助引体的数字方向与普通负重相反；
• “两边各三个片”“史密斯两边二十加十”需要盘片和器械语义。

动作 schema 至少要区分 LOAD、ASSISTANCE、BODYWEIGHT、BODYWEIGHT_PLUS、PER_HAND_LOAD、MACHINE_STACK 和 PLATE_PER_SIDE。

7.5 反馈与风险#

正常情况优先震动和视觉瞬时确认，不让耳机一直说话；只有低置信度或异常值才追问。应使用个人历史范围拦截“80 kg 被识别为 180 kg”等错误。

MVP 使用 Push-to-talk，不做持续监听，原因包括电量、隐私、误触发、旁人讲话和健身房噪声。语音不能成为唯一输入：推荐顺序是预测/预填、一键确认、语音、手动编辑。

最大商业风险是用户不愿在公共健身房说话。语音是否成立必须看第 4 周留存、纠错率和相对触控节省，而不是首日新鲜感。

8.1 Zero Logging 路线#

自动记录的长期演进路径是：

手动输入
→ 上次数据预填与一键确认
→ 上下文语音
→ 手表快捷记录
→ 穿戴传感自动识别动作与次数
→ 视觉识别器械、配重、ROM 与速度
→ 训练自然发生，记录成为副产品

Motra 等产品已经展示利用手表加速度计识别动作和次数的方向；SmartGym 展示了脱离手机的手表训练体验。这说明方向可行，但动作覆盖、误识别、重量获取和平台差异仍需实测。

8.2 动作视频反馈#

长期可观察信号包括：重复次数、节奏、活动范围、左右差、杠铃路径、深度、躯干角度和组内速度衰减。可交付流程应为：

用户主动选动作并录制
→ 检查机位与可见性
→ 关键点/时序分析
→ 只输出 1–2 个可观察提示
→ 回放对应时间点
→ 展示置信度并允许“看错了”反馈

第一批只做少量动作，例如深蹲、卧推、硬拉、RDL、引体、俯卧撑、弯举和肩推。做好 8 个动作比做 500 个低质量检测更有价值。

不能从单相机直接输出疼痛原因、伤病诊断或“动作 96 分所以可以加重”。遮挡、机位、衣着、体型、光线和器械都会影响结果；低质量输入必须主动拒评。

8.3 VBT 与异步诊断#

另一条更克制的视觉路线是：

• 局部追踪杠铃或握把的垂直位移；
• 估算向心平均速度与速度衰减；
• 用作疲劳与组内表现的辅助信号；
• 在组间或训练后异步回放，而不是负重过程中持续说话。

VBT 仍需可靠标定，不能把单目估算当成实验室测量。其价值是补充主观 RIR，而不是取代用户感受与训练规则。

8.4 隐私设计#

若未来处理动作视频，建议端侧先做人脸检测与打码，上传前显示预览并允许手动补涂；原始含脸视频默认不出端。摄像头、麦克风、穿戴和健康数据按功能单独授权，用户拒绝任何非核心权限后仍能完整训练。

9.1 中国产品#

9.2 训练记录与计划产品#

9.3 居家、内容与适配产品#

9.4 营养产品#

9.5 教练平台与综合 Agent#

9.6 自动识别专项#

Motra 代表 wearable-first 自动动作与次数识别；语音专项产品包括 Kratos、Liftly、SLAB、GhostFit、Gym Journal、RepTalk、SayLift、JoT。它们共同验证训练记录摩擦存在，但多数仍停留在 Voice Input。真正的差异应是上下文、状态机、修正、替换和后续决策。

将所有竞品放在一起后，可以看到八个结构性缺口：

1. 记录与教练分裂：记录器有数据但不下判断，AI 教练下判断却缺可审计组级数据。
2. 推荐在黑盒中：用户看不到依据、改变了什么、没改变什么，也不能局部撤销。
3. 把变化当个性化：每天生成新训练看起来智能，却破坏技术练习和可比基线。
4. 输入精度与反馈精度不匹配：照片、手表和主观状态有噪声，却输出过于精确的数字。
5. 训练当下仍像填表：导航、键盘、同步和错误恢复在最需要专注时制造摩擦。
6. 现实变化没有进入计划内核：器械、时间、地点和漏练仍由用户自己解决。
7. 本地语境不足：中文动作别名、器械品牌、外卖、食堂、国产 Android 和健康平台没有形成深层闭环。
8. 长期数据没有变成响应模型：产品知道“用户做了什么”，却不知道“什么调整对这个人在什么条件下有效”。

11.1 两种信息架构建议#

材料提出了四入口和五入口两种形态。

四入口版本：Today、Train、Eat、Progress。适合营养是核心组成的长期产品。

五入口版本：今天、训练、进展、动作、我的；营养根据用户目标嵌在今天和进展中，也可作为可选入口。适合训练优先的首发产品。

共同原则是：AI 不成为独立主导航，不把聊天框放首页；AI 出现在换动作、下一组、今晚吃什么、这周怎么调等具体对象旁边。

11.2 Today#

Today 是产品大脑，可能读取：训练计划、上次训练、训练频率、身体重量趋势、肌肉酸痛、可选睡眠/HRV、昨天训练、饮食状态、当前位置和 Gym Profile。

用户只需回答真正会改变计划的问题：感觉、异常不适和可用时间。输出一份稳定周期内的“今日最佳解”，不是重新随机生成计划。

理想首页可以非常简单：

Upper A · 48 min · Hypertrophy
身体状态：Good

今天卧推建议 +2.5 kg
原因：前三次训练均达到目标次数

[开始训练]

Nutrition（可选）
1680 / 2450 kcal
Protein 116 / 170 g
晚餐优先补约 54 g 蛋白质

11.3 Train#

训练界面只显示动作、上次、本次、目标与计时。高级字段按需展开。任何智能建议不能阻塞记录；用户拒绝建议后仍可继续训练。

11.4 Eat#

Eat 的存在取决于用户是否启用营养。它不是第二个 MyFitnessPal，而是展示体重趋势、蛋白质和热量方向、常用餐、下一餐与可选精确记录。

11.5 Progress#

Progress 先回答“是否进步”和“下一步改什么”，再允许进入详细图表。训练、体重、围度、营养和恢复按目标显示，不制造统一健康总分。

11.6 动作与我的#

动作入口用于当前计划、最近使用、当前场地和可搜索完整库；“我的”管理目标、限制、设备、Gym Profile、数据权限、导入导出、算法控制和隐私。

12.1 晚高峰商业健身房#

用户在入场前说今天精神疲劳、下背轻微酸胀。系统结合近期训练和可选睡眠信号，把站姿推举替换为有靠背版本，并解释只是当天调整。到馆后卧推架被占，用户点击“器械被占”，系统给出三项候选、展示差异和保守起始重量。训练中每组一键或语音记录，计时自动开始；若视觉/VBT 已启用，只在满足机位和置信度时给组后反馈。训练完成后说明下次变化，并把本次替换保持为单次事件。

12.2 居家 20 分钟且需要安静#

系统读取 Home Gym Profile，保留主要推、拉、蹲/髋动作，把转换和休息计入 20 分钟预算，不推荐跳跃。固定哑铃过轻时，用变式、幅度、次数或节奏作为不同版本记录，不伪造成与原动作相同的力量 PR。

12.3 减脂期公司食堂#

用户拍个人餐盘，确认米饭只吃半碗、某道菜只吃一部分，油量未知则保留估算标签。用户可只保存照片与份量，不被迫补齐调味料。晚餐提供两个现实选择，周复盘不因一顿估算偏高要求补偿性运动。

12.4 停训两周后回归#

保留原计划，询问中断原因和当前状态；第一节采用校准或保守版本，不直接强推离开前峰值。训练后根据实际完成更新下一次，一周后检查回归是否顺利。

12.5 错误状态#

识别失败可手动录入；网络断开可继续训练；计划没有合适替代时说明缺什么；导入无法匹配时暂存；用户拒绝建议仍能训练；模型不可用时回退到上次计划和确定性规则。错误路径必须和正常路径一样被设计。

13.1 分层架构#

交互与感知层
触控 / 语音 / Watch / 摄像头 / 健康平台
                ↓
状态与事件层
Workout State Machine / Local Event Store / Plan Version
                ↓
安全与约束层
单位、器械、时间、疼痛、安全、最大变化幅度、权限
                ↓
候选与决策层
规则引擎 / 时间序列特征 / 个体响应模型 / 排序
                ↓
知识与长期记忆层
Exercise Graph / Gym Equipment Graph / Personal Fitness Graph
                ↓
LLM 与多模态层
结构化输入、解释、总结、异常追问、食物/器械候选
                ↓
反馈闭环
接受 / 修改 / 拒绝 / 原因 / 实际执行 / 后续结果

13.2 技术职责#

13.3 核心数据对象#

13.4 Local-first 与平台连接#

核心训练日志必须由应用本地数据库掌握：写入立即成功，后台增量同步，支持事件去重、冲突合并和崩溃恢复。服务端保存规则版本和建议快照。LLM 异步化，模型离线不影响训练。

Health Connect 可承载训练会话、计划训练、营养、睡眠、体重等数据，但中国设备生态不能假设单一接口稳定覆盖所有厂商，应设计可插拔适配器并逐家验证。

13.5 四类长期数据壁垒#

• Personal Fitness Graph：动作、负荷、恢复、营养、表现和身体变化的纵向关系。
• Exercise Knowledge Graph：动作、肌群、动作模式、器械、难度、替代和不等价关系。
• Gym Equipment Graph：具体场馆的器械、型号、可调参数、配重范围和用户确认。
• Response Model：什么调整对什么人在什么条件下有效。

真正难复制的是最后一类：例如某用户在胸部每周 12 组时进步最快，16 组后表现下降；RIR 1–2 依从性最好；每周四练的完成率明显高于五练。

14.1 产品边界#

• 定位一般健身与行为辅助，不宣称诊断、治疗或预防疾病；
• 新发、严重、持续或伴随异常的疼痛触发停止/专业评估提示；
• 特殊人群和既往病史不由通用对话生成计划；
• 高风险规则先于 LLM，LLM 只解释批准文本；
• 训练、营养、恢复和视觉结论标出数据来源、估计属性与不确定性。

14.2 信任功能#

材料涉及《个人信息保护法》、生成式 AI 和算法推荐等中国法规。本文仅保留产品风险清单，不构成法律意见；正式上线前需按具体数据流、服务性质和地区由专业律师审查。

15.1 付费边界#

统一逻辑是：

Free = 好用的 Tracker
Pro  = 持续替用户做决定的 Coach
Credits = 高推理成本的多模态能力
Human / B2B = 后期服务与组织能力

基础记录、常用动作、基本计时、历史访问和数据导出不应被人质化。免费层的任务是建立习惯、积累高质量数据和信任。

15.2 Free / Pro 功能并集#

15.3 Pro 真正售卖的价值#

1. Decide for me：今天练什么；
2. Tell me how much：这一组/下一次用多重；
3. Adjust for me：根据表现、时间、器械和疲劳改计划；
4. Tell me what went wrong：平台期为什么发生；
5. Tell me what to do next：把洞察直接应用到下一周。

付费墙应展示具体结果，例如“下一次卧推建议 82.5 kg，原因是最近三次达到次数区间且 RIR 合格”，而不是只写 Smart Progression。

15.4 付费时刻#

• 完成约 3 次训练，系统首次具备个体建议；
• 完成第一周，形成第一份周复盘；
• 连续多次无增长，出现平台期分析需求；
• 连续 7 天营养与体重数据，开始估计个体 TDEE；
• 刚破 PR 后展示下一次建议。

比下载当天开始 7 天倒计时更合理的方式是：先免费完成 3 次训练，再开启 14 天 Pro 体验。

15.5 价格、Credits 与后续业务#

材料给出的中国候选测试区间包括：

• Launch：约 ¥18/月、¥118/年；
• 常规：约 ¥28/月、¥168/年；
• 成熟：约 ¥38/月、¥228–268/年；
• 另一套研究建议直接测试年费 ¥168 / ¥228 / ¥298。

这些都是实验输入，不是已经验证的最优价格。第一版只做 Free / Pro 两档，不做永久 AI 会员。

视频分析等高计算成本能力可采用订阅内少量额度 + 按次包，例如每月 5 次、额外购买 10/30 次。它不应拖累普通训练订阅的毛利。

后续路线包括：

• Coach Pro：教练查看学员完成率、趋势与 AI 建议，再由教练批准；
• Gym OS：为健身房提供会员 AI Coach、器械档案和匿名化运营洞察；
• 真人复核：高风险或高价值案例升级给专业人员。

这些都在 C 端核心闭环成立后再做。

16.1 研究顺序#

1. 20–30 名目标用户深访；
2. 至少 10 次真实训练现场观察；
3. 收集最近两周真实计划和记录；
4. 用相同任务对照训记、Strong/Hevy、Fitbod、Keep、MacroFactor 等；
5. 用 Figma 或人工后台模拟建议；
6. 10 名设计伙伴连续两周；
7. 40–60 人 4–6 周核心可用性试验；
8. 100–200 人至少 8 周付费 Beta；
9. 若要宣称长期效果，再做更长时间、按预期效应设计的对照研究。

16.2 指标并集#

16.3 停止条件#

• 用户仍回到原日志，主记录迁移率持续低于目标；
• 合格建议接受或轻改持续低于约 35%；
• 产品必须强迫用户输入大量字段才有价值，导致留存明显下降；
• 营养增加大量维护和客服，却不改善训练留存或结果；
• 视觉在教练标注集上无法达到准确与安全弃权阈值；
• 核心价值必须依赖医疗宣称或无法合规取得的数据；
• 8 周后用户只觉得“更智能”，却没有减少决策时间、迁移主记录或形成建议反馈闭环。

17.1 第一阶段：AI 力量训练记录 + 自适应教练#

• 极速 logger、历史、计时、离线；
• 稳定计划和渐进超负荷；
• 动作替换、时间压缩和漏练重排；
• Gym Profile、动作内容与导入；
• 可解释周复盘；
• 上下文语音作为减负能力。

目标组合可概括为：Strong 的记录体验 + Fitbod/Alpha 的自动建议 + MacroFactor 的数据思想 + Planfit 的 Gym Context。

17.2 第二阶段：训练与 Nutrition 联动#

• 体重趋势、热量和蛋白质方向；
• 三档饮食记录；
• 图片、语音、订单和菜单输入；
• 动态 TDEE；
• 下一餐和周复盘；
• 谨慎的训练—营养联合归因。

17.3 第三阶段：自动感知与“魔法”#

• Watch 自动动作与次数识别；
• 少量动作 Camera Form Feedback；
• VBT 与组后异步诊断；
• 器械、铭牌、配重块和 weight stack 辅助识别；
• Gym Equipment Graph 与众包确认；
• 走到器械旁自动弹出该机器的目标设置和重量。

17.4 第四阶段：教练与组织网络#

• 教练协作和人工复核；
• Accountability 与训练伙伴；
• Coach Pro；
• 健身房 B2B；
• 更广人群、居家专项、有氧与其他运动引擎。

完整愿景可以很大：训练、饮食、恢复、器械、语音、视觉、穿戴、教练和场馆最终会汇入一个长期个人体能系统。

但产品的精神必须始终保持简单：

用户不应该管理一个健身 ERP，也不应该在深蹲组间做 prompt engineering。系统越复杂，前台越应该只给少量、可信、可执行的动作。

最具穿透力的定位不是“AI 生成计划”“拍照算热量”或“2000 个动作”，而是：

长期文案可以是：

本索引用来检查“并集”是否完整。它不是再次摘要，而是标明每份原材料的独有内容在总报告中的去向。

A.1《语音力量训练·产品思考》#

A.2《AI 健身产品深度拆解》#

A.3《AI 健身房应用·产品思考与商业化设计》#

A.4《AI 原生健身应用研究报告》#

A.5《AI 健身产品研究：从规律训练者真实需求出发》#

A.6《AI 健身应用：从第一性原理到六个月可验证产品》#

以下是原材料出现过的具体技术候选。它们属于待评估选项，不代表已经确定选型。

B.1 语音与端侧推理#

ASR 必须做接口抽象，不锁死一家。评估数据要来自真实健身房录音，并包含拒识与追问率，不只测试安静办公室。

B.2 视觉与跟踪#

打码区域可在检测框外增加约 15%–20% 缓冲，防止转头或抬头时短暂露脸；这一参数仍需在真实视频中验证。

B.3 时间序列与知识层#

原材料提到 Neo4j、卡尔曼滤波、贝叶斯模型等实现方向。是否采用取决于数据量、可解释性和团队能力；首版用关系表和确定性规则即可验证产品价值。

该矩阵保留原材料更具体的额度设想，正式上线前应通过真实付费实验简化，不建议原样全部启用。

商业化禁忌仍然成立：不限制基础组数、不完全封锁 AI 体验、不用“AI”包装每个普通功能、不做去广告型会员、不以内容数量作为主要付费价值、不扣押数据导出、不直接售卖聊天轮次。