确定性同步与开放式分析分开#

xiaomi2weight 负责把小米体脂秤数据写入 Garmin，再由现有同步链进入训练平台。这个任务规则固定，适合脚本自动运行。

garmin_mcp 则把活动、负荷、HRV、睡眠和趋势作为独立工具提供给 Claude。模型根据问题选择数据组合，适合回答“最近疲劳来自哪里”这类开放问题。

1
确定性数据流 → 脚本与 API
2
按问题组合信息 → MCP 与模型

让模型负责定时搬运数据会增加不确定性；让固定脚本穷举所有分析问题也缺乏灵活性。

数据旁路会破坏全部结论#

实践中，训练平台的体重曾长期被 Strava 资料中的固定值覆盖。同步脚本运行正常，最终数据仍然错误，因为另一个来源具有覆盖权。

这说明数据检查不能只看主链是否成功，还要检查：

• 同一字段有哪些来源；
• 冲突时谁覆盖谁；
• 时间戳和单位是否一致；
• 手工录入是否持续覆盖自动数据；
• 称重条件是否稳定。

在体重错误期间，任何功体比结论都不可信。模型无法通过更复杂的推理修复错误输入。

观测、推断与建议分三层表达#

训练分析中，我要求输出明确标记：

1. 观测值：活动功率、心率、HRV、睡眠和负荷等实际记录；
2. 推断：疲劳、恢复或训练适应的可能解释；
3. 建议：基于当前目标和风险给出的下一步安排。

FTP、LTHR 等配置值还要说明是实测、平台估算还是暂时假设。缺少关键数据时，结论应降低置信度或停止给出强建议。

当前选择：模型提供解释，不替代测量#

我会让脚本维护稳定数据管道，让 MCP 提供细粒度只读工具，模型负责关联趋势并提出需要进一步验证的问题。训练计划的重大调整仍以实测、长期趋势和身体反馈为准。

代价是需要维护来源追踪与数据校验，也不能把一次模型分析当作医学或训练诊断。它适合减少多 App 切换和整理成本，不适合在数据缺失、来源冲突或身体异常时自动作出高风险决定。