系统设计全景

项目全景图文档

面向团队统一理解业务全景、技术分层、核心对象和平台演进路径。

静态 HTML 版本 适合挂载到官网 / 内部门户 2026年5月25日 15:21

1. 文档目的

本文档用于给团队统一解释本项目的业务全景和技术全景。

它不是某个模块的详细设计文档,而是一份“总览地图”,用于回答下面这些问题:

  1. 这个项目到底要解决什么问题
  2. 它的核心业务是什么
  3. 它和普通课件工具、普通 AI 对话工具有什么区别
  4. 当前系统是怎么工作的
  5. 未来平台化之后会演进成什么
  6. 团队后续拆分和重构时,边界应该怎么理解

2. 一句话定义

本项目是一个面向学校、老师、学生和家长的 AI 教学平台。

它的目标不是只生成一套 PPT,而是:

基于主题、材料和教学目标,自动生成可播放、可互动、可评测、可导出、可分发的 AI 课程,并支持老师围绕教学进度进行备课、调整、重生成和课堂使用,同时支持学生学习与家长陪学。

3. 它解决的核心问题

传统备课和上课过程里,老师通常需要自己完成以下大量工作:

  • 设计课程结构
  • 组织知识点顺序
  • 制作课件页面
  • 补充图片、视频、案例
  • 准备课堂讲稿
  • 准备互动环节
  • 准备随堂练习与讲评
  • 根据教学进度调整内容

课后又会出现新的割裂:

  • 学生复习没有统一承接
  • 家长陪学缺少高质量内容
  • 课堂内容难以长期沉淀为学校资产

这个项目要做的是把这些工作中的高重复部分平台化、结构化、自动化。

4. 业务全景

4.1 当前核心业务

当前系统最核心的业务能力有四块:

  1. 课程生成 从一句话主题、课程需求、PDF 材料生成完整课程。
  2. 课堂运行 将课程作为一个“可播放课堂”运行,而不是静态展示页面。
  3. 多 Agent 互动 让 AI 教师、助教、学生等角色参与讲解、问答和讨论。
  4. 学习强化 通过 quiz(测验场景)interactive(交互场景)pbl(项目式学习场景) 等场景帮助学生巩固知识。

4.2 未来平台化业务

按当前规划,未来业务会扩展成一个完整的教学平台,除课程生成外,还会包括:

  • 学校管理
  • 老师管理
  • 班级管理
  • 课程管理
  • 课程版本管理
  • 课时与教学进度管理
  • 指定场景重生成
  • 考纲管理
  • 知识库或教材基础数据管理
  • 课堂播放与互动教学
  • 学生学习与课后复习
  • 家长陪学与学习监督
  • 课后复盘与复用

这意味着产品将从“单次课程生成工具”升级成“教师备课与课堂运行平台”,并进一步演化成“学校、老师、学生、家长协同的教学平台”。

4.3 目标用户

学校

关注:

  • 组织、账号、权限
  • 课程资产统一管理
  • 教学标准和考纲统一

老师

关注:

  • 快速备课
  • 调整和重生成课程
  • 按教学进度组织课时
  • 课堂播放和互动教学

学生

关注:

  • 更直观的讲解
  • 多媒体学习体验
  • 互动问答
  • 测验和强化学习
  • 自主探索感兴趣主题

家长

关注:

  • 使用老师提供的课程进行陪学
  • 帮助孩子复习和强化
  • 了解孩子的学习进度和结果

5. 产品全景图

Mermaid 流程图
flowchart TD A["学校与组织"] --> B["老师工作台"] A --> H["考纲与基础数据管理"] B --> C["课程生成"] B --> D["课程编辑与局部重生成"] B --> E["课时与教学进度"] B --> F["课堂播放"] B --> G["测验与互动"] C --> J["课程资产沉淀"] D --> J F --> J J --> S["学生学习端"] J --> P["家长陪学端"] S --> R["课后复习与强化"]
查看结构源码
flowchart TD
    A["学校与组织"] --> B["老师工作台"]
    A --> H["考纲与基础数据管理"]
    B --> C["课程生成"]
    B --> D["课程编辑与局部重生成"]
    B --> E["课时与教学进度"]
    B --> F["课堂播放"]
    B --> G["测验与互动"]
    C --> J["课程资产沉淀"]
    D --> J
    F --> J
    J --> S["学生学习端"]
    J --> P["家长陪学端"]
    S --> R["课后复习与强化"]

