核心命题：Context-aware Voice Gym Interface（上下文感知的健身房语音操作系统）——而不是"给记录页面加个麦克风按钮"。

关键词：零摩擦记录 · Workout State Machine · Push-to-talk · Wear OS

Part 1问题与机会

1.1 竞品观察

已有一批专门做语音训练记录的产品：Kratos、Liftly、SLAB、GhostFit、Gym Journal、RepTalk、SayLift。它们普遍强调同一个痛点：训练时频繁解锁手机、找动作、输重量次数，会破坏训练节奏。

判断：这些产品大部分只做到了 Voice Input（语音输入）。真正值得做的是 Context-aware Voice Gym Interface（上下文感知的语音操作系统）。两者差别非常大。

1.2 为什么力量训练特别适合语音

传统 App 每组结束后的操作：

拿手机 → 解锁 → 找到当前动作 → 点重量 → 输入80
     → 点次数 → 输入8 → 完成 → 开始计时

一场训练：6 个动作 × 4 组 = 24 个 working sets，用户一天可能操作手机几十次。

问题不是每次操作 5 秒还是 10 秒，而是：

每组训练后都强迫用户切换注意力。

训练状态：  用力 → 结束 → 喘气 → 恢复 → 准备下一组
加入记录后：用力 → 结束 → 拿手机 → 找数字 → 输入 → 检查 → 放手机 → 恢复

这就是 friction。

1.3 但最初级的"语音记录"也不够好

很多 Voice Gym App 要求每组说完整句子，比如"杠铃卧推80公斤8个"——每一组重复一遍完整信息。太蠢，因为系统明明知道用户正在做卧推。

正确设计应该是 Context-aware：

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

Part 2交互设计

2.1 理想的一次训练交互

打开 Push Day，系统已知：

当前动作：杠铃卧推
计划：80kg，4 组，8-10 reps，RIR 1-2

上次                 今天
80 × 9          →    80 × ?
80 × 8               80 × ?
80 × 8               80 × ?
77.5 × 9             80 × ?

做完第一组，长按耳机或手表：

"9个。"

系统结合上下文解析：

{ "exercise": "bench_press", "weight": 80, "reps": 9 }

然后耳机轻提示"9次，已记录"（或仅震动），休息计时自动开始 02:30。

整个过程：1 秒左右的用户交互。这才有意义。

2.2 反馈方式：haptic > voice

健身房里一直语音播报很烦。正常情况只需：

• 手表震一下
• 屏幕瞬间显示 ✓ 80 × 9

耳机只在异常情况下说话，例如："刚才听到的是90公斤9次？"

haptic feedback > voice feedback —— 否则 AI Coach 很快会变成话痨。

2.3 语音真正厉害的地方：覆盖整个训练控制过程

GhostFit 已把 drop sets、supersets、AMRAP、rest-pause 列入语音记录范围 —— 高级训练者需要的语义远不只是 weight × reps。

2.4 Superset 是检验系统智商的地方

计划：A1 哑铃侧平举 / A2 绳索下压。用户说：

"侧平举十二公斤十二个，下压25公斤十个。"

应直接理解为：

A1: 12kg × 12
A2: 25kg × 10

或者说"跟上一轮一样" → 自动复用上次记录。

如果系统还要求"请选择当前运动项目"，产品就失败了 —— 因为它没有真正理解 Workout State。

2.5 两种记录模式并存

Dump Mode 下 AI 生成结构化记录 + 确认界面：

Bench Press
80 × 9 / 80 × 8 / 80 × 8 / 80 × 7

Incline DB Press
30 × 10 / 30 × 9 / 30 × 8

Cable Fly
50 × 12 / 50 × 11 / 50 × 10

正确吗？ [ ✓ ]

比强迫所有用户使用同一个流程聪明得多。

2.6 语音解决一个隐蔽痛点：记忆失败

做完一组 → 跟朋友聊了两分钟 → "艹，刚才到底做了8个还是9个？"

语音记录让"动作结束后几秒钟内完成记录"成为自然行为，几乎不破坏训练。

2.7 自动询问（谨慎做）

系统检测到：休息计时已开始，但没有训练记录 → 耳机问："刚才卧推做了几个？"

必须学习用户习惯：经常忘的人提醒，稳定记录的人闭嘴。

Part 3技术架构

3.1 核心不是 LLM，而是 Workout State Machine

运行时始终维护：

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

示例状态：

