AI 健身产品方向与完整执行方案

1.1 现在做什么#

现在应该做一款：

首版不是内容平台、不是 AI 聊天壳、不是饮食大全，也不是摄像头健身玩具。它必须先成为用户真正愿意替换现有日志的主训练工具，然后才有资格成为 AI 教练。

1.2 产品三层定义#

当前要完整设计三层的数据基础，但只把前两层做到可验证可使用。

1.3 一句话承诺#

对外可测试三种表达：

1. 不再猜下一次怎么练。
2. 记住你的训练，适应今天的条件，告诉你下一步。
3. 你负责练，剩下的交给我们。

第一句适合首版获客，第二句适合产品说明，第三句适合长期品牌愿景。

1.4 为什么选择这个切口#

• 目标用户每周重复训练，频率足够高；
• 已有日志、表格或计划，痛点和迁移行为可观察；
• “下一组/下一次怎么做、器械被占怎么办”比泛健康建议更具体；
• 训练数据天然形成纵向反馈闭环；
• 中国已有强记录器和综合平台，但“透明决策层”仍可验证；
• 可以从确定性规则开始，不依赖大模型幻觉；
• 后续能自然连接语音、营养、穿戴、视觉、教练和场馆。

2.1 首发用户#

必须同时满足大部分条件：

• 每周力量训练 2–5 次；
• 已持续至少 8 周，典型为 3–18 个月；
• 目标是增肌、力量或减脂保肌；
• 知道基础动作，但不会或不想独立做长期 programming；
• 正在用训记、Strong、Hevy、表格或笔记，或曾因麻烦/无反馈放弃；
• 没有长期私教；
• 主要在商业健身房训练；
• 使用 Android，愿意让软件建议但要求保留控制权。

2.2 共同设计用户#

邀请少量高级训练者和教练作为红队与规则审核者。他们不是默认用户，但可以发现单位、组型、器械、RIR、周期和特殊动作中的漏洞。

2.3 首版不服务#

• 术后康复、疾病处方、孕产和需要医疗监督的人群；
• 专项竞技备赛和药物相关建议；
• 完全依赖视频跟练、没有动作基础的零基础用户；
• 只想要食谱、减重打卡或社交内容的人；
• 教练工作室 SaaS、健身房运营系统和多人直播课程。

不服务不是永久放弃，而是避免在产品还没有核心闭环时承担不同内容、责任和销售模式。

3.1 先行动，后聊天#

默认展示已经算好的可执行卡片。用户只有在异常、解释和补充输入时才进入自然语言。AI 不占据独立主导航，首页不放大聊天框。

3.2 稳定优于新奇#

计划应在数周内保留可比较基线。只有证据达到阈值才调整，每次尽量只改一个主要变量。每天生成全新训练不是个性化。

3.3 Zero-Friction First#

交互优先级：

系统预测/预填
→ 一键确认
→ 加减或长按小改
→ 语音处理复杂情况
→ 完整手动编辑兜底

Voice First 是手段导向，Zero-Friction First 才是用户价值导向。

3.4 用户拥有控制权#

所有建议都允许接受、修改、拒绝和撤销；所有长期变化显示作用范围；所有数据可导入、导出和删除。拒绝建议不会降低基础功能。

3.5 承认不确定性#

营养给区间，视觉给置信度，恢复给弱信号，器械重量给保守校准。数据不足时系统应保持、不判断或询问关键问题，而不是编出答案。

3.6 复杂性留在系统内#

后台可以有状态机、规则、时间序列、知识图谱和模型；前台训练界面只能有当前动作、上次、本次、目标和计时。Complexity in the system, simplicity for the user。

3.7 结果优于功能数量#

成功不是动作更多、AI 对话更长、生成计划更多，而是用户更快开练、训练不被打断、现实变化后仍能完成、下一次更清楚，并长期把它当主工具。

4.1 首版五入口#

营养首版作为可选模块嵌入“今天”和“进展”，验证后再决定是否成为独立 Eat 入口。长期产品可回到 Today / Train / Eat / Progress 四入口。

4.2 全局 AI 入口#

可以保留一个低权重的“问教练”，但它读取的是用户结构化数据，并优先执行产品动作：

• “今天只有 30 分钟” → 生成缩短版本；
• “下周出差” → 调整当周/下周安排；
• “不喜欢保加利亚分腿蹲” → 更新偏好并给替代；
• “把这张计划截图导进来” → 生成待确认计划；
• “为什么卧推不涨” → 打开平台期分析。

