OpenMAIC 系统设计文档站
蓝图与路线图
系统设计文档站 / 蓝图与路线图

课程内核重构工程推进路线图（V1）

本文件用于定义 OpenMAIC 在“课程内核彻底重构”前提下，从 0 开始推进新工程的整体路线图。

16 静态 HTML 版本 2026年5月26日 14:26

1. 文档目的

本文件用于定义 OpenMAIC 在“课程内核彻底重构”前提下，从 0 开始推进新工程的整体路线图。

这里的“从 0 开始”不等于立刻推翻所有历史资产重新写完全部功能，而是指：

  1. 以 [15-课程内核重构蓝图（V1）.md](./15-%E8%AF%BE%E7%A8%8B%E5%86%85%E6%A0%B8%E9%87%8D%E6%9E%84%E8%93%9D%E5%9B%BE%EF%BC%88V1%EF%BC%89.md) 为唯一设计基线
  2. 建立一套新的课程内核工程骨架
  3. 旧系统只作为参考、取材和对照，不继续作为新内核的结构母体

2. 推进原则

  1. master 仍为唯一长期基线
  2. 第一阶段坚持 模块化单体
  3. 先冻结协议，再推进实现
  4. 先打通正向主骨架，再补另外两条正式主线
  5. 页面、平台和权限能力不得反向主导课程内核结构
  6. 先保证“能稳定生成课程主干”，再逐步强化课程质量、交互深度和 AI 能力覆盖

2.1 当前阶段的优先级判断

当前阶段建议把目标分成 3 层：

P0：先做出来

这一层是当前绝对优先级，目标是先让课程内核真正能生成课程：

  • 新工程骨架
  • 领域模型
  • 生成协议
  • 正向组课主链
  • 最小运行链

P1：做成正式主线

这一层是在主骨架成立后继续补全三条正式主线：

  • 诊断补救主线
  • 能力专题主线
  • 三门主课首批增强器

P2：做强与做深

这一层不删除，但明确后排到主干生成成功之后：

  • 课程质量系统化增强
  • 深交互式训练
  • 动画 / 视频 / 可视化深用
  • TTS / ASR 的教学化深用
  • 搜索增强的精细策略
  • 高级导出与复杂投影

这意味着：

  • 第一阶段不以“课程质量做到极致”为验收门槛
  • 第一阶段不以“交互做得很深”为验收门槛
  • 第一阶段不以“AI 能力覆盖得很全”为验收门槛

第一阶段真正的验收门槛是：

  • 课程主干能不能稳定生成
  • 三层主结构能不能稳定装配
  • 生成结果能不能进入最小运行闭环

3. 总体路线

建议整体按以下 8 个阶段推进：

  1. 蓝图冻结
  2. 新工程骨架建立
  3. 领域模型与协议落地
  4. 正向组课主骨架打通
  5. 教学运行内核打通
  6. 诊断补救主线打通
  7. 能力专题主线打通
  8. 学科增强、编辑导出与平台外壳扩展

4. 分阶段路线

阶段 0：蓝图冻结

目标：

  • 结束核心概念漂移
  • 固定三条主线、核心对象、模块边界和阶段产物

交付物：

  • 蓝图主文档
  • 三条主线输入样例
  • 阶段产物清单
  • 核心对象字段表
  • 模块调用边界草图
  • 各阶段暂不实现项清单

阶段退出标准：

  • 对 Stage / Unit / Scene
  • ProblemSolvingPattern / CapabilityUnit / GapProfile / RemediationCoursePlan
  • CourseStrategy / LessonIntent / AssemblyMode / UnitType 不再存在结构性争议

阶段 1：新工程骨架建立

目标：

  • 在当前仓库内建立新工程骨架
  • 不再把新内核逻辑继续塞进旧结构

建议结构：

  • packages/domain-model
  • packages/generation-contracts
  • packages/course-kernel
  • packages/subject-enhancers
  • packages/runtime-engine
  • apps/api
  • apps/web

交付物：

  • workspace 目录骨架
  • 构建、lint、类型检查基线
  • 基础模块依赖规则

