1. 项目概述：一个为耐力运动员设计的确定性AI教练协议

如果你是一名严肃的耐力运动爱好者，无论是公路车、铁三还是越野跑，你大概率都曾为“今天该怎么练”这个问题纠结过。传统教练费用高昂，而市面上的AI教练应用又往往像个黑盒——你输入数据，它给出一个计划，但你永远不知道这个建议是基于科学模型，还是基于某个通用模板的猜测。更让人头疼的是，这些AI的建议常常前后矛盾，今天让你猛冲，明天又让你彻底休息，缺乏一个连贯、可追溯的逻辑。

这正是 Section 11 项目要解决的问题。它不是一个具体的软件或App，而是一套开源的“协议”或“框架”。你可以把它理解为一套极其详尽的“AI教练行为准则”和“数据交换规范”。它的核心目标，是让任何具备代码理解能力的主流AI模型（如ChatGPT、Claude、Gemini等），在接入你的训练数据后，能够像一个遵循最新运动科学、且每一步推理都可审计的人类教练那样，为你提供训练指导。

想象一下，你完成了一次骑行，将数据同步到Intervals.icu。然后，你打开一个配置好的AI对话窗口，问它：“我今天练得怎么样？” AI不会给你一个模糊的“很棒，继续努力”，而是会调取你过去90天的训练历史、本次训练的详细分段数据、你当前的体能状态（CTL）、疲劳度（ATL）、压力平衡（TSB），甚至结合你昨晚的睡眠和晨起心率变异性（HRV），生成一份结构化的报告：“今日2小时Z2骑行，实际TSS 78，计划75，完成度104%。平均功率175W，NP 182W，变异指数1.04，控制良好。心率漂移2.1%，表明有氧效率稳定。当前TSB为-18，处于正常累积疲劳区间，ACWR（急慢性负荷比）为1.15，负荷增长安全。明日可按计划进行间歇训练。” 这份报告里的每一个数字、每一个结论，都能在Section 11协议中找到对应的科学依据和计算逻辑。

这就是Section 11的魅力： 确定性 与 可审计性 。同样的输入，永远产生同样的输出分析框架。每一个训练建议，都必须引用如Seiler的80/20极化训练模型、Gabbett的ACWR急慢性负荷比等经过同行评议的科学框架。你的数据永远留在你控制的设备或仓库里，协议本身不运行任何后端服务。它本质上是一份给AI的“超级说明书”，以及一套帮你把训练数据（主要来自Intervals.icu）整理成AI可读格式的自动化工具链。

2. 核心设计理念与架构解析

2.1 为什么是“协议”而非“应用”？

市面上的训练应用很多，从TrainingPeaks、Today‘s Plan到Final Surge，它们都提供了数据分析功能。但它们的分析逻辑是封闭的，你无法定制或审计。Section 11反其道而行之，它不尝试再造一个应用，而是定义了一套开放的数据规范和交互协议。这样做有几个深层考量：

1. 避免平台锁定与数据主权： 你的所有数据——FTP、心率区间、训练记录、健康指标——都通过脚本同步到你自己的GitHub私有仓库或本地文件夹。AI只是这个数据的“读取者”和“分析引擎”。你可以随时更换AI平台（从ChatGPT换到Claude），甚至未来有更好的模型出现，你的数据和这套分析框架依然有效。数据主权完全掌握在你手中。

2. 利用AI的泛化能力，而非专用算法： 一个专门开发的应用程序，其分析逻辑是固定的。而像GPT-4、Claude 3这样的通用大模型，在获得了详尽的协议指导和结构化数据后，能够进行更复杂、更贴近自然语言的推理。例如，它可以理解“本周单调性指数（Monotony）偏高”与“你昨天在论坛提到工作压力大”之间的潜在关联，这是专用算法难以做到的。

3. 社区驱动与快速迭代： 运动科学在不断演进。作为一个开源协议，任何研究者或教练都可以提议将新的科学模型（例如最新的心肺功能代谢研究）整合进协议中，通过社区讨论和验证后即可成为标准的一部分。这种迭代速度远超封闭式商业软件。