不要把它做成另一个只能泛聊健身的 ChatGPT。

6.1 首次使用与导入#

首次只问影响安全和训练安排的信息：

• 目标：增肌、力量、减脂保肌；
• 训练经验；
• 每周可训练天数和单次时间；
• 主要健身房与器械；
• 已知动作限制和需专业处理的情况；
• 使用模式：自主记录、辅助建议或带练；
• 是否已有训练计划。

不得根据身高体重直接猜工作重量，也不要求新用户做 1RM 测试。

已有计划用户可以：

• 选择模板后修改；
• 从 CSV/表格导入；
• 粘贴文本；
• 后续使用截图、PDF 或聊天内容解析。

首次训练作为校准。熟悉动作可直接输入工作组；新动作给保守起始范围并要求用户确认。所有重量明确 kg/lb、单只/总重、器械 stack/每侧盘片等口径。

6.2 今天页#

今天页只回答三件事：

1. 今天做什么；
2. 有什么真正会改变行动的提醒；
3. 是否可以马上开始。

首版内容：

Push A · Week 4
预计 52 分钟

今日关键变化
卧推维持 80 kg
原因：上次达到次数，但 RIR 低于加重条件

[开始训练]
[只有 30 分钟]
[今天状态不好]

状态检查只问可用时间、异常疼痛和极端疲劳。可穿戴睡眠/HRV 如果存在只做背景，不每天强迫填问卷，也不能用“睡 5 小时”直接算出“所有动作减重 12%”。

6.3 训练中界面#

一屏一件事：

BARBELL BENCH PRESS
Set 2 / 4

上次：80 × 9 @ RIR 2
目标：80 × 8–10 @ RIR 1–2
本次：80 kg × 9

[−]  [完成]  [＋]
Rest 01:43

[器械被占] [不舒服] [跳过] [更多]

交互规则：

• 计划值预填，点击完成立即本地保存并开始计时；
• 长按或局部点击修改重量、次数和 RIR；
• 滑动撤销上一组；
• 计时结束不自动判定完成；
• 热身组、递减组、超级组、单侧、Rest-pause 按需展开；
• 高级字段默认隐藏，但不丢失专业能力；
• App 切后台、锁屏或崩溃后可恢复；
• 网络和模型不可用不影响完成训练。

6.4 进阶引擎#

首版只做三类可审计规则。

双进阶

• 在目标次数区间内先加次数；
• 连续达到上限，且 RIR/RPE 在目标范围，才增加最小可用重量；
• 加重后回到区间下部；
• 器械最小增量进入计算；
• 不同器械、变式和活动范围不能直接共享 PR。

RIR 当日调节

• 实际 RIR 明显低于目标：下一组保守降重、降次数或保持；
• 实际 RIR 明显高于目标：可小幅加重或增加次数；
• 单次异常不立即改掉长期计划；
• 数据不足时保持上次值。

Top set + back-off

• 只向有足够历史和理解能力的用户开放；
• 顶组用于估计当天能力，回退组按规则计算；
• 若技术、休息或记录异常，降低置信度；
• 不把估算 1RM 当实测 1RM。

6.5 建议展示#

每条建议都包含：

• 建议动作：保持、加重、加次数、减量、替换或重新校准；
• 依据：引用最近哪些可复算事实；
• 变化：具体改了什么，没改什么；
• 置信度：高/中/低及原因；
• 作用范围：当前组、今天、当周或长期；
• 操作：接受、修改、拒绝；
• Why：展开完整解释；
• 撤销：恢复之前版本。

示例：

下次卧推：82.5 kg × 8–10

为什么：最近两次 80 kg 的全部工作组均达到目标次数，
且最后一组 RIR 分别为 2 和 1，符合本计划的加重条件。

变化：重量 +2.5 kg；组数和次数区间不变。
置信度：高

[接受] [改成 81 kg] [保持 80 kg]

6.6 动作替换#

用户点击原因：器械被占、不舒服、不会做、不喜欢、当前场地没有、器械损坏。

候选排序输入：

• 当前训练目标和目标肌群；
• 动作模式与关节运动；
• 稳定需求和阻力曲线；
• 已完成动作造成的疲劳；
• 当前 Gym Profile；
• 用户熟悉度、偏好和历史不适；
• 不同器械负荷语义；
• 预计切换与训练时间。

