Lzheng Fitness Plan

Lzheng 个性化健身计划

把计划视为基于某一时间点用户状态的可验证训练假设。先建档、再分层、再选动作和训练变量，最后从同一份结构化数据生成文字与 HTML。

读取模式

从零建档、结构性重做，或目标、频率、训练条件、安全限制、动作选择、训练量发生变化时，依次读取：

1. 知识路由：确定本次应读取的内置知识与联网来源。
2. 问诊与状态快照：收集必要信息并生成不可覆盖的时间快照。
3. 训练者分层：判断整体 P0—L3 和单动作等级。
4. 动作适配：选择固定器械、自由重量、自重或绳索动作。
5. 计划设计：确定目标、频率、分化、训练量、渐进和短期降级。
6. 计划数据协议：建立唯一 plan_contract。
7. 计划页面视觉契约：固定页面结构、导航、模板资产和设计边界。
8. HTML 输出规范：生成和审计最终页面。
9. 证据基础：核验安全、训练频率、器械选择和公共活动量的来源边界。
10. 训练专家选择协议：仅在专家变量会改变计划时选择最少必要来源模块。

不要凭模型记忆代替 Skill 内置资料。只读取知识路由为当前问题指定的参考文件；涉及容易变化的安全或公共指南时再联网核验官方来源。

低 token 局部修订

如果只修改已确认的日期排程、计划版本、训练周次、工作重量、次数/RPE 或由正式复盘明确给出的下一次处方，并且目标、频率、器械、健康限制、动作结构和周训练量均不变，则使用局部修订模式：

1. 先运行 lzheng-training-system inspect --root "<系统根目录或训练项目根目录>"，不得读取整份 健身工作台.html。
2. 只读取摘要中 authoritative_sources 指向的当前计划 JSON、当前执行基准和本次复盘/交接；不扫描历史计划、全部复盘、完整专家库或工作台模板。
3. 必读 references/plan-contract.md；只有被修改变量涉及对应规则时，才读取动作、计划设计或证据参考。
4. 在同一份当前计划结构上产生新版本 JSON，并重新运行完整 JSON 校验、HTML 渲染和 HTML 审计；校验完整不等于重新读取全部资料。
5. 独立计划 HTML 只能写入计划目录，绝不得覆盖 健身工作台.html。创建 LZHENG_HANDOFF 后由 process-handoffs 刷新工作台数据块。

无法确认是否属于局部修订时，按结构性重做处理。出现疼痛、疾病、停训或训练条件变化时不得使用低 token 模式绕过安全分流。

专家知识路由

专家库是内部来源层，不是另一个处方系统。目标含营养、肌肥大、计划结构、专项力量、反复中断或已获专业允许活动后的返场变量时，先按专家选择协议读取 ../lzheng-training-expert-library/references/expert-registry.json，再进入对应模块。默认 1 位；只有独立变量或真实冲突才增加。专家只提供来源限定判断，计划事实、最终处方、版本和写入仍由本 Skill 所有。实际采用时按专家库输出协议展示；未采用时不增加专家区块。

执行流程

1. 确认任务边界

• 用户只问原则或解释时，回答问题，不自动创建状态档案或计划文件。
• 用户要求制定、重做或调整完整计划时，执行完整流程。
• 用户明确要求单个力量动作的 8—12 周周期，或明确确认专项周期建议时，才调用 lzheng-strength-cycle-planner。
• 不因用户只提到“力量提升”自动调用周期 Skill；没有确认时使用普通渐进。
• 用户停训达到 7 天、连续漏练 3 次、疾病后恢复、训练条件明显改变或 4 周内反复中断时，路由到 lzheng-training-return。
• 漏练 1—2 次、单日状态差或时间不足仍由本 Skill 处理。

2. 读取当前事实与知识

先建立“用户本次确认 / 当前动态记录 / 本地长期知识 / 联网更新 / 未知”事实表。