2.2 三大支柱：协议、数据与执行

Section 11的架构清晰地区分为三个层次，这对应了其项目仓库中的核心文件：

第一层：行为协议（SECTION_11.md） 这是整个项目的“宪法”。它详细规定了AI教练在分析数据、给出建议时必须遵守的所有规则。主要分为三部分：

• A部分 - AI教练指导协议： 定义了AI的日常行为准则。例如，“禁止虚拟计算”——AI必须使用从你数据中获取的真实计算值（如TSB），而不是自己重新估算。“显式数据请求”——如果数据缺失，AI必须询问，而不是假设。“容忍度合规”——训练建议必须在功率±3W、心率±1bpm的误差范围内。
• B部分 - AI训练计划协议： 规定了AI如何生成或修改长期训练计划。包括周期阶段（基础期、进展期、巅峰期、减量期）的划分逻辑、每周训练量上限（不超过基线的±10%）、强度分布（遵循80/20极化原则）等。
• C部分 - AI验证协议： 定义了一个标准化的元数据输出格式。每次AI生成回复，都应该附带一个“验证元数据”，像飞行数据记录仪一样，列出它检查了哪些数据源、引用了哪些科学框架、通过了哪些验证点。这确保了每次交互都是可审计的。

第二层：数据同步与预处理（ /examples 中的各类Sync脚本） 协议需要高质量、结构化的数据。项目提供了多种将Intervals.icu数据同步到本地的方案，核心是生成几个关键的JSON文件：

• latest.json : 你最近一次训练的数据快照，包含本次活动的详细指标以及当前体能状态（CTL/ATL/TSB等）。
• history.json : 你过去90天（日）、180天（周）、乃至3年（月）的历史训练数据汇总。这是进行趋势分析和周期检测的基础。
• intervals.json : 针对有结构化间歇（如5x5分钟阈值区间）的训练，提供每个间歇段的详细数据（功率、心率、完成度）。这对于分析单次训练质量至关重要。
• routes.json : 针对未来有计划路线的活动（如一场比赛），提供地形分析数据，包括爬升、坡度、赛道分类等，用于赛前策略制定。

这些脚本的另一个重要作用是 预先计算关键衍生指标 。例如，ACWR（急慢性负荷比）、恢复指数（Recovery Index）、单调性指数（Monotony）等。这些计算在本地完成，AI直接读取结果，避免了不同AI模型计算方式不一致的问题，确保了“确定性”。

第三层：AI平台执行与交互 这是你作为用户直接接触的部分。你需要在一个支持“长上下文”和“文件读取”的AI平台上（如ChatGPT的“项目”功能、Claude的“项目”、或具备代码执行能力的“智能体”平台如OpenClaw），上传或让AI读取上述协议文件和你的数据文件。然后，通过精心设计的提示词（在 SETUP_ASSISTANT.md 中提供），引导AI扮演一个严格遵守Section 11协议的教练角色。

2.3 科学框架的集成：不只是80/20

很多人一听“科学训练”，就想到“80/20”。Section 11的深度在于它整合了 超过15个 经过验证的运动科学模型，形成一个多维度的决策矩阵：

• 负荷管理： 使用 Banister的 impulse-response（TRIMP）模型 来计算CTL（长期训练负荷）、ATL（短期训练负荷）和TSB（训练压力平衡）。使用 Gabbett的ACWR模型 来评估受伤风险，确保负荷增长在安全范围（通常0.8-1.3）内。
• 强度控制： 核心是 Seiler的极化训练模型 ，确保约80%的训练时间在低强度（Z1-Z2），20%在高强度（Z4+）。同时监控“灰色区域”（Z3）的时间占比，避免低效训练。
• 周期规划： 参考 Issurin的板块周期理论 ，将训练划分为目标不同的宏观周期（如基础期、进展期、巅峰期），并设计动态的“滚动阶段逻辑”，根据实时负荷和疲劳数据自动调整当前所处阶段。
• 疲劳与恢复： 利用 Foster的单调性与紧张度指数 来预警过度训练。结合每日的 HRV（心率变异性）和静息心率 数据，作为“准备度”的客观指标。
• 表现预测： 集成 Skiba的W’平衡模型 和 Coggan的功率-持续时间模型 ，用于分析高强度间歇训练中的疲劳累积和恢复情况。

