课程内核重构蓝图（V1）

1. 文档目的

本文档用于定义 OpenMAIC 下一阶段重构的课程内核蓝图。

本蓝图不以平台权限、组织模型、学校管理、分发运营为第一优先，而是先回答以下问题：

1. 什么是本系统最核心、最稳定、最值得长期投资的课程能力
2. 怎样建立一套可持续演化的课程生成与教学运行内核
3. 怎样支持学科特有增强，同时不把主干系统做散
4. 怎样先把语文、数学、英语三门主课做到专业，再扩展其他学科

本文档应作为后续课程内核重构、协议冻结、技术实现拆分和设计评审的核心基线。

2. 本次重构的核心判断

本次重构不应继续从“平台壳层”出发，而应从“课程内核”出发。

原因如下：

1. 当前最核心的产品价值来自课程生成与教学表达，而不是组织和权限包装
2. 学校、机构、老师、学生、家长等角色边界仍可能变化，过早固化会增加返工成本
3. 一旦课程内核足够强，平台化只是课程访问、分发、配置和协作方式的后置包装
4. 对中国应试教育场景而言，课程质量、训练强度、知识点覆盖和专业表达能力决定产品是否有真实竞争力

因此，本阶段建议把系统拆成：

• 课程内核
• 学科增强
• 运行与编辑
• 平台外壳

其中只有前三者进入当前重构主线，平台外壳后置。

2.1 系统本质定义

本系统不应被定义为：

• 课件生成器
• AI 文本生成工具
• 学校后台管理系统

本系统应被定义为：

• 课程工厂
• 教学运行内核

其中：

课程工厂

负责把主题、教材、知识点、教学目标、课程策略和学科增强配置，转化为可复用的课程主干资产。

它的目标不是一次性吐出一份内容，而是稳定地产出：

• 课程结构
• 教学表达
• 题目与训练
• 讲评与回补
• 可导出、可复用、可变体化的课程资产

教学运行内核

负责把课程资产转化为课堂过程与学习过程。

它的目标不是单纯播放页面，而是驱动：

• 讲授
• 互动
• 测验
• 讲评
• 强化训练

2.2 总体架构策略

本蓝图建议采用以下总体架构策略：

• 单引擎
• 多策略
• 多投影

单引擎

所有课程共享同一套课程生成和教学运行内核。

不论课程属于：

• exam_aligned
• curriculum_aligned
• exploratory
• bridge_course

都不应拆成多套独立系统。

多策略

课程差异不通过“重做一套系统”体现，而通过策略注入体现。

建议由以下对象共同决定课程差异：

• CourseStrategy
• SubjectEnhancer
• EngagementSkin
• GenerationOptions

多投影

同一门课程不应被绑定为单一页面形态，而应被视为一份可投影的课程主干资产。

在此基础上，系统可以派生出多个消费视图，而不需要重复生成多门“看似不同、实则同源”的课程。

3. 蓝图目标

3.1 业务目标

1. 产出真正可讲、可练、可测、可讲评、可强化训练的课程
2. 对中国小学、初中、高中的主课教学表达形成足够专业的支持
3. 允许老师进行局部修订、重生成和按教学目标调整课程
4. 支持课程从生成到播放再到训练闭环的完整流程
5. 在不破坏主干架构的前提下，同时支持考纲导向课程与学生自主探索课程

3.2 工程目标

1. 冻结课程内核领域模型
2. 统一课程生成协议
3. 抽出独立教学运行状态机
4. 建立学科增强的插件式边界
5. 明确课程协议与数据库表结构的分离
6. 为后续平台化和多端化预留边界

4. 非目标

当前蓝图不优先处理以下内容：

1. 学校组织架构和复杂权限模型
2. 多租户平台规则
3. 行政管理后台的完整设计
4. 所有学科一次性增强到位
5. 一次性替换全部旧实现

5. 顶层设计原则

5.1 课程优先于平台

先定义课程如何被设计、生成、讲授、训练和复用，再决定平台如何分发和管理课程。

5.2 知识点优先于页面

课程的本质不是 PPT 页面集合，而是围绕知识点、能力目标、讲解策略和训练路径组织的教学资产。

5.3 结构优先于内容填充

先有稳定的课程结构和教学结构，再由模型填充正文、题目、图示和媒体。

5.4 学科增强可插拔

主干课程内核必须稳定，学科特有表达通过增强层注入，而不是把所有特例写进主流程。

5.5 运行与生成分离

生成系统负责产出课程资产，运行系统负责驱动课堂与训练，不共享 UI 状态，不共享页面内部实现。

5.6 教学闭环优先

课程输出不应停留在“内容生成完成”，而要覆盖：

• 知识讲解
• 互动理解
• 测验检测
• 讲评纠错
• 强化训练

5.7 教学主干与表现包装分离

为兼顾中国考纲导向与学生注意力抓取，课程设计建议明确区分：

• 教学主干：知识点、能力目标、题型目标、训练路径、讲评逻辑
• 表现包装：故事化叙事、游戏化类比、角色设定、世界观皮肤、情境化表达

两者应同时存在，但不能相互替代。

约束如下：

1. 表现包装必须服务教学目标，而不是喧宾夺主
2. 知识点顺序、难度控制、训练目标和讲评逻辑由教学主干决定
3. 同一门课程允许切换不同表现包装，但不能改变其教学主干
4. 后续所有高趣味性课程都应建立在同一套课程协议之上

5.8 考纲课程与探索课程共存

课程内核不应被定义为“只生成考纲课程”。

系统应同时支持：

• 标准课程：围绕教材、考纲、考试和课堂教学组织
• 探索课程：围绕兴趣、自主学习、拓展主题和超前知识组织
• 衔接课程：围绕先修补足、跨阶段过渡和能力过桥组织

这三类课程共享同一套课程内核，但采用不同的课程策略。

5.9 课程策略优先于课程类型

课程生成时，不应先问“是不是某个学科”，而应先判断“这门课采用什么教学策略”。

原因：

1. 同一个学科内也会同时存在应试课、兴趣课和衔接课
2. 数学既可以生成月考强化课，也可以生成“0基础学习微积分”探索课
3. 课程策略决定考纲约束、难度组织、题型结构和表达方式

5.10 个体化补救优先于统一补课

真实学习过程中，很多学生会出现“以为自己听懂了，但并未真正掌握”的情况。

一旦某个关键知识点未被真正理解，后续内容又沿着先修链继续推进，就容易出现骨牌式掉队。

因此系统不应只支持“统一生成一门课”，还应支持：

• 基于测验与作答证据定位遗漏点
• 基于知识点依赖关系反推根因
• 基于个人情况重组补救课程
• 基于再训练与再检测形成掌握闭环

也就是说，课程内核必须同时支持：

• 正向组课
• 诊断驱动的反向组课

5.11 能力训练不等于知识点复述

在多数应试场景下，学生即使完成了知识点学习，也未必具备综合解题能力。

尤其面对：

• 跨章节综合题
• 多步推理题
• 变式迁移题
• 综合阅读与综合写作任务

系统不能只回到“逐个知识点再讲一遍”，而应支持：

• 从难题或题型反向拆解能力要求
• 串联跨章节知识点与解题链路
• 形成能力专题课程
• 通过变式训练固化综合能力

6. 课程内核范围

本蓝图中的课程内核，指以下能力集合：

1. 课程输入理解
2. 考纲与知识点对齐
3. 课程结构设计
4. 场景内容生成
5. 教学动作编排
6. 学科增强注入
7. 图文排版与可视化
8. 题目与训练生成
9. 课堂运行
10. 编辑修订与局部重生成
11. 导出与课程沉淀

7. 顶层架构

flowchart TD
    A["课程输入层"] --> B["课程设计与生成内核"]
    B --> C["学科增强层"]
    C --> D["课程装配层"]
    D --> E["教学运行层"]
    D --> F["编辑修订层"]
    D --> G["导出沉淀层"]
    H["平台外壳层"] --> D
    H --> E
    H --> G

8. 课程内核分层

8.1 输入层

负责接收和标准化：

• 主题
• 教材/PDF/讲义
• 学段、年级、学科、章节
• 课时目标
• 学生基础
• 训练强度
• 风格与语言要求
• 可选搜索和媒体策略
• 课程策略

8.2 课程结构层

负责将课程组织为稳定结构：

• Stage
• Unit
• Scene

这里建议将原先的二层结构升级为三层结构。

原因：

1. Stage 代表完整课程或一次课堂实例
2. Unit 代表章节、专题、课时段、考点簇
3. Scene 代表可讲授、可切换、可互动的最小教学场景

如果没有 Unit，后续语数英课程很容易把章节边界、训练边界和播放边界都堆进 Scene。

8.3 教学表达层

负责定义课程如何被讲出来，包括：

• SceneContent
• Action
• Asset
• ExplanationStrategy
• VisualizationPlan

8.4 训练评测层

负责定义课程如何被练、被测、被讲评，包括：

• AssessmentPlan
• Question
• PracticePlan
• RemediationPlan
• LearningProgress

8.5 学科增强层

负责在课程主干稳定的前提下，根据学科差异注入专有能力：

• 语文增强
• 数学增强
• 英语增强
• 其他学科的基线增强

8.6 运行层

负责课堂运行、互动、训练和恢复，不直接依赖 React 页面。

8.7 编辑层

负责老师进行结构修订、局部重生成和教学策略调整。

8.8 导出层

负责 PPT、HTML、讲义、练习册、题单和沉淀资产输出。

9. 核心领域模型

9.1 Stage

Stage 代表一门完整课程或一堂完整课堂实例，是课程聚合根。

建议职责：

1. 持有课程级元信息
2. 关联 Unit
3. 关联课程级学科配置和风格配置
4. 关联课程级 Agent 配置
5. 作为保存、复制、导出、复用的顶层对象
6. 显式持有课程策略和课程模式

9.2 Unit

Unit 不应被定义为教材章节的别名，而应被定义为“面向教学目标的课程组织块”。

它可以由不同编排起点生成，例如：

• 章节驱动
• 知识点驱动
• 易错点驱动
• 讲评驱动
• 专题训练驱动

建议字段：

• id
• stageId
• title
• order
• unitType
• knowledgePointIds
• teachingObjectives
• estimatedDurationSec
• sceneIds
• assessmentPlanId
• practicePlanId
• assemblyMode
• sourceRefs

建议职责：

1. 承接章节和考点结构
2. 聚合一组相互关联的 Scene
3. 作为训练和讲评的自然边界
4. 允许同一课程中同时存在“章节型 Unit”和“知识点型 Unit”

9.2.1 UnitType 建议

建议为 Unit 增加显式类型，用于统一编排逻辑：

• chapter_unit
• knowledge_unit
• topic_unit
• review_unit
• remediation_unit
• sprint_unit
• capability_unit

9.2.2 AssemblyMode 建议

建议为课程或 Unit 显式标记其装配方式：

• chapter_based
• knowledge_based
• capability_based
• mixed

这样系统就可以支持：

1. 按教材章节组织课程
2. 从指定知识点反向组织一门精讲课
3. 从难题或能力目标反向组织能力专题课
4. 对同一课程中的某组知识点单独抽出形成专题或补救课

9.3 Scene

Scene 仍然是课堂运行时最小切换单元。

建议类型统一为：

• slide（课件页）
• quiz（测验场景）
• interactive（交互场景）
• pbl（项目式学习场景）

但建议额外加入 scenePattern 概念，描述其教学意图，例如：

• concept_explanation
• worked_example
• guided_reading
• interactive_drill
• quiz_check
• review_feedback
• reinforcement_block

这样能避免单靠 scene.type 表达过粗。

9.4 KnowledgePoint

建议把 KnowledgePoint 提升为课程内核的一等对象。

原因：

1. 中国考纲场景天然围绕知识点组织
2. 训练、测验、讲评、错因分析都需要回挂到知识点
3. 学科增强的很多差异，本质上是知识点表达差异

建议字段：

• id
• subject
• stage
• grade
• chapter
• title
• description
• tags
• prerequisites
• relatedPoints
• difficultyBand
• abilityTargets
• examRelevance

9.4.1 CompositeKnowledgeChain

建议把跨章节、跨知识点协同解题所需的复合知识链定义为正式对象。

它不描述单个知识点，而描述一类综合题背后需要被联合调用的知识网络。

建议字段：

• id
• subject
• title
• knowledgePointIds
• dependencyEdges
• bridgeConcepts
• commonTransitions
• difficultyBand
• targetProblemTypes

9.4.2 ProblemSolvingPattern

ProblemSolvingPattern 用于描述某类难题的标准解题结构，而不是具体某一道题。

建议采用“中度正式化协议”，即核心对象强约束、学科细节弱约束、装配链路显式化，但不在本阶段做过重本体化。

建议字段按 5 层组织：

1. identity - id - subject - name - patternType - version - status
2. applicability - applicableProblemTypes - gradeBands - difficultyBand - prerequisiteLevel - entrySignals - triggerContexts
3. cognitiveKernel - requiredKnowledgeChains - requiredCapabilities - reasoningSteps - keyDecisionPoints - commonMistakes - misconceptionSignals - successCriteria
4. trainingHints - variantAxes - recommendedTraining - assessmentFocus - remediationHints
5. assemblyHints - preferredScenePatterns - masterySignals

9.4.2.1 协议边界

ProblemSolvingPattern 的定位是“能力模式原子”，而不是课时对象、页面对象或题目对象。

应坚持以下边界：

