Section 11: Endurance Training Coach (Intervals.icu)

核心用法

Section 11 是一套证据驱动的耐力骑行AI教练协议，采用严格的"数据优先"架构：

数据获取流程：每次响应训练问题前必须抓取运动员的JSON数据源（来自私人GitHub仓库的latest.json），禁止虚拟计算。系统按四层优先级处理：原始数据 > 协议规则（SECTION_11.md）> 运动员档案（DOSSIER.md）> 心跳配置（HEARTBEAT.md）。

首次配置要求：需完成三步设置——(1) 获取并填写DOSSIER模板，记录功率区间、目标、日程；(2) 建立GitHub数据镜像，实现Intervals.icu自动同步；(3) 配置HEARTBEAT.md，设定地理位置、天气阈值、骑行时段与通知偏好。

报告类型：Pre-workout（训练前准备度评估，含Go/Modify/Skip建议）、Post-workout（课后指标、计划符合度、周累计）、Heartbeat（日常/周期性自动监控）。

显著优点

• 循证设计：强制依赖真实训练数据，杜绝AI幻觉
• 结构化输出：标准化报告模板，专业运动科学术语
• 自动化集成：与Intervals.icu、天气API、GitHub无缝衔接
• 个性化适配：通过DOSSIER和HEARTBEAT实现千人千面
• 风险控制：Section 11 C验证清单确保建议合规性

局限性与风险

• 配置门槛高：首次使用需技术操作（GitHub仓库、API配置），非技术用户难以独立完成
• 数据依赖性强：若运动员未维护JSON数据源，系统无法运作
• 网络依赖：所有核心资源需从GitHub raw地址实时拉取，存在单点故障
• 隐私考量：训练数据存储于GitHub（即使私有），敏感用户可能顾虑
• 版本锁定：当前为v11.3，协议更新需手动同步

适合人群

• 严肃业余/半职业公路车、铁三运动员
• 具备基础技术能力的自我指导型骑手
• 已有Intervals.icu使用习惯的数据驱动型训练者

常规风险

• 未经验证清单直接生成建议可能导致训练过量或受伤
• 天气阈值配置不当可能推荐不适宜户外骑行条件
• 心跳通知的随机化 timing 可能错过关键恢复窗口提示
• 私有仓库token管理不当存在数据泄露风险

Section 11 — AI骑行教练协议评估

核心用法

Section 11是一款专为耐力骑行设计的循证训练教练系统，通过结构化协议实现数据驱动的训练管理。核心工作流程包括：首次使用时建立运动员档案（DOSSIER.md）、配置JSON数据源（通常同步自Intervals.icu）、设置自动化心跳监控（HEARTBEAT.md）。系统强制要求在任何训练相关查询前获取运动员的latest.json数据，确保所有建议基于实际数据而非虚拟计算。

显著优点

1. 科学严谨性：基于功率区间、TSS（训练负荷）、CTL/ATL/TSB（体能/疲劳/状态）等成熟运动科学指标
2. 数据完整性：强制数据获取机制杜绝"幻觉"建议，所有计算基于真实训练记录
3. 自动化监控：心跳系统支持天气感知、训练窗口智能提醒、周度背景分析
4. 标准化报告：预训练准备度评估（Go/Modify/Skip）与后训练复盘模板确保一致性
5. 社区验证：开源协议持续迭代（当前v11.3），由活跃骑行训练社区维护

潜在局限

• 配置门槛：需完成档案填写、GitHub仓库搭建、Intervals.icu同步三步初始化，对技术新手不友好
• 依赖外部平台：核心功能依赖Intervals.icu数据导出与GitHub托管，服务中断将影响使用
• 无原生移动端：纯文档型Skill，需配合聊天界面使用，缺乏专用App体验
• 天气数据未明确：心跳天气检查未说明具体API来源

适合人群

严肃业余骑行者、业余竞赛车手、半职业运动员，以及愿意投入时间理解功率训练理论的自我教练型用户。不适合休闲骑行者或完全依赖直觉训练的运动员。

常规风险

1. 数据隐私：训练数据存储于用户自建GitHub私有仓库，需自行管理访问权限
2. 过度训练风险：AI建议需结合主观疲劳感，协议虽含验证检查清单但最终决策责任在用户
3. 技术依赖：GitHub或Intervals.icu服务变更可能导致协议中断