AI教练的每一个建议，都必须关联到这些框架中的一个或多个。例如，当它建议你明天进行恢复骑行时，它可能会同时引用“ACWR值已连续三天高于1.5（Gabbett模型，高风险区间）”和“今晨HRV较7日基线下降15%（准备度触发点）”。这种引用机制，迫使AI的推理过程从“模糊的感觉”变为“基于证据的链条”。

实操心得： 刚开始接触时，可能会被这么多科学术语吓到。但关键在于，你不需要成为所有这些模型的专家。Section 11和AI帮你完成了“翻译”工作。你只需要关注AI最终给出的、基于这些模型综合研判的“可执行建议”：今天练什么、强度多少、时长多久。这套系统的价值在于，它把顶尖运动队科研人员使用的复杂分析模型，封装成了一个普通爱好者也能日常使用的工具。

3. 从零开始搭建你的确定性AI教练

3.1 第一步：准备你的“运动员档案”（Dossier）

在让AI分析你之前，你必须先告诉它“你是谁”。这就是 DOSSIER_TEMPLATE.md 文件的作用。它不是一个简单的个人信息表，而是一份结构化的教练简报。

你需要填充的核心信息包括：

1. 生理基础数据： 年龄、体重、身高、性别。这些是计算热量消耗、评估负荷相对强度的基础。
2. 当前能力阈值（这是重中之重）：
   • 骑行： 当前FTP（功能阈值功率）、对应的心率区间、功率区间（基于FTP的百分比）。
   • 跑步： 当前阈值配速、阈值心率、心率区间。
   • 游泳： 阈值配速、心率（如有）。
   • 务必注明这些数据的测试日期和测试方式 （如20分钟测试、Ramp Test），因为AI需要知道数据的“新鲜度”。
3. 训练目标： 明确、可量化。例如：“在6个月内完成一场70.3英里铁人三项，目标完赛时间5小时30分钟”，比“我想变得更健康”要好得多。目标决定了周期规划的方向。
4. 可用训练时间： 每周哪几天、每天什么时段、每次训练最多能安排多长时间。现实的时间约束是计划可行的前提。
5. 设备与数据源： 你使用什么品牌的手表/码表（Garmin, Wahoo, Suunto等）、是否连接心率带、功率计、是否使用AlphaHRV等HRV监测设备。这关系到数据获取的完整性和准确性。
6. 营养与恢复策略： 训练前后常规的补给策略、睡眠目标、压力管理方式。这有助于AI在建议中考虑恢复因素。

注意事项： 诚实是第一原则。虚报FTP或训练时间，会导致AI基于错误数据给出危险建议（如负荷过高）。如果你不确定自己的FTP，宁可设置一个保守值，让AI在后续训练数据分析中帮你逐步验证和调整。 DOSSIER.md 是一个动态文件，你应该随着能力的提升定期更新它。

3.2 第二步：建立自动化数据管道（以GitHub Actions为例）

这是技术性稍强的一步，但项目提供了详细的“抄作业”脚本。我们以最常用的 GitHub Actions自动同步方案 为例，讲解核心步骤和原理。

1. 创建私有数据仓库： 在你的GitHub账号下创建一个新的私有仓库，例如命名为 my-training-data 。私有性保证了你的敏感训练数据不会公开。

2. 获取Intervals.icu API密钥： 登录你的Intervals.icu账户，进入设置（Settings）-> API，创建一个新的API密钥。这个密钥就像一把只能读取你数据的钥匙。 务必妥善保管，不要泄露。

3. 配置仓库Secrets： 在你的 my-training-data 仓库中，进入 Settings -> Secrets and variables -> Actions。新建一个Repository secret，名称填 INTERVALS_ICU_API_KEY ，值粘贴你刚才复制的API密钥。这样，GitHub Actions工作流在运行时就能安全地使用这个密钥去拉取数据，而不会在代码中明文暴露。