1. 不直接拥有 Scene
2. 不直接拥有具体题目实例
3. 不直接定义 UI 表现
4. 可以被多个 CapabilityUnit 复用
5. 可以引用 CompositeKnowledgeChain，但不等同于知识链本身

其中：

• preferredScenePatterns 只表示装配建议，不是对 Scene 的硬约束
• masterySignals 只定义模式层“算学会了什么”，不能替代 CapabilityUnit 的检查点规划，也不能替代 PracticePlan 的检查点设计

9.4.2.2 reasoningSteps 结构化要求

reasoningSteps 不建议长期停留在纯文本数组。后续协议冻结时，建议升级为结构化步骤对象，至少包含：

• stepId
• goal
• requiredSignals
• stepAction
• expectedOutput
• commonFailureModes

每个 reasoningStep 应具备可观察的阶段性产出或判断结果，便于后续：

1. 投影为步骤拆解类 Scene
2. 生成步骤练习与变式训练
3. 回挂错因与掌握检查点

9.4.3 CapabilityUnit

CapabilityUnit 是围绕某种综合能力而不是单章节知识点组织的 Unit 形态。

例如：

• 数学压轴题拆解专题
• 英语阅读长难句与推断题专题
• 语文综合阅读与表达专题

它适合承载：

• 跨章节知识串联
• 多步推理讲解
• 解法模式对比
• 变式强化训练

9.4.3.1 教学化裁剪原则

CapabilityUnit 不应被理解为把 ProblemSolvingPattern 原样搬进课堂，而应被理解为对 Pattern 做“教学化裁剪”后的能力专题单元。

这意味着同一个 Pattern 在不同场景下可以被不同范围地覆盖，例如：

• 只取部分 reasoningSteps
• 只突出某些 commonMistakes
• 只围绕某几个 variantAxes 组织训练

建议 CapabilityUnit 显式具备以下组织信息：

• patternRefs
• knowledgeChainRefs
• targetCapability
• coverageScope
• errorFocus
• masteryCheckpointPlan

其中 coverageScope 用于表达“本次单元到底覆盖 Pattern 的哪些部分”，避免 CapabilityUnit 退化成模式文档的课堂翻译。

9.4.3.2 四次投影链

建议把以下链路正式定义为四次投影，而不是四次复制：

ProblemSolvingPattern -> CapabilityUnit -> Scene -> PracticePlan

各层职责如下：

1. ProblemSolvingPattern - 定义这类题如何识别、如何思考、常错在哪里、如何变式
2. CapabilityUnit - 把模式组织成可讲、可练、可测的教学单元
3. Scene - 把能力单元投影成课堂运行片段
4. PracticePlan - 把场景后的训练闭环结构化，并可回挂到诊断与补救

建议把这条链理解为：

• Pattern 定义会题方式
• CapabilityUnit 定义教法组织
• Scene 定义课堂承载
• PracticePlan 定义训练闭环

9.4.3.3 能力单元的推荐 Scene 组合

对 capability_unit 而言，建议优先支持以下 scenePattern 组合作为默认模板：

• pattern_recognition
• step_decomposition
• worked_example
• error_comparison
• variant_transfer
• checkpoint_quiz

该组合表示推荐模板，而不是固定流程。系统应允许根据学科、年级、课时和教学目标进行裁剪。

9.5 AssessmentPlan

AssessmentPlan 描述某个 Unit 或某组 Scene 的测验设计。

应包含：

• 题型分布
• 题量
• 难度分布
• 知识点覆盖
• 评分方式
• 讲评策略

9.6 PracticePlan

PracticePlan 描述强化训练设计。

应包含：

• 练习目标
• 题组结构
• 变式策略
• 错因回补策略
• 训练强度
• 是否分层

9.6.1 与能力模式的关系

PracticePlan 不应被理解为课堂结束后的附属题单，而应是对 CapabilityUnit 和 Scene 的训练性投影。

其输入应显式继承：

• coverageScope
• reasoningSteps
• variantAxes
• commonMistakes
• assessmentFocus
• masteryCheckpointPlan

建议优先组织为以下训练段：

1. foundation_fixation
2. single_axis_variation
3. multi_axis_combination
4. error_correction
5. mastery_check

这意味着 PracticePlan 的重点不是“把课堂题再出几道”，而是围绕步骤固化、变式迁移、错因回补和掌握检查来设计训练闭环。

9.7 RemediationPlan

RemediationPlan 描述测验后如何回到讲解和再练。

这是课程内核区别于普通课件生成工具的关键对象之一。

9.8 EngagementSkin

建议把趣味性、故事性、类比风格提升为课程内核中的正式可选对象，而不是零散提示词技巧。

EngagementSkin 不负责定义知识点本身，只负责定义课程外在表达方式。

建议字段：

• id
• name
• themeType
• tone
• personaHints
• worldSetting
• allowedMetaphors
• forbiddenMetaphors
• visualStyleHints
• interactionStyleHints
• ageFit

建议支持的 themeType 例如：

• exam_strict
• story_based
• game_based
• competition_based
• historical_immersion
• life_scenario_based

9.8.1 设计约束

EngagementSkin 必须受到以下约束：

1. 不得改写知识点本体
2. 不得破坏考纲顺序与题型目标
3. 不得引入与学科逻辑冲突的类比
4. 必须可被老师关闭或替换

9.9 CourseStrategy

建议把 CourseStrategy 作为课程内核中的正式顶层对象，用于定义课程采用什么样的教学组织与生成约束。

它不直接描述课程内容，而是描述课程应当“如何被生产”。

建议字段：

• courseMode
• examAlignmentLevel
• curriculumDependency
• knowledgeScope
• practiceIntensity
• visualizationPriority
• explorationTolerance
• assessmentRequirement
• remediationRequirement

9.9.1 职责边界

建议将以下几个概念明确分责，避免在蓝图后续章节中混写：

• CourseStrategy：回答课程在什么总约束下被生产
• LessonIntent：回答这一轮课主要要完成什么教学任务
• AssemblyMode：回答系统按什么组织逻辑装配内容
• UnitType：回答当前 Unit 在课程结构中扮演什么组织角色

可以概括为：

• CourseStrategy = 约束
• LessonIntent = 目标
• AssemblyMode = 编排
• UnitType = 结构

其中：

1. CourseStrategy 默认是 Stage 级对象
2. LessonIntent 至少是 Stage 级，可允许 Unit 级局部覆盖
3. AssemblyMode 是装配器视角
4. UnitType 是装配结果视角

9.9.2 CourseMode 建议

建议显式支持以下模式：

• exam_aligned
• curriculum_aligned
• exploratory
• bridge_course

9.9.3 四类课程说明

exam_aligned

适用于：

• 中高考导向课程
• 月考、单元测、专题训练、讲评课

特点：

• 强考纲约束
• 强题型与难度控制
• 强训练闭环

curriculum_aligned

适用于：

• 教材同步课
• 常规课堂教学
• 单元讲授与巩固

特点：

• 强教材与章节对齐
• 不一定高强度应试
• 更强调课堂讲授与基础巩固

exploratory

适用于：

• 学生兴趣驱动学习
• 课外拓展
• 非考纲专题
• 高阶概念启蒙

例如：

• 0基础学习微积分
• AI 入门
• 古文明中的数学思想

特点：

• 不强制要求考纲映射
• 更重视入门路径、概念直觉、图示和理解兴趣

bridge_course

适用于：

• 学段衔接
• 先修补足
• 跨章节、跨能力的承接课

例如：

• 初中函数到高中导数前置理解
• 高中极限直觉课
• 英语语法衔接强化课

特点：

• 重视先修知识补齐
• 重视能力过桥和概念过渡
• 既可带训练，也可偏讲解

能力导向装配说明

综合难题训练不一定需要新增顶层 courseMode。

更建议在现有 CourseStrategy 下，通过以下组合显式表达：

• LessonIntent = 综合能力专题
• AssemblyMode = capability_based
• UnitType = capability_unit

这样可以在不膨胀顶层策略枚举的前提下，支持综合题与难题训练主线。

9.9.4 设计结论

所有课程都应归属某个 CourseStrategy，而不能默认都走“考纲课”逻辑。

9.9.5 组课入口模式

除 CourseStrategy / LessonIntent / AssemblyMode / UnitType 外，建议单独引入“组课入口模式”概念，用于承载当前蓝图已明确的三条正式主线：

1. 正向组课
2. 诊断驱动的反向组课
3. 能力导向的反向组课

它回答的不是“课程本身属于哪类策略”，而是“这次课程是从哪个入口被装配出来的”。

本蓝图当前输入协议中暂用 learningSessionMode 字段承载该语义；从语义上看，它更接近 AssemblyEntryMode。

因此建议在后续协议冻结时坚持以下边界：

• learningSessionMode / AssemblyEntryMode：组课入口模式
• courseMode：课程生产模式

两者不能混用，否则会把主线入口和课程策略混成同一层概念。

9.10 LearnerStateSnapshot

建议把学习者当前状态定义为课程内核中的正式对象，而不是零散附加信息。

它用于描述学生当前“能否跟上、哪里可能断裂、接下来应如何安排”。

建议字段：

• learnerId
• subject
• schoolStage
• gradeLevel
• currentMastery
• suspectedWeakPoints
• prerequisiteRiskPoints
• paceRiskLevel
• attentionRiskLevel
• recentAssessmentRefs
• recentInteractionSignals

9.11 DiagnosticAssessment

DiagnosticAssessment 不只是一次做题与判分，而是一次定位学习断点的诊断过程。

它应回答：

1. 哪些题错了
2. 错误回挂到哪些知识点
3. 哪些错误只是表层失误，哪些错误暴露了先修缺口
4. 当前是否存在“看似听懂、实则未掌握”的风险

建议字段：

• id
• diagnosticType
• questionSetId
• knowledgeCoverage
• abilityCoverage
• confidenceCollectionMode
• resultSummary
• gapProfileId

9.12 GapProfile

GapProfile 用于沉淀诊断后识别出的学习缺口画像。

它不应只记录“错题列表”，而应记录“为什么会跟不上”。

建议字段：

• id
• learnerId
• knowledgeGaps
• prerequisiteGaps
• misconceptions
• errorPatterns
• falseMasterySignals
• priorityLevel
• recommendedEntryPoint
• estimatedRecoveryPath

建议职责：

1. 标记当前最需要先补的知识点
2. 区分主问题和伴随问题
3. 区分内容不会、方法不会、审题失误和表达失误
4. 为后续反向组课提供明确起点

9.12.1 多维分类建议

GapProfile 不建议设计为单标签对象，更建议采用“主类 + 表现特征 + 证据来源 + 决策建议”的多维结构。

缺口主类

建议优先支持：

• prerequisite_fracture
• local_concept_gap
• mastery_imbalance
• procedure_gap
• pattern_gap
• comprehension_gap
• expression_gap

其中 false_mastery 更适合被定义为状态信号或证据标记，而不是稳定主类本身。

表现特征

建议优先支持：

• single_breakpoint
• multi_point_scattered
• boundary_unstable
• slow_but_correct
• guessing_tendency
• transfer_failure

证据来源

建议至少记录以下证据来源，用于提升诊断可信度：

• 做题证据
• 课堂互动证据
• 跟做 / 独做对比证据
• 口头 / 书面对比证据

尤其对于 falseMasterySignals，若缺少证据来源，容易把“暂时不熟练”误判为“看似会、实则不会”。

9.12.2 分类判断原则

建议采用如下默认判断原则：

1. 若错误沿先修链可追到明确主断点，优先判为 prerequisite_fracture
2. 若同一知识点在多种基础题中持续不稳，优先判为 local_concept_gap
3. 若正确率高度离散，优先判为 mastery_imbalance
4. 若基础概念能认出，但固定卡在解题流程步骤上，优先判为 procedure_gap
5. 若单点会、综合题不会整合，优先判为 pattern_gap
6. 若换个表述就错、条件抽取不稳，优先判为 comprehension_gap
7. 若口头能说但书面失分明显，优先判为 expression_gap

这些判断用于形成诊断画像，不直接等同于最终补救路径。

9.12.3 诊断画像与补救决策分层

GapProfile 负责回答“为什么不会”，RemediationStrategySelector 负责回答“这次怎么补”。

两者之间应是推荐关系，而不是直接等号关系。

例如：

• prerequisite_fracture 通常推荐 rollback
• pattern_gap 通常更接近 hybrid
• mastery_imbalance 更可能触发 recompose

但这些都应视为默认建议，而不是强绑定规则。

9.13 RemediationStrategySelector

RemediationStrategySelector 用于在诊断完成后，决定系统应采用哪一种补救路径。

它的意义是把“发现问题”和“如何补救”明确分层，避免系统一诊断完就粗暴重组课程。

建议职责：

1. 判断是否存在明确主断层
2. 判断问题是单点断裂还是多点掌握不均
3. 判断应采用回退补缺、知识链重组，还是混合路径
4. 输出补救起点、补救范围和补救编排约束

建议进一步区分：

• 正式补救主线
• 轻量干预策略

其中正式补救主线继续保持：

建议支持的 RemediationMode：

• rollback
• recompose
• hybrid

轻量干预可单独表达为：

• practice_only

practice_only 不建议与正式补救主线并列为第三类课程路径，而更适合作为“内容大体已会、当前主要是不稳或需要再练”时的轻干预决策。

rollback

从断层开始处回退，沿原先修链路补缺，再逐步回到当前学习位置。

适用于：

