训练师 Agent 小程序产品上线啦

官网：plan.wwenj.com/

小程序：

产品设计理念

产品围绕“动作—档案—计划—执行”构建完整训练闭环。基础动作库提供动作查询与演示，用户可以通过三种方式设置训练计划：

1. 自由编排：1000+ 动作库自由编排，设置训练顺序、组数、次数与休息时间。
2. 基础课程：内置通用基础课程，适合普通人日常健身，可直接选择并快速开始，课程持续更新。
3. AI 训练师：通过海量动作库、个人档案、个性化需求和训练偏好，提供专业的训练计划，主要聚焦复杂功能训练、运动康复与运动表现。

三种方式覆盖了从自主设计、快速选择到智能定制的全链路场景。

计划创建后，用户可以进入执行与跟练，按计划顺序查看动作演示、完成训练组次、控制休息节奏并保存训练记录。

产品能力覆盖用户从查找动作、设计计划到完成训练的完整过程，个人档案与训练记录则为后续计划调整提供持续的数据基础。

产品功能示例

1. 首页总览与个人档案

档案页用于持续跟踪用户信息，训练师页面作为核心入口，提供多种训练计划选择场景。

2. 多种训练计划入口

训练计划有三种来源：直接选择通用课程、从动作库手动编排，或交给训练师进行智能定制。前两种适合已有明确目标或希望自己掌控动作安排的用户；定制入口用于承接更具体的训练需求。

3. 训练师智能定制

面向运动康复、专项能力和运动表现等复杂目标，用户填写本次需求后，训练师会结合已维护的档案与动作库进行分析，生成可选择的训练计划。

4. 开放动作资料库

动作库支持按部位、器械和训练目标搜索、筛选。动作详情提供演示、执行要点和相关动作。动作库持续补充内容，是计划设计与实际执行共用的基础资料。

5. 计划执行与跟练记录

用户从计划列表进入训练后，可以按动作和组数逐步跟练，查看动作演示，并记录每一组的训练数据。当前组数和当前动作保持清晰可见，完成后的记录也为后续统计和调整提供依据。

从档案和目标，到选计划、找动作、完成每组训练，五个模块共同构成一个闭环。小程序并不把计划停留在一段建议文本，而是把它落到可选择、可理解、可执行和可记录的训练流程中。

产品技术架构与训练师 Agent 设计

1. 动作库基础数据获取与清洗

基础数据是重中之重，很多时候大家在做技术方案时会过于依赖 Agent 架构和 LLM 自身的能力，反而忽略基础数据，或者寄托于一套复杂的知识库处理框架，这是非常不可取的。

动作库是产品的基础，同时服务于用户浏览、计划编排和 Agent 检索。为了保证每个动作都能被准确查看、理解和组合，动作数据依次经过媒体清洗、内容清洗和结构化属性清洗。

在开始之前，我们应该花大力气，对基础数据做反复清洗。

1. 动作收集与剪辑

动作素材首先按照训练部位、动作类型和器械来源进行合理分类与收集，要保证类别分布全面、质量均衡。

收集的原始视频经过筛选和剪辑，去除片头、片尾、等待和重复片段，保留清晰、完整的核心动作周期。随后统一处理画面比例、尺寸、时长和文件体积，再统一做压缩与格式转换。

2. 动作内容清洗

统一动作名称和描述的标准用语，重点处理名称不一致、翻译不准确、同名异动作、动作变式混杂和多动作交叉冗余。

动作完整性按照动作家族进行评估，关注不同训练部位、动作模式、器械条件和难度阶段下是否具有足够覆盖与替代选择。这样可以让用户找到合适动作，也可以让 Agent 在当前条件不满足时继续搜索合理的替代方案。

3. LLM 多维度标注

每个动作进一步拆解为九类核心业务属性：

• primaryRegion：主要训练部位
• movementPatterns：深蹲、髋铰链、推、拉、弓步、旋转等动作模式
• equipmentRequired：哑铃、杠铃、弹力带、药球等完成动作所需器械
• bodyPositions：站姿、坐姿、跪姿、仰卧、俯卧、悬垂等执行姿态
• laterality：双侧、单侧、交替或不对称等侧别
• trainingQualities：抗阻、爆发、稳定、活动度、拉伸、有氧、协调等训练属性
• technicalLevel：动作技术复杂度评级
• impactLevel：跑动、腾空和落地带来的身体冲击等级
• doseMode：按次数、时间、距离、静态保持或混合方式计量