4. 部署同步工作流： 将项目 examples/json-auto-sync/ 目录下的 .github/workflows/sync.yml 文件复制到你仓库的相同路径下。这个YAML文件定义了GitHub Actions要执行的任务：每隔15分钟（你可以调整这个频率），触发一个任务，使用你的API密钥调用Intervals.icu的接口，获取你的最新数据，经过计算处理后，生成 latest.json , history.json 等文件，并提交回你的仓库。

5. 提交你的Dossier： 将你填写好的 DOSSIER.md 文件也放入这个数据仓库的根目录。这样，你的所有数据（动态指标+静态档案）就都在一个地方了。

这个自动化流程的好处是“一劳永逸” 。一旦设置完成，你就不再需要手动导出、上传数据。你的AI教练总能访问到你最近15分钟内的训练状态。这对于需要每日甚至多次交互的教练场景至关重要。

替代方案：本地同步 如果你不想依赖GitHub，或者对数据隐私有极致要求，可以使用 examples/json-local-sync/ 提供的Python脚本。在树莓派、旧电脑或NAS上运行这个脚本，它会在本地定时执行同步，将数据保存在你的硬盘上。然后，你可以通过将本地文件夹共享给AI桌面应用（如Claude Cowork），或使用云盘同步（如Google Drive）的方式，让AI读取数据。

3.3 第三步：配置你的AI教练平台

这是将协议、数据和AI大脑连接起来的环节。你需要选择一个能处理长文本、能读取文件（或访问网络资源）的AI平台。根据其能力，可分为两类：

A. 智能体平台（功能完整，体验最佳） 这类平台如OpenClaw、Claude Code、Cursor等，通常以桌面应用或命令行工具形式存在，具备代码执行能力和对本地文件系统的完全访问权限。

• 优势： 可以直接读取你本地同步的JSON文件，速度最快；可以执行 push.py 这样的脚本，将AI生成的训练计划直接写入你的Intervals.icu日历；可以实现完全离线的私密交互。
• 设置流程（以Claude Cowork为例）：
  1. 在电脑上安装Claude Cowork应用。
  2. 将你的本地数据文件夹（包含 latest.json , history.json , DOSSIER.md 等）和下载的 SECTION_11.md 协议文件放在一个目录下。
  3. 在Claude Cowork中创建一个新项目，并将这个目录作为项目的“知识库”或“工作区”关联起来。
  4. 将 SETUP_ASSISTANT.md 中的完整提示词粘贴到项目的“指令”区域。
  5. 现在，你就可以在这个项目中与你的AI教练对话了。它可以直接读取所有文件，无需网络请求。

B. 网页聊天平台（门槛低，适用性广） 这类平台包括ChatGPT（项目功能）、Claude（项目功能）、Gemini（Gems功能）、Grok等。它们主要通过浏览器使用，通过“连接器”来访问外部数据源（如GitHub仓库）。

• 优势： 无需安装软件，使用方便；通常有免费或低成本的套餐。
• 设置流程（以ChatGPT Projects为例）：
  1. 在ChatGPT官网创建一个新的“Project”。
  2. 在Project设置中，找到“连接器”或“知识库”选项，连接你的GitHub账户，并授权访问你的私有数据仓库 my-training-data 。
  3. 由于 SECTION_11.md 协议文件不在你的数据仓库中，你需要手动将其内容上传到Project的“知识库”中，或者额外连接 CrankAddict/section-11 这个公共仓库。
  4. 将 SETUP_ASSISTANT.md 中的提示词，精心修改后填入Project的“指令”框。这里的关键修改是数据访问部分：你需要明确告诉AI，数据位于你已连接的GitHub仓库中，并给出 latest.json 等文件的原始链接（Raw URL）格式，例如 https://raw.githubusercontent.com/[你的用户名]/my-training-data/main/latest.json 。
  5. 保存设置，即可开始对话。

避坑指南：AI不读取数据怎么办？ 这是新手最常见的问题。你问“我今天练得如何？”，AI回答“请提供你的训练数据”。这通常是因为：