• 存在明确主断点
• 后续问题主要由上游知识缺失引起
• 需要快速恢复跟课能力

recompose

不直接按原章节回退，而是根据诊断结果重梳知识点顺序，重新编排一条更适合当前学生的学习路径。

适用于：

• 薄弱点分散
• 掌握深浅不一
• 原课程顺序不再是最佳补救顺序

hybrid

先局部回退修复主断层，再对剩余分散问题做知识链重组与强化训练。

这是本蓝图建议的默认策略。

9.14 RemediationCoursePlan

RemediationCoursePlan 用于把 GapProfile 转化为一条可执行的补救学习路径。

它不是普通课程计划的缩短版，而是针对缺口定制的回补计划。

建议字段：

• id
• gapProfileId
• remediationMode
• rollbackEntryPoint
• recompositionConstraints
• targetKnowledgePoints
• backfillUnits
• bridgeUnits
• practiceBlocks
• masteryCheckpoints
• exitCriteria

这里建议明确支持两类面向学生课后补救的正式路径：

1. 断层回退型
2. 知识链重组型

前者强调“从哪里掉队，就从哪里补起”； 后者强调“根据诊断结果重新编排更适合当前学生的课程”。

9.15 MasteryCheckpoint

MasteryCheckpoint 用于在学习过程中持续验证“是否真的掌握”。

它的意义在于防止学生因为流程继续推进而掩盖真实掉队情况。

建议字段：

• id
• checkpointType
• knowledgePointIds
• difficultyBand
• passCriteria
• fallbackAction

设计约束：

1. 检查点不应只出现在课程末尾
2. 对关键先修点应设置微型检查点
3. 未通过检查点时，系统应能回退到补救路径，而不是强行推进

10. 课程输入模型

建议在原 GenerationInput 基础上扩展，形成更强的教学约束输入。

interface GenerationInputV2 {
  requestId?: string;
  subject: 'chinese' | 'math' | 'english' | 'generic';
  schoolStage: 'primary' | 'junior' | 'senior';
  gradeLevel?: string;
  term?: string;
  chapter?: string;
  requirement: string;
  courseStrategy?: CourseStrategyInput;
  sourceMaterials?: SourceMaterial[];
  curriculumStandard?: CurriculumStandardRef[];
  lessonIntent?: LessonIntent;
  learnerProfile?: LearnerProfile;
  learnerStateSnapshot?: LearnerStateSnapshotInput;
  diagnosticContext?: DiagnosticContextInput;
  remediationPreference?: RemediationPreferenceInput;
  examConstraint?: ExamConstraint;
  learningSessionMode?: 'forward_design' | 'diagnostic_remediation' | 'capability_reverse_design';
  assemblyMode?: 'chapter_based' | 'knowledge_based' | 'capability_based' | 'mixed';
  selectedKnowledgePoints?: string[];
  targetProblemSet?: ProblemSampleInput[];
  targetCapability?: CapabilityGoalInput;
  engagementSkin?: EngagementSkinInput;
  generationOptions?: GenerationOptions;
  subjectOptions?: SubjectSpecificOptions;
  providerOptions?: ProviderSelectionOptions;
  locale?: string;
}

这里的 learningSessionMode 当前承担“组课入口模式”的语义，用于区分：

• forward_design
• diagnostic_remediation
• capability_reverse_design

后续协议冻结时，可继续保留该字段名，也可重命名为更贴近语义的 assemblyEntryMode，但应始终与 CourseStrategy.courseMode 分层。

建议新增几个关键对象：

CurriculumStandardRef

用于指向考纲、教材章节、课程标准条目。

CourseStrategyInput

用于指定课程属于哪种课程策略。

建议字段：

• courseMode
• targetExamContext
• targetCurriculumContext
• learningOrientation
• practiceIntensity
• explorationLevel

LessonIntent

描述本节课重点是：

• 新授
• 复习
• 专题
• 讲评
• 补救回补
• 冲刺训练
• 综合能力专题

它回答的是“这一轮课主要解决什么教学任务”，而不是“课程属于哪一类生产策略”。

建议默认按以下顺序做决策：

组课入口模式 -> CourseStrategy -> LessonIntent -> AssemblyMode -> UnitType

这样可以把主线入口、课程总约束、当前教学目标、装配方式和最终单元形态严格分层。

LearnerStateSnapshotInput

用于传入学生当前掌握情况、近期学习状态和潜在掉队风险。

DiagnosticContextInput

用于传入诊断驱动反向组课所需证据，例如：

• 最近测验结果
• 错题集合
• 信心自评
• 互动卡顿点
• 已知薄弱知识点

当存在 DiagnosticContextInput 时，系统应允许优先走“反向组课”路径，而不是默认按章节顺排。

RemediationPreferenceInput

用于表达老师、家长或系统当前更偏向哪种补救方式。

建议支持：

• auto
• rollback_first
• recompose_first
• hybrid_preferred

默认建议为 auto，由系统根据 GapProfile 自动判定。

ProblemSampleInput

用于传入目标难题、压轴题、综合题样本，供系统反向拆解能力要求。

CapabilityGoalInput

用于传入希望重点训练的综合能力，例如：

• 多步函数综合题
• 几何证明压轴题
• 阅读推断题
• 综合写作表达

ExamConstraint

描述本次课程的应试导向约束，例如：

• 偏概念理解
• 偏题型训练
• 偏考试讲评
• 偏基础巩固
• 偏拔高训练

在 exploratory 模式下，ExamConstraint 可以为空或降级为弱约束。

EngagementSkinInput

描述课程希望采用的外在表达包装，例如：

• 王者荣耀类比
• 古风叙事
• 校园闯关
• 竞赛挑战
• 生活情景化

它应被视为“表现层偏好”，而不是教学主干约束。

SubjectSpecificOptions

用于传入可选学科增强开关。

10.1 三条主线的准正式输入样例

以下样例用于在进入实现前统一请求边界。它们是“准正式输入样例”，用于约束字段组合，不代表所有字段都必须一次性实现。

10.1.1 样例 A：正向组课输入

const inputA: GenerationInputV2 = {
  subject: 'math',
  schoolStage: 'senior',
  gradeLevel: 'grade_10',
  term: 'fall',
  chapter: '函数单调性',
  requirement: '生成一节教材同步的新授课，包含基础巩固与小测',
  learningSessionMode: 'forward_design',
  courseStrategy: {
    courseMode: 'curriculum_aligned',
    targetCurriculumContext: '人教版高中数学必修',
    learningOrientation: 'classroom_teaching',
    practiceIntensity: 'medium',
    explorationLevel: 'low',
  },
  lessonIntent: '新授',
  assemblyMode: 'chapter_based',
  curriculumStandard: [{ id: 'curriculum_ref_001' }],
  sourceMaterials: [{ type: 'textbook_chapter', ref: 'chapter_ref_001' }],
  examConstraint: { focus: '基础巩固' },
  engagementSkin: { themeType: 'exam_strict' },
  locale: 'zh-CN',
};

关键特征：

• 不依赖 diagnosticContext
• 不依赖 targetProblemSet
• 以教材章节、课程标准和老师目标为主输入

10.1.2 样例 B：诊断驱动反向组课输入

const inputB: GenerationInputV2 = {
  subject: 'english',
  schoolStage: 'junior',
  gradeLevel: 'grade_8',
  requirement: '根据最近测验结果生成一条课后补救学习路径',
  learningSessionMode: 'diagnostic_remediation',
  courseStrategy: {
    courseMode: 'bridge_course',
    learningOrientation: 'remediation',
    practiceIntensity: 'medium_high',
    explorationLevel: 'low',
  },
  lessonIntent: '补救回补',
  assemblyMode: 'knowledge_based',
  learnerStateSnapshot: {
    currentMastery: 'unstable',
    suspectedWeakPoints: ['reading_inference', 'long_sentence_parse'],
    prerequisiteRiskPoints: ['complex_sentence_structure'],
  },
  diagnosticContext: {
    recentAssessmentRefs: ['exam_202605'],
    wrongQuestionRefs: ['q_101', 'q_118', 'q_124'],
    confidenceSignals: ['low_confidence_on_independent_reading'],
    interactionSignals: ['guided_ok_independent_fail'],
  },
  remediationPreference: 'auto',
  engagementSkin: { themeType: 'life_scenario_based' },
  locale: 'zh-CN',
};

关键特征：

• 以 diagnosticContext + learnerStateSnapshot 为主输入
• 允许系统自动做 GapProfile 与补救路径判断
• 不要求先按教材章节顺排

10.1.3 样例 C：能力导向反向组课输入

const inputC: GenerationInputV2 = {
  subject: 'math',
  schoolStage: 'senior',
  gradeLevel: 'grade_12',
  requirement: '围绕函数最值综合题生成一节压轴题能力专题课',
  learningSessionMode: 'capability_reverse_design',
  courseStrategy: {
    courseMode: 'exam_aligned',
    targetExamContext: '高考数学压轴题',
    learningOrientation: 'capability_training',
    practiceIntensity: 'high',
    explorationLevel: 'low',
  },
  lessonIntent: '综合能力专题',
  assemblyMode: 'capability_based',
  targetCapability: {
    id: 'cap_goal_math_extremum',
    name: '函数最值综合题',
  },
  targetProblemSet: [
    { id: 'sample_001', source: 'mock_exam', problemType: 'function_extremum' },
    { id: 'sample_002', source: 'past_exam', problemType: 'function_extremum' },
  ],
  examConstraint: { focus: '拔高训练' },
  engagementSkin: { themeType: 'competition_based' },
  locale: 'zh-CN',
};

关键特征：

• 以 targetCapability + targetProblemSet 为主输入
• 允许不显式提供教材章节
• 目标是能力模式反推，而不是章节复习

10.2 输入样例的字段组合规则

建议至少冻结以下组合规则：

1. forward_design - chapter / curriculumStandard / sourceMaterials 应至少有一类主输入 - diagnosticContext 和 targetProblemSet 通常为空
2. diagnostic_remediation - diagnosticContext 或 learnerStateSnapshot 至少存在其一，最好同时存在 - remediationPreference 可选，但推荐显式传入
3. capability_reverse_design - targetCapability 与 targetProblemSet 至少存在其一 - assemblyMode 默认应倾向 capability_based

这些规则的目的不是限制灵活性，而是避免三条主线在请求入口层就互相污染。

11. 课程生成流水线

本次蓝图建议将课程生成明确拆成十个阶段。

11.1 输入理解

职责：

• 读取主题与材料
• 识别学科、学段、章节、语言约束
• 判断课型
• 判断课程策略
• 提取老师需求和训练意图

产出：

• GenerationContext

11.1.1 三入口生成原则

课程生成建议显式支持三类入口：

1. 正向组课
2. 诊断驱动的反向组课
3. 能力导向的反向组课

正向组课

从主题、教材、章节、教学目标出发，正向装配课程。

诊断驱动的反向组课

从测验、错题、掌握度和先修缺口出发，先定位问题，再反向组织课程。

能力导向的反向组课

从难题样本、目标题型或目标能力出发，先拆解综合能力要求，再反向组织课程。

这三类入口共享同一课程内核，但起始输入不同。

11.1.2 三条主线的端到端装配样例

以下样例用于验证当前蓝图中的协议是否闭环。它们是“装配参考样例”，不是固定模板。

样例 A：正向组课

场景示例：

• 高一数学
• 教材同步
• 主题：函数单调性
• 目标：完成一节新授 + 基础巩固课

输入侧重点：

• learningSessionMode = forward_design
• CourseStrategy.courseMode = curriculum_aligned
• LessonIntent = 新授
• AssemblyMode = chapter_based
• 主要输入来自教材章节、课程标准、老师教学目标

关键判断：

1. 主线入口为正向组课，不需要先做诊断画像
2. 课程总约束以教材同步和课堂讲授为主
3. 该课以章节推进为主，不需要能力专题化重组

中间产物：

• CurriculumAlignmentResult：定位到教材章节和目标考点
• KnowledgeGraph：拆出函数单调性的定义、图像判断、解析式判断、区间语言表达
• UnitPlan[]：形成 1 个 chapter_unit，必要时附带 1 个 review_unit

装配结果：

• Stage
• 面向教材同步课堂
• Unit
• chapter_unit
• assemblyMode = chapter_based
• Scene
• concept_explanation
• worked_example
• interactive_drill
• quiz_check
• review_feedback
• PracticePlan
• 以基础定型和单点巩固为主
• 训练强度中等
• 错因回补以当前知识点为中心

验证重点：

这个样例验证“章节驱动 + 教材同步 + 常规课堂”可以不依赖诊断和能力反推，仍然完整走通 Stage -> Unit -> Scene -> PracticePlan。

样例 B：诊断驱动的反向组课

场景示例：

• 初二英语
• 学生课后补缺
• 现象：阅读推断题和长难句题反复出错
• 目标：定位断点并生成一条补救学习路径

输入侧重点：

• learningSessionMode = diagnostic_remediation
• CourseStrategy.courseMode = bridge_course
• LessonIntent = 补救回补
• AssemblyMode = knowledge_based 或 mixed
• 输入包含 DiagnosticContextInput、LearnerStateSnapshotInput、近期错题和作答证据

关键判断：

1. 先做 DiagnosticAssessment，而不是先按教材章节出课
2. 根据 GapProfile 判断主问题是先修断层、掌握不均，还是步骤与审题问题
3. 由 RemediationStrategySelector 决定走 rollback、recompose、hybrid 还是 practice_only