阶段退出标准：

  • 新工程能独立编译
  • 模块依赖方向符合蓝图
  • 未出现旧系统反向绑入新模块的强依赖

阶段 2：领域模型与协议落地

目标：

  • 把蓝图对象正式落为 TypeScript 协议与阶段产物

优先对象：

  • GenerationInputV2
  • Stage / Unit / Scene
  • KnowledgePoint / CompositeKnowledgeChain
  • ProblemSolvingPattern
  • CapabilityUnit
  • GapProfile
  • RemediationCoursePlan

交付物：

  • domain-model 类型定义
  • generation-contracts 请求/结果协议
  • 样例级协议校验能力

阶段退出标准：

  • 三条主线输入样例全部可被协议表达
  • 阶段产物清单全部可被类型层承接

阶段 3：正向组课主骨架打通

目标：

  • 先打通最稳定的一条主线
  • 验证新内核不是空壳
  • 明确以“主干生成成功”为第一优先级，而不是同时追求交互和质量上限

范围：

  • forward_design
  • curriculum_aligned
  • chapter_based

交付物：

  • generateCourse
  • 最小 Unit / Scene / PracticePlan 装配链
  • 一条可运行的教材同步课程

阶段退出标准：

  • 能从教材同步输入生成可讲、可练、可测课程
  • 不依赖诊断模块和能力专题模块
  • 不要求在此阶段完成高质量动画、复杂交互和多模态深覆盖

阶段 4：教学运行内核打通

目标：

  • 让装配结果真正可运行

范围：

  • 教学运行状态机
  • Scene 切换
  • 动作执行
  • 检查点事件回传

交付物：

  • runStageSession
  • 运行时事件主链
  • 最小课堂运行闭环

阶段退出标准：

  • 阶段 3 生成结果可被运行
  • 运行事件可回传到 API 和持久化层

阶段 5：诊断补救主线打通

目标：

  • 建立“诊断 -> 缺口画像 -> 反向组课 -> 训练回挂”的第二条正式主线

范围：

  • diagnostic_remediation
  • GapProfile
  • RemediationStrategySelector
  • RemediationCoursePlan

交付物：

  • generateRemediationCourse
  • 诊断输入处理
  • 缺口画像产物
  • 补救课程装配链

阶段退出标准：

  • 能从真实诊断证据生成补救课程
  • 补救逻辑不是原课程重放
  • 训练结果能回挂画像

阶段 6：能力专题主线打通

目标：

  • 建立“题样/能力目标 -> 模式反推 -> 能力专题”的第三条正式主线

范围：

  • capability_reverse_design
  • CompositeKnowledgeChain
  • ProblemSolvingPattern
  • CapabilityUnit

交付物：

  • generateCapabilityCourse
  • 模式识别与能力反推
  • 四次投影链落地

阶段退出标准：

  • 能从样题或能力目标生成能力专题课程
  • 不依赖章节顺排
  • Pattern -> CapabilityUnit -> Scene -> PracticePlan 闭环成立

阶段 7：学科增强、编辑与导出

目标：

  • 在三条主线可跑后，提升主课专业度和生产可用性
  • 在课程主干稳定后，再系统增强课程质量、媒体质量与交互深度

顺序建议：

  1. 数学优先打通能力主线增强
  2. 英语优先打通诊断补救增强
  3. 语文优先打通正向组课与专题衔接增强

并行补充：

  • 老师局部修订
  • 局部重生成
  • 核心导出投影
  • 教学可视化与媒体表达增强
  • TTS / ASR 的教学化增强
  • 搜索与材料增强的精细策略

交付物：

  • 三门主课首批增强器
  • 关键对象局部编辑能力
  • PPT / HTML / 讲义 / 题单最小导出能力

阶段退出标准：

  • 每门主课至少有一条代表性路径达到可评审水准
  • 老师可做局部修订
  • 课程可导出为核心投影

阶段 8：平台外壳扩展

目标：

  • 在内核稳定后，再逐步补平台能力

范围：

  • 组织
  • 权限
  • 分发
  • 协作