这些维度分别回答“练哪里、怎么练、需要什么条件、以什么姿态完成、适合什么阶段、如何写入计划”等关键问题。

通过统一的字段字典和 Schema，动作库从展示型内容转变为可检索、可比较、可组合的结构化训练数据。

2. 双模型标注与 GPT 冲突裁决

人工标注需要较强的专业知识和较高的人工成本，基本不可行，因此通常采用 LLM 数据标注方式。

双路 LLM 独立标注

为了尽量减少人工校验，我设计了双路独立标注方案：分别采用国产模型 GLM-5.3 与海外模型 Gemini 3.5-flash 同时读取相同的动作名称和说明，输出符合统一 Schema 的结构化结果。两个模型独立完成判断，标注过程中互不可见。

测试了好几款模型，要同时保证返回规整度、速度、质量、费用还是挺麻烦的，最终选择这两款模型，基本符合预期。

双路结果的合并策略

很多字段属于发散型字段，并无严谨答案，因此双路结果按照字段类型进行合并：

• 主训练部位等关键字段一致时直接通过。
• 关键字段不一致时，该字段进入冲突池，等待进一步裁决。
• 动作模式、器械、姿态和训练属性等数组字段，在语义接近且数量符合约束时进行合集处理。
• unknown 与明确值冲突时，根据原始标题、说明和证据完整度保留可信结果。
• 技术等级和冲击等级相差不超过一级时，采用更保守的较低值。
• 等级差距过大或字段之间存在明显语义冲突时，转入字段级裁决。

合并失败的兜底 LLM 裁决

冲突字段由 GPT-5.6 Terra 进行兜底判断。裁决过程只处理存在分歧的字段，并结合两路候选值、原始文本和字段规则输出最终结果。

理论上，人工裁决仍然更好，但这种结果也还凑合，能节省我的精力。

3. 基于 DSH 构建训练师 Agent

Agent 架构没有定式。我认为它不是最重要的部分；最近 DeepSeek-Harness 很火，所以拿来用用。

训练师 Agent 采用 DSH 架构，并围绕训练计划场景设计专用 Profile、任务上下文和 Native Tools。

用户发起个性化计划请求后，服务端将个人档案、本次训练目标、重点部位和补充需求整理为精简任务上下文，再启动独立的短生命周期 DSH 进程。

Agent 运行期间开放相关核心工具，用于多维度检索动作。

整体架构为 Plan 设计与 Tools 循环，以及一些辅助工具。

获得足够候选动作后，Agent 负责选择动作、安排训练顺序，并设置组数、次数和休息时间。计划中的动作 ID 必须来自当前任务的真实检索结果，服务端会对动作有效性、难度覆盖、剂量字段和文本长度进行最终校验。

每次生成会提供多份不同难度的候选计划，并附带简短的设计说明。用户确认候选方案后，系统通过事务写入正式训练计划。

DSH 负责 Agent 的推理和工具调度，Native Tools 提供结构化动作检索与计划提交能力，服务端负责权限控制、结果校验和数据持久化。这套分层设计使计划生成过程具备明确的数据来源、操作边界和结果验证机制。

4. 个人档案与个性化需求

产品通过个人档案持续记录年龄、性别、身高体重、训练目标、训练经验、每周训练频率、单次训练时长、训练场地、运动习惯，以及用户主动填写的体态和伤病情况。

长期档案描述用户相对稳定的身体与训练条件，本次需求则记录当前重点部位、阶段目标、训练偏好和需要回避的情况。Agent 综合两类信息设置检索条件、比较候选动作并设计训练计划。

每次规划都需要用户提出明确的个人需求和训练重点，系统主要围绕用户实际需求将其转化为科学训练方案，而非理解和猜测用户需求。

总结

产品灵感来自最近一直在做的各种运动损伤康复锻炼。除了找专业的运动康复师，日常也会频繁求助于 GPT。虽然它有非常强的专业性，但是很考验对话能力，并且 GPT 的答案往往非常发散。

所以我希望有个基础全面、质量高的动作库，用于限制 GPT 生成训练计划时的动作来源，让每次生成的计划在质量和执行上都足够统一。最开始只是个 skill，后面顺便改造成了一个产品，也顺便锻炼下我的产品设计能力。

欢迎使用，纯免费使用，底层模型使用的 DeepSeek，也不是很贵。

原创声明

原创文章，转载请注明作者和文章原链接。插图由 AI 生成，关注公众号看更多文章哦！

内容创作 AI 自律声明