开源健身教练Skill：让Agent当私教的完整搭建指南

1. 从一句标题说起：Agent当私教到底靠不靠谱

第一次看到"开源的健身教练Skill，让Agent当上了私教"这个标题，我脑子里冒出来的第一个念头是：又一个把大模型套个壳就敢叫"私教"的项目？毕竟这两年各种"AI+行业"的项目见得太多了，十个里面有八个是把提示词包装一下，真正能落地、能持续用下去的少之又少。但仔细琢磨了一下这个方向，我发现它其实踩中了一个非常真实的需求缺口——健身这件事，缺的从来不是知识，而是持续、个性化、低成本的反馈。

你去健身房请个私教，一节课几百块，一周三次，一个月下来小几千就没了。而且私教的时间是固定的，你晚上十点想加练一组，人家早下班了。网上的健身教程倒是免费，但那是"一对多"的广播式内容，它不知道你的体重、你的伤病史、你今天状态好不好、你昨天是不是刚练完腿。而一个能接入你个人数据、能记住你训练历史、能根据你当天反馈动态调整计划的Agent，理论上可以填补这个空白——这就是"健身教练Skill"这个项目真正想解决的问题。

所谓Skill，在这类Agent生态里通常指的是一组封装好的能力模块：它可能包含一套结构化的提示词、若干工具调用（比如计算热量、查询动作库、记录训练日志）、以及一套决策逻辑。把它挂载到Agent上，Agent就从一个"什么都能聊两句"的通用助手，变成了一个"专门盯着你训练"的私教角色。这个转变的关键不在于模型多聪明，而在于Skill把领域知识和交互流程固化下来了，让Agent不用每次从零开始理解"什么叫渐进超负荷""组间休息该多久"。

这篇文章我打算把这个项目拆开揉碎讲清楚：它背后的设计思路是什么、一个健身教练Skill到底该包含哪些核心模块、怎么从零把它搭起来、实操中会遇到哪些坑。适合两类人看——一类是想自己动手做一个垂直领域Agent Skill的开发者，另一类是健身爱好者，想搞明白这类工具到底能不能替代真人私教。我会尽量把技术细节和健身常识都讲透，让两边的人都能看懂。

2. 拆解"健身教练Skill"的核心设计思路

2.1 为什么是Skill而不是一个提示词

很多人做垂直Agent的第一反应是写一段超长的系统提示词，把健身知识全塞进去。我早期也这么干过，结果就是提示词越写越长，模型开始"顾此失彼"——你让它算热量它忘了看训练历史，你让它排计划它又忽略了用户的伤病。根本原因在于，单一提示词无法承载多步骤、有状态的决策流程。

Skill的思路不一样。它把"当私教"这件事拆成了几个可独立调用的能力单元，每个单元职责单一，Agent在对话过程中按需调用。这就好比真人私教的工作也不是一坨混沌的经验，而是分成"评估体态""制定周期计划""执行单次训练""复盘调整"几个明确阶段。Skill的价值就在于把这个阶段划分显式地编码进去，让Agent的行为有章法，而不是每次即兴发挥。

从工程角度看，Skill还带来一个隐性好处：可测试、可迭代。你可以单独测试"热量计算"这个模块准不准，单独优化"动作推荐"的逻辑，而不用每次改动都担心把整个提示词搞崩。这一点在长期维护中太重要了，我见过太多项目因为提示词是一整块，改一处崩三处，最后没人敢动。

2.2 一个合格私教Skill该有的四大模块

我把这类项目的核心能力归纳成四块，缺一块都会让体验大打折扣。

第一块是用户画像与目标管理。这是所有个性化推荐的地基。它要记录的不只是身高体重年龄这些静态数据，还包括训练目标（增肌/减脂/塑形/康复）、可用器械、每周能练几次、每次多长时间、有无伤病。这些信息决定了后面所有计划的边界。我特别想强调伤病这一项——很多开源项目为了简化直接忽略了，但这是最危险的省略，一个膝盖有伤的人被推荐去做深蹲跳，后果不是"效果不好"而是"直接受伤"。

第二块是训练计划生成。这是最考验专业性的部分。一个好的计划要考虑周期化（比如4周一个中周期，逐步增加负荷）、动作搭配（推拉腿分化还是上下肢分化）、容量控制（每个肌群每周多少组）。这里面的门道很深，Skill需要把健身科学里那些成熟的原则（渐进超负荷、专项性原则、恢复原则）转化成可执行的规则。

