Phase 2 - 教学闭环增强

完善教学流程（资源、评分、互动），让平台具备完整教学使用能力。

⁋ 2.1 - 教学资源管理系统

实现教学资源的上传、管理与展示能力，支持课程中的课前学习与课后复习，完善教学闭环。

教学资源模型与数据结构设计

需要定义 “教学资源（Resource）” 这一实体，用于存储课程相关的学习材料，例如文档、视频、链接等。核心字段包括：资源名称、类型（文件 / 视频 / 链接）、所属课程、上传者、创建时间等。核心工程问题是：资源是课程的附属内容，必须与课程强绑定且结构清晰。同时需要考虑扩展性，例如未来是否支持分类（章节 / 模块）或标签。

教师上传资源功能

需要实现教师上传教学资源的接口，支持上传文件（如 PDF、PPT）或添加外部链接（如视频地址）。核心工程问题是：权限与内容管理，必须限制只有课程教师可以上传资源，同时要处理文件上传的基本问题（大小限制、格式限制）。MVP 增强阶段可以继续使用本地存储方案，保持简单。

资源列表与分类展示

需要实现资源列表接口，并在前端按课程展示资源内容。可以提供简单分类（如 “课件 / 视频 / 参考资料”），但不需要复杂结构。核心工程问题是：让学生快速找到需要的学习材料，避免资源堆积后难以使用。同时需要考虑排序（按时间或分类）。

学生资源访问与查看

需要实现学生查看与访问资源的功能，包括下载文件或跳转外部链接。核心工程问题是：访问控制与用户体验，确保只有课程成员可以访问资源，同时资源打开方式清晰（例如新窗口打开视频）。还需要处理资源不存在或失效的情况。

文件存储与路径管理优化

需要在已有文件上传机制基础上扩展资源文件存储，统一管理文件路径（例如按课程或资源类型分目录）。核心工程问题是：避免文件混乱与命名冲突，例如多个资源文件覆盖或难以定位。同时需要确保数据库记录与文件路径一致。

前端资源界面实现

需要在课程详情页中增加资源模块，展示资源列表，并提供上传入口（教师）与查看入口（学生）。核心目标是：让资源自然融入课程页面，而不是独立系统。需要处理不同角色的界面差异（教师可上传，学生只能查看）。

资源系统接口联调与验证

需要完成资源相关接口的联调，包括上传资源、获取资源列表、访问资源等，并验证完整流程。核心工程问题是：确保资源能正确关联课程并被学生访问，同时测试异常情况（无权限访问、文件缺失等）。

⁋ 2.2 - 成绩与评估系统

实现实验成绩记录与统计分析能力，使教师能够评估学生表现，并为学生提供学习反馈，完善教学闭环。

成绩模型与数据结构设计

需要定义 “成绩（Grade）” 这一数据结构，可以独立成表，也可以作为提交记录（Submission）的扩展字段（MVP 推荐直接加在 Submission 上）。核心字段包括：评分（score）、评语（comment）、评分时间、评分人等。核心工程问题是：成绩必须与具体提交绑定，而不是抽象挂在学生或实验上，否则无法支持多次提交与逐次评估。

教师评分功能实现

需要实现教师对学生提交进行评分的接口，支持填写分数与简单评语。核心工程问题是：权限与数据绑定，必须保证只有课程教师可以评分，并且评分对象必须是该课程下的提交记录。同时需要考虑重复评分（是否允许覆盖）以及评分更新逻辑（MVP 阶段允许覆盖即可）。

学生成绩查看功能

需要实现学生查看自己成绩的功能，包括每个实验的评分结果与评语。核心工程问题是：数据隔离与隐私保护，确保学生只能看到自己的成绩，而不能访问其他学生数据。同时需要处理 “未评分” 的情况（如显示 “待评分”）。

基础成绩汇总与统计

需要实现课程维度的成绩汇总，例如：每个学生的实验成绩列表，或简单平均分计算。核心工程问题是：从 “单个提交” 提升到 “整体表现”，为教师提供基本的教学反馈能力。MVP 增强阶段不需要复杂分析，只需支持基础统计即可。

提交与成绩关联展示优化

需要在前端将 “提交记录” 和 “成绩” 整合展示，例如在提交列表中直接显示该次提交的评分情况。核心目标是：减少信息割裂，让用户在一个视图中看到完整结果。同时需要区分最新提交与历史提交的成绩。

教师成绩查看界面

需要为教师提供查看全班提交与成绩的界面，例如按实验查看所有学生提交及评分情况。核心工程问题是：提高教师管理效率，避免逐个学生查看。同时可以提供简单排序（按分数 / 提交时间）。

成绩系统接口联调与验证

需要完成评分、查询、统计等接口的联调测试，验证完整流程：学生提交 → 教师评分 → 学生查看成绩。核心工程问题是：确保评估流程闭环成立，并测试异常情况（未评分、重复评分、权限错误等）。

⁋ 2.3 - 实时课堂与互动功能