阶段退出标准：

  • 平台外壳不反向污染课程内核
  • 组织与权限模型服务课程资产流转，而不是改写课程协议

5. 建议里程碑

建议以以下 4 个里程碑判断工程是否走在正确轨道上：

  1. 第一条正向课程可生成并运行
  2. 第一条补救课程可从诊断证据生成
  3. 第一条能力专题课可从样题生成
  4. 老师可对生成结果做局部修订

6. P0 执行收敛稿

本节用于把前文的阶段路线进一步收敛为“当前立刻可以开工的最小执行方案”。

核心原则只有一句话：

  • 先做出第一条稳定可运行的课程主干，再扩主线，再提质量

6.1 P0 只打通一条最小成功链

P0 不追求三条主线同时启动，而是只打通一条最小成功链：

  • learningSessionMode = forward_design
  • courseStrategy.courseMode = curriculum_aligned
  • assemblyMode = chapter_based
  • 课程形态先收敛为“教材同步正向组课”
  • 优先面向老师组课入口，不同时展开家长、学生、机构多入口

建议选择一条样例课程作为 P0 唯一基准样例，持续用它检验协议、装配链和运行链是否稳定。

推荐做法：

  1. 先固定单学科、单年级、单章节样例
  2. 先固定单课型，建议默认为“教材同步新授课”
  3. 先固定单投影消费形态，建议优先 ClassroomProjection

这里的重点不是“先把某门学科做满”，而是先找到一条结构最稳定、最容易复测的主干样例。

6.2 P0 的首个成功产物定义

P0 的“第一门成功课程”不以视觉效果判定，也不以内容华丽程度判定，而以是否形成完整主干产物判定。

建议至少满足以下结构结果：

  1. 能从一份稳定输入生成一个 Stage
  2. Stage 下至少生成一组有顺序的 Unit
  3. 每个 Unit 下至少生成一组可运行 Scene
  4. 每个 Unit 都能挂接对应的 PracticePlan
  5. 课程结果可被最小运行链消费，而不是只停留在静态 JSON

建议 P0 默认收敛为以下最小 Scene 编排骨架：

  • concept_explanation
  • worked_example
  • quiz_check
  • reinforcement_block

如果某章节需要更完整节奏，可再补：

  • review_feedback
  • summary_transfer

但这两类不应成为 P0 硬门槛。

6.3 P0 的最小输入约束

P0 不宜让输入协议一开始就承担过多自由度，建议把第一条正向样例输入收敛到以下范围：

  • subject
  • schoolStage
  • gradeLevel
  • chapter 或等价教材章节定位信息
  • sourceMaterials
  • learningSessionMode
  • courseStrategy
  • lessonIntent
  • assemblyMode
  • estimatedDuration 或等价时长约束

其中建议明确：

  1. learningSessionMode 固定为 forward_design
  2. assemblyMode 固定为 chapter_based
  3. lessonIntent 先收敛到教材同步新授，不在 P0 同时打开复习、讲评、补救、能力专题
  4. 学生画像、诊断证据、能力样题等输入在 P0 全部后置

这样做的目的，是先验证“标准教材同步课”能否被稳定表达，而不是一开始就把所有入口揉进同一轮实现。

6.4 P0 的最小产物链

P0 建议只冻结一条最小阶段产物链：

  1. GenerationInputV2
  2. StagePlan
  3. UnitPlan[]
  4. ScenePlan[]
  5. PracticePlan[]
  6. StageArtifact
  7. ClassroomProjection

对应关系应尽量清晰：

  • StagePlan 负责课程级目标、顺序和边界
  • UnitPlan 负责承接章节知识组织
  • ScenePlan 负责课堂片段组织
  • PracticePlan 负责课内/课后最小训练闭环
  • StageArtifact 负责沉淀为可保存、可回放、可再投影的课程资产

P0 当前不要求：

  • 完整导出体系
  • 丰富媒体资产体系
  • 复杂诊断回挂
  • 高自由度教师编辑态

6.5 P0 的模块建设顺序