6. 产品核心对象

团队理解这个项目时,最重要的是先理解几个核心对象。

6.1 Stage(课程)

Stage(课程) 表示一门完整课程或一个课堂实例。

6.2 Scene(场景)

Scene(场景) 表示课程中的单个场景,是教学最小单元。

6.3 SceneType

当前包含:

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

6.4 Action(教学动作)

Action(教学动作) 表示课堂运行时执行的教学行为,例如:

  • 语音讲解
  • 白板书写
  • 聚焦
  • 激光笔
  • 讨论触发
  • Widget 互动控制

6.5 Agent

课堂里的 AI 角色,例如:

  • 教师
  • 助教
  • 学生

6.6 Asset(资源)

Asset(资源) 表示课程依赖的图片、视频、音频、文件等资源。

7. 业务流程全景

7.1 课程生成流程

  1. 老师输入主题、课程要求或上传材料
  2. 系统理解输入并补充上下文
  3. 系统设计课程大纲
  4. 系统逐个生成场景内容
  5. 系统为内容生成讲解动作
  6. 系统生成图片、视频、TTS 等媒体
  7. 系统装配成完整课程并保存

7.2 备课调整流程

  1. 老师打开已有课程
  2. 发现某个场景不合适
  3. 对指定场景发起局部重生成
  4. 系统只更新对应场景内容或动作
  5. 老师确认并继续调整

7.3 课堂播放流程

  1. 老师选择课程和课时
  2. 系统载入课程
  3. 课堂播放器按场景顺序执行
  4. 语音、白板、聚焦、视频、讨论依次触发
  5. 进入互动、问答或测评场景
  6. 课堂结束后保存状态和结果

7.4 学生学习流程

  1. 学生进入老师发布的课程
  2. 学生完成学习、互动和测验
  3. 系统记录学生学习进度
  4. 学生可课后复习与强化

7.5 家长陪学流程

  1. 家长获取老师开放的课程
  2. 家长选择适合孩子的学习内容
  3. 孩子在家庭场景下完成学习或复习
  4. 家长查看学习过程与结果

8. 技术全景

8.1 当前技术思路

当前系统已经具备比较明确的技术骨架:

  1. 生成链路
  2. 运行链路
  3. 多 Agent 交互链路
  4. 存储与导出链路

虽然现有实现还有耦合点,但整体方向是对的。

8.2 当前系统的本质

从技术角度,本项目不是普通网站,而是四个子系统叠加:

  1. 课程生成引擎
  2. 课堂运行引擎
  3. 多 Agent 互动引擎
  4. 课程资产平台

8.3 系统分层

建议团队统一按下面五层理解系统:

表现层

  • 首页
  • 生成预览页
  • 教师工作台
  • 课堂播放页
  • 学校管理页
  • 学生学习端
  • 家长陪学端

应用层

  • 生成课程
  • 局部重生成
  • 保存课程
  • 播放课程
  • 发起讨论
  • 提交测验
  • 发布课程给学生
  • 家长获取和使用课程
  • 记录学生学习进度

领域层

  • Stage(课程)
  • Scene(场景)
  • Action(教学动作)
  • Agent
  • Asset(资源)
  • QuizState
  • PlaybackSnapshot
  • GenerationJob

领域服务层

  • 大纲生成器
  • 场景生成器
  • 动作编排器
  • 多 Agent 导演器
  • 媒体编排器
  • 导出器

基础设施层

  • LLM Provider
  • 图片 / 视频 Provider
  • TTS / ASR Provider
  • 数据库
  • 对象存储
  • 任务队列
  • 流式通讯

9. 技术架构图