1. 连接器未正确授权： 检查AI平台内的GitHub连接器状态，确保它已成功连接并拥有对你数据仓库的读取权限。
2. 指令不清晰： 在提示词中，必须用极其明确的指令告诉AI 第一步 就是去获取数据。Section 11的提示词模板中包含了严格的“数据访问”步骤：先检查对话中是否已附加文件，再尝试通过连接器读取，最后才尝试通过URL获取。确保你复制粘贴的指令完整无误。
3. URL错误或仓库非公开： 如果你使用URL获取方式，确保链接正确，且如果你的仓库是私有的，确认你使用的AI平台支持通过授权访问私有仓库的原始内容（现在ChatGPT、Claude等大多支持）。
4. 平台缓存： 有时更改了指令或数据后，AI会沿用旧会话的缓存。 开启一个新的聊天会话往往是解决各种奇怪问题的最快方法。

3.4 第四步：测试与校准

设置完成后，不要急于投入日常使用。先进行系统性的测试，确保AI教练的行为符合预期。

测试1：基础数据获取 输入：“列出我当前的核心训练指标（CTL, ATL, TSB, ACWR）。”

• 期望响应： AI应能直接从 latest.json 中提取这些数值，并正确说出其含义（例如：“你当前的CTL（长期训练负荷）为98，ATL（短期训练负荷）为112，TSB（训练压力平衡）为-14，表示你正处于适度疲劳的积累期。ACWR（急慢性负荷比）为1.18，负荷增长在安全范围内。”）
• 失败响应： AI要求你提供数据，或给出的数值明显错误（如TSB高达-100）。

测试2：单次训练分析 输入：“分析我最近一次训练的质量。”

• 期望响应： AI应能识别出最近一次活动，列出其类型、时长、距离、平均功率/心率、强度分布（各区间时间占比）、TSS、以及本次训练的关键质量指标如心率漂移、变异指数等。并给出一个简短的合规性评价。
• 失败响应： AI混淆了活动日期，或遗漏了关键指标，或开始进行与协议无关的泛泛而谈。

测试3：训练建议生成 输入：“根据我过去一周的数据和明天的可用时间（1小时），推荐一个明晚的训练内容，并说明理由。”

• 期望响应： AI应首先检查你的准备度指标（如近期HRV/RHR趋势）、当前负荷（TSB, ACWR）和疲劳状态，然后从Section 11 B协议规定的“训练库”中选择一个合适的课程模板（例如：“30分钟Z2稳定骑行 + 4组 3分钟Z5间歇，组间休息3分钟”），并引用相关科学框架解释为何此建议适合你当前状态（例如：“鉴于你ACWR为1.1且TSB为-12，可承受一定强度；同时过去72小时无高强度训练，故安排间歇训练以刺激VO2max。”）。
• 失败响应： AI给出一个模糊的建议（如“进行一些高强度间歇”），没有具体参数，或没有引用任何数据和分析过程。

通过这几个测试，你就能基本判断你的AI教练是否已正确“上岗”。如果测试失败，回头检查数据同步是否成功、AI平台连接器是否正常、提示词指令是否准确。

4. 实战应用：与你的AI教练深度协作

当系统搭建并测试完毕后，你就可以将其融入日常训练生活了。以下是一些典型的使用场景，展示了Section 11如何改变你的训练决策方式。

4.1 场景一：晨间准备度检查与当日训练决策

传统上，你可能凭感觉决定今天是否要执行计划中的高强度课表。现在，你可以这样问你的AI教练：

“早上好。这是我昨晚的睡眠数据（深度睡眠1.5小时，HRV 55ms，静息心率48）。我今天计划进行2小时的耐力骑，但感觉有点疲惫。请评估我的准备度，并给出训练建议。”

AI教练的响应流程：