• 用户本次明确确认的当前事实优先。
• 用户明确授权并且当前环境能够访问训练记录服务时，可查询最近 4—8 周训练、当前计划、恢复和体重；否则只使用用户本次提供的资料并明确限制。
• 读取用户提供或可核验的当前有效计划和执行基准，不把历史计划、旧 PR 或其他用户数据当作当前事实。
• 按知识路由读取 Skill 内置参考；安全和最新标准需要联网核验官方来源。
• 把每条实际使用的来源写入 knowledge_sources，不能只写“参考相关资料”。

3. 完成最少必要问诊和安全分流

使用两轮问诊：首轮收集目标、困惑、近期训练、动作经验、场地时间、恢复和健康限制；第二轮只补会改变计划结构的缺失信息。用户已经提供的内容不要重复询问。减脂还要确认近期体重记录、日常步数或活动基线、可接受的有氧方式和频率；增肌还要确认重点肌群与能否持续记录每个重点动作的重量、次数和余力。没有这些事实时把相应追踪项标为待建立基线，不编造热量、步数或体重目标。

输出三种准备状态：

• full：信息足够，可生成完整计划；
• conservative：非关键数据缺失，使用 RPE/RIR 和保守起点并标明假设；
• blocked：安全、目标、时间、场地或关键动作信息不足，暂不生成精确处方。

锐痛、麻木、放射痛、晕厥、胸部异常不适或持续加重症状不进入普通训练处方；停止高强度建议并提示寻求合适的线下专业评估。

4. 保存时间快照

完整问诊结束后，先按参考规范生成状态快照，再生成计划。

• 用户指定输出目录时优先使用该目录。
• 未指定时，先读取已初始化系统的 系统/lzheng-system.json，保存到 output_locations.profiles；只有尚未建立系统配置时，才使用 LZHENG_FITNESS_HOME/profiles/ 或当前工作目录的 lzheng-fitness-output/profiles/。
• 使用 YYYY-MM-DD-HHmm-lzheng-training-profile.md；客户模式只使用代号和脱敏资料。
• 新状态创建新文件，不覆盖历史；计划引用准确的 snapshot_id 和路径。
• 不在快照记录完整病历、账号或无关隐私，只记录会影响训练决策的限制和来源。

5. 分层并选择动作

先判断整体 P0—L3，再逐个判断计划中的主要动作。允许“整体 L2、卧推 L2、深蹲 L1、硬拉 P0”。

动作选择必须经过：器械可用性与安全排除 → 目标和动作模式 → 当前可控难度 → 刺激/疲劳/学习成本 → 延续熟悉动作 → 替代与进阶标准。

• P0 优先高稳定、易学习、容易调负荷的器械或支撑动作，但不禁止自由重量。
• 高级训练者仍可使用固定器械；训练等级不等于器械等级。
• 传统硬拉不是 P0、增肌、减脂或健康计划的必选动作。只有无痛髋铰链、基本躯干固定、合适器械和明确目标都成立时才安排学习路径。

6. 生成计划主体

写清：阶段目标、周期长度、每周频率、训练分化、休息日、每个动作的顺序、组次、RPE/RIR、休息、目的、替代动作、渐进方式和复盘节点。每个动作必须写固定动作模式，并按固定健美肌群标注 1.0 直接贡献或 0.5 间接贡献；周组数由渲染器按周频次自动汇总，禁止手填一份可能不一致的总表。

用户是 P0、L1 或明确不熟悉 RPE/RIR 时，在对话中第一次使用前主动解释：RPE 7 约等于还能做 3 次，RPE 8 约等于 2 次，RPE 9 约等于 1 次。教学属于 AI 建档和带练职责，不在计划 HTML 中插入术语课程；计划页优先显示“约留几次余力”的直白表达。

每个动作都必须给出明确的负荷状态。已有记录时写入工作重量、来源和下一次加重/保持/回退规则；没有记录时写入现场校准步骤和判断规则。禁止只写“按 RPE 自行选重量”。