Mermaid 流程图
flowchart LR U["学校 / 老师 / 学生 / 家长"] --> FE["前端应用层"] subgraph FE["前端应用层"] F1["教师工作台"] F2["课程编辑与重生成"] F3["课堂播放端"] F4["学校管理端"] F5["学生学习端"] F6["家长陪学端"] end FE --> APP["应用服务层"] subgraph APP["应用服务层"] A1["认证与权限"] A2["课程生成服务"] A3["课程管理服务"] A4["课堂运行服务"] A5["多 Agent 服务"] A6["测评与状态服务"] A7["课程分发与可见性服务"] A8["导出服务"] end subgraph DOMAIN["领域服务层"] D1["Outline Generator"] D2["Scene Generator"] D3["Action Orchestrator"] D4["Media Orchestrator"] D5["Agent Director"] D6["Playback State Machine"] D7["Assessment Engine"] end A2 --> D1 A2 --> D2 A2 --> D3 A2 --> D4 A4 --> D6 A5 --> D5 A6 --> D7 subgraph INFRA["基础设施层"] I1["LLM Providers"] I2["Image / Video Providers"] I3["TTS / ASR Providers"] I4["PostgreSQL"] I5["Object Storage"] I6["Queue / Event Stream"] end D1 --> I1 D2 --> I1 D3 --> I1 D4 --> I2 D4 --> I3 D5 --> I1 APP --> I4 APP --> I5 APP --> I6
查看结构源码
flowchart LR
    U["学校 / 老师 / 学生 / 家长"] --> FE["前端应用层"]

    subgraph FE["前端应用层"]
        F1["教师工作台"]
        F2["课程编辑与重生成"]
        F3["课堂播放端"]
        F4["学校管理端"]
        F5["学生学习端"]
        F6["家长陪学端"]
    end

    FE --> APP["应用服务层"]

    subgraph APP["应用服务层"]
        A1["认证与权限"]
        A2["课程生成服务"]
        A3["课程管理服务"]
        A4["课堂运行服务"]
        A5["多 Agent 服务"]
        A6["测评与状态服务"]
        A7["课程分发与可见性服务"]
        A8["导出服务"]
    end

    subgraph DOMAIN["领域服务层"]
        D1["Outline Generator"]
        D2["Scene Generator"]
        D3["Action Orchestrator"]
        D4["Media Orchestrator"]
        D5["Agent Director"]
        D6["Playback State Machine"]
        D7["Assessment Engine"]
    end

    A2 --> D1
    A2 --> D2
    A2 --> D3
    A2 --> D4
    A4 --> D6
    A5 --> D5
    A6 --> D7

    subgraph INFRA["基础设施层"]
        I1["LLM Providers"]
        I2["Image / Video Providers"]
        I3["TTS / ASR Providers"]
        I4["PostgreSQL"]
        I5["Object Storage"]
        I6["Queue / Event Stream"]
    end

    D1 --> I1
    D2 --> I1
    D3 --> I1
    D4 --> I2
    D4 --> I3
    D5 --> I1
    APP --> I4
    APP --> I5
    APP --> I6

10. 生成与运行是两条不同的主链

团队最容易混淆的一点,是把“生成课程”和“运行课堂”看成同一件事。

实际上应该拆成两条链:

10.1 生成链

负责把输入变成课程资产。

输入:

  • 主题
  • 材料
  • 教学目标

输出:

  • Stage(课程)
  • Scenes(场景集合)
  • Actions(教学动作集合)
  • Assets(资源集合)

10.2 运行链

负责把课程资产作为课堂执行。

输入:

  • 已生成课程

输出:

  • 播放状态
  • 互动事件
  • 测评状态
  • 课堂运行结果

11. 系统核心竞争力

从团队视角,这个项目的真正亮点不是“会生成 PPT”,而是下面几个组合能力:

  1. 课程结构化生成
  2. PPT 风格内容生成
  3. 讲解行为生成
  4. 多 Agent 互动
  5. 白板与多媒体融合
  6. 可播放课堂而不是静态课件
  7. 从老师工具走向学校、学生、家长协同平台的潜力

12. 未来平台化后的能力地图