输出不超过三个候选，每个显示：为什么、主要差异、保守起始负荷、是否只替换今天。

首版不要宣称杠铃卧推 80 kg 精确等于某器械 75 kg。正确方式是引用个人该器械历史；没有历史则给保守校准组。

6.7 时间压缩与 Minimum Viable Workout#

用户选择 15/20/30/45/60 分钟时，系统必须把组间休息和器械转换计入时间预算。

压缩顺序建议：

1. 保留目标优先级最高的复合或主要动作；
2. 保留本周尚未满足的关键刺激；
3. 删除重复孤立动作；
4. 在不破坏安全与表现的前提下安排超级组；
5. 不通过无限压缩休息“塞回”原训练量；
6. 清楚说明删了什么、后续是否需要补足。

当用户“不想练”时，允许选择 15–20 分钟最低有效版本，不用连续打卡羞辱或强迫完成原计划。

6.8 漏练、出差与回归#

计划日历区分计划、实际、跳过和改期。错过训练后给：顺延、合并、跳过低优先动作等选项及影响，不自动把两节完整训练堆到第二天。

出差前根据酒店/自重器械创建临时场地；回归后不直接套用中断前峰值，首节校准，随后逐步恢复。

6.9 训练结束与周复盘#

训练结束只显示：

• 完成了什么；
• 哪些地方与计划不同；
• 下一次会改变什么；
• 系统是否理解正确。

周复盘最多三张决策卡，例如：

• 卧推 +2.5 kg；
• 腿举维持；
• 下周总组数减少 2 组。

每张卡可查看依据和反事实、接受、修改或跳过，并一键应用到下一周。

7.1 首版动作内容#

先做 60 个高频动作；若内容生产能力更强，可扩到 80–120 个，但不能牺牲质量。每个动作必须同时完成：

• 标准名、中英文和常见中文别名；
• 用户私人别名；
• 动作模式、主/次肌群、稳定需求；
• 负荷语义：总重、每手、每侧、辅助、自重等；
• 10–25 秒真实视频和静音字幕；
• 器械设置与起始姿势；
• 最多三个关键提示和常见错误；
• 2–4 个按原因组织的替代；
• 不等价说明；
• 内容来源、授权和审核版本。

7.2 Gym Profile#

每个场地保存：

• 哑铃范围和最小增量；
• 杠铃、深蹲架、史密斯、龙门架和主流固定器械；
• 可用附件和握把；
• 器械品牌/型号和用户命名；
• 座椅、靠背、握把、Cable 高度等个人设置；
• 空间、固定点、噪声和时间限制。

同样标示 50 kg 的两台机器不能直接当作相同外部负荷。不同场地的历史按设备分别保存，并在足够数据后建立个人换算关系。

7.3 器械识别路线#

• v1：用户勾选模板和手动添加；
• v2：扫二维码/铭牌匹配品牌型号；
• v3：照片给 2–3 个设备候选，用户确认；
• v4：加入场馆共享器械图谱和众包纠错；
• v5：与当前位置/近场设备联动，走到器械旁自动调出当前目标。

识别成功的终点是“可以开始训练”，而不是“这是推胸机”。

8.1 语音定位#

语音是记录和控制训练状态的 P1 能力，不能早于可靠触控。价值包括：

• 组后几秒内记录，减少记忆失败；
• 双手被占或戴手套时操作；
• 一句话表达 RIR、修正、递减组和异常情况；
• 直接控制计时、跳过、加组和替换。

8.2 MVP 命令范围#

支持：

• “8 个”“80 公斤 8 个”“8 个 RIR 2”；
• “加 2.5”“减 2.5”；
• “不是 8 个，是 7 个”“刚才作废”；
• “再来一组”“跳过”“休息 3 分钟”；
• “卧推架有人”；
• 简单递减组和超级组；
• 训练后 Dump Mode 批量口述。

不支持：任意开放自然语言、持续监听和无确认的低置信写入。

8.3 状态机与可靠性#

每个语音命令必须绑定当前 WorkoutSession。解析顺序：领域归一化 → 上下文规则 → 置信度 → LLM fallback → schema → 合理性/个人范围 → 状态机事件。

反馈优先震动，其次屏幕，只有异常才语音追问。语音失败不影响触控和训练。

8.4 Watch#

Free/基础能力：当前动作、目标、记录 reps、计时、震动。

Pro/后续能力：下一组建议、Push-to-talk、RIR、离线完整训练、自动动作/次数候选。

