引言
在LeaScript：面向端侧/视觉跟练的动作脚本规范，描述了 LeaScript 分层架构中的第一层（原子层） 与第二层（序列层）。
- 原子层解决的是“单个动作标不标准”的问题，由算法工程师维护骨骼点、角度阈值与纠错逻辑。
- 序列层解决的是“一组操编排得好不好”的问题，由教练/UP主从动作库中挑选动作、排列组合，形成一套完整的“操”。
而这一篇要讨论的第三层——课程层，则站在了更高的位置，回答一个完全不同的问题：
如何把多套“操”，按天（Day）组织成一套科学的、可执行、可商业化分发的训练计划？
课程层不再关心单个动作如何做、单套操如何编排。它的处理单位是操，UP主在这里看不到任何姿态阈值，也无需理解状态机与语音播报。他只做一件事：决定哪一天、要出现哪些操、每套操做几轮。
这也是 LeaScript 三层架构的顶层设计目标所在——彻底解耦，逐层降低创作门槛。
解耦与开源：课程的“规范”与“实现”是两件事
LeaScript 从设计之初就是开源的。它的规范（<workout>、<state2>、<pose> 等语法定义）不绑定任何一家公司的产品，任何人都可以基于这套规范去实现自己的编辑器、播放器或课程平台。
这一点在课程层尤其重要。
因为课程层天然带有商业化属性——它涉及定价、购买、激活、宽限期、到期，甚至后续的订阅、群发、服务。不同的人，对“商业化”的想象力完全不同：
- 有人想做一次性买断，课程就是一次性商品；
- 有人想做订阅制，课程只是长期服务中的一个“内容模块”；
- 有人想做私域运营，课程是引流工具，真正的变现靠社群与直播；
- 有人想做企业团购，课程需要批量授权、批量激活、批量统计。
LeaScript 规范只定义课程的结构（<wkocourse>、<day>、<workout>），不定义课程的商业逻辑。
kDesktop 是课程层的一种实现。 它选择了“小程序 + 内购 + 群发 + 图表评语”这条路径，但它并不是唯一路径。任何开发者都可以基于 LeaScript 规范，设计出完全不同商业模式的课程层实现。
这也是本篇文章写作的前提：讨论的是课程层的规范，而不是某一款产品的功能。
一、规范：<wkocourse> 的语法定义
1.1 文件结构
<wkocourse> 是一个 .cfg 文件的最外层标签，一个文件有且仅有一个 <wkocourse> 块，它对应着一套完整的“课程”（如“15天瘦腰肚子计划”、“30天久坐体态修复计划”）。
课程层在 LeaScript 的分层架构中属于第三层（顶层）。它的内部单位是“操”（<workout>），而不是“动作”。
<wkocourse> 下包含两个层级：
- 课程级字段：直接写在 <wkocourse> 标签下，描述课程的整体属性。
- <day> 子标签：按天（Day）组织课程内容，每一天下面包含若干个 <workout>。
1.2 课程级字段
| 字段名 | 数据类型 | 必需 | 说明 |
| id | 字符串 | 是 | 课程的唯一标识。映射物理文件名，格式为 id.cfg。命名规范与动作脚本 ID 相同（仅允许英文字母、数字、下划线，不超过 24 字节）。 |
| title | 字符串 | 是 | 课程名称。显示在 App 首页的 tab、课程详情页等处。如“15天瘦腰肚子计划”。 |
| description | 字符串 | 是 | 课程简介。用一两句话向用户说明这门课练什么、适合谁、有什么效果。建议不少于 15 个中文字符。 |
| total_days | 整数 | 是 | 课程总天数。取值范围 1 ~ 90，默认 15。超过 60 天建议拆分为多期。 |
| grace_period_days | 整数 | 是 | 激活宽限期（天）。购买后可在该天数内自由选择激活日；逾期未激活则自动开始 Day 1。取值范围 0 ~ 10，默认 7。 |
| price | 整数（分） | 是 | 课程售价。建议以“分”为单位存整数，避免浮点误差。如 price=1990 表示 19.90 元。 |
| currency | 字符串 | 是 | 货币单位。ISO 4217 三字母代码，如 CNY、USD。 |
| reference | 字符串 | 否 | 课程介绍视频的 URL。用于在 App 课程详情页展示“课程介绍”播放按钮。若为空，则 App 不显示该按钮。 |
| author | 字符串 | 否 | 课程作者署名。用于在 App 中展示创作者身份。 |
关于 id 命名的补充说明：课程层的 ID 规范与动作层一致——id 直接映射为物理文件名，加载时在文件名后附加 .cfg。多小程序生态下，课程的全局唯一标识由 bundleid + id 组合而成（内部称为 id2）。
关于 price 的补充说明：price 是课程在 App 内展示和购买的依据。实际支付金额建议以服务器返回为准，避免脚本被篡改。
1.3 <day> 子标签
<day> 用于定义课程中的某一天（或某几天）的内容。
| 字段名 | 数据类型 | 必需 | 说明 |
| days | 字符串 | 是 | 该天数据对应课程中的哪一天。支持两种写法：单天（如 days="1"），多天复用（如 days="1,3,5,7"）。多天写法可大幅缩减脚本长度，避免大量重复的 <day> 块。 |
| title | 字符串 | 是 | 当日标题。只写“今天练什么”（如“肩颈唤醒”、“休息日（轻拉伸）”），不写“第几天”，由系统展示时自动拼接“Day X”。 |
| <workout> | 子块 | 否 | 当天要执行的操。一个 <day> 下可包含 0 ~ 9 个 <workout> 块。 |
关于 days 的补充说明：字段名使用复数 days，既能表达“多天复用”的语义，也明确提示解析器这是一个按逗号分隔的数字列表。day 为非法字段，解析器应予以拒绝。
1.4 <workout> 子标签
<workout> 用于定义某一天中要执行的单套“操”。
| 字段名 | 数据类型 | 必需 | 说明 |
| id | 字符串 | 是 | 引用序列层的“操”ID。如 lea_plank、xiyuan_shoulderneck。课程层不直接引用动作（原子层），只引用操（序列层）。 |
| rounds | 整数 | 否 | 该操在当天执行的轮数。取值范围 1 ~ 8，默认 1。超过 8 轮应拆分或减少轮数。 |
| note | 字符串 | 否 | 健身操备注。用一两句话说明该操在当天训练中的角色，如“基础热身”、“核心强化”、“可选替代”。 |
关于 rounds 的补充说明：一轮 = 该套操完整执行一遍。如“平板支撑60秒 + 眼镜蛇拉伸”这套操，做 1 轮就是完整做完“平板支撑60秒 + 眼镜蛇拉伸”；做 2 轮就是再做一遍。“100% 完成”是针对单轮而言的——完成 1 轮计数 +1，逐轮累加。
1.5 一天的校验规则
- 每一天都必须有 <day> 标签，即使这天什么操都不做（休息日），也必须写一个 <day>，在 title 里注明“休息日”。
- 每一天的 title 都不能为空。如果这天没有安排任何操，title 也必须写清“休息日”之类的说明。
- 一天内的 <workout> 数量建议在 1 ~ 9 之间。其中第 9 个可作为“可选替代”操（二选一），用于给不同水平用户提供退阶/进阶选择。
1.6 一个课程脚本示例
[wkocourse] id="posture_fix_30days" title="30天久坐体态修复计划" description="30天久坐体态修复。拉伸肩颈、强化腰背、矫正圆肩驼背。" total_days=30 grace_period_days=7 price=0 currency="CNY" reference="https://www.bilibili.com/video/BV1m2bh6VEv8" author="阿见见Zz" [day] days="1" title="肩颈唤醒" [workout] id="xiyuan_shoulderneck" note="肩颈+体态" [/workout] [/day] [day] days="2" title="肩颈放松" [workout] id="lea_shoulderneck_10s" note="肩颈操，拉伸颈侧" [/workout] [workout] id="lea_plank_cobraflow" [/workout] [/day] [day] days="3,5,7" # 第3、5、7天复用同一套安排 title="核心唤醒" [workout] id="lea_pelvictilt" note="矫正骨盆前倾" [/workout] [workout] id="xiyuan_shoulderneck" [/workout] [/day] # ... 其余天数 [/wkocourse]
二、工业化生产：课程是如何被“制造”出来的
LeaScript 三层架构的终极目标，不是发明一套新的脚本语言，而是把原本感性的“内容创作”过程，拆解为理性的“工业化生产”流水线。
在传统模式下，一个健身 UP 主想出一套 30 天课程，他需要自己构思动作、自己演示、自己录制、自己剪辑、自己配语音。整个过程高度依赖个人能力，较难复制、较难规模化。
而 LeaScript 的三层架构，把这件事拆成了三段：
- 原子层：算法工程师负责定义“动作标不标准”。
- 序列层：教练/UP主负责决定“一组操怎么编排”。
- 课程层：课程策划负责规划“哪一天练哪些操”。
这三段之间，通过 .cfg 文件完全解耦。每段的生产者只需要专注自己的环节，做出来的东西可以被下一环节直接复用。这就是工业化生产的基本形态：分工明确、标准统一、接口清晰。
2.1 流水线：从“待办清单”到“可跟练的课程”
工业化生产的核心特征，是输入和输出标准化。
在 LeaScript 体系里，一个 UP 主要制作一套课程，他只需要给出最上层的 “待办清单”（如图 1 所示）：
这份清单，就是课程层的全部输入。剩下的工作，由流水线自动完成：
- 课程脚本生成：根据待办清单，自动生成 <wkocourse> 脚本，确定每一天要做哪些操、做几轮。
- 操脚本生成：根据每个操的动作和次数/时长，自动生成 <workout> 脚本，把原子层的动作排列组合成一套完整的操。
- 原子层复用：动作直接从 action_tpl2s.cfg 动作库中引用，无需重复定义姿态阈值和纠错逻辑。
在这个流程里，UP 主不需要写任何一行 INI/JSON/XML，也不需要理解骨骼点或状态机。他只需要说清楚“哪一天练什么”。这就是工业化生产的意义：把“创作”变成“组装”。
2.2 质量如何不降？
工业化生产有一个担忧：量上来了，质量会不会下来？
LeaScript 的答案是：质量由规范保证，不由人保证。
- 动作质量：由原子层决定。每个动作的姿态阈值、计次逻辑、纠错语音，都由算法工程师或高级教练一次性定义好，全平台复用。动作的标准是统一的，不会因为 UP 主不同而不同。
- 操的质量：由序列层的校验规则决定。比如，每个操的时长必须 ≥ 30 秒；每个动作的阈值可以覆盖，但不能改变 diff_id 结构。这些硬性约束，保证了操的“基本质量”。
- 课程的质量：由课程层的校验规则决定。比如，每一天都必须有内容（休息日也要写清楚）；每一天的操数必须在 1 ~ 9 之间；每一天的 title 不能为空。这些规则，保证了课程的“完整性”。
这里有一个关键点：UP 主的“待办清单”一旦确定，后续的脚本生成、校验、导出，都是由程序自动完成的。程序不看“量大量小”——它只认规范。 待办清单是 10 天的课还是 90 天的课，动作层、操层、课程层的校验规则完全一致，不会因为课程长了就“松一点”，也不会因为课程短了就“紧一点”。
这就是工业化生产的意义：把“质量把关”从“人盯人”变成“程序执行”。 只要规范是程序，量大量少，质量的下限就一样稳。
换句话说，只要 UP 主在 Launcher 里能成功导出脚本，这份课程就已经通过了所有质量校验。质量的下限，由架构本身兜底。
2.3 AI：流水线的柔性引擎
工业化生产还有一个目标：让生产更灵活、更智能。 这是 AI 要解决的问题。
LeaScript 体系对 AI 的态度是：AI 是流水线的柔性引擎，不是黑盒替代品。 它的落地需要分层推进：课程层最容易，操层次之，动作层最难（但必须靠语义元数据支撑）。
在动作层：为了保证质量与健身安全，动作的定义不能是黑盒。即使端侧 AI 再强，也不能让 AI 随意判断“这个深蹲做得对不对”。所以，动作层需要增加“语义元数据”，让 AI 能理解每个动作的语义：
- body_part：部位标签，如 core、upper、lower、shoulder、neck、back、arm、leg。
- level：难度等级，如 beginner、intermediate、advanced。
- movement_type：动作类型，如 strength、stretch、cardio、balance、mobility、rehab。
- training_role：训练角色，如 warmup、main、cooldown。
这些字段不改变现有的物理执行层（<track_pose>、<task>、<pose>），只是在 <action_tpl2> 上增加一组可选的语义标签。人类看 name 和 msg，AI 看语义字段。
在操层：给 AI 一份“动作 + 次数/时长”的清单，它已经能生成基础的 <workout> 脚本。但“准确”这件事要分两层看：语法正确（AI 完全能做到，因为标签结构是固定的）、内容合理（AI 不一定能做到，比如把拉伸排到热身前面，或把两个高强度动作连续排在一起）。所以，操层的原则是 “AI 负责生成，规则负责校验”。
在课程层：语法比操层更简单——它只有 <day> 和 <workout> 两层结构，不涉及姿态、阈值、状态机。所以，一旦给 AI 一份待办清单（图 1 中的课程部分），AI 生成 <wkocourse> 脚本的准确率会非常高。课程层是 AI 落地最快的场景。
2.4 为什么 AI 是必须的？
因为跟练 App（像 kDesktop）不可能内置一整个编辑器模块。
编辑器（Launcher）是一个复杂的状态机可视化工具，它需要渲染 <state2> 流程图、渲染 <pose> 参数面板、处理 diff_id 覆盖逻辑。它的体积和复杂度，不适合放在一个“跟练”为主的 App 里。
但用户在使用 kDesktop 时，可能会临时产生需求：
- “我今天不想做课程里的操，想换成另一种”；
- “我腰不舒服，能不能给我生成一套舒缓的拉伸操”；
- “我想给这个课程加一天休息日”。
如果这些需求都要求用户打开 Launcher，体验就断了。所以，kDesktop 需要一个轻量级的、能理解 LeaScript 的 AI 引擎，在用户说几句话的时候，就能生成或修改 <workout> 或 <wkocourse> 脚本，然后直接开始跟练。
这就是 AI 在 LeaScript 体系里的最终定位：它不是替代编辑器，而是作为“轻量级生成器”嵌入到跟练 App 里，让脚本生成从“编辑器里点选”变成“对话里生成”。
而这套机制的底层支撑，依然是三层架构的彻底解耦——AI 不需要理解骨骼点，它只需要理解“操”和“课程”的语义，就能生成可执行的脚本。AI 是流水线的柔性引擎，不是流水线的替代品。