Mermaid 流程图
flowchart TD P1["学校管理"] --> P2["老师管理"] P2 --> P3["课程管理"] P3 --> P4["课时管理"] P3 --> P5["课程生成"] P3 --> P6["局部重生成"] P3 --> P7["课程版本管理"] P1 --> P8["考纲与教材基础数据"] P4 --> P9["课堂播放"] P9 --> P10["学生学习"] P10 --> P11["家长陪学"] P10 --> P12["测评与学习结果"]
查看结构源码
flowchart TD
    P1["学校管理"] --> P2["老师管理"]
    P2 --> P3["课程管理"]
    P3 --> P4["课时管理"]
    P3 --> P5["课程生成"]
    P3 --> P6["局部重生成"]
    P3 --> P7["课程版本管理"]
    P1 --> P8["考纲与教材基础数据"]
    P4 --> P9["课堂播放"]
    P9 --> P10["学生学习"]
    P10 --> P11["家长陪学"]
    P10 --> P12["测评与学习结果"]

13. 为什么未来要平台化重构

因为未来的核心场景已经不只是“用户输入一句话生成课程”,而是:

  • 老师长期备课
  • 多课时组织
  • 围绕教学进度增量修改
  • 学校统一课程资产管理
  • 课程发布给学生
  • 家长参与课后陪学

这要求系统从“单体工具”升级成“平台系统”。

14. 团队需要统一的几条共识

14.1 这不是单纯课件项目

它是课程生成 + 课堂运行 + 学习平台 + 管理平台的组合体。

14.2 先重构内核,再重构页面

最该先稳定的是:

  • 领域模型
  • 生成协议
  • 运行时事件协议
  • 存储边界

14.3 平台化后,前端只是壳层

无论未来用 Vue 还是 React,真正的核心都应该是:

  • 领域模型
  • 服务边界
  • 事件协议
  • 任务和状态系统

15. 团队分工建议

如果团队后续要并行推进,建议按下面分工理解:

产品 / 业务

  • 学校端能力
  • 老师工作台能力
  • 学生学习端能力
  • 家长陪学端能力
  • 课程生命周期设计
  • 考纲与教学进度逻辑

AI / 生成方向

  • 课程生成协议
  • 大纲生成
  • 场景内容生成
  • 局部重生成策略

客户端 / 前端

  • 教师工作台
  • 课程编辑器
  • 课堂播放器
  • 学生学习端
  • 家长陪学端
  • 事件消费与状态展示

后端 / 平台

  • 用户与权限
  • 课程管理
  • 课程发布与可见性
  • 学习记录与进度管理
  • 存储模型
  • 任务系统
  • 审计日志

16. 推荐阅读顺序

如果新成员加入团队,建议按这个顺序看文档:

  1. 本文档
  2. [01-系统架构设计文档.md](./01-%E7%B3%BB%E7%BB%9F%E6%9E%B6%E6%9E%84%E8%AE%BE%E8%AE%A1%E6%96%87%E6%A1%A3.md)
  3. [02-业务架构设计文档.md](./02-%E4%B8%9A%E5%8A%A1%E6%9E%B6%E6%9E%84%E8%AE%BE%E8%AE%A1%E6%96%87%E6%A1%A3.md)
  4. [03-领域模型说明.md](./03-%E9%A2%86%E5%9F%9F%E6%A8%A1%E5%9E%8B%E8%AF%B4%E6%98%8E.md)
  5. [07-生成协议草案.md](./07-%E7%94%9F%E6%88%90%E5%8D%8F%E8%AE%AE%E8%8D%89%E6%A1%88.md)
  6. [08-运行时事件协议.md](./08-%E8%BF%90%E8%A1%8C%E6%97%B6%E4%BA%8B%E4%BB%B6%E5%8D%8F%E8%AE%AE.md)
  7. [09-存储模型与表结构草案.md](./09-%E5%AD%98%E5%82%A8%E6%A8%A1%E5%9E%8B%E4%B8%8E%E8%A1%A8%E7%BB%93%E6%9E%84%E8%8D%89%E6%A1%88.md)

17. 总结

这个项目现在的最佳理解方式,不是“AI 帮你做课件”,而是:

一个以课程为核心,以场景为载体,以动作和 Agent 为运行机制,连接学校、老师、学生和家长的 AI 教学系统。

后续任何重构、选型和分工,只要围绕这句话展开,方向就不会偏。