产品入口
小程序：
产品设计理念
产品围绕“动作—档案—计划—执行”构建完整训练闭环。基础动作库提供动作查询与演示，用户可以通过三种方式设置训练计划：
- 自由编排：1000+ 动作库自由编排，设置训练顺序、组数、次数与休息时间。
- 基础课程：内置通用基础课程，适合普通人日常健身，可直接选择并快速开始，课程持续更新。
- 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 生成，关注公众号看更多文章哦！