中间产物：

• GapProfile
• 例如主类为 procedure_gap + comprehension_gap
• 表现特征为 transfer_failure
• 伴随 falseMasterySignals
• RemediationCoursePlan
• 明确补救起点、范围、检查点和退出条件
• UnitPlan[]
• 形成 1 个或多个 remediation_unit
• 必要时夹带小型 review_unit

装配结果：

• Stage
• 面向个体化补救学习
• Unit
• remediation_unit
• assemblyMode = knowledge_based 或 mixed
• Scene
• concept_explanation
• guided_reading
• interactive_drill
• quiz_check
• review_feedback
• reinforcement_block
• PracticePlan
• 以错因回补、步骤补齐和掌握检查为主
• 可带 practice_only 轻干预块
• 训练结果需回挂到 GapProfile

验证重点：

这个样例验证“诊断画像”和“补救策略选择”是分层的，课程不是错题重讲，而是基于缺口画像重组。

样例 C：能力导向的反向组课

场景示例：

• 高三数学
• 压轴题能力训练
• 目标：围绕函数最值综合题做一节能力专题课

输入侧重点：

• learningSessionMode = capability_reverse_design
• CourseStrategy.courseMode = exam_aligned
• LessonIntent = 综合能力专题
• AssemblyMode = capability_based
• 输入包含 ProblemSampleInput[]、CapabilityGoalInput

关键判断：

1. 起点不是教材章节，也不是当前错题，而是目标难题样本
2. 系统先反推 CompositeKnowledgeChain[] 和 ProblemSolvingPattern[]
3. 组装核心不应是“章节复习”，而应是“能力模式教学化裁剪”

中间产物：

• CompositeKnowledgeChain
• 串联函数性质、导数、单调区间、最值条件转换
• ProblemSolvingPattern
• 例如 function_extremum_transform
• CapabilityUnit
• coverageScope 只覆盖本轮训练真正需要的步骤、错因和变式轴

装配结果：

• Stage
• 面向能力专题训练
• Unit
• capability_unit
• assemblyMode = capability_based
• Scene
• pattern_recognition
• step_decomposition
• worked_example
• error_comparison
• variant_transfer
• checkpoint_quiz
• PracticePlan
• 围绕 reasoningSteps + variantAxes + commonMistakes
• 组织基础定型、单轴变式、多轴混合和掌握检查

验证重点：

这个样例验证“Pattern -> CapabilityUnit -> Scene -> PracticePlan”四次投影链可以独立于章节顺序成立，适合承载综合题和压轴题训练主线。

样例收敛结论

通过这三条样例，可以得到以下判断：

1. 三条正式主线可以共用同一课程内核，而不需要三套系统
2. 三条主线的真正差异主要来自入口模式、输入证据和装配策略，而不是运行时模型不同
3. CourseStrategy / LessonIntent / AssemblyMode / UnitType 的分层在三条样例里都可以成立
4. GapProfile、RemediationStrategySelector、ProblemSolvingPattern、CapabilityUnit 已具备进入“协议冻结稿”的条件
5. 后续若要进入实现阶段，优先应围绕这三条样例做数据协议和模块边界映射

11.2 考纲与教材对齐

职责：

• 把输入映射到考纲条目
• 把输入映射到教材章节
• 标记核心考点和能力目标

约束说明：

1. exam_aligned 模式下，此阶段为强约束阶段
2. curriculum_aligned 模式下，此阶段为中强约束阶段
3. exploratory 模式下，此阶段可降级为“先修知识与主题参考阶段”
4. bridge_course 模式下，此阶段应同时关注前置知识和目标知识之间的连接关系

产出：

• CurriculumAlignmentResult

11.3 知识点拆解

职责：

• 形成 KnowledgePoint[]
• 建立先修关系和逻辑顺序
• 标注重难点和易错点

在 exploratory 模式下，应额外强调：

• 概念进入门槛
• 抽象层级控制
• 直觉解释优先级

产出：

• KnowledgeGraph

11.3.1 诊断驱动下的知识点反推

在 diagnostic_remediation 场景下，知识点拆解不应只做“当前错了什么”的表层映射。

还应额外完成：

1. 从错题反推相关知识点
2. 从相关知识点继续反推关键先修点
3. 识别是“当前点不会”，还是“上游基础没补”
4. 标记哪些知识点必须回退重讲，哪些知识点只需再练

11.3.2 能力导向下的复合知识链反推

在 capability_reverse_design 场景下，系统应从目标难题或题型反推：

1. 该类题需要哪些知识点协同工作
2. 哪些知识点之间存在关键过渡关系
3. 解题链路中的关键转折步骤是什么
4. 应如何把分散在不同章节的知识重新串联为一条能力训练路径

产出不应只是 KnowledgePoint[]，还应形成：

• CompositeKnowledgeChain[]
• ProblemSolvingPattern[]

11.4 Unit 规划

职责：

• 把知识点簇组织为 Unit
• 决定各 Unit 的教学目标和训练目标
• 根据 assemblyMode 决定是按章节、知识点还是混合方式装配

建议同时根据 courseMode 决定 Unit 的组织风格：

• exam_aligned：更接近训练单元和讲评单元
• curriculum_aligned：更接近教材章节单元
• exploratory：更接近概念导入单元和理解推进单元
• bridge_course：更接近承接单元和过渡单元

若 assemblyMode = capability_based，则 Unit 应更接近能力专题单元和变式训练单元。

产出：

• UnitPlan[]

11.5 Scene 规划

职责：

• 为每个 Unit 规划 Scene
• 决定场景类型与教学模式
• 决定测验和训练插入点

产出：

• SceneOutline[]

11.6 Scene 内容生成

职责：

• 根据 SceneOutline 生成结构化场景内容
• 区分讲授、练习、讲评、互动等不同 pattern

产出：

• SceneContentGenerationResult[]

11.7 动作编排

职责：

• 生成讲解动作、强调动作、讨论动作、互动动作
• 生成讲述节奏和阻塞关系

产出：

• SceneActionGenerationResult[]

11.8 学科增强注入

职责：

• 根据学科选择增强器
• 为部分场景注入图示、动画、媒体、题型策略
• 根据 engagementSkin 为课程注入角色化、故事化或游戏化表达包装

约束说明：

1. exam_aligned 模式下，趣味包装优先级应低于考点稳定性
2. exploratory 模式下，可适度提高故事化、游戏化和直觉化表达比重
3. bridge_course 模式下，应优先保证“过渡解释”而不是花哨包装

产出：

• SubjectEnhancementResult

11.8.1 教学主干与表现包装的先后顺序

建议流程固定为：

考纲对齐 -> 知识点拆解 -> Unit/Scene 编排 -> 学科增强 -> 表现包装注入

不建议先做趣味包装，再反过来拼教学结构。

原因：

1. 趣味包装应建立在正确课程结构之上
2. 否则容易出现“看起来有趣，但考点组织失真”的问题
3. 老师也更容易信任这类课程

11.9 测验与训练生成

职责：

• 生成 AssessmentPlan
• 生成题目和答案
• 生成 PracticePlan
• 生成 RemediationPlan

产出：

• AssessmentBundle
• PracticeBundle

11.10 装配与持久化

职责：

• 组装 Stage + Unit + Scene + Action + Asset + Assessment
• 写入课程协议对象
• 保存为可恢复、可导出课程

11.11 三条主线的阶段产物清单

以下清单用于把前文 10.1 的输入样例与生成流水线阶段严格对齐。建议后续实现时把它视为阶段验收的最低标准。

11.11.1 样例 A：正向组课阶段产物

1. 输入理解 - GenerationContext - 明确 forward_design
2. 考纲与教材对齐 - CurriculumAlignmentResult
3. 知识点拆解 - KnowledgeGraph - KnowledgePoint[]
4. Unit 规划 - UnitPlan[] - 至少 1 个 chapter_unit
5. Scene 规划 - SceneOutline[]
6. Scene 内容生成 - SceneContentGenerationResult[]
7. 动作编排 - SceneActionGenerationResult[]
8. 学科增强注入 - SubjectEnhancementResult
9. 测验与训练生成 - AssessmentBundle - PracticeBundle
10. 装配与持久化 - Stage - Unit[] - Scene[]

11.11.2 样例 B：诊断驱动反向组课阶段产物

1. 输入理解 - GenerationContext - 明确 diagnostic_remediation
2. 诊断识别 - DiagnosticAssessment - LearnerStateSnapshot
3. 缺口画像 - GapProfile - 记录主类、表现特征、证据来源
4. 补救策略选择 - RemediationStrategySelectionResult - 明确 rollback / recompose / hybrid / practice_only
5. 知识点反推 - KnowledgeGraph - prerequisiteBacktrace
6. 补救课程规划 - RemediationCoursePlan - UnitPlan[] - 至少 1 个 remediation_unit
7. Scene 规划与内容生成 - SceneOutline[] - SceneContentGenerationResult[]
8. 训练与回挂设计 - PracticeBundle - masteryCheckpointPlan - gapFeedbackHook
9. 装配与持久化 - Stage - Unit[] - Scene[] - GapProfileRef

11.11.3 样例 C：能力导向反向组课阶段产物

1. 输入理解 - GenerationContext - 明确 capability_reverse_design
2. 能力目标解析 - CapabilityGoalResolution - ProblemSampleAnalysis
3. 复合知识链反推 - CompositeKnowledgeChain[]
4. 能力模式识别 - ProblemSolvingPattern[]
5. 能力单元装配 - CapabilityUnit - coverageScope - masteryCheckpointPlan
6. Scene 规划与内容生成 - SceneOutline[] - 推荐出现 pattern_recognition / step_decomposition / variant_transfer
7. 训练计划生成 - PracticePlan - 显式继承 reasoningSteps / variantAxes / commonMistakes
8. 装配与持久化 - Stage - capability_unit - Scene[]

11.11.4 阶段产物的共性要求

无论三条主线走哪一条，后续建议统一要求：

1. 每个阶段产物都应可序列化
2. 每个阶段产物都应能被持久化或重放
3. 上一阶段的核心输出必须能成为下一阶段的正式输入
4. 不允许把关键判断长期藏在 prompt 文本里而不结构化暴露
5. 若某阶段暂不实现，其缺位应被显式记录，而不是由下游阶段隐式猜测

12. 教学运行蓝图

原有运行状态机以播放器为中心，本蓝图建议升级为“教学运行状态机”。

建议核心状态：

• idle
• instructing
• interactive
• assessing
• reviewing
• reinforcing
• paused
• completed

状态含义

• idle：未开始或等待进入下一段
• instructing：讲授和动作执行
• interactive：讨论、问答、互动模拟
• assessing：测验或作答阶段
• reviewing：讲评、反馈和错因解释
• reinforcing：强化训练阶段
• paused：任意阶段暂停
• completed：课程结束

这样可以把“讲授”和“训练”统一纳入一个内核，而不是只围绕页面播放。

13. 学科增强总设计

学科增强不进入主干流程分叉，而是通过统一接口注入。

建议接口：

interface SubjectEnhancer {
  subject: string;
  enhanceScenePlan(input: SubjectEnhancerInput): SubjectEnhancerOutput;
  enhanceSceneContent(input: SubjectEnhancerContentInput): SubjectEnhancerContentOutput;
  enhanceAssessment(input: SubjectAssessmentInput): SubjectAssessmentOutput;
  enhancePractice(input: SubjectPracticeInput): SubjectPracticeOutput;
}

建议同时定义：

• SubjectProfile
• ScenePatternPolicy
• MediaPolicy
• QuestionPolicy
• VisualizationPolicy

14. 第一批学科增强范围

本阶段只优先做三门主课：

• 语文
• 数学
• 英语

其他学科先走 GenericSubjectProfile。

15. 语文学科增强蓝图

15.1 目标

让语文课程不仅能“生成内容”，还要具备以下专业感：

1. 古文与现代文的表达差异清晰
2. 阅读理解与讲解路径清晰
3. 修辞、情感、结构、主旨可被拆解
4. 写作素材和写作训练可挂接
5. 在不破坏文本理解的前提下，允许引入合适的情境化和故事化表达

15.2 优先增强能力

• 古文意象画面生成
• 古文语境场景还原
• 句段层次拆解
• 修辞与表达手法标注
• 阅读题路径设计
• 朗读节奏与停顿建议
• 作文素材链与范式输出

15.3 典型 ScenePattern

• text_context_intro
• classical_chinese_scene_render
• paragraph_analysis
• rhetoric_focus
• reading_comprehension_drill
• composition_material_extension

15.4 表现包装示例

语文尤其适合结合 EngagementSkin 做受控增强，例如：

• 古文场景可配置古风叙事皮肤
• 诗词意象可配置画面化和镜头化表达
• 文学作品可配置角色视角讲述

但约束依然是：

1. 注释、主旨、修辞、结构分析必须完整
2. 趣味化表达不能代替标准文本讲解

15.5 首批语文 ProblemSolvingPattern 建议

语文模式不建议只按“字词句篇”划分，而应按阅读、理解、表达任务中的稳定解题结构划分。

15.5.1 classical_text_decoding

适用题型：

• 文言文断句
• 文言翻译
• 实词虚词判断
• 句意理解题

entrySignals

• 句子结构紧凑且省略较多
• 需要先断句再理解
• 题目同时考查词义、句法和语境

requiredKnowledgeChains

• 文言实词与虚词
• 句法骨架识别
• 语境还原
• 文化与常见表达习惯

reasoningSteps

