---
name: lzheng-strength-cycle-planner
description: 为深蹲、卧推、硬拉、负重引体、推举等力量主项制定、解释、调整或复盘完整的 8—12 周周期，并交付含主项渐进曲线的可本地打开训练计划 HTML。用于用户要求规划组数、次数、重量、RPE/RIR、顶组、回退组、减量、测试、渐进规则或未完成分支，或要求把训练计划做成网页、总览页、可视化计划时。
---

# Lzheng—力量训练周期规划

为一个明确的力量动作生成可执行、可反馈、可调整的 8—12 周周期。把计划视为待验证的训练假设，不把固定重量表当作必须完成的命令。

## 必读参考

生成或调整计划前读取：

- [周期设计规则](references/cycle-design-rules.md)：底层模型、阶段选择、动作差异和调整规则。
- [问诊与输出规范](references/output-spec.md)：最少输入、完整表格和未完成分支格式。
- [训练计划网页规范](references/training-plan-website-spec.md)：数据核验、HTML 交付、视觉和响应式要求。
- [周期 HTML 与曲线契约](references/cycle-html-contract.md)：固定页面框架、图表口径、JSON 数据结构和验收要求。
- [证据基础](references/evidence-base.md)：说明周期适用边界、来源和最新指南核验规则。
- [训练专家选择协议](../lzheng-training-expert-library/references/expert-selection-contract.md)：在计划结构、力量瓶颈或训练阶段变量会改变周期时读取最少必要模块。

专家库只提供约束与判断：一般结构优先 Eric Helms，力量停滞、专项性、变量实验或峰值使用 Greg Nuckols + Eric Helms，目标与现实脱节或是否回到基础时才使用 Dan John。当前表现、周期重量、最终处方和写入权始终归本 Skill；没有真实交叉变量时不制造多人讨论。

## 任务边界

- 一次优先规划一个主项；需要多个主项时，先分别建立动作周期，再检查它们在同一周中的疲劳冲突。
- 生成动作周期，不擅自重写用户整套训练计划；必须读取或询问会影响该动作的现有训练安排。
- 当前训练记录、体重和完成数据属于动态信息。用户授权且当前环境能访问训练记录服务时优先查询最近记录和当前周期；否则使用用户本次提供的数据。旧计划、历史 PR、旧身体数据不能冒充当前事实。
- 只在用户明确要求时写回外部记录服务；但制定或重做训练计划时，默认交付本地 HTML 页面，除非用户明确说不要文件或网页。
- 不提供医学诊断。出现锐痛、麻木、放射痛或持续加重的关节疼痛时，停止高强度推进并建议线下专业评估。

## 执行流程

### 1. 核验基本信息和训练事实

先建立“已核验 / 用户直接提供 / 缺失或冲突”的事实表。用户已给出的内容不要重复询问；缺少会改变计划结构的信息时，用一轮紧凑问题补齐，不要边猜边生成精确重量表。

至少确认：

- 使用者、当前日期和计划适用周期；不要复用其他人的数据。
- 目标动作、动作标准和目标成绩；
- 近期真实成绩：重量、组数、次数、RPE/RIR和动作质量；
- 当前训练频率、相关训练日和辅助/变式动作；
- 训练年限及该动作的熟练度；
- 可用器械、最小加重单位和单次时长；
- 近期完成度、恢复、疼痛或技术限制；
- 是否有测试日期，以及希望采用 8、10 或 12 周。

负重自重动作还要确认体重，并使用“体重 + 附加重量”判断总系统负荷。

出现冲突时，优先级为：用户当次明确确认的近期完整记录 > 已授权且可核验的当前训练记录 > 用户明确标注为历史的成绩 > 估算。记录日期、动作名称和重量单位；器械重量、总系统负荷和附加重量不得混写。

### 2. 判断是否适合多周周期

- 新动作、技术不稳定或仍能逐次线性加重：采用动作学习或简单线性周期，但仍可按用户要求整理为 8 周表格；不要伪装成复杂高级周期。
- 单次加重已经不稳定、训练记录可靠：使用多周周期。
- 主项暴露频率很低：按“有效暴露次数”规划，不按自然周强行加重。