Wear OS 可能比手机语音更符合最终场景，但在 Android 设备碎片化和麦克风权限上必须实测。

9.1 首版轻营养#

仅在训练闭环成立后加入：

• 晨重与趋势；
• 目标方向：增肌、减脂、维持；
• 蛋白质下限；
• 热量方向或区间；
• 常用餐和重复餐；
• 最低、快速、精确三种记录模式；
• 用户可以完全关闭。

不自建百万食物库，优先合法数据源、合作、导入或外接。

9.2 拍照与语音记录#

AI 只负责把图片/语言拆成可编辑候选，营养计算交给结构化数据。必须询问影响明显的份量、油和合餐范围，并显示最大不确定项。

示例：

识别：米饭、鸡腿、西兰花
估算：650–790 kcal
主要误差：鸡皮和烹饪油

米饭份量：半碗 / 一碗 / 一碗半
鸡皮：吃了 / 没吃 / 不确定

9.3 下一餐与计划#

不要输出固定七日鸡胸肉菜单。输出可替换约束和现实选择：

• 在家怎么吃；
• 外卖怎么点；
• 食堂怎么选；
• 训练前后如何安排；
• 今天超出后如何平稳处理，而非补偿性节食/有氧。

9.4 动态 TDEE 与联合复盘#

只有摄入和体重数据足够连续时才更新个体消耗估计。数据不足就暂停，不假装知道。

联合分析必须先排除记录、动作和生活中断，再判断训练、恢复或营养。一次只提出一个主要调整，并用后续结果验证。

10.1 先后顺序#

1. 视频只作为用户主动录制与回放；
2. 少量动作计次、节奏和 ROM；
3. 固定机位的深蹲/卧推/硬拉等专项；
4. 局部杠铃/握把 VBT；
5. 穿戴传感与视觉融合；
6. 器械和配重辅助识别；
7. 长期个体动作趋势。

10.2 输出边界#

可以说：后几次活动范围较前几次缩短、向心速度下降、左右轨迹差异增大。

不能说：你有某种损伤、这个动作绝对安全、得分 96 所以应该加重。

低置信度直接拒评，用户可标记“看错了”。所有视频默认私密；含脸视频端侧打码后才允许上传，并提供预览和手动补涂。

11.1 正常训练#

1. 今天页显示 Upper A、预计 52 分钟和关键建议；
2. 用户开始训练；
3. 卧推显示上次、目标和预填值；
4. 用户一键完成，自动计时；
5. 系统基于首组和目标给下一组建议；
6. 训练结束展示偏差和下次变化；
7. 用户确认系统理解正确。

11.2 器械被占#

1. 点击“器械被占”；
2. 系统读取当前刺激目标、已完成动作和 Gym Profile；
3. 展示不超过三个替代及差异；
4. 优先展示该替代动作自己的历史；
5. 无历史则给校准组；
6. 本次默认为单次替换，不永久改计划。

11.3 只有 20 分钟#

1. 用户在今天页选择 20 分钟；
2. 系统保留高优先动作，把休息和切换算入预算；
3. 显示删减内容和对本周影响；
4. 训练完成记为“适配完成”，不是失败；
5. 后续是否补足由周计划决定。

11.4 用户今天不想练#

1. 选择“最低有效版本”；
2. 系统输出 15–20 分钟核心动作；
3. 不使用连续打卡压力和羞辱文案；
4. 仍保留“今天休息”的合法选择。

11.5 漏练一节#

1. 系统展示顺延、合并、跳过低优先内容；
2. 说明每个选择对本周训练的影响；
3. 不自动堆叠两节完整训练；
4. 记录用户选择，作为长期可执行性数据。

11.6 语音记录#

1. 当前为卧推 80 kg，第 2 组；
2. 用户长按耳机/手表说“8 个，RIR 2”；
3. 规则解析并校验；
4. 高置信度保存，手表震动并显示“80 × 8 @ RIR 2”；
5. 低置信度时问“80 还是 85”；
6. 用户可立即撤销。

11.7 食堂饮食#

1. 用户拍个人餐盘；
2. 系统列候选食物与未知项；
3. 用户确认米饭和个人实际摄入；
4. 油量不明保留区间；
5. 晚餐给现实可买的 2–3 个组合；
6. 不因单餐偏离要求补偿运动。

11.8 停训回归#