1. 先找句子主干
2. 划分停顿和层次
3. 结合上下文判断词义
4. 还原句意与语气
5. 完成翻译或作答

commonMistakes

• 逐字硬译
• 不先断句就直接理解
• 只背词义不看语境
• 译文通顺性差

variantAxes

• 单句理解到整段理解
• 断句到翻译再到作用分析
• 课内文言到课外迁移

recommendedTraining

• 句法骨架训练
• 断句训练
• 语境释义训练
• 翻译通顺性训练

15.5.2 modern_reading_argument_trace

适用题型：

• 现代文阅读
• 论述类文本
• 说明类文本
• 信息筛选与结构分析题

entrySignals

• 文本强调观点、论据、结构关系
• 题目询问段落作用、论证逻辑、信息筛选
• 答题需要从局部回到全文结构

requiredKnowledgeChains

• 中心观点提取
• 段落关系识别
• 论据与说明对象定位
• 信息整合

reasoningSteps

1. 判断文本核心任务和主旨
2. 理清段落层次与推进关系
3. 定位相关信息区间
4. 分析局部信息在全文中的作用
5. 组织成规范答案

commonMistakes

• 只摘句不分析关系
• 看局部不看整体结构
• 会找信息但不会概括
• 答案碎片化

variantAxes

• 论述类到说明类
• 信息筛选到结构作用分析
• 单段分析到全文逻辑追踪

recommendedTraining

• 段落关系训练
• 中心观点提炼训练
• 结构作用答题训练
• 信息整合训练

15.5.3 literary_image_theme_pattern

适用题型：

• 散文阅读
• 小说阅读
• 诗歌鉴赏
• 意象、情感、主旨分析题

entrySignals

• 文本含有明显意象、描写和情感铺垫
• 题目询问表达效果、人物形象、情感主旨
• 作答需要把局部描写回挂到整体主题

requiredKnowledgeChains

• 意象识别
• 描写手法分析
• 情感变化判断
• 主旨与结构回挂

reasoningSteps

1. 识别关键意象或描写对象
2. 判断其情感色彩和表达功能
3. 关联人物、情节或作者情感
4. 回挂到主旨和结构位置
5. 形成“内容 + 手法 + 作用”答案

commonMistakes

• 只描述内容不分析作用
• 情感判断空泛
• 手法和主旨脱节
• 套模板但不贴文本

variantAxes

• 诗歌到散文到小说
• 单意象分析到多意象联动
• 局部赏析到全文主旨整合

recommendedTraining

• 意象识别训练
• 手法作用训练
• 情感链追踪训练
• 主旨回挂训练

15.5.4 writing_argument_assembly

适用题型：

• 材料作文
• 任务驱动型作文
• 议论文写作
• 综合表达题

entrySignals

• 输入为材料、任务或观点冲突
• 输出要求形成完整表达结构
• 需要立意、组织、论证和收束

requiredKnowledgeChains

• 审题立意
• 论证结构搭建
• 材料选择与组织
• 段落推进
• 表达规范

reasoningSteps

1. 审题并确定立意边界
2. 搭建中心论点与分论点
3. 选择并组织材料
4. 推进论证与段落衔接
5. 回扣任务要求和中心立场

commonMistakes

• 立意偏题
• 材料堆砌
• 结构松散
• 结尾无法收束

variantAxes

• 材料作文到任务驱动作文
• 观点表达到论证深化
• 单材料到多材料整合

recommendedTraining

• 审题立意训练
• 结构搭建训练
• 材料组织训练
• 收束与回扣训练

16. 数学学科增强蓝图

16.1 目标

让数学课程能够体现：

1. 概念链清楚
2. 步骤推演清楚
3. 图形与函数足够直观
4. 变式与题组训练有强度

16.2 优先增强能力

• 概念关系图
• 几何图形可视化
• 函数变化动画
• 例题步骤分解
• 变式题自动扩展
• 错因归类
• 题组强化训练

16.3 典型 ScenePattern

• concept_graph_intro
• worked_example_step_by_step
• geometry_visual_demo
• function_animation_demo
• variant_drill_block
• error_pattern_review

16.4 首批数学 ProblemSolvingPattern 建议

本阶段建议优先沉淀 5 类高价值数学能力模式。

这些模式不按教材目录划分，而按“综合题的稳定解题结构”划分。

16.4.1 function_extremum_transform

适用题型：

• 最值题
• 取值范围题
• 恒成立题
• 参数综合题
• 动点函数化问题

entrySignals

• 出现“最大值、最小值、范围、恒成立、恰有解”
• 某个量随另一个量变化
• 几何或实际问题可以转写成函数关系

requiredKnowledgeChains

• 设元
• 代数关系转化
• 函数解析式建立
• 定义域与范围
• 二次函数/分段函数性质

reasoningSteps

1. 找出核心变量
2. 建立自变量与因变量关系
3. 转化为函数表达式
4. 确定定义域与约束
5. 用函数性质求最值或范围
6. 回译到原题语境

commonMistakes

• 不会找核心变量
• 会列式但不会函数化
• 忽略定义域
• 求完结果不会解释题意

variantAxes

• 纯代数到几何背景
• 求值到参数讨论
• 显式函数到隐式关系
• 单函数到分段函数

recommendedTraining

• 设元专项
• 函数化专项
• 定义域检查专项
• 同模型多背景变式训练

16.4.2 geometry_relation_construction

适用题型：

• 几何证明题
• 动点几何
• 面积与长度综合题
• 圆与相似综合题

entrySignals

• 目标是证明关系
• 条件分散且目标不直接可见
• 图形中存在潜在相似、全等、圆性质
• 常需要辅助线

requiredKnowledgeChains

• 全等与相似
• 角关系
• 圆的性质
• 比例与面积
• 辅助线构造

reasoningSteps

1. 明确目标关系
2. 倒推所需中间关系
3. 识别潜在构造点
4. 补辅助线或做等价转化
5. 建立桥梁关系
6. 收束到目标结论

commonMistakes

• 不会从目标倒推
• 识别出相似苗头但不会构造
• 桥梁关系选择错误
• 证明链条过长且发散

variantAxes

• 静态图到动态点
• 证明到求值
• 平面几何到坐标化
• 单关系到存在性/最值

recommendedTraining

• 目标倒推训练
• 辅助线模式训练
• 桥梁关系识别训练
• 同图多问变式训练

16.4.3 classification_discussion_pattern

适用题型：

• 绝对值题
• 参数方程与不等式
• 分段函数
• 几何位置关系分类
• 存在性问题

entrySignals

• 出现参数、绝对值、分段、位置变化
• 要求判断有几个解、是否存在、何时成立
• 结论依赖不同条件区间

requiredKnowledgeChains

• 分类标准识别
• 方程/不等式求解
• 函数与图像性质
• 边界控制
• 结果整合

reasoningSteps

1. 识别必须分类的触发点
2. 选定分类标准
3. 保证互斥且穷尽
4. 分支内分别求解
5. 合并各分支结论
6. 检查边界与遗漏

commonMistakes

• 不知道按什么分类
• 分类重叠或遗漏
• 会算分支但不会整合
• 边界值处理错误

variantAxes

• 代数分类到几何分类
• 显性分段到隐性分类
• 两类到多层分类
• 求解到存在性证明

recommendedTraining

• 分类标准识别训练
• 互斥穷尽训练
• 边界值检查训练
• 多分类法对比训练

16.4.4 equivalent_transform_chain

适用题型：

• 复杂代数推导
• 方程/不等式综合
• 根式与分式链式化简
• 条件转目标的连续变形题

entrySignals

• 题面复杂但目标形式规整
• 直接计算难以推进
• 需要连续等价变形
• 常伴随证明、化简、参数求解

requiredKnowledgeChains

• 恒等变形
• 因式分解
• 分式与根式转化
• 换元
• 条件控制

reasoningSteps

1. 判断目标形式
2. 确定最关键的转化方向
3. 连续做局部等价变形
4. 同步检查限制条件
5. 必要时换元或引入中间量
6. 收束到可证或可解形式

commonMistakes

• 变形方向不清
• 非等价变形
• 增根漏根
• 中间步骤正确但无法收口

variantAxes

• 化简到证明
• 求值到参数讨论
• 单表达式到多条件联动
• 显式结构到换元结构

recommendedTraining

• 目标导向变形训练
• 等价/非等价辨析训练
• 条件控制训练
• 一题多路径比较训练

16.4.5 model_building_comparison

适用题型：

• 应用题
• 方案选择题
• 成本利润题
• 效率与路程综合题
• 数据分析与决策题

entrySignals

• 现实语境较强
• 需要比较多个方案
• 文字信息多
• 结论需要解释现实意义

requiredKnowledgeChains

• 变量定义
• 数量关系整理
• 方程/函数建模
• 约束识别
• 结果解释

reasoningSteps

1. 提炼对象、变量与约束
2. 组织为表格、式子或函数
3. 建立统一比较指标
4. 求解模型
5. 比较方案优劣
6. 用题目语境解释结论

commonMistakes

• 无法从文字中抽变量
• 指标不统一
• 算完不会解释
• 忽略隐含约束

variantAxes

• 单方案到多方案比较
• 线性模型到非线性模型
• 纯计算到开放决策
• 表格数据到图像数据

recommendedTraining

• 文字转模型训练
• 约束识别训练
• 指标统一训练
• 结果解释训练

17. 英语学科增强蓝图

17.1 目标

让英语课程体现：

1. 词汇、句型、篇章的连接关系
2. 听说读写不是割裂模块
3. 阅读理解有清晰解题路径
4. 写作训练有模板和迁移逻辑

17.2 优先增强能力

• 语境化对话场景
• 发音与语调建议
• 词汇到句型到语篇链
• 阅读定位策略
• 写作模板和扩写训练
• 听说练联动

17.3 典型 ScenePattern

• situational_dialogue
• vocabulary_sentence_link
• reading_strategy_walkthrough
• grammar_in_context
• guided_writing_template
• listening_speaking_drill

17.4 首批英语 ProblemSolvingPattern 建议

英语模式不建议只按“词汇/语法/阅读”粗分，而应按任务型解题结构划分。

17.4.1 reading_inference_pattern

适用题型：

• 阅读推断题
• 作者态度题
• 深层含义题
• 段落意图题

entrySignals

• 题干中出现 infer、imply、attitude、suggest
• 正确答案不在原文表层复现
• 需要结合上下文和语气判断

requiredKnowledgeChains

• 关键信息定位
• 上下文逻辑
• 语气与态度词识别
• 干扰项排除

reasoningSteps

1. 定位题干关键词
2. 找相关句与前后文
3. 区分显性信息和隐含信息
4. 结合逻辑与语气做推断
5. 排除表面正确但逻辑错误的选项

commonMistakes

• 把原文复述项当答案
• 只看单句不看上下文
• 语气判断失误
• 推断过度

variantAxes

• 局部推断到全文态度
• 事实判断到深层意图
• 记叙文到说明/议论文

recommendedTraining

• 显性/隐性信息辨析训练
• 干扰项排除训练
• 态度词与逻辑词训练

17.4.2 long_sentence_parse_pattern

适用题型：

• 长难句理解
• 阅读卡顿突破
• 翻译题
• 语篇精读题

entrySignals

• 句子成分层次复杂
• 从句、非谓语、插入语较多
• 学生读到一半失去主干

requiredKnowledgeChains

• 句子主干识别
• 从句层级拆解
• 非谓语结构识别
• 逻辑连接关系

reasoningSteps

1. 先找主谓宾骨架
2. 标出从句与修饰成分
3. 识别非谓语和插入结构
4. 还原语义层级
5. 回到段落逻辑理解句意

commonMistakes

• 一上来逐词硬译
• 找不到主干
• 修饰关系挂错
• 句子看懂了但段落中作用没看懂

variantAxes

• 单句精读到段内多句联动
• 说明文到议论文
• 理解到翻译/改写输出

recommendedTraining

• 主干提取训练
• 从句拆解训练
• 句内层级标注训练

17.4.3 grammar_in_context_pattern

适用题型：

• 语法填空
• 改错
• 句型转换
• 写作纠错

entrySignals

• 不能只靠单条语法规则判断
• 必须结合上下文和句法位置
• 语法与语义同时制约答案

requiredKnowledgeChains

• 词性与句法位置
• 时态语态
• 从句与非谓语
• 固定搭配
• 语境语义判断

reasoningSteps

1. 先判断空缺或错误所在句法位置
2. 再判断语境功能
3. 确定时态、语态、从句或搭配
4. 代回原文检验语义与结构

commonMistakes

• 脱离语境背规则
• 只看搭配不看句法
• 时态判断只看时间词
• 改对局部却破坏全文一致性

variantAxes

• 单句到语篇
• 规则识别到综合纠错
• 客观题到写作修改

recommendedTraining

• 句法位置训练
• 语境判定训练
• 全文一致性检查训练

17.4.4 reading_to_writing_transfer

适用题型：

• 读后续写
• 概要写作
• 应用文迁移写作
• 阅读到表达整合题

entrySignals

• 输入是文章或材料
• 输出不是选择答案，而是书面表达
• 要求从阅读中提炼结构与信息

requiredKnowledgeChains

• 信息筛选
• 结构提炼
• 表达模板调用
• 语篇衔接
• 输出重组

reasoningSteps

1. 提炼原文关键信息与结构
2. 判断写作任务目标
3. 选择表达模板与语篇框架
4. 重组信息并完成输出
5. 检查连贯性与任务完成度