### 3. 确定周期长度和阶段

- 8 周：目标单一、动作频率较高、只需要一次积累与一次转化。
- 10 周：一般力量发展，兼顾积累、强度与验证。
- 12 周：训练频率低、需要更慢推进，或需要完整积累、强度、实现与减量。

根据目标分配积累期、强度期、实现期和减量/验证期。阶段长度不是固定生理定律；以有效暴露次数、表现趋势和恢复反馈为准。

### 4. 安排每次训练的职责

明确每次暴露只承担一个主要任务：强度、训练量、技术、变式或恢复。

- 顶组用于校准当天状态、练习较高负荷和估算当前能力。
- 回退组是顶组后的计划内正式训练，用较低重量积累主要训练量。
- 未完成分支是计划没有按目标完成时替代原安排的条件分支，不是额外追加的训练组。

不要混淆“回退组”和“未完成/退行分支”。

### 5. 生成重量和组次

- 数据充分时给出可落地的公斤数，同时保留目标 RPE/RIR和调整范围。
- 数据不足时先询问；仍无法确认时只给百分比、RPE和选重方法，明确标记假设，不编造精确重量。
- 主要正式组通常不超过 RPE 9；大部分训练控制在 RPE 7—8.5。
- 对每个包含 2 组及以上正式工作组的动作，直接在处方单元格写出 **`首组 RPE→末组 RPE`**，例如 `75kg 4×6 @6→7`。不要只写 `75kg 4×6 @7` 后再依赖全局说明解释；固定重量与次数下，RPE 随组数上升是正常现象。
- 顶组若只有 1 组，可保留单一 RPE 或 RPE 区间；顶组后的多组回退组、容量组和辅助动作仍必须使用箭头格式。历史训练事实要标明“末组 RPE”或逐组实际 RPE，不能伪装成未来处方。
- 不要求重量、次数和组数同时增加。
- 把测试成绩和训练成绩分开；测试不是常规训练周的默认任务。

### 6. 写清调整规则

为顶组和回退组分别说明：

- 达到上限且 RPE 不超标时如何推进；
- 完成目标但过重时为什么保持；
- 少一次、动作变形或热身异常时如何处理；
- 连续两次表现下滑时何时减少训练量或提前减量；
- 中断后如何接回。

只有确实存在有价值的条件分支时才输出“未完成/退行方案”。固定减量日、轻技术日或无需分支的训练不要硬塞退行组。

### 7. 完整交付

用户要求制定周期时，最终输出必须包含：

1. 当前判断与周期目标；
2. 已知输入、关键假设和需要持续记录的数据；
3. 为什么这样设计：动作特性、频率、训练水平、目标、恢复和最小加重单位；
4. 8—12 周完整周期表，按每次实际训练暴露展开；
5. 热身、组间休息和动作质量标准；
6. 顶组与回退组的渐进规则；
7. 仅在需要时给出的未完成/退行分支；
8. 减量、测试和下一周期的判定方式。

### 8. 生成训练计划网页

在文字交付完成后，按 `references/training-plan-website-spec.md` 创建可直接双击打开的 HTML 页面。把网页视为计划的可视化版本，而非另一套独立数据：网页中的基本信息、动作、组次、重量、RPE、周次和调整规则必须与文字计划逐项一致。

先按 `references/cycle-html-contract.md` 把当次最终计划整理为 JSON 数据，再用 `scripts/render_strength_cycle_html.py` 和唯一模板 `assets/strength-cycle-template.html` 生成 HTML。网页结构、导航、配色、图表位置、坐标轴、阶段带和响应式规则来自模板；动作、阶段、重量、容量、周数、测试目标和 SVG 路径必须由当次数据生成。不得复制其他计划的图表数值、手改曲线坐标或手写另一套页面。