1. 保留历史与原计划；
2. 询问中断原因和当前情况；
3. 首次采用校准/保守训练；
4. 根据实际表现更新下一次；
5. 一周后检查是否恢复顺利。

12.1 最少输入#

稳定画像：目标、经验、可训练天数、常用器械、动作限制、单位和偏好。

训练事件：动作、器械、负荷、次数、组型、RIR/RPE、休息、完成/跳过、替换和原因。

结果与约束：体重趋势、围度、异常疼痛、极端疲劳、可用时间；穿戴只是背景。

12.2 决策顺序#

1. 硬约束：疼痛红旗、禁用动作、器械、时间、权限
2. 数据质量：历史是否足够、单位是否一致、记录是否异常
3. 有限候选：保持、加量、减量、替换、重新校准
4. 规则排序：目标、近期表现、RIR、疲劳与用户偏好
5. 个体响应：有足够数据时修正候选排序
6. 生成解释：依据、变化、置信度和未判断内容
7. 用户选择：接受、修改、拒绝
8. 后续评估：实际执行与表现是否支持该建议

12.3 建议版本#

任何自动建议都保存：

• 输入事实快照；
• 规则/模型版本；
• 候选列表与排序；
• 最终展示文案；
• 用户选择和覆盖原因；
• 实际完成；
• 后续表现。

这样才能调试错误、做 A/B、形成个体响应模型，也能回答用户“为什么”。

13.1 训练对象#

13.2 未来对象#

13.3 负荷语义#

必须在模型层明确：

• LOAD；
• ASSISTANCE；
• BODYWEIGHT；
• BODYWEIGHT_PLUS；
• PER_HAND_LOAD；
• MACHINE_STACK；
• PLATE_PER_SIDE。

否则辅助引体、哑铃、史密斯、Cable 和配重片器械会污染进阶和容量分析。

14.1 运行架构#

Android / Wear OS / Optional Web Import
                 ↓
Local Database + Event Log + Workout State Machine
                 ↓
Sync / Conflict Resolution / Crash Recovery
                 ↓
Rules & Safety Engine
                 ↓
Candidate Generator + Time-series Features
                 ↓
Recommendation Snapshot / Versioning
                 ↓
LLM Parser & Explainer / OCR / VLM（按需）
                 ↓
Analytics + Evaluation + Personal Response Model

14.2 工程约束#

• 每组先本地写入；
• 原始事实不可被模型静默覆盖，修改产生新事件；
• 同步幂等并处理重复设备记录；
• 单位、单只/总重和器械口径必须进入 schema；
• LLM 输出经过结构校验和业务规则；
• 模型不可用时使用确定性回退；
• 核心流程不依赖云端；
• Health Connect 和厂商平台是适配器，不是真相源；
• 建议和解释必须可重放；
• 数据删除和导出进入自动化测试。

14.3 技术选型原则#

不需要为了营销构建“多智能体教练团”。首版真正需要的是：移动端本地数据库、同步服务、动作知识、规则计算、模型调用与评估日志。

ASR 采用可插拔接口，候选包括端侧/云端方案。训练开始时注入当天动作、用户动作库和领域 hotwords。端侧 VAD/ASR 与服务器复杂解析可分层，但弱网时基础命令仍需可用。

15.1 安全分流#

• 新发、严重、持续或伴随异常的疼痛：停止自动加量；
• 用户可立即停止动作并记录情况；
• 只给保守替代或建议专业评估；
• LLM 不诊断、不推测损伤原因；
• 特殊人群进入独立、经过验证的路径。

15.2 隐私默认#

• 非核心采集默认关闭；
• 麦克风、摄像头、睡眠、位置和健康数据逐项说明用途；
• 图像和视频默认私密；
• 原始含脸视频默认不出端；
• 用户可查看和删除长期记忆；
• 是否用于模型改进单独同意；
• 停订不影响历史访问与导出。

15.3 上线前测试#

• 计划约束是否排除无器械和禁用动作；
• 时间是否包含休息和转换；
• 临时限制是否误写为长期偏好；
• kg/lb、单只/总重、辅助重量和重复导入是否正确；
• 解释引用的历史事实是否可复算；
• 模型无数据时是否主动不判断；
• 弱网、闪退、同步重试、账号迁移和删除是否可靠；
• 疼痛红旗是否始终在 LLM 之前触发。

16.1 招募#

第一轮 20–30 人，建议结构：