commonMistakes

• 抄原文不重组
• 信息筛选失焦
• 结构混乱
• 语言能写但任务未完成

variantAxes

• 概要写作到读后续写
• 信息复述到任务表达
• 单材料到多材料整合

recommendedTraining

• 信息提炼训练
• 结构重组训练
• 模板迁移训练
• 任务完成度检查训练

18. 其他学科的基线策略

在未进入专项增强前，历史、物理、化学、生物、地理等先走通用基线：

1. 标准课程结构
2. 标准讲授场景
3. 标准题型组合
4. 标准讲评与训练链路

后续再逐步增加：

• 历史事件复原
• 古文明场景动画
• 物理过程可视化
• 化学实验动画
• 生物结构图
• 地理时空图示

18.1 非考纲课程支持原则

对于学生自主式学习、兴趣学习和超前学习，系统应允许生成不直接属于中高考考纲的课程。

典型示例：

• 0基础学习微积分
• 英语电影对白入门
• 中国古典神话中的文学意象

但这些课程不应伪装成标准应试课程，而应显式归类为：

• exploratory

或

• bridge_course

这样既能扩展系统能力，又不会破坏老师对“标准课”的信任感。

19. 图文排版与媒体设计原则

为满足中国老师对专业度的要求，图文表达不应只是视觉美化。

应建立以下设计原则：

1. 版式服从知识结构表达
2. 理科优先图解和过程可视化
3. 文科优先语境、材料、结构和时间关系表达
4. 图片、视频、动画必须服务教学目标
5. 媒体不是随机装饰，而是教学策略的一部分

建议后续建立独立对象：

• LayoutIntent
• VisualizationIntent
• MediaIntent

19.1 教学可视化、动画与视频表达设计原则

课程中的图片、动画与视频，不应按“视觉炫目程度”选择，而应按教学任务分层选择。

核心判断是：

• 静态图适合结构总览
• 轻动画适合原理显现
• 步骤动画适合思路拆解
• 对比动画适合迁移训练
• 视频适合情境导入与实验替代
• 交互可视化适合规律探索

因此，课程系统不应把“生成动图/视频”理解为附属装饰能力，而应把它视为一种正式教学表达结构。

19.2 哪些内容最适合做可视化与动画

建议优先支持以下 5 类内容做教学可视化：

1. 过程型内容 - 电流流动 - 力学变化 - 几何构造变化 - 函数图像变化
2. 因果型内容 - 某个条件变化如何引起结论变化
3. 对比型内容 - 串联 / 并联 - 定滑轮 / 动滑轮 - 原型题 / 变式题
4. 抽象量可视化 - 力、方向、电压、电流、参数变化
5. 结构总览型 - 专题地图 - 知识结构图 - 题型关系图

并非所有知识点都值得动画化。若内容本质是静态结构说明，则应优先使用高质量静态图，而不是为了“动起来”而强行动画化。

19.3 教学介质分层

建议把可视化介质正式分为以下 6 类：

19.3.1 静态图

适合：

• 专题总览
• 结构关系图
• 概念地图
• 章节导航图

目标：

• 帮学生建立地图感与结构感

19.3.2 轻动画

适合：

• 流向、方向、增减、通断
• 单一对象变化
• 局部关系显现

目标：

• 把看不见的关系变得可见

19.3.3 步骤动画

适合：

• 多步推理
• 审题到建模
• 几何构造
• 起手思路拆解

目标：

• 演示“怎么起步、怎么推进”

19.3.4 对比动画

适合：

• 原型题与变式题
• 正确起手与错误起手
• 两种结构或两种条件的区别

目标：

• 帮学生建立模式边界与迁移判断

19.3.5 完整视频

适合：

• 课前情境导入
• 实验过程
• 现实世界现象映射
• 难以用单帧表达的完整过程

目标：

• 建立感知、情境和现实连接

19.3.6 交互式可视化

适合：

• 参数变化观察
• 图像联动
• 几何动态构造
• 电路结构切换

目标：

• 让学生主动操纵因果关系与变化规律

19.4 各种介质的使用场景建议

建议按以下方式选用介质：

1. 若目标是建立整体框架，用 静态图
2. 若目标是显现隐藏关系，用 轻动画
3. 若目标是训练起手思路与步骤，用 步骤动画
4. 若目标是训练辨型、迁移和纠错，用 对比动画
5. 若目标是做导入、实验替代或现实映射，用 完整视频
6. 若目标是让学生主动试错和调参，用 交互式可视化

也就是说，课程不应把“视频”视为高级形式，也不应把“静态图”视为低级形式。真正的标准是：是否匹配当前教学任务。

19.5 教学微动画原则

对大量课程内容而言，最有效的往往不是长视频，而是 5 到 20 秒的“教学型微动画”。

建议微动画优先满足以下要求：

1. 一图一义 - 一段动画只解决一个关键关系
2. 单一变化轴 - 最好只有一个核心变量在变化
3. 可暂停讲解 - 关键帧必须适合停顿说明
4. 变化可追踪 - 学生能明确看出“谁在变、什么没变”
5. 先对象，后符号，最后公式 - 尤其照顾想象力薄弱学生

19.6 课程内建议支持的动画模板

建议把课程动画模板化，而不是每次从零做自由设计。

优先模板包括：

1. principle_reveal - 原理显现
2. single_variable_shift - 单变量变化
3. side_by_side_compare - 并排对比
4. step_build_up - 分步搭建思路
5. error_contrast - 错误路径对比
6. overview_map - 专题总览图

这些模板可以同时服务：

• 静态图输出
• 可暂停动画输出
• 短视频输出

19.7 对领域对象的补充要求

当前蓝图中已有：

• LayoutIntent
• VisualizationIntent
• MediaIntent

建议进一步补充以下表达层意图：

AnimationIntent

回答：

• 这里为什么需要动画
• 是轻动画、步骤动画、对比动画还是参数联动动画
• 哪个对象在变化
• 哪个量在变化
• 哪个量保持不变
• 关键帧和暂停点在哪里

VideoIntent

回答：

• 为什么这里需要视频而不是普通动画
• 是导入、实验替代、现实映射还是专题总览

InteractionIntent

回答：

• 是否需要学生主动调参
• 交互目标是探索规律、验证假设还是检查理解

19.8 与 ScenePattern 的关系

教学可视化不应游离于 ScenePattern 之外。

建议后续在部分 ScenePattern 上显式支持视觉表达组合，例如：

• concept_explanation + principle_reveal
• worked_example + step_build_up
• review_feedback + error_contrast
• interactive_drill + single_variable_shift
• pattern_recognition + side_by_side_compare

这样课程系统才能把媒体表达和教学意图绑定，而不是把图片、动画、视频作为场景之后再随意追加。

19.9 使用 JS 与可视化库的设计建议

在实现层面，建议把可视化技术分层使用，而不是单一依赖某一种前端动画库。

19.9.1 SVG / DOM 动画层

适合：

• 电路图
• 结构图
• 关系图
• 步骤高亮

适用于：

• principle_reveal
• step_build_up
• error_contrast

19.9.2 Canvas / 2D 图形层

适合：

• 流动效果
• 高密度动态图
• 复杂 2D 过程演示

适用于：

• 电流流动
• 力学过程
• 动态结构变化

19.9.3 图表与数据动画层

适合：

• 函数图像变化
• 参数联动
• 统计关系与趋势

适用于：

• 数学图像
• 物理量变化曲线

19.9.4 3D 表达层

适合：

• 空间几何
• 立体结构
• 空间受力

原则：

• 只有在 2D 难以表达时才启用
• 不应为了“炫”而强行 3D 化

19.9.5 视频生成层

适合：

• 批量导出讲解视频
• 把脚本化动画转为可分发视频资产

原则：

• 视频生成应建立在结构化动画脚本之上
• 不建议把视频制作做成纯人工剪辑流程

19.10 质量控制原则

所有图片、动画、视频与交互可视化，建议统一按以下 6 个维度控制质量：

1. 教学正确性 - 原理、方向、结构、符号和关系必须准确
2. 教学目标单一性 - 一段媒体应服务一个明确目标
3. 可追踪性 - 学生能看清“谁变了、怎么变、为什么变”
4. 认知负荷控制 - 避免同屏信息过载
5. 风格一致性 - 图标、颜色、箭头、符号、动画语言要统一
6. 生产可复用性 - 能否模板化、参数化、投影化输出

19.11 最终设计结论

本蓝图建议正式采纳以下判断：

图片、动画、视频和交互可视化，不是课程装饰，而是高密度、强可视、可暂停讲解、可服务思路生成的教学表达单元。

因此，后续课程系统应：

1. 按教学任务选择介质
2. 按模板化方式组织动画与视频
3. 把视觉表达能力纳入正式领域边界
4. 把质量控制纳入课程生产流程

只有这样，图片、动画和视频才能真正帮助那些想象力不足、结构感不足、略难题容易没思路的学生。

19.12 AI 基础能力到课程能力映射

当前系统涉及的大模型与多模态能力，不能只停留在“可调用工具”层，而应进一步判断它们是否已经进入课程内核、是否真正被教学化。

本蓝图建议区分以下 3 个层级：

1. 能力存在 - 系统已经接入或已预留该类技术能力
2. 能力纳入蓝图 - 该能力已经被正式纳入输入、生成、表达、运行或导出边界
3. 能力被充分教学化 - 该能力已明确进入对象协议、Scene 设计、训练闭环和质量控制

按这个标准看，当前判断是：

• 语言能力、图像能力、可视化能力，已经明显进入课程设计主线
• 视频能力已进入教学表达设计，但尚未完全形成成熟生产闭环
• 语音合成、语音识别、PDF 解析、网络搜索，当前更多仍停留在“工具能力”或“输入增强能力”，尚未全部完成课程化

19.12.1 能力映射表

19.12.2 当前最需要补强的不是“接更多能力”，而是“把能力课程化”

后续不建议把重点放在继续罗列模型能力，而应优先回答每类能力的 5 个问题：

1. 它解决哪一种教学问题
2. 它适合进入哪类 ScenePattern
3. 它的输入输出协议是什么
4. 它如何接受质量控制
5. 它如何证明自己确实提升了理解、记忆或迁移

如果这 5 个问题没有回答清楚，那么再强的模型能力，也只能算“平台工具能力”，还不能算“课程能力”。

19.12.3 当前判断结论

本蓝图建议正式采纳以下判断：

大模型语言能力、图像生成能力、视频生成能力、语音合成能力、语音识别能力、PDF 解析能力和网络搜索能力，已经基本纳入系统能力版图与蓝图边界；但真正被充分运营到课程教学里的，目前主要是语言能力、图像能力与教学可视化能力。

其余能力并非不重要，而是尚需进一步完成：

• 协议化
• 场景化
• 教学化
• 质控化

只有完成这 4 步，这些基础 AI 能力才会真正转化成稳定的课程生产能力。

20. 题型与强化训练设计原则

建议把题型和训练从“附属产物”提升为课程内核的一部分。

20.1 原生题型集合

建议至少原生支持：

• 单选
• 多选
• 填空
• 判断
• 简答
• 计算
• 阅读理解
• 写作
• 探究

20.2 强化训练结构

建议统一支持：

• 基础巩固
• 变式训练
• 易错点回补
• 专题强化
• 冲刺训练

20.3 讲评结构

讲评至少应包含：

• 正误判断
• 错因说明
• 知识点回挂
• 解法对比
• 再练建议

20.4 诊断驱动的补救学习闭环

面向家长和学生在正课后的再次学习与强化场景，建议正式支持以下闭环：

诊断 -> 缺口画像 -> 反向组课 -> 定向学习 -> 强化训练 -> 掌握检查 -> 再诊断

这条链路的核心不在于“多做一次测验”，而在于通过诊断结果重新组织课程主干。

建议要求：

1. 诊断结果必须回挂知识点和能力点
2. 系统必须能区分“需要重讲”和“只需再练”
3. 补救课不应简单等于原课程重放
4. 训练结束后必须再次验证是否真正掌握

20.4.1 两类正式补救路径

针对学生和家长的课后查漏补缺，本蓝图建议正式支持两类路径：

1. 断层回退路径
2. 知识链重组路径

断层回退路径

系统识别出“真正开始跟不上的地方”后，从该处向前后组织补救课程。

重点是：

• 快速修复主断层
• 恢复继续学习所需的先修基础
• 适合链式依赖强的学科内容

知识链重组路径

系统不再默认沿原章节顺序补课，而是根据诊断结果重新梳理知识点主次、顺序和训练重点，再重新装配课程。

重点是：

• 解决掌握深浅不一的问题
• 避免整章重学带来的低效率
• 更贴近真正的因材施教

20.4.2 课后补救的默认决策

本蓝图建议默认采用：

• 先判断是否存在主断层
• 若存在明显主断层，则优先回退补缺
• 若问题呈现多点分散，则优先知识链重组
• 若两类问题同时存在，则采用混合路径

也就是说，系统不应把“二选一”完全丢给家长或学生，而应先给出诊断后的推荐路径。

20.5 隐性掉队与掌握度幻觉

系统需要正视一个常见问题：

• 学生在听课时可能自以为理解
• 但由于缺乏即时验证，误以为自己已经掌握
• 后续课程沿先修链继续推进后，问题会被放大

因此，课程设计不应只依赖“课后统一测一次”。

建议同时支持：

1. 课中微型检查点
2. Unit 结束检查点
3. 课后补救性检查点
4. 多轮掌握确认