同时生成：

• 标准版；
• 30 分钟版；
• 20 分钟版；
• 10 分钟最低版；
• 状态差版；
• 漏练 1—2 次接回规则。

在 plan_meta.goal_mode 明确写入 strength、hypertrophy、fat_loss 或 general_fitness，并在 tracking_targets 写入对应追踪项：增肌包含训练完成、重点肌群计划组数与双重渐进记录；减脂包含训练完成、体重趋势、日均步数与有氧时长；力量包含训练完成、关键动作实际表现与周期判定；综合健身至少包含训练完成。每一项要写明数据来源、状态和下一步记录动作；未知基线只能写 needs_baseline，不能省略目标追踪。

短版必须从原计划降级，优先保留当天主线；不得补课、加倍训练、惩罚性有氧或随机换成无关动作。

7. 建立并验证 plan_contract

先写 JSON，再生成用户可见计划。运行：

python scripts/validate_plan.py <plan.json>
python scripts/render_fitness_plan.py <plan.json> <output.html>
python scripts/audit_html_plan.py <output.html> --plan <plan.json>

任何错误都必须修正后再交付。警告需要在计划的假设或待确认项中处理。

8. 交付 HTML

除非用户明确只要口头分析或拒绝文件，制定/重做完整计划时同时交付独立 HTML。必须由 assets/fitness-plan-template.html 生成；页面只展示阶段目标、周结构、并排训练日简表、统一进阶与周期复盘表，以及可切换的动作模式/健美肌群覆盖。周结构卡补充当天训练重点；覆盖区只显示合计大于 0 的实际项目。复盘节点由 AI 主动向用户确认实际反馈，周期末确认后生成下一阶段计划。完整重量校准、动作理由和短版收进对应训练日的折叠说明；不展示“下一次训练”、完成状态、实时记录、安全筛查、追踪卡、漏练规则、AI 内部判断、来源或假设。

用户指定输出目录时优先使用；否则先读取已初始化系统的 系统/lzheng-system.json，把正式 JSON 与 HTML 写入 output_locations.plans，并通过 LZHENG_HANDOFF → process-handoffs 接入唯一当前计划；只有尚未建立系统配置时，才写入 LZHENG_FITNESS_HOME/plans/ 或当前工作目录的 lzheng-fitness-output/plans/。不得覆盖旧文件，实质修订使用 -v02、-v03；任何计划渲染器都不得写入或替换根目录 健身工作台.html。

与其他 Skill 的边界

• lzheng-strength-cycle-planner：只在用户主动询问或确认后，为一个明确力量主项生成 8—12 周周期；返回结果后重新审核整周疲劳。
• lzheng-strength-training-review：处理周期或无周期训练复盘、滚动渐进、基准训练、下一次处方和待确认结构调整。
• lzheng-training-return：处理 7 天以上、连续多次、疾病后或条件改变后的中断恢复。

质量检查

• 状态快照先于计划生成，计划引用准确快照；
• 整体与单动作分层均有依据，不以训练年限或绝对重量机械分级；
• 动作与器械来自用户条件，不幻想设备；
• 固定器械和自由重量按适配选择，不暗含高低等级；
• 所有重量可追溯到记录、RPE/RIR 或明确估算；
• 新手在首次接触 RPE/RIR 时已由 AI 用余力次数解释，HTML 不承担术语教学；
• 声明的每周训练频率、周计划中的训练次数和每个训练日的排程完全一致；
• 动作模式、肌群贡献系数和周频次可计算，页面覆盖汇总不靠 AI 手填；
• 每个训练日都有可执行短版；
• 未获确认时没有调用单项力量周期；
• 文字、JSON 与 HTML 的动作、组次、RPE、版本和来源一致；
• HTML 无外部运行依赖，手机与打印可读；
• 每条关键判断能追溯到用户事实、本地知识或当前官方来源。