第三块是单次训练的执行与记录。用户今天练什么、每组做几次、休息多久、感觉如何，这些都要实时记录。记录不只是为了存档，更是下一次调整的依据。真人私教会根据你今天的表现决定要不要加重量，Agent也得有同样的能力。

第四块是反馈与动态调整。训练不是一成不变的，用户可能这周状态差、可能某个动作一直找不到发力感、可能平台期卡住了。Skill需要能识别这些信号并做出响应，而不是死板地执行原计划。

2.3 技术选型：为什么用工具调用而不是纯生成

在实现上，我强烈建议把能算的东西交给工具，别让模型硬生成。举个例子，计算每日蛋白质摄入量，模型直接"心算"经常出错，尤其是涉及体重、活动系数、目标系数的多步乘法。但如果封装一个计算工具，输入体重和目标，返回克数，准确率就是100%。

再比如动作库查询。健身动作有成百上千个，每个动作涉及的肌群、器械、难度、替代动作都不一样。把这些做成结构化的数据表，让Agent通过查询工具获取，比让模型凭记忆"编"动作要可靠得多。模型编动作的典型翻车场景是：推荐一个需要龙门架的动作，但用户明确说了只有哑铃——这种错误在纯生成模式下几乎无法根除。

提示：工具调用的设计原则是"凡是能确定性计算的，绝不交给模型生成"。模型擅长的是理解意图、组织语言、做模糊判断，不擅长精确计算和事实检索。把这两类任务分开，整个系统的稳定性会提升一个档次。

3. 核心模块的细节实现与实操要点

3.1 用户画像模块：别一上来就问一堆问题

新手做这类项目最容易犯的错，是开场就甩一个十几项的表单让用户填。实测下来，填完率极低，大部分人填到第三项就跑了。更好的做法是渐进式采集：第一轮只问最关键的三个——目标、每周能练几次、有无伤病。这三个决定了计划的基本框架，缺了没法往下走。剩下的细节（具体器械、偏好动作、饮食情况）在后续对话中自然带出来。

数据结构上，我建议用一个JSON对象存画像，字段设计要留扩展余地。下面是一个我实际用过的结构，供参考：

{ "user_id": "u_001", "goal": "muscle_gain", "frequency_per_week": 4, "session_duration_min": 60, "injuries": ["left_knee"], "equipment": ["dumbbell", "barbell", "bench"], "experience_level": "intermediate", "body_weight_kg": 72, "training_history": [] }

这里有个细节值得说：injuries字段我用的是数组而不是布尔值，因为一个人可能同时有多个部位的问题，而且后续做动作过滤时需要精确匹配。training_history单独存，不塞进画像里，因为它会不断增长，混在一起会让画像对象越来越臃肿。

3.2 计划生成：把健身科学翻译成规则

计划生成是整个Skill里最"重"的部分。我的做法是把它拆成两层：模板层和调整层。模板层负责根据目标和频率选一个成熟的分化方案，比如一周四练就用"上下肢分化"（上肢A、下肢A、上肢B、下肢B），一周三练就用"全身分化"。这些模板是健身领域验证过无数次的，直接拿来用比自己瞎编靠谱。

调整层负责根据用户的具体情况微调。比如用户左膝有伤，那所有涉及膝关节大幅屈伸的动作（深蹲、箭步蹲、跳箱）都要替换成对膝盖友好的变式（腿举、臀桥、罗马尼亚硬拉）。这个替换逻辑需要一张"动作替代映射表"，把高风险动作映射到低风险替代动作。

容量控制是另一个关键参数。健身科学里有个常用的起点是每个肌群每周10-20组，新手取下限，进阶者取上限。Skill需要根据用户的experience_level自动设定这个范围，然后在生成计划时统计每个肌群的组数，确保落在区间内。这个统计如果靠模型心算很容易出错，我建议写成一个校验函数，生成完计划后跑一遍，超了就报警。

注意：计划生成后一定要做一次"冲突检查"。常见冲突包括：连续两天练同一肌群（恢复不足）、单次训练容量过大（超过用户时间预算）、动作所需器械用户没有。这三个检查能拦掉大部分低级错误。

3.3 训练执行：记录比指导更重要

很多人以为私教的核心价值在于"教动作"，其实在Agent场景下，记录和追踪才是真正的价值点。因为动作教学可以看视频，但"你上周卧推做了多少、这周该加多少"这种连续性信息，只有持续记录才能提供。

单次训练的记录结构我建议设计成"训练-动作-组"三层：