实现基础实时通信能力，使教师与学生在课程中具备简单互动功能（消息与状态同步），增强课堂参与感。

实时通信方案选型（WebSocket）

需要选择并引入 WebSocket 作为实时通信方案，用于支持双向通信（服务器可主动推送消息）。核心工程问题是：HTTP 无法满足实时性需求，而 WebSocket 可以建立长连接。在后端（core）中需要集成 WebSocket 支持，并设计基础通信结构（如连接、断开、消息分发）。MVP 阶段不需要引入复杂中间件（如消息队列），保持简单实现即可。

房间（课堂）模型设计

需要设计 “课堂房间（Room）” 概念，每个课程可以对应一个实时房间，所有在线用户加入该房间进行通信。核心工程问题是：如何将实时通信与课程体系绑定，避免消息混乱（不同课程互相干扰）。需要维护房间 ID（如 course_id）与连接用户列表之间的映射关系。

在线状态与用户加入 / 离开机制

需要实现用户进入课程时自动加入对应房间，并在离开时断开连接或移除。可以维护一个简单的在线用户列表（如当前在线学生）。核心工程问题是：实时同步用户状态，让教师知道哪些学生在线。这一步不需要复杂心跳机制，简单连接管理即可。

核心实时消息功能

需要实现基础聊天功能，包括：发送消息、接收消息、广播到房间内所有用户。核心工程问题是：保证消息在正确范围内传播（只在当前课程内），并确保基本可靠性（不丢消息、不串房间）。消息结构需要统一（如发送者、内容、时间戳）。

教师广播与简单控制能力

需要为教师提供基础 “广播能力”，例如发送公告或提示消息（如 “开始实验”）。核心工程问题是：区分普通消息与系统消息，可以通过字段区分消息类型（chat / system）。MVP阶段不需要复杂控制（如禁言、分组等）。

前端实时交互界面实现

需要在课程或实验页面中加入实时互动区域（如侧边聊天框），用于展示消息与发送内容。核心目标是：增强课堂参与感，而不是重做一个聊天应用。需要处理消息展示、滚动、简单输入框等交互。

连接管理与异常处理

需要处理 WebSocket 连接异常情况，例如断线重连（简单版本即可）、连接失败提示等。核心工程问题是：保证系统在网络不稳定情况下仍然可用，避免用户完全失去交互能力。

实时功能联调与验证

需要完成实时功能的联调测试，包括：多用户同时在线、消息同步、加入离开房间等。核心工程问题是：验证多人场景下系统行为是否正确，例如消息是否同步、是否出现串消息等。

⁋ 2.4 - 前端体验与权限优化

优化系统整体交互体验与界面反馈机制，提高用户操作效率与系统可用性，使平台更加流畅、直观、可靠。

全局加载与状态反馈优化

需要为系统中的关键操作增加加载状态提示（如按钮 loading、页面 skeleton、数据加载中提示）。核心工程问题是：避免用户在等待时 “无反馈” 而误操作。例如提交实验时显示 “上传中”，课程加载时显示骨架屏。这一块实现成本低，但体验提升非常明显。

统一错误提示与交互反馈

需要建立统一的错误提示机制，例如接口失败时展示统一风格的提示（toast / snackbar），而不是直接报错或无反馈。核心工程问题是：让用户 “知道发生了什么”，例如 “登录失败：密码错误”、“提交失败：文件过大”。同时要避免技术性报错直接暴露给用户。

页面结构与导航优化

需要对页面结构进行整理，例如增加清晰的导航（顶部栏/侧边栏），明确 “当前位置”（如课程 → 实验）。核心工程问题是：避免用户迷路，尤其是在课程与实验层级较深时。可以增加简单的 breadcrumb（面包屑导航），提升路径感知。

表单体验优化（登录 / 创建 / 提交）

需要优化所有表单交互，包括输入校验提示（实时提示）、提交按钮状态控制（防止重复提交）、错误提示定位等。核心工程问题是：减少用户输入错误成本，例如密码不符合要求时提前提示，而不是提交后才报错。

实验提交流程体验优化

需要重点优化实验提交体验，包括：文件选择提示、上传进度显示、提交成功反馈、失败重试机制等。核心工程问题是：让用户对 “是否提交成功” 有明确感知。这是系统最核心的操作之一，体验必须清晰可靠。

空状态与边界状态处理

需要为 “无数据” 场景设计合理提示，例如：没有课程时提示 “还没有加入课程”，没有实验时提示 “暂无实验”。核心工程问题是：避免页面空白让用户困惑。同时需要处理加载失败、权限不足等边界情况。

基础视觉统一与样式整理

需要对整体 UI 做基础统一，例如按钮风格、字体大小、间距、颜色规范等。核心工程问题是：避免界面 “拼凑感”。不需要做设计系统，但至少保证视觉一致，让项目看起来更专业。

响应式与基础适配