• 商业健身房规律训练者为主；
• 交叉覆盖经验、性别、目标和是否记录饮食；
• 至少 10 人当前使用训记、Strong、Hevy、表格或笔记；
• 包含少量曾因记录麻烦而放弃的人；
• 不以“喜欢 AI”作为筛选条件。

16.2 访谈与观察#

必须让用户展示真实记录、计划和购买，不只问观点。核心问题：

1. 把最近一次训练从进门到离开完整讲一遍；
2. 最近一次加重量依据是什么；
3. 哪些字段从来不填，为什么；
4. 最近一次器械被占怎么处理；
5. 哪次训练应用最烦，当时正要完成什么；
6. 如何知道计划有效；
7. 平台期做过什么；
8. 漏练后原计划发生什么；
9. 最近一次记录饮食为何开始或停止；
10. 哪类建议绝不交给 AI；
11. 怎样的解释才足够；
12. 过去一年为日志、计划或教练实际付过多少钱。

现场观察记录：拿手机次数、每组输入时长、误触、查历史、临时换动作、忘记次数、网络问题和训练中断。

16.3 竞品同任务测试#

记录平台、版本、地区、订阅档位和测试日期；免费与付费能力分开比较。

17.1 接下来 14 天#

产品与研究

• 完成招募问卷和筛选条件；
• 招募 20–30 人，锁定 10 名设计伙伴；
• 做 10 次现场训练观察；
• 收集真实计划、日志、截图和导出文件；
• 建立训记、Strong/Hevy、Fitbod、Planfit 的任务对照；
• 用人工教练后台给 10 人连续两周“下一步建议”。

设计

• 只做今天、训练中、快速替换、训练结束、周复盘五个原型；
• 训练卡明确上次—目标—本次—Why；
• 测试一键、长按、滑动撤销和单手可达；
• 设计接受、修改、拒绝及原因采集；
• 不先做品牌动画、社区和聊天。

规则与内容

• 教练审核双进阶、RIR 调节和安全边界；
• 先选 20 个动作完成数据模型和替代图，再扩到 60 个；
• 定义负荷语义和单位规则；
• 明确疼痛红旗、拒绝和回退模板。

工程准备

• 定义核心事件模型；
• 设计本地写入、同步、冲突和恢复；
• 定义建议快照、规则版本和埋点；
• 做最小 Android 会话技术原型；
• 暂不接 LLM。

14 天结束只回答一个问题：目标用户是否愿意把真实计划迁进来，并在真实训练中反复需要“下一步建议”。若仍不清楚，不进入大规模开发。

17.2 第 1–2 月#

目标：成为可替代现有工具的记录器。

交付：

• Android local-first；
• 计划创建和基础导入；
• 60 个动作；
• 组级日志、历史、计时、预填、撤销；
• 热身/工作/递减/超级组等基础组型；
• 离线、同步、崩溃恢复；
• 基础 Gym Profile；
• CSV/JSON 导出；
• 全量行为埋点。

刻意不做：聊天、营养、语音、视觉、复杂图表。

17.3 第 3 月#

目标：记录开始帮助下一次决策。

交付：

• 双进阶；
• RIR 当日调节；
• Top set + back-off；
• Why、版本、置信度；
• 接受/修改/拒绝；
• 周复盘；
• 人工教练审查后台。

17.4 第 4 月#

目标：处理真实世界。

交付：

• 器械替换；
• 30/45/60 分钟压缩；
• Minimum Viable Workout；
• 漏练重排；
• 出差/回归；
• 完整 Gym Profile；
• 疼痛安全分流。

17.5 第 5 月#

目标：降低输入并试探第二闭环。

交付候选：

• Push-to-talk 有限命令；
• Watch 快捷记录；
• Health Connect；
• 体重趋势、蛋白质与热量方向；
• 三档营养记录；
• 照片/语音生成可编辑候选；
• 不自建全量食物库。

这些能力应按用户证据取舍，不要求全部同时上线。

17.6 第 6 月#

目标：付费 Beta 和产品取舍。

• 100–200 名合格用户；
• 至少 8 周 cohort；
• 真实年费或可退押金；
• A/B 测试建议解释长度和付费时刻；
• 删除低使用且不影响结果的功能；
• 完成安全、隐私、导出和删除流程审查。

17.7 六个月以后#

按证据逐项进入：