1. 数据获取与验证： 自动读取 latest.json 中的最新健康数据（HRV, RHR）和训练负荷数据（TSB, 单调性指数）。
2. 协议检查： 根据Section 11 A中的准备度阈值进行比对。例如，它会检查“HRV较7日基线下降是否超过20%”、“RHR是否上升超过5bpm”、“自感疲劳度（RPE）是否≥4”。
3. 综合分析： 结合所有指标。比如，虽然HRV略有下降但仍在正常范围，RHR稳定，但TSB较低（-25）且自感疲劳度高。
4. 给出确定性建议： 它不会说“也许你可以轻松一点”，而是会给出明确指令：“根据协议，你的HRV和RHR未触及调整阈值，但TSB为-25且自感疲劳度高。建议将今日2小时耐力骑的强度从Z2上限（75%FTP）调整为Z2下限（65%FTP），并将时长缩短至1.5小时，以促进恢复。这符合Gabbett ACWR模型中对高疲劳状态下的负荷管理原则。”
5. 提供验证元数据（如果询问）： 你可以要求它“显示本次分析的验证清单”，它会输出一个类似协议C部分的JSON片段，列出所有检查项和引用的框架。

这种交互将主观的“感觉”变成了客观的、基于多重数据交叉验证的 决策支持 。

4.2 场景二：周期训练计划的动态调整

你正在为一个目标赛事进行16周的训练。原计划第8周是增量周。但第7周末你因故错过了一次关键长距离训练。

提问：“我错过了上周日的长距离课表，这对我当前的训练阶段和下周的计划有何影响？是否需要调整？”

AI教练的响应流程：

1. 回顾与重评估： 调取 history.json ，重新计算过去4周的负荷趋势、ACWR、以及“滚动阶段逻辑”中的各项指标。
2. 阶段检测： 根据协议B中的“滚动阶段逻辑”，判断你当前实际所处的训练阶段（可能是“基础期”的巩固，而非原计划的“进展期”起点）。
3. 计划调整： 基于新的阶段判断，从训练库中重新选取或微调下周的课表。例如，它可能建议：“原定下周进入‘进展期’增加强度。但由于上周负荷未达标，建议延长‘基础期’一周，重复本周的中等量Z2训练，将ACWR稳定在1.0左右，下周再重新评估是否进入进展期。”
4. 风险提示： 它会指出：“如果强行按原计划增加强度，ACWR可能跃升至1.4以上，受伤风险增加（参考Gabbett, 2016）。”

这体现了Section 11的另一个核心： 动态适应性 。训练计划不是一成不变的圣经，而是根据你的实际执行情况和身体反馈不断演化的路线图。

4.3 场景三：高强度间歇训练（HIIT）的精准分析

你完成了一次痛苦的5x5分钟阈值间歇训练。上传数据后，你不仅想知道完成与否，还想知道每一组间歇的质量如何。

提问：“请详细分析我今天5x5分钟阈值间歇的完成情况，包括每一组的功率稳定性、心率漂移和组间恢复。”

AI教练的响应流程：

1. 定位数据： 发现 latest.json 中该活动标记了 has_intervals: true ，于是自动去 intervals.json 中查找该活动的详细分段数据。
2. 逐组分析： 对每一组5分钟间歇，报告其平均功率、标准化功率（NP）、是否达到目标区间（如100-105%FTP）、心率反应、以及“变异指数”（VI，衡量功率平稳度的指标）。
3. 整体评估： 计算本次间歇训练的整体“完成质量”（例如：5组中有4组功率落在目标区间±3W内）。分析心率漂移情况，判断是否因疲劳导致后几组心率攀升过快。
4. 恢复评估： 分析组间休息期间的心率下降速率，评估你的恢复能力。
5. 综合反馈： “本次间歇训练完成质量优秀。第1-4组功率稳定在目标区间（VI<1.05），第5组功率下降3%，但心率漂移仅2%，表明疲劳可控。组间心率恢复速率良好。建议48小时内安排主动恢复。”

这种颗粒度的分析，以往需要教练手动在WKO5或Golden Cheetah等专业软件中操作。现在，通过结构化的 intervals.json 和AI的解析能力，你可以即时获得。

4.4 场景四：赛事策略模拟与地形分析

你报名了一场百公里越野赛，赛事方提供了GPX路线文件。你想知道如何分配体力。

提问：“我已将‘百公里越野赛’的GPX文件添加到Intervals.icu的日历中。请基于路线地形，为我制定一个配速和体力分配策略。”

AI教练的响应流程：

