目录 ▾
10 月 9 日，晚上九点多，我又出去跑了一次 5 公里。
两天前，我刚跑过一次 5 公里。那次已经跑得有些吃力，想着第二次总该适应一点。
结果，跑得更慢，心率更高。
我想让 ChatGPT 帮忙看看，究竟是起跑太快，还是没有恢复好。于是，通过一个连接 COROS（高驰）的 MCP 服务，让它读取了两次运动记录。
这次对话最后走得比我预想的远：经过我的确认，它把未来一个月的训练计划直接写进了 COROS。
之前也看过不少 MCP 的介绍。这一次，我具体感受到了它替我省掉的是哪一步。
一、同样跑 5 公里，第二次为什么更累？
把两次记录放在一起，差别很直观。
| 指标 | 10 月 7 日 | 10 月 9 日 |
|---|---|---|
| 跑步距离 | 5.02 km | 5.20 km |
| 平均配速 | 6’26”/km | 6’46”/km |
| 平均心率 | 168 bpm | 173 bpm |
| 训练负荷 | 119 | 141 |
| 第 5 公里配速 | 6’42”/km | 7’25”/km |
第二次平均每公里慢了 20 秒，平均心率却高了 5 bpm。到了第五公里，掉速更加明显。
如果只看这张表，我大概会归结为：太久没跑，体能下降了。
但这个解释有点笼统。接下来到底应该慢一点跑、少跑一点，还是多休息？仅凭“体能下降”四个字，我仍然不知道怎么调整。
ChatGPT 继续读取了逐公里数据，以及近期的睡眠、HRV、静息心率和训练负荷。
10 月 9 日的第一公里，配速是 5’48”；第五公里，变成了 7’25”。步幅也从第一公里的 0.96 米，缩到了第五公里的 0.78 米。
起跑的速度，我没能维持到最后。
恢复数据也提供了一条线索：10 月 8 日早晨的睡眠 HRV 是 33 ms，低于记录中的个人基线 52 ms；10 月 9 日早晨回升到了 47 ms。
不过，不能据此就说“原因找到了”。HRV 会受到训练、睡眠和生活压力等多种因素影响，需要结合个人趋势来看。COROS 的官方说明也把它作为观察身体压力反应的指标。
两次跑步，加上几个恢复指标，还不足以确定为什么这次更累。
AI 给出的建议是：先把恢复、起跑强度和训练连续性放在前面，暂时放下配速目标。
对我有帮助的地方，在于它把原本散落在几个页面里的数据摆到了一起。哪些地方值得关注，哪些判断还需要继续观察，比一句“最近状态不好”具体多了。
二、我又问了一句：能直接写进 COROS 吗？
分析结束后，我让 ChatGPT 根据这些记录，制定未来一个月的训练方案。
它给出的安排以恢复为主：先跑走结合，再建立每周两到三次的规律，随后逐步延长轻松跑时间，最后用一次轻松的 5 公里观察恢复情况。
计划也考虑了睡眠和工作节奏，提醒我不要为了完成训练挤占睡眠。
到这里，它已经完成了一次常见的 AI 咨询：看数据，给建议，排计划。
但我还得把计划搬进平时使用的工具里。哪天跑、热身多久、正式训练怎么安排、最后怎样放松，都需要逐项设置。
于是，我又问了一句：
你有办法在 COROS 中创建训练日程吗？
它回答可以。
得到我的确认后，它先查询了 COROS 中是否存在正在执行的训练计划，再调用创建工具。
最后返回了一行结果：
Training plan saved and running.
按工具返回的结果，一份覆盖 10 月 10 日至 11 月 8 日、包含 12 次跑步训练的计划，已经保存并启用。每次训练包含热身、正式训练和放松阶段，以及对应的参考配速或强度要求。
这比生成一张训练表更让我意外。12 次训练，每次的日期和训练阶段，我都不用再照着聊天记录，逐项录入 App。
已经讨论好的安排，就这样被送进了我接下来会使用的系统。
三、分析靠模型，执行靠工具
MCP，全称 Model Context Protocol，是连接 AI 应用与外部系统的一套开放标准。外部服务可以通过它，把可读取的数据、可调用的工具提供给 AI 应用。MCP 官方介绍
放在这次体验里，分工其实很清楚：
- COROS 提供运动记录和训练计划等能力。
- 连接服务把相应能力提供给 ChatGPT 调用。
- 模型结合数据组织分析、生成方案，再由工具执行写入。
所以，MCP 不负责判断我该怎么训练，也不会让模型自动变成专业教练。能读取哪些数据、能修改哪些内容，还要看具体服务开放了什么，以及我授予了什么权限。
通过 API 等方式，AI 原本也能调用外部系统。MCP 的作用，是给这类连接提供共同的规范。
过去，AI 帮我生成结果，我负责把结果搬进系统；这一次，在我的授权下，工具把这段操作也接了过去。
省掉的，是两个系统之间那段人工搬运。
这也让我开始换一个标准看 Agent：
对话之外，目标系统里到底改变了什么？
如果只得到一篇分析，我拿到的是建议。训练日程完成写入，才多交付了一步。
而一旦允许写入，检查就要跟上。读错一条数据，可能影响分析；写错日期、重复创建计划或覆盖已有安排，会直接影响接下来怎么用。
创建前查询已有计划，并保留我的确认，是流程里值得保留的步骤。MCP 的工具规范也建议对敏感操作进行用户确认，并校验工具结果。但具体应用有没有做好，仍然要单独检查。
四、计划已创建，效果还没验证
写到这里，需要把这次体验的终点说清楚。
我拿到了数据分析，确认了训练安排，工具返回了创建成功。这个月的训练还没有开始，更没有证据说明它一定适合我、一定能改善成绩。
接下来还有两层核对。
先回到 COROS，核对日期有没有偏移、安排是否重复、每次训练的时长和强度是否与确认的方案一致。工具说“成功”，还需要目标系统里的实际记录来印证。
收到成功响应、目标系统保存正确、训练确实有效，是三件不同的事。对 Agent 的验收，也应该从“有没有调用成功”，继续往下走到“结果是否符合预期”。
然后才是按身体实际反应评估计划。训练完成得怎么样、主观上累不累、恢复情况如何，都要继续观察。这份 AI 生成的安排只能作为待验证的个人训练参考，不能替代专业评估。
我期待的下一步，是每次训练后，AI 能把新数据与原计划放在一起，指出哪里可能需要调整，并说明理由。涉及修改，再由我确认。
这部分还没有实现。一次创建成功，距离持续可靠地辅助训练，还有路要走。
不过，这次体验已经足够让我改变一个使用习惯。
以后再让 AI 制定计划，我会多问三句：
能写进哪个工具？写入前让我确认什么？写完后到哪里核对？
这次，AI 帮我少做了一遍录入。接下来一个月，我想验证的是：它能不能帮我少做几次不合适的训练安排。
易浅小站
EACHEN STUDIO / ARTICLE END