{ "session_id": "s_20240115", "date": "2024-01-15", "exercises": [ { "name": "barbell_bench_press", "sets": [ {"weight_kg": 60, "reps": 8, "rpe": 7}, {"weight_kg": 60, "reps": 8, "rpe": 8}, {"weight_kg": 62.5, "reps": 6, "rpe": 9} ] } ] }

这里我特意加了rpe（自觉用力程度，1-10分）字段。这个字段是动态调整的金矿——如果用户某组RPE到了9-10，说明接近力竭，下次就不该加重量；如果RPE只有6-7，说明还有余力，可以适当加重。真人私教就是靠观察你的表情和动作速度来判断RPE的，Agent靠用户自报，虽然精度差一点，但比没有强太多。

3.4 动态调整：让计划"活"起来

死计划不如没计划。一个不能根据反馈调整的计划，用户练两周就会发现"这玩意儿根本不管我"。动态调整的逻辑我总结成三条规则：

• 进步规则：如果某动作所有组都完成了目标次数且RPE≤8，下次加2.5kg（上肢）或5kg（下肢）。
• 维持规则：如果完成了次数但RPE在9-10，下次维持重量，争取把RPE降下来。
• 退阶规则：如果连续两次没完成目标次数，减重10%重新积累。

这三条规则简单，但覆盖了80%的调整场景。关键是它们可以被确定性地执行，不需要模型"判断"。模型在这里的角色是把这个调整结果用自然语言解释给用户听，比如"你上周卧推60公斤做了3组8次感觉还行，这周咱们试试62.5公斤"，而不是让模型自己决定加多少。

4. 从零搭建：完整实操流程与关键配置

4.1 环境准备与依赖清单

假设你用的是主流的Agent开发框架，搭建这个Skill大致需要这么几样东西。首先是一个支持工具调用的模型接口，这是基础。其次是一个持久化存储，用来存用户画像和训练历史，SQLite就够用，别一上来就上重型数据库。第三是动作库数据，这个可以自己整理，也可以找公开的健身动作数据集，但要注意数据质量，很多公开数据集的动作描述不准确。

我实际搭的时候用的是一个轻量的本地存储方案，把用户数据存成JSON文件，训练历史按日期分文件存。这样做的好处是调试方便，直接打开文件就能看数据长什么样。等用户量上来了再迁移到数据库也不迟。过早优化存储是新手常见的浪费时间的做法。

4.2 动作库的整理：这是最耗时的活

说实话，搭这个Skill最花时间的不是写代码，是整理动作库。一个可用的动作库，每个动作至少要包含这些字段：

joint_stress这个字段是我强烈建议加的，它就是用来做伤病过滤的。用户左膝有伤，系统就自动排除所有joint_stress包含"膝关节"的动作，或者把它们替换成alternatives里的低压力变式。这个设计让伤病处理从"靠模型判断"变成了"查表过滤"，可靠性天差地别。

整理动作库没有捷径，我当时的做法是先覆盖最常用的50-80个复合动作和孤立动作，这些能撑起90%的训练计划。剩下的长尾动作用到再加。别想着一次整理几百个，那样你会在整理数据的过程中耗尽热情。

4.3 对话流程的设计：像真人私教一样分阶段

Agent和用户的交互不能是"你问我答"的散乱模式，得有阶段感。我把它设计成四个阶段，每个阶段有明确的进入条件和退出条件：

阶段一：初次评估。用户第一次来，Agent采集核心画像，确认目标和约束。退出条件是三个必填项（目标、频率、伤病）都拿到了。

阶段二：计划制定。基于画像生成首周计划，展示给用户确认。用户可以要求调整（比如"我不想练硬拉"），Agent据此修改。退出条件是用户确认计划。

阶段三：训练执行。每次训练前Agent推送当天计划，训练中用户报告完成情况，Agent记录。退出条件是本次训练的所有动作都记录完毕。

阶段四：周期复盘。每4周做一次复盘，看进步情况，调整下个周期的计划。

这个阶段划分的好处是，Agent在任何时刻都知道自己"该干什么"，不会出现用户问了个无关问题后Agent就迷失方向的情况。实现上可以用一个状态字段来标记当前阶段，每次对话先读状态再决定行为。

4.4 关键参数的计算过程

前面提到热量和蛋白质计算要交给工具，这里把计算逻辑展开说一下，因为很多人不知道系数怎么取。

以蛋白质摄入为例，常用公式是：每日蛋白质克数 = 体重(kg) × 系数。系数取值跟目标相关：

• 普通久坐人群：0.8-1.0
• 增肌训练者：1.6-2.2
• 减脂期（保肌肉）：1.8-2.4
• 耐力运动员：1.2-1.6