1. 获取地形数据： 识别到该计划活动标记了 has_terrain: true ，从 routes.json 中读取详细的路线分析数据：总距离、总爬升、爬升分布（有多少个Cat 1级爬坡？）、下坡技术路段长度等。
2. 结合能力模型： 根据你的 DOSSIER.md 中提供的阈值配速/功率、以及历史 history.json 中类似地形活动的表现（如上下坡效率），建立你的体力消耗模型。
3. 生成策略： 输出分段建议：“前20公里平缓，建议以85%阈值心率巡航，储备体力。第20-40公里连续两个Cat 2爬升，预计耗时90分钟，建议将功率控制在FTP的90-95%，心率控制在阈值区间上限。顶峰后10公里下坡技术路段，优先安全，心率可回落至Z2。最后30公里起伏路，根据实时疲劳感，采用‘上坡保守，下坡积极’的策略……”
4. 补给提醒： 甚至可以结合距离和预计耗时，提醒关键的补给点时间窗口。

这超越了简单的训练分析，进入了 战术规划 的领域。AI教练利用地形数据和你的个人能力模型，扮演了“战术分析师”的角色。

5. 高级技巧、常见问题与深度优化

5.1 数据质量是生命线：常见数据问题与排查

问题：活动数据中出现大量 null 值或字段缺失。

• 根源： 这几乎总是因为你的设备（如Garmin手表） 通过Strava同步 到了Intervals.icu。由于API限制，Strava传输的数据是精简版的。
• 解决方案： 在Intervals.icu的设置中，断开Strava连接（或保留它仅用于社交），然后直接添加你的设备制造商（Garmin、Wahoo、Suunto等）作为数据源。这样，完整、高保真的原始数据（包括功率、心率、海拔、GPS轨迹）将直接流入Intervals.icu，再被Section 11脚本同步。
• 检查方法： 在Intervals.icu网页上打开一个有问题的活动，如果详情丰富，但API同步后缺失，就是此问题。

问题：AI教练报告的数据看起来“过时”了。

• 根源1： GitHub Actions同步任务失败。去你数据仓库的“Actions”标签页，检查最近的同步工作流是否成功运行（绿色对勾）。失败常见原因：API密钥失效、Intervals.icu服务暂时不可用、GitHub Actions额度用尽（免费用户有一定限制）。
• 根源2： AI平台缓存。许多AI平台会缓存它们读取的文件内容一段时间，以提高响应速度并减少API调用。
• 解决方案：
  1. 手动触发一次同步（在仓库的Actions页面点击“Run workflow”）。
  2. 在AI对话中，明确要求AI“忽略缓存，重新从源地址获取最新的JSON数据”。你可以在提示词中加入强制刷新的指令，例如要求AI在每次分析前在URL后附加一个时间戳参数 ?t= 。
  3. 最彻底的方法：开启一个新的聊天会话。

问题：FTP变化后，AI的分析似乎还沿用旧值。

• 根源： DOSSIER.md 中的FTP是静态的，而 latest.json 中的CTL/ATL等是基于一个动态的“表现指数”计算的，这个指数可能未及时更新。
• 解决方案： Section 11的同步脚本维护了一个 ftp_history.json 文件来跟踪FTP变化。你需要：
  1. 在Intervals.icu中更新你的FTP设置。
  2. 确保同步脚本正常运行，它会检测到FTP变化并记录在历史中。
  3. 同时， 务必手动更新 DOSSIER.md 文件中的FTP数值和日期 ，并重新上传或让AI重新读取。AI在计算区间百分比时，会优先使用Dossier中提供的最新、最权威的数值。

5.2 提示词工程：让你的AI教练更“听话”

项目提供的 SETUP_ASSISTANT.md 是一个强大的基础提示词，但你可以根据个人偏好进行微调，让AI的回复风格更贴合你的需求。

• 调整回复格式与深度：

  • 偏好简洁： 在指令中加入“请用最简练的要点形式回复，省略科学框架引用，直接给出结论和建议。”
  • 偏好教学： 加入“在给出建议时，请简要解释其背后的科学原理（例如，为什么此时ACWR比TSB更重要），以帮助我学习。”
  • 控制长度： 明确要求“每日报告请控制在200字以内；周度分析请提供详细数据，但不超过500字。”

