教学管理平台

01 / 场景

场景与约束

任务式学习的教学形态本身在变：今天是观看视频并提交心得，明天是对弈记录，下周是 Scratch 作品。如果每引入一种题型就要改一次流程，教研和开发都会被拖住。同时这类平台面向未成年人，账号、内容、数据与互动都需要更明确的边界。

• 题型多样，流程重复建设，新内容上线慢
• 作品提交涉及图片、音视频，存储与访问需要权限控制
• 评阅与反馈过程需要留痕，便于教研复盘
• 未成年人数据与互动范围需要明确约束

02 / 方案

方案构成

平台把“任务”抽象成统一模型：配置、分配、进行、提交、评阅、反馈共用一套状态机，不同题型只是任务的不同呈现与提交形式。新增题型时接入新的交互组件即可，不必重写任务流程。管理端承接机构、班级、标签、角色与积分，教师端负责评阅与反馈，家长侧通过机构安排的方式查看进度。

• 任务模型：配置、分配、状态、提交、评阅、反馈
• 学生端：多种题型的统一任务列表与作品提交
• 教师端：评阅、评分、评语、退回与历史记录
• 管理端：机构、班级、标签、角色、积分与资源
• 资源服务：图片/音视频上传、鉴权访问与清理

03 / 技术

技术要点

学生端用 Flutter 统一承载多种交互，避免为每种题型单独做原生应用；资源上传走对象存储的临时凭证（STS），前端直传、后端只签发与校验，既降低服务端压力也避免密钥外泄；管理端用 React 构建，权限按机构与角色分层；评阅与提交记录保留完整历史，支持教研回看。

• 学生端：Flutter 多题型容器
• 管理端：React + 角色权限
• 资源：OSS + STS 临时凭证直传
• 记录：提交历史、评阅留痕、积分流水

04 / 交付

交付与验收

这类平台的验收看两件事：新题型能不能在不动主流程的前提下接进来；一次完整的教学周期（发布—完成—评阅—反馈—积分）能不能跑顺。交付时会用一个真实任务做端到端演练。

• 任务模型与题型接入说明
• 学生端、教师端、管理端可运行版本
• 资源上传与权限配置说明
• 积分与运营规则配置说明
• 端到端演练记录（一个完整教学周期）

05 / 边界

可复用与边界

统一任务模型可以复用到企业内训作业、社团活动管理与竞赛组织。边界需要强调：面向未成年人的产品在账号体系、内容审核与数据留存上要单独设计，不能照搬成人产品；新题型如果涉及第三方内容或版权素材，需要先确认授权；积分与激励规则属于运营策略，平台只提供配置能力，不对效果负责。

• 可迁移：企业内训作业、社团活动、竞赛组织
• 合规：未成年人账号、内容审核与数据留存单独设计
• 依赖：第三方内容与素材的授权情况