20.5.1 从概念理解到解题迁移的桥接断层

在真实教学场景中，存在一类非常普遍的现象：

• 学生对概念讲解“能听懂”
• 刚讲完的简单例题，在相关记忆新鲜时还能尝试完成
• 但一旦遇到略难题、变式题、跨条件整合题或需要更整体视角的问题时，往往“没有思路”

这类问题不应简单归因为“概念完全没学会”，而更应被理解为：

概念理解 -> 例题模仿 -> 变式识别 -> 模式调用 -> 综合迁移

这条链路在中间层发生了断裂。

也就是说，很多学生的问题并不是零理解，而是：

1. 概念理解停留在“听的时候明白”
2. 例题掌握停留在“题面相似时能模仿”
3. 尚未形成稳定的步骤结构
4. 尚未形成稳定的模式识别与变式迁移能力

20.5.2 这类问题的系统归因

从课程系统角度看，这类“略难题没思路”通常不应直接归类为单一知识点缺失，而更接近以下几类问题的叠加：

1. falseMasterySignals - 跟着老师能明白，但不能独立调取
2. procedure_gap - 知道概念，但不知道先做什么、后做什么
3. pattern_gap - 单点知识会，但不会把多个点组织成解题模式
4. transfer_failure - 原型题会做，变式题不会做

这意味着系统在诊断和编排时，必须区分：

• “概念未建立”
• “步骤未固化”
• “模式未形成”
• “迁移未完成”

否则就会误把大量桥接问题处理成“再讲一遍概念”，从而导致过度重讲、低效补课。

20.5.3 设计结论：课程系统必须显式支持桥接层

当前很多课程系统容易只覆盖两端：

• 概念讲解
• 题目训练

但对大量学生而言，真正缺失的是中间层：

• 起手判断
• 步骤组织
• 模式识别
• 变式比较
• 综合迁移

因此，本蓝图建议把“概念理解到解题迁移的桥接层”正式视为课程内核的一部分，而不是老师经验层的临场发挥。

20.5.4 桥接层的课程设计要求

针对这类学生，系统不应只做“再讲概念”或“再刷几题”，而应显式支持以下桥接动作：

1. 独立提取检查 - 检查学生是否能离开老师讲述链独立调用概念
2. 起手策略训练 - 训练学生在“没思路”时如何识别题型信号和第一步动作
3. 步骤拆解训练 - 把多步题的关键步骤显式化，而不是只展示完整答案
4. 模式识别训练 - 让学生知道“这类题为什么属于这一类”
5. 变式轴训练 - 围绕条件变化、问法变化、结构变化做迁移训练
6. 比较式讲评 - 对比正确起手、错误起手、原型题与变式题
7. 延迟与混合检查 - 防止学生只在短时记忆窗口内看起来会做

20.5.5 对领域对象的直接要求

这一桥接层不是抽象口号，而应直接落实到当前蓝图对象中：

对 ProblemSolvingPattern 的要求

不能只描述“这类题最后怎么做”，还应显式描述：

• entrySignals
• reasoningSteps
• keyDecisionPoints
• commonMistakes

也就是说，Pattern 不只是高难题专题对象，也应成为很多“略难题没思路”场景下的桥接支撑对象。

对 CapabilityUnit 的要求

CapabilityUnit 不应只服务压轴题训练，也应允许承担：

• 概念到题型的过桥
• 章节知识到解题套路的过桥
• 原型会做到变式会做的过桥

对 PracticePlan 的要求

训练计划不应只生成“更多同类题”，而应至少区分：

1. 原型定型
2. 单轴变式
3. 易错矫正
4. 综合迁移
5. 延迟检查

20.5.6 对 Scene 设计的要求

若系统要真正解决“没思路”问题，就不能把所有思路训练都隐藏在普通讲解页里。

建议显式支持更偏桥接层的 scenePattern，例如：

• pattern_recognition
• step_decomposition
• error_comparison
• variant_transfer
• checkpoint_quiz

这些 Scene 的目标不是增加页面数量，而是承载“思路生成训练”本身。

20.5.7 最终判断

本蓝图建议正式采纳以下判断：

大量学生“略难题无思路”的核心原因，不是概念零理解，而是概念尚未转化为稳定的步骤结构、模式识别能力与变式迁移能力。

因此，课程系统必须显式支持这一桥接层，而不能只支持“概念讲解”和“题目练习”两端。

20.6 个体化补救编排原则

即使表面错的是同一道题，不同学生的真实原因也可能不同。

因此补救课编排建议至少区分以下几类原因：

1. 先修知识缺失
2. 当下概念未建立
3. 解题步骤不会
4. 审题与表达失误
5. 节奏过快导致理解断裂

个体化补救的目标，不是“给每个人一套完全不同的课程”，而是：

• 找到其真实断点
• 选择合适的回退层级
• 缩短无效学习路径
• 用最少但足够的课程段完成回补

20.7 综合难题能力训练主线

除“知识点补缺”外，系统还应正式支持“综合难题能力训练”主线。

它主要服务这样一类场景：

• 知识点基本学完
• 但学生仍不会做综合题、压轴题、跨章节题
• 难点在于整合、迁移、推理和多步变式，而不是单点记忆

建议闭环为：

难题样本/目标能力 -> 能力拆解 -> 复合知识链 -> 能力专题课程 -> 变式强化训练 -> 能力检查

20.7.1 设计原则

1. 不把综合能力问题简化为单个知识点问题
2. 必须显式串联跨章节知识点
3. 必须显式讲清解题模式与关键转折步骤
4. 强化训练应围绕变式轴展开，而不是只换数字重做

20.7.2 与课后补缺的区别

课后补缺主线 解决的是“哪里断了”。

综合难题能力训练主线 解决的是“为什么不会把多个点联合用来解题”。

前者以补断层为中心； 后者以整合、迁移、推理和模式识别为中心。

21. 编辑修订蓝图

老师必须可以对以下对象进行局部修订：

• Unit
• Scene
• Explanation
• Question
• Media
• PracticePlan

建议支持的操作：

1. 局部重生成 Scene
2. 仅重生成题目
3. 仅重生成讲解动作
4. 仅替换媒体
5. 调整难度和训练强度
6. 调整学科增强开关

22. 导出与沉淀蓝图

课程内核生成后，建议至少支持以下沉淀物：

• 课堂播放版
• PPT 导出版
• HTML 导出版
• 教师讲义
• 训练题单
• 讲评稿
• 错题本
• 可复用模板

同时建议在导出元数据中保留：

• courseMode
• courseStrategy
• engagementSkin

便于未来同一课程主干派生出不同课堂版本。

22.1 课程投影模型

建议把课程的不同使用形态正式定义为“课程投影”，而不是把它们视为彼此独立的课程副本。

同一门课程主干，建议至少支持以下投影：

• ClassroomProjection
• TeacherNotesProjection
• PracticeSetProjection
• ReviewProjection
• SelfLearningProjection
• DiagnosticReportProjection

ClassroomProjection

面向课堂讲授与播放。

重点承载：

• 场景顺序
• 动作执行
• 互动与讨论
• 测验插入

TeacherNotesProjection

面向老师备课和课堂讲稿。

重点承载：

• 教学目标
• 知识点结构
• 讲解重点
• 讲评提示

PracticeSetProjection

面向训练题单和课后强化。

重点承载：

• 题组结构
• 难度分层
• 变式训练
• 易错点回补

ReviewProjection

面向讲评课和错题回看。

重点承载：

• 错因归类
• 知识点回挂
• 解法对比
• 再练建议

SelfLearningProjection

面向学生自主学习和探索式学习。

重点承载：

• 更清晰的路径引导
• 更强的概念可视化
• 更细的分步解释
• 更适合单人推进的学习节奏

DiagnosticReportProjection

面向学生和家长查看当前薄弱点、回补路径和阶段性掌握状态。

重点承载：

• 缺口知识点
• 先修断点
• 推荐补救模式
• 当前补救建议
• 已完成与未完成检查点
• 下一步学习建议

22.2 投影设计原则

1. 投影只改变“呈现与消费方式”，不改变课程主干
2. 投影之间共享同一套知识点、训练和讲评逻辑
3. 同一门课程允许面向老师和学生生成不同投影，但不应各自产生独立事实源

23. 技术栈建议

本蓝图先确定边界，再讨论实现。

但就本阶段目标而言，建议技术实现按以下思路推进：

23.1 第一阶段实现形态

第一阶段建议采用：

• 模块化单体

这意味着：

1. 先拆清代码边界和领域边界
2. 不急于拆部署边界
3. 先让课程内核、运行内核、增强器、API 壳层在一个系统内稳定协作
4. 等协议、模型和任务边界稳定后，再判断是否拆服务

这里的重点是：

• 当前要拆的是“系统结构”
• 不是“运维拓扑”

23.2 总体路线

采用“模块化单体 + 独立课程内核包 + 服务端为权威”的方式。

23.3 推荐组合

• 前端：React，短期可继续 Next.js，但课程运行内核必须独立于页面
• 后端：优先 NestJS，便于平滑从现有 TypeScript 体系拆出模块
• 数据库：PostgreSQL
• 对象存储：S3 / MinIO
• 任务：第一阶段 BullMQ
• 流式：SSE

23.4 结构建议

建议逐步形成以下模块：

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

23.4.1 模块职责建议

建议将上述模块按以下职责收口：

packages/domain-model

负责沉淀稳定领域对象与枚举，不承载具体生成算法。

重点包括：

• Stage / Unit / Scene
• KnowledgePoint / CompositeKnowledgeChain / ProblemSolvingPattern
• AssessmentPlan / PracticePlan / RemediationPlan
• GapProfile / RemediationCoursePlan
• CourseStrategy / LessonIntent / AssemblyMode / UnitType

packages/generation-contracts

负责统一输入输出协议和阶段产物协议，是三条主线共享的请求边界。

重点包括：

• GenerationInputV2
• CourseStrategyInput
• DiagnosticContextInput
• ProblemSampleInput
• CapabilityGoalInput
• 各阶段 Result 与 Plan 对象

packages/course-kernel

负责课程装配主流程，是三条主线共用的编排中枢。

重点包括：

• 输入理解与上下文归一化
• 三条主线入口分流
• 考纲/教材对齐
• 知识点拆解与反推
• Unit / Scene / PracticePlan 装配
• RemediationStrategySelector 调用

packages/subject-enhancers

负责在课程主干稳定后注入语文、数学、英语等学科增强能力。

重点包括：

• 学科专有图示与表达策略
• 学科题型与讲评策略
• 首批 ProblemSolvingPattern 模式库
• 学科特有 Scene 和训练建议

packages/runtime-engine

负责把已装配好的课程资产转成课堂运行过程，不参与课程组装决策。

重点包括：

• 教学运行状态机
• 场景切换与动作执行
• 测验、讲评、强化训练切换
• 运行时事件回传与检查点触发

apps/api

负责请求接入、任务编排、持久化和对外服务暴露。

重点包括：

• 调用 generation-contracts
• 驱动 course-kernel
• 连接数据库、对象存储、任务系统
• 输出阶段结果与可恢复课程资产

apps/web

负责老师与学生的消费界面，不承载课程协议本体。

重点包括：

• 课程创建与编辑入口
• 课堂播放与讲评视图
• 练习与补救视图
• 诊断报告与进度视图

23.4.2 三条样例到模块边界的映射

前文 3 条端到端样例，可直接用来检验模块边界是否合理。

样例 A：正向组课

主要经过：

• apps/web 提交教材同步组课请求
• apps/api 接入请求并下发到 packages/course-kernel
• packages/generation-contracts 约束输入为 forward_design
• packages/course-kernel 完成考纲对齐、知识点拆解、chapter_unit 装配
• packages/subject-enhancers 注入学科表达
• packages/runtime-engine 消费装配结果运行课堂

这个样例主要检验：

• CourseStrategy + AssemblyMode + UnitType 的基本路径
• 正向场景下 course-kernel 是否可以不依赖诊断模块正常工作

样例 B：诊断驱动的反向组课

主要经过：

• apps/web 或家长/学生入口提交诊断证据
• packages/generation-contracts 约束输入为 diagnostic_remediation
• packages/course-kernel 调用 DiagnosticAssessment -> GapProfile -> RemediationStrategySelector
• packages/domain-model 提供 GapProfile / RemediationCoursePlan / remediation_unit 的稳定协议
• packages/subject-enhancers 为补救单元注入学科特有回补策略
• packages/runtime-engine 执行补救学习、检查点与回挂

这个样例主要检验：

• 诊断画像和补救决策是否分层
• GapProfile、RemediationCoursePlan 是否足够支撑反向组课

样例 C：能力导向的反向组课

主要经过：

• apps/web 提交 ProblemSampleInput[] 或 CapabilityGoalInput
• packages/generation-contracts 约束输入为 capability_reverse_design
• packages/course-kernel 反推 CompositeKnowledgeChain[] 与 ProblemSolvingPattern[]
• packages/domain-model 提供 CapabilityUnit、coverageScope、四次投影链的正式对象
• packages/subject-enhancers 读取具体模式库并补充学科能力模板
• packages/runtime-engine 运行能力专题场景与掌握检查

这个样例主要检验：

• ProblemSolvingPattern -> CapabilityUnit -> Scene -> PracticePlan 是否能独立成立
• 能力主线是否无需新增另一套课程系统

23.4.3 当前最值得先拆清的内部边界

