一句话的旅程
设想一个示意场景，内容为模拟，不代表任何真实用户。
用户在 App 里输入：“我想十二周后把半程马拉松跑进两小时，膝盖有时候不舒服，每周最多能练四天，周三晚上没时间。”
这句话里混着几类东西：
- 目标：半马，两小时，十二周；
- 约束：每周四天，周三不可用；
- 身体顾虑：膝盖不适，程度和频率不明；
- 隐含要求：计划应当稳妥，别把人练伤。
如果让一个通用大模型直接回答，它会给出一份看上去很专业的十二周计划。问题在于，这份计划不是从这位用户的心率、配速和恢复数据算出来的，是从大量文本里“像”出来的。它可能合理，也可能与用户当前的能力差距很大。所以我们把这条链拆成几段，让每段用最适合它的方法。
各模型各管什么
| 环节 | 负责什么 | 输入 | 输出 | 不该做什么 |
|---|---|---|---|---|
| 语言模型 | 听懂目标，把自然语言转成结构化约束，并把结果解释成人话 | 用户的话、历史对话 | 目标、期限、可训练日、身体顾虑标记 | 自己计算心率、配速或负荷 |
| 姿态模型 | 从视频里估计关节位置与动作形态 | 视频帧 | 关节点、角度、置信度 | 判断“你会不会受伤” |
| 时间序列模型 | 读心率、功率、配速等序列，估算负荷与恢复 | 传感器序列、天气 | 负荷、疲劳、恢复评估及不确定性 | 生成训练建议的文字 |
| 优化模型 | 在约束下排出训练安排 | 目标约束、负荷与恢复状态 | 具体的周计划或当日安排 | 忽略语言模型给出的约束 |
一个粗略的原则是：擅长语言的负责语言，擅长算数的负责算数。这种让语言模型去调用外部工具的思路，在学界有一批相关工作，比如 ReAct、Toolformer 等常被提到的早期研究，核心想法就是让语言模型判断何时该调用别的工具，而不是用文字硬猜答案。
数据怎么流动
上面那位用户的一次完整处理，大致是这样：
- 语言模型把用户的话解析成结构化目标：半马、120 分钟、12 周、四天每周、周三不可用、膝盖顾虑标记为“需要低冲击选项”。解析结果会回显给用户确认，比如“我理解你希望……对吗”。
- 时间序列模型读取近几周的跑步数据，得到一个当前状态：近四周平均周跑量、典型配速下的心率、恢复速度的估计，还有它有多不确定。
- 如果用户有过动作视频，姿态模型提供步频、触地、躯干姿态等信息，这些信息可作为“膝盖顾虑”的补充证据，但只是证据，不是诊断。
- 优化模型拿到目标、约束、当前状态，排出每周的训练安排，并给出每项安排的主要依据。
- 语言模型把结果翻译成用户看得懂的说明，同时引用优化模型给出的依据，不允许自行添加。
这五步里，最重要的是每一次转手，不确定性都跟着走。时间序列模型如果只说“恢复良好”，而没说“数据只有五天，很不确定”，后面优化模型就会当作可靠输入使用。
交接处最容易丢的东西
多模型链路的风险，几乎都出现在交接处。
语言到结构化。“膝盖有时候不舒服”，是每周一次还是每次跑完都痛？语言模型不应替用户决定，遇到这种模糊信息时应该追问，或者标记为“待确认”，而不是直接写成“无问题”。
视频到数字。姿态模型给出的关节角度带着误差和遮挡，如果下一环只拿到角度，不知道置信度，就会把猜出来的数值当作事实。
数值到计划。优化模型是在约束下找一个“最好”的方案，但“最好”是按目标函数定义的。如果目标函数只追求提高训练量，它可能推荐一个对这位用户过重的计划，所以恢复和伤病约束必须是硬约束，而不是可以被牺牲的软偏好。
计划到语言。最后一步的解释，容易发生“听上去合理但与计算无关”的问题，在可解释AI教练一文里对此有更细的讨论。
谁来对结果负责
这是多模型系统里最常被回避的问题。
我们的设计立场是：每一环对自己的输出负责，最终建议由整个系统对用户负责，而不是由“模型”这个抽象概念负责。具体拆开：
- 语言模型负责理解是否准确。如果它把“周三没时间”误解为“周三想练”，是它的错，而确认环节就是为了在这里拦住；
- 姿态模型负责关节点估计的质量与置信度声明；
- 时间序列模型负责负荷与恢复估计，以及对不确定性的如实报告；
- 优化模型负责在约束内给出可执行的方案，且方案必须能追溯到输入；
- 系统层面负责链路的完整性：任何一环失败、数据缺失或置信度过低时，整体应降级，给出更保守的建议或直接告诉用户“当前信息不足”。
另外还有一层：涉及心率、疲劳或膝盖不适的提示，只属于训练安排层面，不替代医生或专业教练的意见。系统不做诊断，遇到明显的疼痛描述，会建议先咨询专业人员。
隐私也在交接里
每一次数据交接，也是一次隐私问题。语言模型需要知道用户的目标，不一定需要知道全部的心率序列；姿态模型需要视频，但视频没有必要进入语言模型的上下文。
一个合理的做法是最小化传递：每个模型只拿到完成自己任务所需的那部分，能在本地做的先在本地做。这一点会在运动数据要不要全部上传云端里更具体地展开。
这样做的代价与判断
多模型协作不是免费的午餐。它让链路更长、延迟更高、调试更难；一个环节的小误差，可能在后面被放大。相比之下，单一大模型“一步到位”确实简洁。
我们仍然选择拆分，是因为体育训练这个场景对可核对性要求很高：负荷是不是被低估、动作是不是被误判、计划为什么这样排，都应该能追问到具体的一环。当系统只有一个黑盒的时候，出了问题，最诚实的回答只有“模型是这么输出的”。而在分工清楚的链路里，至少可以说：这一步的输入是什么，这一环的把握有多大，问题出在哪里。
那位想跑进两小时的用户，最终得到的是一份带着理由、带着不确定说明的计划，而不是一份漂亮的模板。