建议按以下顺序推进，而不是多模块同时展开：

  1. packages/domain-model - 先冻结 Stage / Unit / Scene / PracticePlan 基础对象 - 先冻结最小枚举：learningSessionMode / AssemblyMode / UnitType / scenePattern
  2. packages/generation-contracts - 定义 P0 版 GenerationInputV2 - 定义 StagePlan / UnitPlan / ScenePlan / StageArtifact
  3. packages/course-kernel - 先只实现正向组课装配器 - 先只打通“教材章节 -> Unit -> Scene -> PracticePlan”
  4. apps/api - 提供最小组课入口 - 提供最小生成任务与结果读取能力
  5. packages/runtime-engine - 先消费 StageArtifact - 先支持最小 Scene 切换与检查点回传
  6. apps/web - 先提供最小创建、预览、播放闭环

packages/subject-enhancers 在 P0 中建议只保留轻量注入口，不承担首轮主路径复杂性。

6.6 P0 明确不做的事项

为了避免“刚开工就膨胀”，建议 P0 明确不做以下内容：

  1. 不同时打通 diagnostic_remediation
  2. 不同时打通 capability_reverse_design
  3. 不引入正式 GapProfile -> RemediationCoursePlan 实施链
  4. 不把 ProblemSolvingPattern 模式库接入首轮主链
  5. 不追求多媒体、动画、视频、TTS、ASR 的深度课程化
  6. 不先做复杂导出、复杂编辑器、复杂权限与协作
  7. 不为了未来扩展预埋过重抽象

这不是降低标准，而是确保第一条课程主干能先成立。

6.7 P0 的验收口径

P0 建议采用“结构稳定性优先”的验收口径。

建议至少满足以下检查项：

  1. 同一份输入可连续多次生成出结构合法的 StageArtifact
  2. 所有 Unit、Scene、PracticePlan 引用关系完整可校验
  3. 生成结果可进入最小运行链并完整走完
  4. 课程主干中不存在必须依赖人工补洞才能播放的断裂对象
  5. 至少有一条样例课程可被保存、重新读取并再次运行

如果上述 5 项尚未稳定成立，则不建议提前进入：

  • 深交互优化
  • 学科增强深挖
  • 多模态能力深化
  • 平台化外壳扩展

6.8 P0 到 P1 的抬升条件

只有当以下条件成立时，才建议把工程重心从 P0 抬升到 P1：

  1. forward_design 主链已稳定
  2. Stage -> Unit -> Scene -> PracticePlan 主骨架不再频繁改字段
  3. 运行链已能稳定消费生成结果
  4. 团队已能用同一份样例课程重复复测主流程

届时再继续推进：

  • GapProfile 与补救主线
  • ProblemSolvingPattern 与能力专题主线
  • 学科增强、编辑、导出与课程质量增强

7. 风险与控制点

7.1 最大风险

  1. 旧结构惯性过强，导致新工程骨架被旧实现拖回去
  2. 三条主线同时深做，导致第一阶段失焦
  3. UI 和平台壳层过早膨胀，反向污染课程协议
  4. 学科特例直接写入主骨架，导致内核失稳
  5. 在主骨架未稳定前，同时追求课程质量极致、复杂交互和多模态全覆盖，导致工程范围失控

7.2 控制点

  1. 每个阶段开始前，复核本阶段“必须做 / 明确不做”
  2. 所有新增模块先检查依赖方向，再写实现
  3. 三条主线始终共享同一套协议和阶段产物框架
  4. 任何新增页面都不得先于协议与阶段产物定义
  5. 质量增强、交互增强和 AI 深覆盖只能在课程主干生成稳定后逐步抬升优先级

8. 当前建议

当前建议正式以本路线图作为“从 0 开始重构”的工程推进基线，并遵循以下执行顺序：

  1. 先完成新工程骨架
  2. 再落领域模型与协议
  3. 再打通正向组课主骨架
  4. 再补运行内核、补救主线和能力主线

也就是说，真正的起点不是页面，也不是后台，而是：

  • 协议
  • 主骨架
  • 阶段产物
  • 可运行闭环