- 每个主项必须在 `<h3>` 与完整周期表之间拥有一张强度/容量图；仅有一个主项时只生成一张，多个主项分别生成。
- 容量优先按职责日正式组的 `重量 × 组数 × 次数` 计算；不同动作的容量口径、低频暴露和自重/归零周必须在图表脚注写清。
- 图表曲线必须使用生成器的 Fritsch–Carlson 单调三次插值；峰谷只能落在真实数据点，低频动作不得补造空周数据。
- 生成器默认拒绝覆盖已有文件。实质修订先创建新版本，再把 JSON 和 HTML 一同复核；只有用户明确授权时才可使用 `--force`。

- 用户指定输出位置时使用该位置；否则先读取已初始化系统的 `系统/lzheng-system.json`，把专项周期 JSON 与 HTML 保存到 `output_locations.cycles`；只有尚未建立系统配置时，才保存到 `LZHENG_FITNESS_HOME/plans/` 或当前工作目录的 `lzheng-fitness-output/plans/`。客户交付或产品样例只使用脱敏资料。
- 新计划的文件名必须为 `YYYY年MM月DD日-训练对象-周期目标训练计划.html`。单项示例：`2026年07月28日-负重引体-3RM提升训练计划.html`；整套计划示例：`2026年07月29日-四日制全身-力量提升训练计划.html`。日期按 Asia/Shanghai 的首次制定日书写，月、日必须补零。
- 对同一计划的实质修改，保留首次制定日期并追加 `-v02`、`-v03` 等版本号；新周期使用新的制定日期。不得使用“最新版”“最终版”等不稳定名称，也不得覆盖已有文件。
- 使用内嵌 CSS 的独立 HTML，不依赖网络、构建服务或登录。页面必须在桌面和手机上可读。
- 默认复用本 Skill 的 `assets/header-lineart.png`，保持白底、左侧标题、右侧线稿的同一视觉。交付到任何单文件上传场景时，必须用 `scripts/inline_html_image.py` 把线稿嵌入 HTML；禁止交付依赖相对本地图片路径的网页。仅当用户明确不要人物图或输出场景不适合时，才改为纯文字页头。
- 使用 `render_strength_cycle_html.py` 时，页头线稿会随生成过程直接内嵌；已有网页需要补嵌线稿时，继续使用 `inline_html_image.py`。
- 用户只要口头问答、明确拒绝文件，或只要求复盘时，不创建网页；其余“制定 / 修改 / 重做训练计划”默认创建。
- 修订既有计划时，创建新版本后对新 HTML、文字执行基准和汇总表做全文 RPE 审计：除单组顶组、测试尝试和明确标注的历史实际记录外，不得遗留 `多组 × 次数 @单一 RPE` 或静态 RPE 区间的旧式处方。

不要只给原则、示意周或前三周样例后声称已经完成周期。

## 质量检查

交付前确认：

- 表格覆盖完整 8—12 周，每次主项暴露都有明确职责；
- 频率不同的动作没有使用完全相同的周进度；
- 所有重量都能追溯到用户成绩、训练最大值、百分比或 RPE规则；
- 计划说明了为什么次数会随强度上升而下降；
- 回退组不会在顶组失败后被机械照做；
- 每个多组工作处方在文字表、HTML 表和执行基准中都直接采用 `首组 RPE→末组 RPE`；没有仅靠页面说明补救的旧式静态 RPE 写法。
- 退行分支替代原计划而不是增加惩罚性训练量；
- 减量是真正降低疲劳，不是换一套同样累的训练；
- 没有把一次状态差误判成平台期；
- 没有通过频繁力竭证明进步。
- 网页中的基准信息、计划表和文字交付一致；不存在未标注的估算、过期信息或不同使用者的数据。
- HTML 位于用户指定目录或可移植默认输出目录，文件名符合日期—训练对象—周期目标规则，引用的 Skill 内资产存在；窄屏时长表可横向滚动或转为单列，不出现逐字挤压换行。
- 每个主项图表只有一份，紧贴对应标题和表格之间；图表数据、容量口径、阶段范围与周期表一致，没有旧版 `<polyline>`、复制来的 SVG 坐标或外链资源。