动作：Barbell Bench Press
当前组：3 / 4
重量：80kg
上一组：80 × 9 @ RIR 2
目标：8-10 reps @ RIR 1-2

此时用户说"8个" —— 完全不需要 LLM 推理，确定性解析即可：

reps = 8, weight = currentWeight, exercise = currentExercise

3.2 推荐架构

                麦克风
                  ↓
                 VAD                    ← 语音活动检测
                  ↓
                 ASR                    ← 语音识别
                  ↓
             Speech Text
                  ↓
        ┌──────────────────┐
        │  Normalization   │         ← 数字 / 单位 / 别名归一化
        └────────┬─────────┘
                 ↓
        Workout Context                 ← 注入当前训练上下文
                 ↓
      Intent / Entity Parser            ← 规则解析为主
                 ↓
             Validator                  ← 置信度 + 合理性校验
                 ↓
      Workout State Machine             ← 状态机执行
                 ↓
              Local DB
                 ↓
        Progression Engine              ← 渐进超负荷引擎

LLM 只作为 fallback 层：规则 parser → 无法确定 → LLM fallback。不要把所有语音都扔给大模型。

3.3 为什么不能全部交给 LLM

一个错误就可能污染训练数据：

"八十公斤8个"
  → LLM 解析成 88kg × 8
  → 历史数据损坏
  → progression engine 下次建议 90kg
  → 持续出错

产品原则：模糊信息可以 AI 推理，关键训练数字不能 AI 猜。

3.4 Confidence 置信度机制

每次解析输出置信度：

{
  "exercise": { "value": "bench_press", "confidence": 0.99 },
  "weight":   { "value": 80,            "confidence": 0.98 },
  "reps":     { "value": 8,             "confidence": 0.97 }
}

3.5 健身房噪音是最大技术挑战

真实环境：音乐、铁片碰撞、旁人讲话、跑步机、喘气、哑铃落地。

MVP 不做 Always Listening（电量、隐私、误触发、噪音、旁人讲话，问题太多）。MVP 用 Push-to-talk。

长按（手机麦克风 / 手表按钮 / 耳机快捷键）
  → 🎙
  → "8个 RIR2"
  → 松开
  → 识别
  → 震动

3.6 Wear OS 可能比手机语音更重要

终极交互：

Phone ←──sync──→ Wear OS Watch ←──Voice── 用户

手表界面：

BENCH PRESS
   80 KG
Set 3 / 4
Target: 8–10
   🎙

抬手说"8个" → 震动 → Done。Android 官方已支持 Wear OS 麦克风录音和 free-form speech input，产品形态符合平台能力。

3.7 Health Connect 平台化

2026 年 Health Connect 的 ExerciseSegment 已可直接表达 repetitions、weight、set index、RPE。内部模型直接对齐平台标准结构：

WorkoutSession
  └── Exercise
        └── Set
             ├── weight / reps / rir / rpe
             ├── duration / distance
             ├── setType
             └── timestamp

再向 Health Connect 映射。

3.8 ASR 选型（可插拔）

interface SpeechEngine   // 底层可切换，不绑定一家

推荐：设备端 VAD + ASR，服务器做复杂语义解析 / LLM fallback —— 弱网也能工作。

3.9 Hotwords 注入

ASR 必须知道用户的动作库。训练开始时注入：

Today's vocabulary + User exercise library + Common fitness terms

识别准确率明显优于通用 ASR。

3.10 LLM 的正确位置

LLM 适合处理非结构化表达：

"这一组还是80，做了8个，最后一个有点勉强，大概还剩一个吧。"

{ "intent": "LOG_SET", "weight": 80, "reps": 8, "rir": 1, "notes": "last rep grind" }

LLM 做的是 unstructured → structured。但绝不让 LLM 直接写数据库：

LLM → WorkoutCommand JSON → Schema validation → Business rules → DB

• Validator 拦截异常值（weight = 800kg）
• 个人范围 plausibility check：卧推历史 70-90kg，突然识别出 180kg → 追问"你刚才说的是80公斤吗？"

3.11 Context 大幅降低不确定性

系统已知：CurrentExercise = Bench, CurrentWeight = 80, ExpectedRep = 6–12

ASR 候选空间：8 / 9 / 10 / RIR1 / RIR2 / 加2.5 / 减2.5 —— 空间极小。

Context drastically reduces uncertainty. 这是产品能做到非常可靠的核心原因。

Part 4落地规划

4.1 中文场景的三个坑

坑一：Domain Language Understanding