若按“先模块化单体，后判断是否拆服务”的原则推进，当前最值得先拆清的是以下 4 条内部边界：

1. 协议边界 - generation-contracts 与 UI、任务系统、内核之间的边界
2. 领域边界 - domain-model 与任何具体算法、页面实现之间的边界
3. 装配边界 - course-kernel 与 subject-enhancers 之间的边界
4. 运行边界 - runtime-engine 与课程生成链路之间的边界

只要这 4 条边界先稳住，后续无论是否拆服务，系统都不会被入口主线和页面形态反向绑死。

23.4.4 模块间调用边界草图

建议把第一阶段的主调用关系先收敛为“单向主链 + 少量受控回传”，而不是允许模块之间自由互调。

主调用链

flowchart LR
    A["apps/web"] --> B["apps/api"]
    B --> C["packages/generation-contracts"]
    C --> D["packages/course-kernel"]
    D --> E["packages/domain-model"]
    D --> F["packages/subject-enhancers"]
    D --> G["课程阶段产物 / 持久化"]
    G --> H["packages/runtime-engine"]
    H --> G
    B --> H
    H --> B

这条链的含义是：

1. apps/web 只负责发起请求、展示结果，不直接拼领域对象
2. apps/api 负责请求接入、任务编排、持久化与阶段调度
3. generation-contracts 负责统一跨模块的输入输出协议
4. course-kernel 负责主装配逻辑
5. domain-model 为内核与增强器提供稳定对象定义
6. subject-enhancers 只在装配阶段被内核调用，不反向主导流程
7. runtime-engine 消费已经装配完成的课程资产，并把运行时事件回传给 apps/api 或持久化层

依赖方向建议

建议第一阶段严格控制为以下依赖方向：

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

如果后续需要阶段化持久化，建议持久化层由 apps/api 统一托管，而不是让 course-kernel、subject-enhancers、runtime-engine 分别直连各自的存储表。

明确禁止的依赖

第一阶段建议明确禁止以下几类调用：

1. apps/web -> course-kernel - 避免页面层直接持有课程组装逻辑
2. apps/web -> domain-model - 页面可以消费序列化结果，但不应以 UI 状态驱动领域协议
3. subject-enhancers -> apps/api / apps/web - 增强器不应感知平台壳层
4. subject-enhancers -> runtime-engine - 学科增强负责“怎么装”，不负责“怎么跑”
5. runtime-engine -> subject-enhancers - 运行时不应临时回头请求学科增强器来决定主干逻辑
6. runtime-engine -> generation-contracts - 运行时消费装配结果，不应重做组课请求解释

这些禁止项的目标，是防止未来出现“页面状态反向决定领域协议”或“运行时临场补算法”的混乱结构。

三条主线在调用边界上的差异

三条主线共享主调用链，但它们在 course-kernel 内部的进入点不同：

1. 正向组课 - apps/api -> generation-contracts -> course-kernel.forward_design
2. 诊断驱动反向组课 - apps/api -> generation-contracts -> course-kernel.diagnostic_remediation
3. 能力导向反向组课 - apps/api -> generation-contracts -> course-kernel.capability_reverse_design

也就是说：

• 差异应收敛在 course-kernel 的入口编排与阶段产物上
• 不应把三条主线拆成三套 API、三套运行时或三套页面基础设施

建议保留的回传链

虽然主链建议单向，但有两类回传需要显式保留：

1. 运行时事件回传 - runtime-engine -> apps/api - 用于记录播放、测验、讲评、训练和检查点事件
2. 学习结果回挂 - runtime-engine / apps/api -> GapProfileRef / LearningProgress / DiagnosticReportProjection - 用于补救闭环和后续再诊断

这两类回传都应回到“阶段产物 / 持久化层”或 apps/api，不建议直接回写到 course-kernel 的瞬时内存状态。

第一阶段的接口收口建议

为避免接口四散，建议第一阶段尽量把对外能力收口为 4 类服务入口：

1. generateCourse - 面向正向组课
2. generateRemediationCourse - 面向诊断驱动补救
3. generateCapabilityCourse - 面向能力专题
4. runStageSession - 面向课堂运行与训练运行

后续即使内部继续拆模块，也建议先围绕这 4 个入口稳定契约，再讨论是否进一步抽象为更细服务。

23.5 结构建议的意义

以上结构的目标不是立刻服务化，而是先让系统具备“未来可拆分”的边界。

也就是说：

1. 当前部署可以保持单体
2. 当前研发可以保持高协同
3. 但课程内核、运行内核、协议层、增强层都必须在代码结构上先独立出来

24. 重构优先顺序

阶段 1

冻结领域模型与课程协议：

• Stage / Unit / Scene
• KnowledgePoint
• AssessmentPlan / PracticePlan / RemediationPlan
• EngagementSkin
• 运行时状态机

本阶段的验证标准建议不只看对象定义是否完整，还应至少用以下样例做纸面校验：

• 正向组课样例是否能完整映射到 Stage -> Unit -> Scene -> PracticePlan
• 诊断补救样例是否能完整映射到 GapProfile -> RemediationCoursePlan -> remediation_unit
• 能力专题样例是否能完整映射到 ProblemSolvingPattern -> CapabilityUnit -> Scene -> PracticePlan

阶段 2

统一生成协议并重写课程生成流水线。

本阶段建议优先打通三条主线共享的最小主流程：

1. 输入归一化
2. 入口模式识别
3. 知识点拆解或反推
4. Unit / Scene / PracticePlan 装配
5. 阶段产物持久化

此阶段不要求立刻把三条主线都做到同样丰富，但要求三条主线共用同一套协议和装配框架。

阶段 3

建立三门主课的增强器：

• 语文
• 数学
• 英语

本阶段建议不要平均发力，而应按样例反推优先级：

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

这样可以让三门主课分别承担一条最有代表性的验证路径。

阶段 4

建立老师修订与局部重生成能力。

本阶段建议围绕前述三条样例补“可编辑性”，而不是先做泛化后台能力：

• 正向组课：允许局部改 Scene 与讲练节奏
• 诊断补救：允许老师改补救起点、训练强度和退出条件
• 能力专题：允许老师改 coverageScope、错因聚焦和变式轴

阶段 5

再向平台化外壳扩展：

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

24.1 样例驱动的迁移顺序建议

若要避免一上来就全量重构，建议采用“1 条主线先贯通，另外 2 条主线保持协议兼容”的迁移方式：

1. 先以正向组课打通主骨架 - 最容易验证 Stage / Unit / Scene 主干是否稳定
2. 再以诊断补救打通 GapProfile 与补救链路 - 最容易暴露协议分层是否真实成立
3. 最后以能力专题打通 ProblemSolvingPattern 与 CapabilityUnit - 最能检验课程内核是否真正支持综合能力主线

这个顺序的好处是：

• 先稳主骨架
• 再稳补救闭环
• 最后再拉高到能力模式层

相比三条主线同时重做，这种顺序更利于在单基线下持续推进。

24.2 进入实现前的最小准备清单

在正式进入代码改造前，建议至少补齐以下 5 项设计产物：

1. 三条主线的准正式输入样例
2. 三条主线的阶段产物清单
3. 核心对象的字段表与可选字段规则
4. 模块间调用边界草图
5. 每个阶段的“暂不实现项”清单

只有这 5 项明确后，模块化单体的改造才不会在中途被 UI、页面流程或学科特例重新拉散。

24.3 核心对象的准正式字段表

以下字段表用于把当前蓝图推进到“可进入实现设计评审”的状态。这里的字段约束是准正式定义，重点回答：

1. 哪些字段是必填
2. 哪些字段是条件必填
3. 哪些字段当前只作为扩展口保留

本节优先覆盖：

• GenerationInputV2
• ProblemSolvingPattern
• CapabilityUnit
• GapProfile
• RemediationCoursePlan

24.3.1 GenerationInputV2

字段组合规则以 10.2 为准，后续实现不建议跳过 learningSessionMode + courseStrategy + lessonIntent + assemblyMode 这四层组合。

24.3.2 ProblemSolvingPattern

补充约束：

• reasoningSteps 当前应视为核心强约束字段
• preferredScenePatterns 不得越级控制 Scene
• ProblemSolvingPattern 不直接拥有题目实例与页面结构

24.3.3 CapabilityUnit

补充约束：

• CapabilityUnit 是对 Pattern 的教学化裁剪，不是模式原样复制
• coverageScope 当前应视为能力单元协议里最关键的强约束字段之一

24.3.4 GapProfile

补充约束：

• gapTypes 与 decisionHints 不能直接等价
• falseMasterySignals 没有 evidenceSources 时，置信度应被下调

24.3.5 RemediationCoursePlan

补充约束：

• practice_only 不应作为 RemediationCoursePlan.remediationMode 的正式取值
• 若系统只给出轻干预建议，可不生成完整 RemediationCoursePlan，而生成轻量训练建议对象

24.3.6 当前字段表的使用原则

这批字段表当前的用途是：

1. 作为实现设计评审时的共识基线
2. 作为后续 domain-model 与 generation-contracts 的拆分依据
3. 作为三条主线样例的协议校验清单

当前不建议做的事情：

1. 不建议现在就把所有可选字段强行落库
2. 不建议把表中每个字段都立刻绑定到 UI 表单
3. 不建议为了字段完整性反向制造复杂配置页

24.4 各阶段的暂不实现项清单

以下清单的目标不是降低标准，而是明确第一阶段到第五阶段“刻意不做什么”。只有把不做项讲清楚，单基线推进时才不容易被需求外溢拖散。

24.4.1 阶段 1 暂不实现项

阶段 1 重点是冻结领域模型与课程协议，因此暂不实现：

1. 全量数据库表结构定稿 - 当前只需要支撑协议与对象边界，不需要一次把所有落库细节拍死
2. 面向所有角色的完整 UI 表单 - 字段表不能直接等同于配置页设计
3. 全学科学科增强 - 仍以语文、数学、英语为首批主课
4. 复杂权限、组织、学校后台模型 - 这属于平台外壳，不属于课程内核冻结阶段
5. 运行时与生成时的所有事件协议细化 - 当前只需冻结主对象和主要状态边界

24.4.2 阶段 2 暂不实现项

阶段 2 重点是统一生成协议并重写课程生成流水线，因此暂不实现：

1. 三条主线一次性做到同等丰富 - 先打通共享主流程，再逐步补深度
2. 多端完全一致的消费体验 - 当前优先保证服务端组课协议一致
3. 所有导出投影一次性打齐 - 先保证主干课程装配与核心投影可用
4. 高度智能的自动策略优化 - 当前优先保证规则清晰、阶段产物可追踪
5. 微服务拆分 - 继续坚持模块化单体

24.4.3 阶段 3 暂不实现项

阶段 3 重点是建立三门主课增强器，因此暂不实现：

1. 其他学科的专项增强器 - 其他学科先继续走基线方案
2. 所有 ProblemSolvingPattern 模式库一次性铺满 - 先围绕三条代表性主线扩充高价值模式
3. 学科增强器反向主导课程主干 - 学科增强只能注入，不改写课程内核主结构
4. 过度依赖多媒体和动画包装 - 优先保证教学主干和训练逻辑
5. 复杂学科联动课 - 当前先以单学科主线打稳协议

24.4.4 阶段 4 暂不实现项

阶段 4 重点是老师修订与局部重生成，因此暂不实现：

1. 全量可视化编排器 - 当前先支持关键对象的局部编辑
2. 任意粒度的任意重生成 - 先收敛到 Scene / Question / PracticePlan / coverageScope 等关键对象
3. 多人实时协同编辑 - 协作属于平台化后期能力
4. 完整版本分支系统 - 当前以单基线和可恢复快照为主
5. 高复杂度审批流 - 暂不进入组织管理流程

24.4.5 阶段 5 暂不实现项

阶段 5 虽然进入平台化扩展，但仍建议暂不实现：

1. 为拆服务而拆服务 - 只有在模块边界稳定、负载和协作成本证明有必要时再拆
2. 过重租户系统 - 优先支持真实场景，不预支未来组织复杂度
3. 全量 BI 和运营后台 - 先围绕课程资产、运行数据和补救闭环构建最小可用视图
4. 所有商业化能力一次性铺开 - 平台壳层扩展应服务核心课程价值，而不是反向主导内核设计

24.4.6 全阶段通用的边界约束

无论推进到哪个阶段，以下事情都不建议提前发生：

1. 不要让 UI 页面状态反向定义领域协议
2. 不要让 prompt 技巧替代结构化阶段产物
3. 不要把单个学科特例直接写进课程主干
4. 不要在未稳定协议前拆成长期多分支并行开发
5. 不要为“未来可能有用”预埋过重抽象

24.4.7 这份清单的使用方式

后续每次进入新阶段前，建议先做一次两列表评审：

• 本阶段必须做的
• 本阶段明确不做的

如果某项需求无法清楚归类到这两列之一，通常说明该需求还没有回到当前蓝图主线，应先做边界澄清，再决定是否纳入。

25. 本蓝图的结论

本次重构的正确起点不是平台，不是权限，也不是管理后台，而是课程内核。

只要课程内核能做到：

1. 对纲
2. 专业
3. 可讲
4. 可练
5. 可测
6. 可讲评
7. 可强化
8. 可局部修订

那么平台化扩展只是时间问题。

当前建议正式以本蓝图作为后续评审基础，并围绕以下三条主线展开详细设计：

1. 课程内核数据模型
2. 课程生成流水线
3. 三门主课增强器设计