Lzheng 个性化健身计划
把计划视为基于某一时间点用户状态的可验证训练假设。先建档、再分层、再选动作和训练变量,最后从同一份结构化数据生成文字与 HTML。
读取模式
从零建档、结构性重做,或目标、频率、训练条件、安全限制、动作选择、训练量发生变化时,依次读取:
- 知识路由:确定本次应读取的内置知识与联网来源。
- 问诊与状态快照:收集必要信息并生成不可覆盖的时间快照。
- 训练者分层:判断整体 P0—L3 和单动作等级。
- 动作适配:选择固定器械、自由重量、自重或绳索动作。
- 计划设计:确定目标、频率、分化、训练量、渐进和短期降级。
- 计划数据协议:建立唯一
plan_contract。 - 计划页面视觉契约:固定页面结构、导航、模板资产和设计边界。
- HTML 输出规范:生成和审计最终页面。
- 证据基础:核验安全、训练频率、器械选择和公共活动量的来源边界。
- 训练专家选择协议:仅在专家变量会改变计划时选择最少必要来源模块。
不要凭模型记忆代替 Skill 内置资料。只读取知识路由为当前问题指定的参考文件;涉及容易变化的安全或公共指南时再联网核验官方来源。
低 token 局部修订
如果只修改已确认的日期排程、计划版本、训练周次、工作重量、次数/RPE 或由正式复盘明确给出的下一次处方,并且目标、频率、器械、健康限制、动作结构和周训练量均不变,则使用局部修订模式:
- 先运行
lzheng-training-system inspect --root "<系统根目录或训练项目根目录>",不得读取整份健身工作台.html。 - 只读取摘要中
authoritative_sources指向的当前计划 JSON、当前执行基准和本次复盘/交接;不扫描历史计划、全部复盘、完整专家库或工作台模板。 - 必读
references/plan-contract.md;只有被修改变量涉及对应规则时,才读取动作、计划设计或证据参考。 - 在同一份当前计划结构上产生新版本 JSON,并重新运行完整 JSON 校验、HTML 渲染和 HTML 审计;校验完整不等于重新读取全部资料。
- 独立计划 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 无外部运行依赖,手机与打印可读;
- 每条关键判断能追溯到用户事实、本地知识或当前官方来源。