1. 文档目的
本文档用于给团队统一解释本项目的业务全景和技术全景。
它不是某个模块的详细设计文档,而是一份“总览地图”,用于回答下面这些问题:
- 这个项目到底要解决什么问题
- 它的核心业务是什么
- 它和普通课件工具、普通 AI 对话工具有什么区别
- 当前系统是怎么工作的
- 未来平台化之后会演进成什么
- 团队后续拆分和重构时,边界应该怎么理解
2. 一句话定义
本项目是一个面向学校、老师、学生和家长的 AI 教学平台。
它的目标不是只生成一套 PPT,而是:
基于主题、材料和教学目标,自动生成可播放、可互动、可评测、可导出、可分发的 AI 课程,并支持老师围绕教学进度进行备课、调整、重生成和课堂使用,同时支持学生学习与家长陪学。
3. 它解决的核心问题
传统备课和上课过程里,老师通常需要自己完成以下大量工作:
- 设计课程结构
- 组织知识点顺序
- 制作课件页面
- 补充图片、视频、案例
- 准备课堂讲稿
- 准备互动环节
- 准备随堂练习与讲评
- 根据教学进度调整内容
课后又会出现新的割裂:
- 学生复习没有统一承接
- 家长陪学缺少高质量内容
- 课堂内容难以长期沉淀为学校资产
这个项目要做的是把这些工作中的高重复部分平台化、结构化、自动化。
4. 业务全景
4.1 当前核心业务
当前系统最核心的业务能力有四块:
- 课程生成 从一句话主题、课程需求、PDF 材料生成完整课程。
- 课堂运行 将课程作为一个“可播放课堂”运行,而不是静态展示页面。
- 多 Agent 互动 让 AI 教师、助教、学生等角色参与讲解、问答和讨论。
- 学习强化 通过
quiz(测验场景)、interactive(交互场景)、pbl(项目式学习场景)等场景帮助学生巩固知识。
4.2 未来平台化业务
按当前规划,未来业务会扩展成一个完整的教学平台,除课程生成外,还会包括:
- 学校管理
- 老师管理
- 班级管理
- 课程管理
- 课程版本管理
- 课时与教学进度管理
- 指定场景重生成
- 考纲管理
- 知识库或教材基础数据管理
- 课堂播放与互动教学
- 学生学习与课后复习
- 家长陪学与学习监督
- 课后复盘与复用
这意味着产品将从“单次课程生成工具”升级成“教师备课与课堂运行平台”,并进一步演化成“学校、老师、学生、家长协同的教学平台”。
4.3 目标用户
学校
关注:
- 组织、账号、权限
- 课程资产统一管理
- 教学标准和考纲统一
老师
关注:
- 快速备课
- 调整和重生成课程
- 按教学进度组织课时
- 课堂播放和互动教学
学生
关注:
- 更直观的讲解
- 多媒体学习体验
- 互动问答
- 测验和强化学习
- 自主探索感兴趣主题
家长
关注:
- 使用老师提供的课程进行陪学
- 帮助孩子复习和强化
- 了解孩子的学习进度和结果
5. 产品全景图
查看结构源码
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 课程生成流程
- 老师输入主题、课程要求或上传材料
- 系统理解输入并补充上下文
- 系统设计课程大纲
- 系统逐个生成场景内容
- 系统为内容生成讲解动作
- 系统生成图片、视频、TTS 等媒体
- 系统装配成完整课程并保存
7.2 备课调整流程
- 老师打开已有课程
- 发现某个场景不合适
- 对指定场景发起局部重生成
- 系统只更新对应场景内容或动作
- 老师确认并继续调整
7.3 课堂播放流程
- 老师选择课程和课时
- 系统载入课程
- 课堂播放器按场景顺序执行
- 语音、白板、聚焦、视频、讨论依次触发
- 进入互动、问答或测评场景
- 课堂结束后保存状态和结果
7.4 学生学习流程
- 学生进入老师发布的课程
- 学生完成学习、互动和测验
- 系统记录学生学习进度
- 学生可课后复习与强化
7.5 家长陪学流程
- 家长获取老师开放的课程
- 家长选择适合孩子的学习内容
- 孩子在家庭场景下完成学习或复习
- 家长查看学习过程与结果
8. 技术全景
8.1 当前技术思路
当前系统已经具备比较明确的技术骨架:
- 生成链路
- 运行链路
- 多 Agent 交互链路
- 存储与导出链路
虽然现有实现还有耦合点,但整体方向是对的。
8.2 当前系统的本质
从技术角度,本项目不是普通网站,而是四个子系统叠加:
- 课程生成引擎
- 课堂运行引擎
- 多 Agent 互动引擎
- 课程资产平台
8.3 系统分层
建议团队统一按下面五层理解系统:
表现层
- 首页
- 生成预览页
- 教师工作台
- 课堂播放页
- 学校管理页
- 学生学习端
- 家长陪学端
应用层
- 生成课程
- 局部重生成
- 保存课程
- 播放课程
- 发起讨论
- 提交测验
- 发布课程给学生
- 家长获取和使用课程
- 记录学生学习进度
领域层
Stage(课程)Scene(场景)Action(教学动作)- Agent
Asset(资源)- QuizState
- PlaybackSnapshot
- GenerationJob
领域服务层
- 大纲生成器
- 场景生成器
- 动作编排器
- 多 Agent 导演器
- 媒体编排器
- 导出器
基础设施层
- LLM Provider
- 图片 / 视频 Provider
- TTS / ASR Provider
- 数据库
- 对象存储
- 任务队列
- 流式通讯
9. 技术架构图
查看结构源码
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 --> I610. 生成与运行是两条不同的主链
团队最容易混淆的一点,是把“生成课程”和“运行课堂”看成同一件事。
实际上应该拆成两条链:
10.1 生成链
负责把输入变成课程资产。
输入:
- 主题
- 材料
- 教学目标
输出:
Stage(课程)Scenes(场景集合)Actions(教学动作集合)Assets(资源集合)
10.2 运行链
负责把课程资产作为课堂执行。
输入:
- 已生成课程
输出:
- 播放状态
- 互动事件
- 测评状态
- 课堂运行结果
11. 系统核心竞争力
从团队视角,这个项目的真正亮点不是“会生成 PPT”,而是下面几个组合能力:
- 课程结构化生成
- PPT 风格内容生成
- 讲解行为生成
- 多 Agent 互动
- 白板与多媒体融合
- 可播放课堂而不是静态课件
- 从老师工具走向学校、学生、家长协同平台的潜力
12. 未来平台化后的能力地图
查看结构源码
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. 推荐阅读顺序
如果新成员加入团队,建议按这个顺序看文档:
- 本文档
- [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)
- [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)
- [03-领域模型说明.md](./03-%E9%A2%86%E5%9F%9F%E6%A8%A1%E5%9E%8B%E8%AF%B4%E6%98%8E.md)
- [07-生成协议草案.md](./07-%E7%94%9F%E6%88%90%E5%8D%8F%E8%AE%AE%E8%8D%89%E6%A1%88.md)
- [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)
- [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 教学系统。
后续任何重构、选型和分工,只要围绕这句话展开,方向就不会偏。