假设用户72kg，目标是增肌，取系数1.8，那就是72 × 1.8 = 129.6克，约130克。这个计算如果让模型做，它可能给你算出个140或者120，误差不小。封装成工具后，输入体重和目标，输出精确值，稳定可靠。

热量计算稍微复杂点，要先算基础代谢率（BMR），再乘活动系数。BMR常用Mifflin-St Jeor公式：男性BMR = 10×体重 + 6.25×身高 - 5×年龄 + 5；女性把最后的+5换成-161。然后乘以活动系数（久坐1.2、轻度活动1.375、中度1.55、高度1.725）。增肌在TDEE基础上加300-500大卡，减脂减300-500大卡。这一串计算必须用工具，手算都容易错，更别说模型了。

5. 常见问题与排查技巧实录

5.1 模型不按套路调用工具怎么办

这是最常见的坑。你明明设计了工具，模型却喜欢自己"编"答案。我踩过的坑是：模型觉得算蛋白质太简单，直接心算给了个数字，根本没调工具。解决办法是在系统提示里明确写"任何涉及数值计算的问题，必须先调用对应工具，禁止自行计算"，并且把这条规则放在提示的靠前位置。另外，工具的描述要写得足够"诱人"，让模型觉得调用它比不调用更省事。

还有一个技巧是在工具返回结果里带上解释。比如计算工具不只返回"130克"，还返回"基于体重72kg和增肌目标系数1.8计算得出"。这样模型拿到结果后能自然地转述给用户，用户体验更好，也更愿意继续用工具。

5.2 计划生成出来不合理的排查思路

如果生成的计划看起来怪怪的，按这个顺序排查：

我遇到最多的是器械过滤失效，原因是动作库里的器械名称和用户画像里的名称不一致，比如动作库写"dumbbell"用户写"哑铃"。解决方法是做一层名称标准化映射，把所有器械名统一成一套标准词。

5.3 用户中途放弃的预防

这是产品层面的问题，但技术也能帮上忙。数据显示，健身类工具的用户流失高峰在第二周。原因通常是"没看到效果"或者"太麻烦"。技术上可以做两件事：一是降低记录负担，允许用户用一句话报告（"今天卧推60做了3组8次"），由Agent解析成结构化数据，而不是让用户填表；二是强化正反馈，每次训练后Agent主动指出进步，哪怕很小（"你这次比上次多做了2次，进步了"）。

提示：别小看这种即时反馈。真人私教的一个重要价值就是"陪着你、鼓励你"，Agent如果只会冷冰冰地报数据，用户很快就会觉得没意思。把鼓励的话术设计进Skill里，是提升留存的关键。

5.4 数据准确性问题的兜底

模型解析用户口语化输入时难免出错，比如用户说"卧推加了5公斤"，模型可能理解成"总重量加了5公斤"而不是"每边加了5公斤"。这种歧义在健身场景里很常见。我的做法是关键数据二次确认：解析完后Agent复述一遍"你是说总重量从60加到65，对吗"，用户确认后才写入。虽然多一轮对话，但避免了错误数据污染训练历史。

6. 这套Skill到底能替代真人私教吗

聊了这么多技术实现，回到最开始那个问题：Agent当私教，到底行不行。我的判断是，在"计划制定"和"记录追踪"这两个环节，它能替代七八成；在"动作纠正"和"临场激励"这两个环节，它目前替代不了。

计划制定和记录追踪本质上是信息处理任务，Agent有天然优势——它不会累、不会忘、能同时记住你三个月的训练数据并找出规律。但动作纠正需要视觉反馈，除非接入摄像头做姿态识别，否则Agent只能靠你描述"我膝盖内扣了"来判断，这显然不如真人一眼看出来。临场激励更是情感层面的东西，Agent的鼓励话术再精心设计，也比不上真人在你力竭时喊的那一嗓子。

所以我的建议是把它定位成"私教的补充"而不是"替代"。你如果有真人私教，可以用这个Skill来记录和追踪，把私教课之间的自主训练也管起来；你如果请不起私教，它可以给你一个结构化的训练框架，至少不会让你瞎练。这个定位比"AI取代私教"的噱头务实得多，也更容易做出真正有用的产品。

最后分享一个我在实际搭建中体会最深的小技巧：别追求一次做完美。我第一版的动作库只有30个动作，计划模板只有2个，但已经能跑通完整流程了。后面根据实际使用中暴露的问题，一点点加动作、加规则、加工具。如果一开始就想做一个"什么都能干"的完美私教，大概率会在半路放弃。先让它能跑，再让它跑得好，这个顺序不能反。