• 动态 TDEE、下一餐和训练营养联合复盘；
• 平台期诊断；
• AI 截图/PDF/纸张导入；
• 少量动作视频反馈和 VBT；
• 自动动作/次数识别；
• 器械图片、配重与场馆图谱；
• 教练协作、Accountability；
• Coach Pro 和 Gym OS；
• 居家专项、有氧和更广人群。

18.1 北极星指标#

有效训练周：用户在一周内完成目标所需的最低有效训练，并至少对一条系统决策产生接受、修改或拒绝的闭环反馈。

它同时要求真实训练和决策价值，比 DAU、聊天轮次、连续打卡和停留时长更接近产品目标。

18.2 指标树#

18.3 指标解释原则#

• “合理缩短完成”和“完整完成”分开，不通过放宽完成定义刷数字；
• 建议采用率只统计规则适用且数据足够的合格建议；
• 覆盖建议不自动算失败，覆盖原因是产品学习数据；
• 语音使用率要看第 4 周，不看首日；
• 结果指标必须控制动作、器械、测量条件和缺失数据；
• 不用成功案例替代 cohort。

19.1 Free#

免费层必须足以成为好用的 Gym Tracker：

• 完整基础训练记录；
• RIR/RPE、Rest Timer、基础组型；
• 常用动作内容；
• 基础计划和有限自定义；
• 基础历史和统计；
• 导入、导出、备份；
• Health Connect 基础；
• Watch 基础；
• 少量语音和智能替换体验。

不能限制一天只能记几组，不能用数据导出做人质，不建议广告。

19.2 Pro#

Pro 首页只卖具体结果：

• 下一组/下一次训练建议；
• Smart Progression；
• 时间、器械、疲劳和漏练自适应；
• 周/月复盘和长期趋势；
• 平台期和 Deload；
• 深度语音/Watch；
• 动态营养与下一餐；
• 长期个体模型。

不要卖“AI 聊天次数”。如果保留 Ask My Coach，它的价值是能读取用户近 12 周真实训练和体重数据，而不是聊天本身。

19.3 付费设计#

• 用户先完成约 3 次训练；
• 系统展示第一条真实个体建议；
• 再开启 14 天 Pro 体验；
• 付费墙展示建议结果和 Why，不只列功能；
• 首轮测试年费 ¥168 / ¥228 / ¥298；
• 只选一个主套餐落地，避免复杂叠加；
• 月费可作为灵活入口，不用永久会员。

19.4 AI Credits#

视频 Form Check、长视频分析、身体扫描等高计算能力单独使用额度。Pro 可包含少量月度次数，超出按次包购买。订阅覆盖日常决策，Credits 覆盖高成本多模态。

19.5 后期业务#

Coach Pro：教练管理学员完成率、趋势、风险和 AI 草稿，教练批准后应用。AI 提高教练服务人数，不宣称替代教练。

Gym OS：场馆向会员提供 AI Coach，建设器械档案并在明确授权下看匿名化运营数据。前三年不优先，除非 C 端验证或出现强渠道机会。

20.1 最小团队#

20.2 主要成本#

成本不只是模型 API，还包括动作内容制作和授权、中文食物数据、测试设备、同步与存储、隐私基础设施、专业审核、用户支持、退款和渠道费用。

基础记录和计时本地完成；知识缓存；照片和周复盘按需异步；不要把长对话上下文用于每一次普通训练事件。

总停止条件：如果真实使用 8 周后，用户只是觉得产品“更好看、更智能”，却没有把它作为主记录器、没有减少训练前后思考、没有在现实变化后完成更多合适训练、也没有对建议形成有效反馈，就不继续堆营养、视觉、社区或更多 AI。回到记录体验，或评估转为教练端工具。

22.1 本周必须产出#

• 一页 ICP 与招募问卷；
• 目标用户名单和 10 次观察排期；
• 竞品同任务测试模板；
• 今天、训练中、替换、结束、周复盘五个低保真原型；
• 20 个动作的结构化样例；
• 双进阶与 RIR 规则 v0.1；
• 核心事件模型 v0.1；
• 安全红旗和“不判断”清单；
• 10 名设计伙伴的人工建议流程。

22.2 两周后的继续条件#

• 目标用户愿意交出并迁移真实计划；
• 记录、进阶或现场替换至少一个问题在真实训练中重复出现；
• 用户实际使用建议，而不是只口头评价；
• 原型不增加训练中注意力负担；
• 人工后台能稳定给出可解释建议；
• 没有发现首发人群或问题定义根本错误。

