Section 11: Endurance Training Coach (Intervals.icu)

核心用法

Section 11 是一套开源的AI骑行教练系统，专为追求科学化训练的耐力骑行者设计。其核心工作流包括：首次使用时配置运动员档案（DOSSIER.md）、建立JSON数据源（latest.json + history.json）、设置自动化心跳监控（HEARTBEAT.md）。系统通过分层数据架构（实时数据→协议规则→运动员档案→心跳配置）驱动决策，要求在任何训练咨询前必须先拉取运动员JSON数据，禁止对预计算指标进行虚拟推算。

协议涵盖完整的训练周期管理：训练数据分析、课前准备度评估（Go/Modify/Skip建议）、课后复盘报告、趋势分析与长期规划。标准化报告模板确保输出一致性，支持动态调整——指标正常时简洁输出，阈值突破或用户追问时展开详细分析。

显著优点

数据主权与隐私优先：所有数据存储于用户控制的本地设备或私有Git仓库，无后端服务、无第三方云存储，彻底杜绝训练数据商业化滥用风险。

开源透明与可审计：协议文件、同步脚本、模板全部开源（CrankAddict/section-11），用户可完整检视算法逻辑，避免黑箱教练建议。

科学严谨性：强制遵循Section 11 C验证清单，要求引用框架依据；禁止虚拟计算，必须使用实际采集的CTL、ATL、TSB、ACWR等衍生指标。

自动化与个性化平衡：心跳机制实现 weather-aware 的自主训练建议，同时保留完整人工覆盖能力；随机化通知时间避免机械化刻板印象。

潜在缺点与局限性

技术门槛较高：需要用户具备Git基础、JSON数据处理能力，或配置Intervals.icu同步流程，对非技术背景骑行者形成使用障碍。

自托管依赖：数据质量完全依赖用户维护，若同步中断或配置错误，AI教练基于过时数据给出建议，风险由用户承担。

无原生社交功能：缺乏训练社区、同伴对比、教练人工复核等机制，不适合需要外部 accountability 或心理支持的运动员。

有限的运动类型覆盖：明确聚焦耐力骑行（公路、TT、 gravel），未针对山地车技术训练、场地短程、铁人三项换项等进行优化。

适合人群

• 已使用功率计/心率带并习惯数据化训练的严肃业余骑行者
• 具备基础技术能力、重视数据隐私的半职业运动员
• 追求自主可控、愿意投入时间维护个人训练系统的自驱型用户
• 对开源工具链有偏好、不信任商业训练平台的早期技术采纳者

常规风险

数据断联风险：私有仓库权限配置错误、GitHub Token过期、Intervals.icu同步故障均可能导致教练基于 stale data 决策。建议每周手动验证数据时效性。

过度自信风险：AI建议的"客观性"可能让用户忽视主观疲劳信号，尤其在TSB绿区但睡眠/压力异常时。协议虽包含健康观察条款，但执行依赖用户诚实汇报。

开源供应链风险：协议文件从GitHub raw URL拉取，若仓库被恶意篡改且用户未及时察觉，可能植入有害训练建议。建议锁定特定commit hash或本地镜像。

自动化边界风险：心跳机制的自主调度可能被误解为"无需思考"，尤其在伤病初期、生活应激事件期间，需主动暂停自动化并人工接管。

Section 11 — 耐力骑行 AI 教练协议

核心定位
Section 11 是一套面向耐力骑行运动员的开源 AI 教练协议，通过结构化 Markdown 文档实现数据驱动的训练规划、实时状态评估与个性化指导。该 Skill 本身为纯协议模板，无实际可执行代码，所有逻辑通过提示词工程约束 LLM 行为完成。

核心用法
1. 首配初始化：引导用户完成三要素配置——运动员档案（DOSSIER.md，含功率区间、目标、日程）、数据源（latest.json/history.json，支持本地文件或私有 GitHub 仓库）、心跳配置（HEARTBEAT.md，天气阈值、通知偏好）。
2. 数据驱动决策：强制优先拉取最新训练数据（latest.json 提供 7 天快照+28 天衍生指标），长期趋势分析调用 history.json（90 天日级/180 周天级/3 年月级数据）。禁止虚拟计算预聚合指标（CTL、ATL、TSB、ACWR 等），必须基于实采数据。
3. 标准化报告：预训练前输出 Readiness 评估（Go/Modify/Skip 建议），训练后生成会话合规性分析，均遵循固定模板，正常指标简要带过，阈值越界时展开详述。
4. 心跳自动化（可选）：按用户配置的时间窗口自主触发，执行日常观察（latest.json）、周度背景分析（history.json）、天气条件筛查，并随机化下次触发时间。

显著优点

• 极致安全架构：纯 Markdown 零代码实现，无依赖链攻击面，获 CLS-Certify S+ 认证（92 分）。
• 数据主权设计：训练数据完全由用户控制，支持纯本地运行或私有仓库，零后端服务、零第三方数据收集，天然符合 GDPR/CCPA。
• 透明可审计：所有协议、模板、同步脚本开源托管于 GitHub，供应链风险完全可见。
• 循证医学基础：强制使用真实训练指标，杜绝 LLM 幻觉生成虚假数据，C 验证清单确保建议可追溯。
• 低门槛自动化：提供 sync.py 实现 Intervals.icu 到 JSON 的自动同步，支持私有仓库+访问令牌的安全链路。

潜在缺点与局限性

• 配置负担重：三文件初始化流程对非技术用户存在门槛，需理解 JSON 结构、GitHub 仓库管理或本地文件路径配置。
• 依赖外部数据源：核心功能依赖 Intervals.icu 或同类平台的导出数据，若无历史数据则无法启用高级分析。
• 无实时连接能力：不直接对接智能骑行台或可穿戴设备，数据新鲜度受同步频率限制。
• 心跳功能受限：自动化能力完全依赖运行环境的调度机制（如 OpenClaw/Claude Cowork），本身无原生定时器。
• 协议更新风险：远程拉取的 SECTION_11.md 若被篡改可能影响行为，需用户自行校验来源完整性。

适合人群

• 具备基础技术素养的耐力骑行爱好者（能操作 GitHub 或本地文件管理）
• 重视数据隐私、拒绝 SaaS 订阅模式的运动员
• 已使用 Intervals.icu、TrainingPeaks 等平台并寻求 AI 增强分析的用户
• 功率训练（FTP/CP 区间）体系的严格执行者
• 需要个性化周期化规划但无力负担人类教练的业余/业余精英选手

常规风险

• 配置阶段信息暴露：若在公共工作区填充 DOSSIER.md 或 HEARTBEAT.md，可能泄露训练目标、居住城市等敏感信息。
• 数据源 URL 管理不当：将 latest.json/history.json 置于公开仓库或未设令牌的可访问路径，可能导致训练数据泄露。
• 供应链完整性：尽管 GitHub 来源可信，仍需防范账户劫持或恶意 PR，建议锁定特定 commit hash 或启用文件签名验证。
• 医疗建议边界：协议明确为训练指导而非医疗诊断，用户需自行承担过度训练或运动损伤风险。