需要对主要页面进行简单响应式优化，使其在不同屏幕尺寸下可用（至少保证在笔记本和常见分辨率下正常）。核心工程问题是：提升实际使用场景的适配能力。不需要专门做移动端，但至少避免布局崩坏。

用户操作流程复盘与优化

需要从用户视角重新走一遍完整流程（登录 → 课程 → 实验 → 提交 → 查看成绩），记录所有 “卡顿点” 或 “困惑点”，并逐一优化。核心工程问题是：发现设计阶段没意识到的问题，例如按钮不明显、跳转不直观等。

⁋ 2.5 - 日志系统与运行监控

实现基础日志记录与运行状态监控能力，提升系统可观测性与问题排查能力。

后端日志体系设计（核心入口）

需要在 core 服务中引入统一日志框架（如 logback），对系统关键行为进行日志记录，包括请求日志、错误日志、业务操作日志。核心工程问题是：当系统出问题时是否能 “看见发生了什么”。需要区分日志级别（info / warn / error），避免日志混乱或信息缺失。

接口请求日志记录

需要对所有 API 请求进行记录，包括请求路径、方法、参数（脱敏）、响应状态等。核心工程问题是：定位接口问题与用户行为路径。例如：用户提交失败，可以通过日志追踪请求链路。

错误日志与异常捕获机制

需要实现全局异常处理（如统一 exception handler），捕获系统异常并记录详细日志。核心工程问题是：避免错误 “悄悄发生” 却没有记录。日志中应包含错误信息、堆栈、请求上下文等。

教学行为关键业务日志

需要对关键业务操作进行记录，例如：创建课程、发布实验、提交实验、评分等。核心工程问题是：记录系统中的 “重要事件”，不仅用于调试，也为后续分析（甚至 AI）提供数据基础。

日志输出与查看方式

需要明确日志输出位置（控制台 / 文件 / Docker logs），并保证开发者可以方便查看。核心工程问题是：日志是否 “可用”，而不是只是写了却看不到。MVP 阶段推荐直接使用容器日志即可。

简单运行监控

需要对系统运行状态进行基础监控，例如服务是否启动、接口是否响应。可以通过简单方式实现（如健康检查接口 /health）。核心工程问题是：快速判断系统是否正常运行。

前端错误基础捕获

需要在前端捕获关键错误（如接口失败、渲染异常），并进行统一处理（提示或记录）。核心工程问题是：避免用户遇到 “无响应” 或白屏，同时为调试提供线索。

日志系统验证与问题排查演练

需要模拟一些异常情况（如接口报错、数据库断开），验证日志是否能正确反映问题。核心工程问题是：验证日志系统是否真正有用，而不是 “形式存在”。

⁋ 2.6 - 用户测试与反馈迭代

通过组织化用户测试与问题反馈机制，验证系统在真实使用场景下的可用性，并基于反馈进行针对性优化迭代。

基于教学流程的测试场景设计

需要围绕完整教学流程设计测试场景，例如：教师创建课程 → 学生加入 → 发布实验 → 提交 → 评分。每个场景应明确操作步骤与预期结果。核心工程问题是：测试是否覆盖真实使用路径，而不是零散功能验证。这些场景将作为后续所有测试的执行标准。

测试账号与数据准备

需要提前准备测试用账号（教师 / 学生）以及基础数据（课程、实验等），避免测试过程中频繁初始化数据。核心工程问题是：降低测试执行成本，提高测试效率。同时可以避免因数据问题导致的误判（如 “功能异常” 其实是数据缺失）。

多角色协同的用户测试执行

需要组织多角色测试（至少包含教师与学生），按照既定测试场景执行操作流程。核心工程问题是：验证系统在多用户协同下的行为是否正确，例如学生提交后教师是否能立即看到结果。

问题记录与复现路径整理

需要在测试过程中记录所有发现的问题，并明确复现路径（操作步骤 + 触发条件）。核心工程问题是：保证问题可定位、可复现、可修复，避免出现 “偶现问题无法处理” 的情况。建议使用 GitHub Issues 统一管理。

问题分类与优先级划分

需要对收集的问题进行分类，例如：功能缺陷、权限问题、交互问题，并划分优先级（阻塞 / 重要 / 一般）。核心工程问题是：控制迭代范围，优先解决影响系统可用性的关键问题，避免陷入低价值优化。

反馈驱动的迭代优化

需要针对高优先级问题进行修复，并在修复后重新执行相关测试场景。核心工程问题是：建立 “测试 → 修复 → 再测试” 的闭环机制，确保问题被真正解决，而不是临时规避。

回归测试与稳定性确认

需要在一轮修复完成后重新执行核心流程测试（1.7 中的主流程），确保新改动没有引入新的问题。核心工程问题是：防止修复一个问题引入新的问题，保证系统整体稳定性。

MVP 版本冻结与发布准备

在核心问题解决且流程稳定后，确定一个最终版本（MVP Release），停止新增功能，仅允许必要修复。核心工程问题是：控制项目收敛，确保系统具备交付条件，避免持续开发导致无法收尾。