22.3 当前唯一正确的开发顺序#

真实训练观察
→ 低保真会话原型
→ 可替代现有工具的本地记录器
→ 可解释的确定性进阶
→ 器械/时间/漏练重排
→ 语音、Watch 和轻营养
→ 平台期、视觉与自动感知
→ 教练、场馆和完整 Personal Training OS

最需要克制的不是想象力，而是同时实现所有想象的冲动。完整并集应保留为产品地图；当前执行必须沿着一条可以被真实用户验证的主链前进：

A.1 Epic 1：可靠训练会话#

A.2 Epic 2：计划与迁移#

A.3 Epic 3：进阶建议#

A.4 Epic 4：现实重排#

A.5 Epic 5：语音#

A.6 Epic 6：周复盘与 Progress#

A.7 Epic 7：轻营养#

B.1 v0.1 内部原型#

• 用户/目标/Gym Profile 基础结构；
• 20 个动作；
• 单训练日、普通组与计时；
• 上次—目标—本次卡片；
• 本地事件写入；
• 一键完成、修改、撤销；
• 双进阶规则离线模拟；
• 人工建议注入入口；
• 关键埋点日志。

B.2 v0.2 设计伙伴版#

• 60 个动作和替代关系；
• 多训练日计划；
• 热身、工作、递减、超级组；
• CSV 导入导出；
• 崩溃恢复和后台同步；
• 双进阶/RIR/Top set 规则；
• Why、作用范围和 PlanVersion；
• 建议接受/修改/拒绝；
• 基础器械替换和 30/45/60 分钟版本。

B.3 v0.3 封闭 Beta#

• 多 Gym Profile；
• 漏练、出差和回归；
• Minimum Viable Workout；
• 周复盘三张卡；
• Health Connect 基础同步；
• Push-to-talk 有限命令；
• 完整隐私权限与数据删除；
• 教练审核后台；
• 性能、同步和规则监控。

B.4 v1.0 付费 Beta#

• Free/Pro 权益；
• 完成三次训练后的 Pro Preview；
• 年费支付实验；
• Watch 基础或深度能力（按研发结果）；
• 轻营养试点（按训练留存结果）；
• 建议与留存 cohort 仪表盘；
• 客服、退款、数据导出和事故处理流程；
• 100–200 名合格用户 8 周运行。

B.5 v1.x 候选#

• AI 截图/PDF/聊天计划导入；
• 动态 TDEE 与下一餐；
• Plateau Detective；
• 语音 Dump Mode 与私人别名学习；
• Gym Equipment Graph；
• 教练异步协作；
• 有限 Form Check / VBT；
• 自动动作与次数候选。

C.1 结束发现阶段前#

• 已访谈 20–30 名符合 ICP 的用户；
• 已完成至少 10 次现场观察；
• 已收集真实计划、记录和历史导出；
• 记录/进阶/替换至少一个问题重复出现；
• 10 名用户愿意迁入真实计划；
• 人工建议被实际使用，而非只得到口头好评；
• 已识别用户绝不交给 AI 的决策；
• 主要竞品已按同任务测试。

C.2 结束记录器阶段前#

• 熟练用户计划内一组中位数 ≤3 秒；
• 首次用户独立完成整练 ≥70%；
• 弱网、后台、闪退恢复通过；
• 无严重数据丢失；
• 单位、负荷语义和组型测试通过；
• 导入无法识别项不会静默丢失；
• 数据可完整导出；
• 核心用户主记录迁移接近或超过 50%。

C.3 结束决策阶段前#

• 所有建议可追溯到输入与规则版本；
• 接受、修改、拒绝和撤销闭环完整；
• 建议不阻塞训练；
• 合格建议接受/轻改接近或超过 60%；
• 用户复述原因接近或超过 70%；
• 低置信度会保持或校准；
• 疼痛和安全红旗始终先于模型；
• 用户覆盖被当作学习信号而非失败。

C.4 开始付费 Beta 前#

• 第 4 周有效训练留存接近目标；
• 核心价值不依赖人工每日救场；
• Free 本身是可长期使用的记录器；
• Pro 展示具体结果而非抽象功能名；
• 付费、退款、停订与历史访问规则清楚；
• 删除、导出、权限撤回流程已实测；
• 已有严重建议事故的响应流程；
• 单位经济按真实模型、存储和支持成本测算。

这个决策日志应在每次研究和版本里更新，避免团队在没有新证据时反复摇摆。