• 注入个人偏好与禁忌：

  • 在 DOSSIER.md 中，除了客观数据，可以增加一个“偏好与限制”章节。例如：“我每周四晚上有固定社交活动，无法训练。”“我非常讨厌跑步机，请优先安排户外跑课表。”“我对高强度间歇后的DOMS（延迟性肌肉酸痛）反应强烈，请确保间歇课后第二天安排彻底休息或非常轻松的主动恢复。”
  • 在AI指令中引用这个章节：“在制定计划时，请严格遵守Dossier中‘偏好与限制’部分的内容。”

• 处理AI的“幻觉”或固执：

  • 即使有协议约束，AI有时仍会固执于某个错误理解或开始“编造”数据。此时， 最强有力的纠正方式是引用协议本身 。例如，如果AI坚持用某个错误公式计算TSS，你可以说：“请重新查阅Section 11 A第3.2条关于‘禁止虚拟计算’的规则，并使用 latest.json 中 tss 字段提供的值。”
  • 如果问题持续，重启一个新会话通常比在旧会话中反复纠错更有效。

5.3 超越基础：探索智能体与自动化

对于技术爱好者，Section 11与具备代码执行能力的“智能体”结合，能开启真正的自动化。

• 自动计划推送： 使用 examples/agentic/push.py 脚本，你可以让AI教练在生成下周训练计划后， 自动 将其写入你的Intervals.icu日历。你只需要审核一下计划，然后说“批准并推送”，剩下的就交给AI了。
• 条件触发与警报： 你可以编写一个简单的监控脚本，定期（如每天早晨）检查 latest.json 中的关键指标（如HRV暴跌、ACWR超标），如果触及阈值，则自动调用AI生成一份紧急报告，并通过邮件或消息推送给你。例如：“警报：您今晨HRV较基线下降25%，建议立即将今日训练调整为恢复日。”
• 多模态数据融合： 未来的扩展可以将睡眠手环（如Oura）、饮食记录（如MyFitnessPal）、甚至每日压力自评的数据也通过类似方式同步进来，让AI教练获得更全面的“健康仪表盘”，做出更精准的判断。

5.4 心理建设：AI是副驾，你才是司机

最后，也是最重要的一点： Section 11 AI教练是一个强大的决策支持系统，但它不能替代你对自己身体的感知和常识。

• 它不懂“情境”： AI不知道你今天和老板大吵一架，情绪极度低落；不知道你昨晚照顾生病的孩子只睡了3小时；不知道你隐隐觉得膝盖有些不适。这些“软信息”至关重要。你必须在与AI的对话中主动提供这些上下文。
• 科学模型有局限： 所有集成的科学模型都是基于群体研究的统计规律，是对复杂生理过程的简化。个体差异永远存在。如果AI建议你按计划进行高强度训练，但你感觉极度疲惫甚至疼痛， 永远优先相信自己的身体信号 。你可以选择跳过或修改训练，并将此作为反馈告诉AI：“我今天感觉异常疲劳，决定将间歇课改为恢复骑。请记录此偏差，并在未来评估其影响。”
• 它不诊断伤病： Section 11协议明确排除医疗建议。持续的疼痛、异常的生理指标（如心率持续极高或极低），必须咨询医生或物理治疗师。

最佳的协作模式是“人机回环”： AI处理海量数据，提供基于证据的客观分析和选项；你结合主观感受、生活情境和最终直觉，做出执行决策。然后将执行结果反馈给系统，让AI在下一次分析时纳入考量。如此循环，你不仅在训练，也在训练一个越来越懂你的个性化AI教练。

这个协议的真正终点，不是创造一个全知全能的机器教练，而是通过一个开放、透明、可审计的框架，极大地增强运动员的自我认知能力和训练决策的科学性。它把教练知识体系 democratize（民主化），让你我能以极低的成本，获得接近职业运动员的数据支持水平。剩下的，就是穿上鞋、踏上踏板，去享受更聪明、更安全的训练旅程了。