# Fitness Planner Pro

> 用于生成中文健身攻略、训练计划、饮食与恢复建议、动作教学、训练日志和复盘模板。当用户需要减脂、增肌、塑形、力量提升、跑步心肺、居家或健身房训练、食堂外卖饮食、动作要点、训练记录、执行困难处理、坚持支持或安全边界建议时使用。不用于医疗诊断或替代医生、康复师的个体化治疗。

- Skill: `ahang1598/fitness-planner-pro` (Agent Skill, multi-file: 13 files)
- Install (CLI): `npx skillmds@latest add ahang1598/fitness-planner-pro`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ahang1598/fitness-planner-pro/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: ahang1598 (https://skillmd.com/u/ahang1598)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/ahang1598/fitness-planner-pro

---


# Fitness Planner Pro

## 概述

这是**攻略体裁**。主线永远是"用户能照着做的健身攻略/训练计划/动作安排"——动作名+组数次数+怎么做、本周怎么排、怎么吃、怎么恢复、怎么判断有效。一切其他内容（强度怎么表达、图片怎么插、疼痛怎么标、飞书怎么建）都是**服务这条主线的执行细节，不能喧宾夺主**。如果某个细节规则和"把攻略写清楚"冲突，以攻略清楚为先。

把用户模糊或明确的健身需求，转成可执行、可调整、可复盘的中文训练与生活方式方案，并**默认直接创建飞书在线文档（Docx）**。优先解决真实执行问题：练什么、怎么练、练多久、如何进阶、怎么吃、怎么恢复、哪些情况必须停止或求助专业人士。

## 交付契约（唯一出处，详细规则见 `references/output-contract.md`）

- 最终交付优先是**真实创建的飞书在线文档**，最终回复只给标题 + URL + 1–3 条内容亮点，**不粘贴正文**。
- 默认用 XML 富文本创建；用户明确要 Markdown 时才用 `--doc-format markdown`。
- 即使用户只问“要怎么做/怎么练”，也按飞书文档交付，不要降级成聊天建议或可复制 Markdown。
- 信息不全也先创建文档，不要只反问。缺失信息只做内部判断：能合理推断的直接写成“适用边界/调整开关”（例如强度、替代动作、疼痛停止线），不能把问题清单塞进文档正文或文末。
- **正文只写健身内容。** 工具版本、CLI 子命令、认证、权限、scope、token、fallback、替代方案、图片搜索失败、未找到可下载图片、`no_reliable_image`、`image-plan.tsv` 等执行状态**只能留在内部记录**，绝不写进飞书正文，也不要写进成功交付的最终回复。
- **正文禁止出现 HTML 表单或裸代码。** 复选清单只能用飞书 XML `<checkbox done="false">事项</checkbox>`；Markdown 降级稿才用 `- [ ] 事项`。绝对不要写 `<input type="checkbox" />`、`<button>`、`<select>`、`<textarea>`、`<label>`、`<form>`，也不要把这些标签转义成 `&lt;input...&gt;` 后放进正文。
- **XML 只用白名单组件。** 允许：`title/h1/h2/h3/p/b/i/br/callout/grid/column/table/thead/tbody/tr/th/td/checkbox/bookmark/blockquote/hr/img`。不要自造 `<card>`、`<action-card>`、`<workout-card>`、`<section>`、`<timeline>`、`<badge>`、`<tag>`、`<panel>`、`<tabs>` 等标签；飞书可能原样显示。所谓“动作卡/饮食卡/复盘卡”必须用 `callout + grid + table` 组合实现。
- 只有飞书工具不可用/认证失败/权限不足/命令失败时才退回聊天兜底，必须说明“本次未能创建飞书在线文档”的原因 + 可重试片段，不要假装已创建。

## 不可跳过的 8 步流程

弱模型按编号执行，**不要跳步**。第 6 步是硬门控。

**1. 提取约束** — 从用户输入提取：目标 / 基础 / 身体信息（年龄性别身高体重体脂久坐）/ 时间资源（每周几练、每次时长、周期）/ 场地器械 / 限制（伤病疼痛孕产期慢病用药睡眠饮食偏好预算）/ 偏好。至少填出 4 项；填不全的能合理推断就继续，推断自然融入方案，**不要在开头列推断前提**。出现红旗（胸痛、晕厥、急性损伤、术后、孕产期、慢病、进食障碍、未成年人极端减重）→ 走安全分流型，先读 `references/safety-and-scope.md`。

**2. 场景路由** — 用下方路由表选 1 条主线，决定读哪 1–2 个 reference（**不要默认读全部**）。

**3. 做场景指纹 + 定标题** — 内部定：真实目标 / 专属词 / 第一屏先答什么 / 主角配角模块 / 文档形态。然后用标题公式生成 `<title>`：`{专属词}+{形态词}`，形态词从{路线、手册、系统、训练卡、面板、清单、吃法、避痛方案、复盘表}选 1。**禁止默认 `XX攻略/XX计划/XX方案`。** 公式和示例见 `output-contract.md §2`。

**4. 生成 XML 内容 + 旁路图片计划** — 先过“清晰充盈攻略骨架”门控，再做视觉组件。用 `output-contract.md §4` 的 XML 骨架填内容，替换 `{{占位符}}`。**图片不在 XML 里内联，也不要在 XML 正文写任何 `<!-- 插图位置 -->`、`<!-- media: -->`、`anchor=`、`caption=` 这类内部字段**；飞书可能把 XML 注释当正文显示。XML 正文只写正常攻略文字，并保留一句唯一锚点句。另建 `outputs/{场景}/image-plan.tsv` 记录每张图的文件、锚点、图注、用途和来源；如果搜不到可靠图片，也在这个文件记录 `status=no_reliable_image` 和尝试过的检索词。内容用知识库校准（读 `references/fitness-knowledge-base.md`）。核心动作写完整动作卡；核心动作优先找真实图解，但**找不到可靠图片就不插图，不生图**，用真实视频/图解 bookmark + 动作卡补足。

生成正文时先做组件白名单检查：所有富文本效果只能落到 `callout/grid/table/checkbox/bookmark/blockquote/hr` 上。不要为了“卡片感”写 `<card title="...">...</card>`；应写成 `<callout>` 或 `<grid><column><callout>...</callout></column></grid>`。

**5. 下载图片到本地 + 写 .xml + 写 image-plan.tsv** — 搜图拿直链后，`curl -sL -A "Mozilla/5.0..."` 下到 `outputs/{场景}/visuals/NN-<名>.png`，`file` 验证是 "PNG/JPEG image data"（HTML/空 → 换源）。XML 写到 `outputs/{场景}/{场景}.xml`，用 `--content @file.xml`。图片计划写到 `outputs/{场景}/image-plan.tsv`，表头固定为 `file<TAB>anchor<TAB>caption<TAB>purpose<TAB>source_type<TAB>source<TAB>status<TAB>reason`。有可靠图片时填 `status=ready`；搜不到可靠图片时不填 file/anchor/caption，填 `status=no_reliable_image` 和 `reason`，并用 bookmark/动作卡补足。

**6. 跑质量脚本（硬门控）** —
```bash
python3 scripts/check_fitness_quality.py --stage draft --image-plan outputs/{场景}/image-plan.tsv outputs/{场景}/{场景}.xml
```
必须输出 **PASSED**。draft 阶段会检查：XML 正文没有内部插图注释、没有生图痕迹、`image-plan.tsv` 完整；如果计划里有 `status=ready` 图片，会校验本地图片文件存在且是真 PNG/JPEG/WebP/GIF；如果全都 `status=no_reliable_image`，则要求正文有足够真实视频/图解 bookmark 和动作卡。若 FAILED：按每条报错逐条修，重跑，直到 PASSED。**不要跳过这一步直接创建文档。**

**7. 创建飞书文档 + 插图** — 先建文档（XML 里只有正常正文，不带图也不带内部图片字段）：
```bash
lark-cli docs +create --api-version v2 --doc-format xml --content @outputs/{场景}/{场景}.xml
```
拿到真实 URL。然后**只对 `image-plan.tsv` 里 `status=ready` 且有 file 的行跑 `+media-insert`**（图真正进飞书、不 403、不堆文末）：
```bash
lark-cli docs +media-insert --as user --doc "<URL>" --file outputs/{场景}/visuals/NN-<名>.png --type image --align center --selection-with-ellipsis "<锚点正文一句>" --caption "图：<对象>"
```
**`--selection-with-ellipsis` 必填**——把图插到锚点附近、跟着内容走；不带则追加文末（这就是"图堆后面"的真因）。全部插完后验证：
```bash
lark-cli docs +fetch --api-version v2 --doc "<URL>" --scope outline
```
确认 outline 里有 media block 且在锚点附近。插图后可用 `lark-cli docs +fetch --api-version v2 --doc "<URL>"` 拉回内容，保存为 final XML，再跑 `python3 scripts/check_fitness_quality.py --stage final final.xml`，final 阶段禁止内部图片字段泄漏，并禁止生图痕迹。若没有可靠图片可插，只要真实视频/图解 bookmark 和动作卡足够，可以正常交付；最终回复不要解释媒体检索过程、缺图原因或替代策略。若 `+media-insert` 失败（如文件格式问题）→ 换图重试或换源；仍失败就放弃该图，用视频/图解 bookmark 补足，不要假装完成。若创建失败：不要把错误写进文档；在聊天回复说"本次未能创建飞书文档，原因：___，可重试：___"，给本地 .xml 路径。

**8. 交付前自评 + 最终回复** — 最终回复前先做"交付前自评"（见下方"交付前自评"小节，三类检查：媒体/事实逻辑/内容丰富度），发现问题改了再交付。然后只回：文档标题 + 飞书 URL + 1–3 条内容亮点。**不粘贴正文，不解释搜图结果，不把缺失信息写成待办或追问，不承诺后续细化。**

成功交付的最终回复禁止出现这些内容：
- 媒体检索失败、图片不可用、下载不稳定、改用其他资料承接等过程说明。
- 文档完整性辩解、执行不受影响、后续可再细化等交付解释。
- 把缺失信息包装成文末问题、待补充清单或需要用户继续补资料的句子。
- `image-plan.tsv`、`no_reliable_image`、`media-insert`、`lark-cli` 等内部文件、状态或命令名。

缺失信息处理规则：
- **文档正文**：只写完整攻略、适用边界、自我调整开关和停止条件；不要把缺失变量写成面向用户的追问块。
- **最终聊天回复**：成功交付时默认只给标题、URL 和亮点。若确有非阻塞变量值得收集，只能放在聊天外层用一句“可选微调方向”轻提示，不写成编号问题清单，不进入文档正文。
- **确实高风险或无法安全生成时**：先不创建普通攻略，在聊天中说明必须先确认的安全信息；确认后再建文档。

成功交付回复示例：
```text
已生成《每周一下午的游泳减脂训练手册》飞书文档：
<URL>

包含 2.5 小时训练节奏、蛙泳/自由泳自检卡、每周一次游泳的饮食与追踪安排。
```

## 场景路由表

| 用户核心场景 | 主线 | 第一屏先答 | 必读 reference（最多 2 个） |
|---|---|---|---|
| 食堂/外卖/不会算热量/上班族减脂饮食 | 饮食执行型 | 今天怎么点、不用称重也减脂 | `scenario-playbooks.md §六` + `nutrition-and-recovery.md` |
| 新手小白/零基础/刚开始健身 | 新手起步型 | 今天第一练和一周节奏 | `scenario-playbooks.md §一` + `beginner-starter-playbook.md` |
| 塑形/马甲线/肩背/翘臀/腹肌/手臂线条/体态 | 塑形线条型 | 练哪些肌群、体重不是唯一指标 | `scenario-playbooks.md §三` + `exercise-technique-library.md` |
| 力量提升/卧推深蹲硬拉/备赛 | 力量主项型 | 主项表现和强度控制 | `training-standards.md` + `scenario-playbooks.md §七` |
| 跑步/心肺/跑几分钟就喘 | 跑走递增型 | 跑走比例、强度、膝踝保护 | `scenario-playbooks.md §八` + `training-standards.md` |
| 增肌/偏瘦增重 | 增肌进阶型 | 怎么吃出盈余、怎么练出渐进 | `scenario-playbooks.md §二/七` + `nutrition-and-recovery.md` |
| 体态/久坐/肩颈腰背 | 体态活动度型 | 风险边界和动作重建 | `scenario-playbooks.md` + `exercise-technique-library.md` |
| 中老年/产后/慢病/疼痛 | 安全分流型 | 避痛边界、可练/暂缓 | `safety-and-scope.md` |
| 居家无器械/无跳跃/不扰民 | 居家小空间型 | 无跳跃如何保留三类刺激 | `scenario-playbooks.md §四` |
| 健身房新手 | 器械路线型 | 进门练哪些器械、怎么调座椅 | `scenario-playbooks.md §五` |
| 25 分钟/忙碌上班族 | 时间盒型 | 单次时间拆解、最低有效训练 | `scenario-playbooks.md §九` |
| 8 周打卡/训练日志/PR/容量 | 打卡复盘型 | 记录什么、记录怎么改变计划 | `scenario-playbooks.md §十` + `competitive-upgrade.md` |
| 单个动作怎么做/替代动作 | 动作教学型 | 这个动作适不适合你、怎么做对 | `exercise-technique-library.md` |
| 计划审查/平台期/太累/没效果 | 诊断审查型 | 保留项、风险项、调整项 | `training-standards.md` |

**所有场景都默认读** `references/fitness-knowledge-base.md`（校准）和 `references/output-contract.md`（格式契约）。上表“必读”是在此基础上**额外**读的场景文件，最多 2 个。

## 清晰充盈攻略骨架（不是固定目录）

完整健身攻略先清楚，再丰富；先能执行，再做视觉。下面是生成前必须具备的能力，不是固定标题或固定顺序：

- **第一屏直接答核心痛点**：用户 30 秒内知道今天先做什么、本周怎么排、最重要的安全边界是什么。不要先写通用健身原则、默认假设或身份口吻。
- **目标路径讲明白**：说明为什么这样安排，而不是只列动作。减脂要讲力量/步数/饮食缺口如何配合；塑形要讲目标肌群和体态；增肌要讲训练量/渐进/热量盈余；跑步要讲跑走比例和递增；饮食型要讲点餐抓手。
- **执行颗粒度足够**：训练模块必须落到动作名、组数、次数/时长、强度大白话、休息、热身/收操、进阶和替代；饮食模块必须落到早餐/午餐/晚餐或食堂/外卖点餐口令、蛋白/主食/蔬菜/饮料零食处理；复盘模块必须写记录字段和根据结果怎么调整。
- **动作要点有厚度**：核心动作写起始姿势、执行路径、发力感觉、常见错误与修正、降阶/进阶、停止条件。辅助动作至少给一句自检，不要只有动作名。
- **现场调整真实可用**：必须覆盖最容易发生的阻力：时间不够、器械被占、漏练、吃超、没动力、疲劳/酸痛、疼痛不适。每种阻力给“怎么减量/换动作/回到计划”，不要只写“坚持”。
- **格式清晰但不模板化**：主要模块形成“为什么 → 怎么做 → 怎么判断/调整”的阅读节奏；表格、grid、callout、checkbox、bookmark 服务执行，不随机堆叠。主要 H2 下不能只有一句话或一张薄表。
- **内容跟用户问题走**：主角模块展开，配角模块合并。用户问食堂外卖减脂，饮食执行是主角；用户问马甲线肩背，肩背/核心动作质感是主角；不要每题都套“安全→训练→动作→饮食→复盘”。

## 周期选择（快速参考）

| 需求 | 默认周期 | 说明 |
|---|---:|---|
| 新手泛攻略 | 8 周 | 建习惯 + 学动作 + 渐进 |
| 减脂 | 8–12 周 | 更需要饮食、步数、复盘 |
| 食堂/外卖减脂 | 2–4 周先建饮食系统，再 8–12 周复盘 | 饮食规则是主体，训练是配套 |
| 增肌 | 8–12 周 | 训练量、渐进、恢复 |
| 力量提升 | 6–12 周 | 围绕主动作和强度周期 |
| 居家无器械 | 4–8 周 | 按动作进阶难度 |
| 跑步/心肺 | 4–12 周 | 按当前跑量和目标定 |
| 体态/久坐 | 4–8 周 | 高频低强度，强调日常纠偏 |
| 中老年/疼痛/产后 | 不固定 | 先安全分流，给低风险起点 |
| 单个动作教学 | 单次 | 不扩成长周期 |

## 必填富 block 清单（完整攻略）

完整攻略必须同时满足，详细组件用法见 `output-contract.md §4`：

- 1 个开头 `<callout>`（结论/判断）
- 1–3 个 `<table>`（训练安排/动作处方/复盘）
- 1 个 `<grid>`（对照）
- ≥3 个 `<bookmark>`（真实 http(s) URL，非 example.com）— 核心动作视频/图解，或饮食权威资源
- ≥3 个 `<checkbox done="false">...</checkbox>`（本周任务/打卡）。不要用 HTML `<input type="checkbox" />`。
- 1–3 个 `<hr/>`
- 1 个系统感组件（训练路线卡/低动力卡/替代矩阵/动作质感卡/饮食交通灯/进步仪表盘）
- 主要模块至少包含“为什么这么做 / 怎么执行 / 怎么调整”中的两类；完整攻略至少覆盖 2 类执行阻力（如漏练、吃超、器械被占、没动力、疼痛、时间不够）。
- **图片跟着内容走，但不强求**：核心动作、动作错误对照、餐盘/样例餐、疼痛边界等“看图才更容易执行”的对象优先搜真实图。训练型/饮食型完整攻略通常可尝试 2–4 张，单动作教学可尝试 1–2 张；不是每个辅助动作都必须配图。**只用真实、权威、可验证图片；搜不到可靠可嵌入图片就放弃插图，严禁生图。**未插图的核心动作必须有视频/图解 bookmark + 一句自检 + 动作卡。
- 富 block ≥5 类；主要 H2 附近至少 1 个非纯文本组件
- H2 泛标题 ≤2 个；≥60% H2 含专属词/动作/场景/动词

## 图片协议（只搜真实图；搜不到就放弃，严禁生图）

图片必须服务一个具体执行目的——纠正动作（动作演示/错误对照）、认得餐盘怎么配（211 餐盘实物）、识别停止信号（疼痛示意）。**不是装饰，不是"为了有图而放图"**。健身动作图片一旦不准确会误导用户，所以**宁可不插图，也不要用不可靠图片或生图**。

**只搜真实图**：中文用户先找国内可打开的教学图/图解页面、B 站/小红书图文、国内权威健康/营养资料；国内资源不稳定或不能嵌入时，再用 Wikimedia、ACE/NASM/NHS/Mayo/ExRx 等开放或权威资源兜底。对具体动作、器械、餐盘、食物等依赖真实视觉特征的内容，必须先按“豆包搜图协议”检索参考图：优先官方/权威来源、主体清晰、语义匹配、角度适合、低水印干扰，并把检索词和来源只记录在 `image-plan.tsv`，不要写进文档正文。**搜不到可靠图片就放弃插图，绝不调用 image_gen，绝不生成健身动作图。**caption 不写来源。

### 图片怎么进飞书（下载本地 + media-insert 锚点定位，避免 403 和堆文末）

飞书 `<img href="外部URL"/>` 会让飞书服务端去抓取那个 URL，但**很多图库/CDN 对飞书抓取返回 403 防盗链**（你看到的 403 就是这个）。所以不要用 `<img href>` 内联外部 URL。正确流程是**下载到本地 → `+media-insert` 上传**（图变成飞书自己的资源，无 403）：

1. **拿图片 URL**：先按豆包搜图协议找最高匹配参考图；可嵌入时拿图片直链，不能稳定嵌入时改用权威/开放直链。仍找不到就记录 `status=no_reliable_image`，不插图。
2. **下载到本地（带浏览器 UA 绕防盗链，验证是真图）**：
   ```bash
   mkdir -p outputs/{场景}/visuals
   curl -sL -A "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36" "<图片直链>" -o outputs/{场景}/visuals/NN-<名>.png
   file outputs/{场景}/visuals/NN-<名>.png
   # 必须是 "PNG image data"/"JPEG image data"；若是 "HTML document"/"ASCII text"/"empty" → URL 不是真图或被挡，换源重试
   ```
3. **建文档后，对每张图跑 `+media-insert --file` + `--selection-with-ellipsis` 锚点定位**：
   ```bash
   lark-cli docs +media-insert --as user --doc "<文档URL>" --file outputs/{场景}/visuals/NN-<名>.png --type image --align center --selection-with-ellipsis "<该图该出现的锚点正文一句>" --caption "图：<对象>"
   ```
   - **`--selection-with-ellipsis` 必填**——它把图插到锚点文本附近，跟着内容走、不堆文末。**不带这个参数默认追加到文末**（这就是"图全堆后面"的真因）。
   - 锚点用正文里一句独特的话（如动作卡里的"膝盖朝脚尖方向"），若该句在多个 block 出现，用 `"前缀...后缀"` 格式消歧。
4. caption 是 `图：{对象}`，自然一句话，不写"用于XX"、不写来源。

**XML 草稿里不要标记图的位置**：不要把 `<!-- 插图位置 -->` 写进 XML 正文；飞书可能把它渲染成用户可见文本。正确做法是正文写正常锚点句，图片计划单独写在旁路文件：

```tsv
file	anchor	caption	purpose	source_type	source
visuals/01-squat.png	膝盖朝脚尖方向，重心落在全脚掌	图：深蹲下蹲路径	纠正膝盖内扣	doubao-search	深蹲 标准动作 图解
visuals/02-row.png	先夹肩胛再拉肘	图：划船动作路径	理解肩胛后收	doubao-search	B站 划船 动作路径 图解
```

建文档后按 `image-plan.tsv` 每一行执行 `+media-insert`，图就插在锚点附近。

**不要用 `<img href="外部URL"/>` 内联**（403）。**不要生图**：动作类生图、示意图、错误对照图都可能画错关节角度和发力路径。搜不到真实可靠图时，改用权威视频/图解 bookmark + 文字动作卡，不硬生成。

### 图片数量

图片数量跟着内容走，不预设固定数：

| 攻略类型 | 配图原则 |
|---|---|
| 训练型完整攻略 | 尝试为核心动作或最容易做错的动作找真实图；找不到就用视频/图解 bookmark |
| 饮食执行型（食堂外卖） | 可尝试 211 餐盘、样例餐等权威/真实图；找不到就用表格/交通灯 |
| 动作教学（单动作） | 优先真实演示/权威图解；找不到就不给图 |
| 长期打卡/周期 | 可尝试核心动作真实图；复盘仪表盘用表格/checkbox，不生图 |

**硬性规则**：没有可靠图片可以 0 张图，但必须有真实可打开的视频/图解 bookmark、动作卡和自检说明。图片要服务执行，不为凑数牺牲内容。

### 图片位置与目的绑定

每个位置先想"这张图帮用户做什么"（内部判断，不写进 caption），搜真实照片：

| 位置 | 视觉 | 放图前想清楚 | 搜索来源 |
|---|---|---|---|
| 核心动作卡旁 | 动作路径/起始结束姿势/错误对照 | 纠正动作：怎么做对、哪里错 | Wikimedia Commons / 权威动作库 |
| 饮食点餐旁 | 211 餐盘实物照 | 照着配餐：每餐怎么搭 | Wikimedia（MyPlate/healthy plate）/ 中国营养学会 |
| 样例餐旁 | 真实餐食照 | 看懂吃什么 | 点评平台实拍 / Wikimedia |

抽象结构（训练卡、仪表盘、替代矩阵、交通灯）用表格/callout/grid/checkbox 等 Feishu 富 block 承载，不生图。

### 禁止突兀大图

不要一张大横图突兀占半页。正确做法：

- **多张统一尺寸卡片穿插**：完整攻略用 3–5 张 `3:4` 或 `1:1` 的图，分别插在对应动作/饮食模块旁，不堆一起。
- **同组同尺寸**：多张动作图都用 `3:4`，多张饮食图都用 `1:1`；不要一张大一张小。
- **默认不放封面**，把图位让给动作演示/餐盘这些更有执行价值的。
- **不放与内容脱节的图**：动作图必须贴在该动作卡旁、餐盘图贴饮食点餐旁。

### 多张图并列展示（重要）

多个核心动作图或多道餐食照要**并列展示，不要纵向堆一长串**。用飞书 `<grid>` 分栏并排：

```xml
<h2>核心动作要点</h2>
<grid>
  <column width-ratio="0.5"><p><b>深蹲：</b>膝盖朝脚尖方向，重心落在全脚掌。</p></column>
  <column width-ratio="0.5"><p><b>划船：</b>先夹肩胛再拉肘，不要耸肩借力。</p></column>
</grid>
```

同时在 `image-plan.tsv` 里写两行，锚点分别用“膝盖朝脚尖方向，重心落在全脚掌”和“先夹肩胛再拉肘”。建文档后按计划跑 `+media-insert --file <本地> --selection-with-ellipsis "<锚点>" --caption "图：对象"`，图插到对应锚点附近。同一组多图必须同尺寸（都用 `3:4`），用 `--width` 统一显示宽度（如 `--width 500`）。若 grid 插图失败，退化为纵向连续多图 + 相同小宽度（`--width 500`）。

### 动作图解配图原则（核心动作优先）

训练型攻略优先给**核心动作**配动作图解，贴在对应动作卡旁。辅助动作可以只给视频/图解 bookmark 和一句自检，不强制每个辅助动作都配图。

- 核心动作通常 3–5 个；从中选择最容易做错、最影响安全和效果的 2–4 个配图。
- 搜图优先：先找国内教学图/图解页面和权威动作库；无法获得可下载真图时，再用 Wikimedia/权威图库；仍找不到就放弃插图。
- caption 不写来源：caption 就是 `图：对象`（如 `图：深蹲下蹲路径`），不写“来源：搜图/生成图”。
- 动作图用统一 `3:4` 尺寸，用 `<grid>` 两列并排展示多张动作图，不要一张占半页。

### 搜图流程（傻瓜 4 步）

1. **先搜国内/权威资源，再用 Wikimedia 找可下载直链兜底**。搜索词固定格式：
   - 国内教学图：`{动作名} 动作 图解 教学 标准动作 常见错误`、`B站 {动作名} 教学 图解`、`小红书 {动作名} 标准动作 常见错误`
   - 权威/开放图片：`{英文名} exercise diagram`、`{英文名} wikimedia commons`、`site:acefitness.org {英文名}`
   - 餐盘：`中国居民膳食指南 餐盘法`、`MyPlate USDA wikimedia`、`healthy plate wikimedia commons`
2. **从结果里挑图片直链**：直链 URL 形如 `https://upload.wikimedia.org/wikipedia/commons/.../*.jpg`（或 `.jpeg`/`.png`/`.webp` 结尾）。**只认这种以图片扩展名结尾的 URL**，不要拿页面 URL（`commons.wikimedia.org/wiki/...` 是页面不是图）。WebSearch 结果里若只给页面，再对页面搜一次 `{文件名} upload.wikimedia.org` 找直链。
3. **下载到本地 + 验证真图**：`curl -sL -A "Mozilla/5.0..." "<直链>" -o outputs/{场景}/visuals/NN-<名>.png`，`file` 验证是 "PNG/JPEG image data"（HTML/空 → 换源）。
4. **建文档后 `+media-insert --file` 插到锚点**：见上方"图片怎么进飞书"。

**搜不到怎么办**：换搜索词或换一张图，最多重试 2 次。仍搜不到 → 在 `image-plan.tsv` 记录 `status=no_reliable_image`、检索词和原因；正文用真实视频/图解 bookmark、动作卡、常见错误表和一句自检补足。**不要生图。**

### 写入 XML 草稿 + 旁路锚点规划

XML 草稿里**不写 `<img href>`**（403），也**不写 XML 注释/内部字段**。正文只写用户该看的内容和一句唯一锚点句；图片文件、锚点和图注全部写进 `outputs/{场景}/image-plan.tsv`：

```xml
<h2>核心动作：深蹲</h2>
<p>起始姿势：双脚与肩同宽，膝盖朝脚尖方向，重心落在全脚掌。</p>
<h2>核心动作：划船</h2>
<p>执行时先夹肩胛再拉肘，手臂像绳子一样把重量带回来。</p>
```

```tsv
file	anchor	caption	purpose	source_type	source
visuals/01-squat.png	膝盖朝脚尖方向，重心落在全脚掌	图：深蹲下蹲路径	纠正深蹲路径	doubao-search	深蹲 标准动作 图解	ready	
```

如果某张图搜不到可靠来源，只在旁路计划里记录跳过原因，正文和最终回复都不要提。

建文档后，对每一行跑一次 `+media-insert --file <本地文件> --selection-with-ellipsis "<锚点>" --caption "..."`，图就插在锚点附近、不堆文末。**`--selection-with-ellipsis` 必填**，否则图追加文末。详见"图片怎么进飞书"。

跑脚本（硬门控，校验 `image-plan.tsv` 完整 + XML 正文无内部注释 + 禁止生图；有 `ready` 图片时校验本地图片文件）→ `lark-cli docs +create` 建文档 → 只按 `ready` 图片计划跑 `+media-insert` 插图 → `lark-cli docs +fetch --scope outline` 验证 media block 在锚点附近。没有可靠图片时可不插图，但媒体链接和动作卡必须充分。

## 内部专业判断视角（驱动内容质量，不写进正文）

每次处理健身需求时先在内部判断，再选文档架构。这些是内容质量维度，**不要在文档里固定列成十个章节**，按用户问题选最重要的写进去：

1. **真实目标**：表面问什么 vs 真想改变什么（体重/线条/力量/心肺/疼痛/体态/习惯/自信）。
2. **人群与阶段**：新手/有基础/久坐/体重较大/跑者/学生/上班族/中老年/产后/疼痛慢病——不能用同一套计划。
3. **安全边界**：红旗信号、疼痛、术后/孕产期/慢病、极端减重、动作风险——哪些必须停练或先线下评估。
4. **可用资源**：每周几练、每次多久、场地器械、预算、作息、能否做饭/跑跳、是否需低噪音低冲击。
5. **动作能力**：蹲、髋铰链、推、拉、核心抗伸展/抗旋转、单腿稳定、肩胛控制、心肺基础——新手优先可控版本。
6. **训练剂量**：频率、组数、次数、强度、休息、进阶速度匹配恢复能力；说明怎么加量、何时降级。
7. **目标配套策略**：减脂看能量缺口和保肌肉；增肌看训练量和盈余；塑形看肌群策略和体态；力量看主项技术和周期；跑步看递增和伤病预防。
8. **饮食与恢复**：最少但有效的饮食动作、蛋白质、睡眠、酸痛处理、休息日。
9. **执行阻力**：时间少、不会动作、器械不足、怕受伤、外卖食堂、出差、没动力——给替代或备用版本。
10. **复盘指标**：完成率、训练重量/次数、围度/照片、7 日均重、疼痛 0–10、睡眠、主观疲劳。
11. **坚持支持**：两周后最可能卡在哪（漏练/吃超/没动力/体重波动/酸痛/器械被占），文档里要有具体处理方式。

**禁止暴露身份/角色/推理视角**。不要写“我是/作为/从某某视角看/我的建议是”。直接写结论，如“这类目标优先练肩背和核心稳定，而不是盲目减重”。

## 执行原则（要点）

- 默认中文输出。
- 先给有立场的方案，再解释取舍。避免百科式堆动作名。
- 不能把高阶计划套给新手、伤病或产后人群。
- 健身建议不是医学诊断：高风险情况先安全分流，再给低风险通用建议。
- 每个训练计划必须可执行：写清动作、组数、次数/时长、强度、休息、频率、进阶规则、替代动作、停止条件。
- 饮食用区间和原则，不做危险极端缺口，不承诺局部减脂或快速瘦身。
- 训练安排包含热身、主训练、收操/拉伸、恢复；高强度要安排休息日和降载。
- 标题/首屏/章节顺序按场景变化，**不要套固定目录**。标题和 H2 规则见 `output-contract.md §2`。
- 不把本地档案、历史训练日志或用户画像带入回答，除非用户明确提供。
- 默认联网搜真实资源，除非极短答复、联网不可用或必须先做高风险医学分流。

## references 索引

| 文件 | 何时读 |
|---|---|
| `output-contract.md` | **必读**。交付契约、标题公式、XML 骨架、富 block 用法、视觉设计、交付前自检 |
| `fitness-knowledge-base.md` | **必读**。训练逻辑校准、动作模式知识卡、目标校准规则、姿势/训练系统输出标准 |
| `scenario-playbooks.md` | 场景路由命中时读对应小节。新手/偏瘦增肌/塑形/居家/健身房/食堂外卖/5天增肌/跑步/25分钟/8周打卡 + 执行陪伴模块库 |
| `training-standards.md` | 训练计划组成、训练模板与日志字段、强度/渐进/降载、新手默认方案 |
| `exercise-technique-library.md` | 任何含动作处方/动作教学/替代动作时。核心动作的起始姿势/路径/发力/错误/降阶进阶/停止条件 |
| `nutrition-and-recovery.md` | 减脂/增肌/体重管理/训练恢复/食堂外卖时。热量/蛋白/餐盘法/外食/复盘指标 |
| `safety-and-scope.md` | 疼痛/产后/中老年/慢病/术后/极端减重/进食障碍时。红旗识别和分流 |
| `media-search-and-sources.md` | 生成训练计划/动作教学/图文文档/核验资源时。搜索策略、来源优先级、图片放置 |
| `competitive-upgrade.md` | 训练模板/动作库/训练日志/RIR/PR/训练容量/体重追踪/替代动作/完整周期时。数据模型和复盘 |
| `beginner-starter-playbook.md` | 新手/零基础泛攻略时。第一练、A/B 训练、动作自检、进阶规则 |

## 质量检查

最终回复前，确认创建前已跑 `check_fitness_quality.py --stage draft --image-plan outputs/{场景}/image-plan.tsv outputs/{场景}/{场景}.xml` 并 PASSED；插图后如能回读文档，再跑 `check_fitness_quality.py --stage final final.xml` 检查无内部标记泄漏。并确认：

- 标题含专属词，不是 `XX攻略/计划/方案`？
- 第一屏直接答痛点，没先讲通用原则？
- 计划匹配目标/基础/器械/时间/限制？动作组数强度休息频率进阶明确？含热身/恢复/替代/停止条件？
- 饮食避免极端节食/虚假承诺/局部减脂神话？给了复盘指标而非一次性计划？
- H2 泛标题 ≤2 个？富 block ≥5 类？有可靠真实图时是否插到对应模块？没有图时是否用视频/图解 bookmark 和动作卡补足？
- 媒体资源覆盖前文核心动作，中文用户优先国内资源？
- 正文没有 lark-cli 版本/auth/权限/fallback 等内部状态？
- 最终回复只有标题 + URL + 1–3 条内容亮点，没有粘贴正文，也没有图片失败、追问补资料、承诺二次细化等过程说明？

## 交付前自评（三类检查，不可跳过）

质量脚本只查结构，查不了事实合理性。最终回复前必须自己过一遍下面三类，发现问题就改了再交付。

### 1. 媒体自评

- **严禁生图**：正文和旁路计划里不能出现 `image_gen`、`generated`、`生成图`、`AI 生成图`。健身动作图片搜不到就放弃，不要生成。
- **搜图是否真图**：每张搜来的图都过了 `file` 验证是 "PNG/JPEG image data" 吗？有没有下到 HTML 错误页冒充图片？
- **图位置对不对**：图有没有堆到文末？每张图都在对应动作/饮食模块旁？（`+media-insert` 带了 `--selection-with-ellipsis` 锚点）
- **核心动作有图或资源**：最容易做错、最影响目标的核心动作是否配了动作图？未配图的辅助动作是否有视频/图解 bookmark 或一句自检？

### 1.5 XML 字段泄露自检

- **XML 标签/注释泄露**：用 `lark-cli docs +fetch` 拉回文档内容，检查正文里有没有 XML 标签（`<callout>`/`<grid>`/`<img>`/`<table>` 等裸标签）、`<!-- 插图位置 -->` 注释、`caption="..."`/`anchor="..."`/`来源：生成图（无文字）` 这类**给工具/脚本看的内部字段**泄露到用户可见正文。有 → 删掉，只留正常攻略文字和已插入的图。
- **HTML 表单泄露**：正文里不能出现 `<input type="checkbox" />`、`&lt;input type="checkbox"...&gt;` 或其他 HTML 表单标签。飞书 XML 复选框写 `<checkbox done="false">事项</checkbox>`；如果是 Markdown 降级稿才写 `- [ ] 事项`。
- **工具状态泄露**：正文有没有 `lark-cli`/`auth`/`scope`/`token`/`+media-insert`/`+create` 这类命令/工具名？（只能出现在最终回复的失败说明里，不能进正文。）

### 2. 事实逻辑自评（真实性，健身红线）

逐条对照，踩中任一就改：

- **危险剂量**：新手有没有被安排大重量（如卧推 100kg、力竭训练、1RM 测试）？新手应从空杆/轻重量学动作，保留 2–4 次余力。
- **极端饮食**：有没有极端热量缺口（每天 <1000 大卡、断碳、长期断食、单一食物减肥）？减脂是轻度缺口。
- **禁忌人群**：疼痛/产后/慢病/术后用户有没有被安排"忍痛练"或普通计划？应先安全分流。
- **虚假承诺**：有没有"一个月瘦 20 斤""快速练出马甲线""局部减脂"？删掉。
- **训练量不匹配**：新手每肌群周训练量有没有超标（应 6–10 组，不是 20 组）？高强度有没有连练同一肌群不给恢复？
- **跑步**：新手有没有被安排冲刺/长距离？应从跑走结合开始。
- **缺少停止条件**：动作/计划有没有写"疼痛明显到让你想停就别硬撑（超过 3/10）、麻木、头晕就停"？
- **强度表达**：强度有没有用大白话给用户解释（如"有挑战还能做 2-3 次"），而不是只甩术语"RPE 7-8"让用户看不懂？内部用 RPE/RIR 校准，呈现给用户时大白话为主、括号标数值。
- **荒谬场景拼凑**：有没有把强度/疼痛描述套到不合适的场景上（如"游泳时能说短句""跑步时没法连续聊天"——游泳/水下没法说话判断强度）？强度描述要贴合实际场景，游泳用配速/心率，别套"说话"。逐条看正文有没有这种把 A 场景的描述硬套到 B 场景的荒谬句。

### 3. 内容丰富度自评（切实可行，不为丰富而丰富）

- **看得懂、做得到**：每个模块给的是具体可执行内容（动作名+组数+次数、具体餐食/点餐口令、具体复盘字段），还是空话（"注意饮食""坚持训练"）？
- **有没有为丰富而丰富**：有没有和用户目标无关的模块凑数？删掉。用户问食堂外卖减脂，就别大篇幅写健身房动作。
- **逻辑清不清楚**：用户能顺着"为什么这么练 → 怎么练 → 怎么调整"读下来吗？有没有跳跃、前后矛盾（前面说新手后面给高阶量）？
- **薄模块**：有没有 H2 下面只有一句话或一张薄表？展开或合并。
- **执行阻力覆盖**：漏练、吃超、器械被占、没动力怎么办，有没有给具体处理（不是"坚持就好"）？
- **第一屏是否解决痛点**：用户最关心的问题（怎么点餐/怎么开始/怎么练）第一屏答了吗，还是要翻到很后面？