真实表达不是"杠铃平板卧推80千克8次"，而是：

"卧推80八个。" / "八十做八个。" / "还是80，做了九个。" / "这组八个力竭。" / "上斜30十个。" / "单边30，十个。" / "两边各三个片。" / "史密斯两边二十加十。"

ASR 只是问题的一半，另一半是 Domain Language Understanding。

还要学习用户私人语言（UserAlias）：用户说"小飞鸟"确认是 Cable Lateral Raise 后，以后自动映射。数字习惯也要学："三十二点五" / "32.5" / "三二点五" / "三十二半" → 32.5kg。

坑二：哑铃的 load_semantics

"哑铃卧推30公斤" 是总重还是单手？

健身人默认理解：单只哑铃 30kg。Exercise Metadata 应定义 load_semantics = PER_HAND，volume 统计必须统一规则（30×2×10 还是 30×10）。

坑三：辅助引体方向相反

"辅助引体40公斤，8个" —— 40kg 不是负重，是 assistance，数字越大动作越容易。

Exercise Schema 至少需要：
LOAD / ASSISTANCE / BODYWEIGHT / BODYWEIGHT_PLUS
PER_HAND_LOAD / MACHINE_STACK / PLATE_PER_SIDE

否则 progression 会出严重问题。

4.2 MVP 范围：克制

"8个"          "80公斤8个"      "8个RIR2"
"加2.5"        "减2.5"         "刚才作废"
"再来一组"     "跳过"          "休息3分钟"

已覆盖大多数训练交互。然后看真实用户录音，再扩 vocabulary。

千万不要一开始"支持任意自然语言"！这是典型 AI 产品陷阱。

4.3 成功指标

Correction rate 最关键：如果 20 次要改 5 次，用户会觉得"还不如自己输"，语音功能就死了。

4.4 最大产品风险：用户不愿意在健身房讲话

中国健身房"社死"问题真实存在。所以不能 Voice only：

Touch + Voice + Watch   三套输入并存，用户自由选择

最好的产品设计不是 Voice First，而是 Zero-Friction First。语音只是手段之一。能不用语音的时候甚至不用语音，这才是第一性原理。

理想输入优先级：

1. 系统自动猜测（基于上次训练预测 80kg × 9，实际完成点 ✓）
       ↓
2. One Tap 确认（± 调整次数）
       ↓
3. Voice（情况复杂时）
       ↓
4. Manual edit（极端情况）

这比"所有东西都用 AI 语音"强很多。

4.5 第一版 Android 界面草案

──────────────────────
BARBELL BENCH PRESS
Set 2 / 4
        80 KG
Target: 8 – 10
Last set: 80 × 9, RIR 2
──────────────────────
[-]      9 reps      [+]
        [  ✓  ]
         🎙
Rest  01:43
──────────────────────

• 正常完成 → 点 ✓
• 次数不同 → ±
• 情况复杂 → 🎙 "8个 RIR 1"

这种产品比"全屏 AI 聊天"高级很多。

结语最关键的产品判断

"有人已经专门做语音力量训练记录"验证了一个更大的判断：

健身追踪最大的机会之一，是让 Logging 从一项用户任务变成系统自动完成的副产品。

现在：训练 + 记录训练
未来：训练 → 记录自然发生

语音只是第一步，下一步是：

Voice → Watch → Sensors → Computer Vision → Automatic Logging

最终用户可能完全不需要记录：他只是训练。 App 自动知道：

做了什么动作 · 多少重量 · 多少次 · RIR 多少
休息多久 · 训练质量如何 · 下一次该怎么练

这已经不是 Workout Tracker，而是 Gym Operating System。

行动建议：优先做"训练中极低摩擦记录 + 上下文语音"，而不是先做饮食拍照。饮食识图已高度同质化，而真正好用的 context-aware gym voice interaction 目前仍远没有被市场彻底做透。

附录参考来源

1. Kratos - Voice Workout Logging（App Store）
2. GhostFit Voice Workout Tracker（Google Play）
3. RepTalk: Voice Workout Log（App Store）
4. JoT — Voice-First Training App
5. Wear OS Voice input（Android Developers）
6. Health Connect ExerciseSegment（Android Developers）
7. ML Kit GenAI Speech Recognition（Google for Developers）
8. whisper.cpp Android 示例（GitHub）
9. sherpa-onnx 文档
10. SenseVoice（GitHub）

整理日期：2026-09-11 · 语音力量训练 · 产品思考