Phase 1 - MVP 核心平台

实现 “课程 + 实验 + 提交” 的最小教学闭环，让系统可以实际使用。

⁋ 1.1 - 用户认证与权限系统

实现基础用户认证与权限控制能力，为课程、实验等功能提供统一身份体系与访问控制。

用户模型与数据结构设计

需要先定义系统中的 “用户是什么”，包括用户的基本属性（如用户名、邮箱、密码、角色等）以及角色类型（至少区分学生和教师）。这一环节的核心工程问题是：后续所有业务都依赖用户模型，如果这里设计不合理会导致大规模重构。需要明确是否支持扩展（例如未来增加管理员角色）、是否允许同一用户有多个角色，以及用户与课程之间的关系（为后续模块预留接口）。

用户注册功能实现

需要实现基础的用户注册接口，允许新用户创建账号。注册流程应包含输入校验（如用户名唯一性、密码强度）、密码加密存储（必须使用加密算法，如 bcrypt），以及错误提示机制。核心工程问题是：保证用户数据安全与系统稳定性，避免明文密码或重复账号等问题。同时需要考虑是否限制注册方式（开放注册或仅教师创建学生账号）。

用户登录与认证机制（JWT）

需要实现登录接口，并在认证成功后返回一个 JWT（JSON Web Token）用于后续请求鉴权。前端在登录后通过 HttpOnly cookie 管理登录态，并在后续请求中携带凭证。这里的核心工程问题是：建立无状态认证机制，支持前后端分离架构，避免使用传统 session 导致扩展困难。同时需要明确 token 的过期时间与刷新策略（MVP阶段可以先简单处理）。

鉴权拦截与接口保护

需要在后端实现统一的鉴权机制（如拦截器或过滤器），对需要登录的接口进行保护，确保只有携带有效 token 的请求才能访问。核心工程问题是：防止未授权访问敏感数据，并避免在每个接口中重复写鉴权逻辑。同时需要区分 “公开接口”（如登录 / 注册）与 “受保护接口”（如课程操作）。

角色权限控制（RBAC 基础）

需要实现基础的角色权限控制机制（RBAC），例如教师可以创建课程与实验，而学生只能加入课程与提交实验。核心工程问题是：避免后期权限逻辑散落在代码各处，需要在设计时统一处理权限判断（例如通过注解或统一方法）。MVP阶段不需要复杂权限系统，但必须保证基本角色隔离。

前端登录态管理

需要在前端实现登录状态的管理，包括：保存 token、页面刷新后恢复登录状态、未登录时自动跳转登录页等。核心工程问题是：保证用户体验与状态一致性，避免出现 “已登录但页面认为未登录” 或反之的情况。同时需要在请求封装中自动附带 token，减少重复代码。

用户基础接口联调与测试

需要完成前后端的接口联调，包括注册、登录、获取当前用户信息等接口，并通过工具（如 Postman）进行测试验证。核心工程问题是：确保接口契约真实可用，避免前端开发基于错误假设。同时需要测试异常情况（错误密码、token 失效等），确保系统行为可控。

⁋ 1.2 - 课程与班级管理系统

实现课程与班级的组织管理能力，使教师可以组织教学、学生可以参与课程，为实验系统提供归属结构。

课程模型与数据结构设计

需要定义 “课程” 这一核心实体，包括课程名称、描述、教师（创建者）、创建时间等基础信息，并明确课程与用户之间的关系（一个课程对应一个教师，多个学生）。这一环节的核心工程问题是：课程是整个系统的组织单位，必须保证结构清晰且可扩展。需要提前考虑：课程是否支持多个教师、是否需要课程状态（进行中 / 已结束），以及课程与实验的关系（一个课程下多个实验）。

教师创建课程功能

需要实现教师创建课程的接口，并限制只有教师角色可以执行该操作。创建课程时应记录课程基本信息，并自动将创建者绑定为课程负责人。核心工程问题是：权限控制与数据归属问题，确保学生无法创建课程，同时保证课程始终有明确的管理者。还需要考虑课程名称重复、非法输入等基本校验。

学生加入课程机制

需要实现学生加入课程的功能，常见方式可以是输入课程邀请码或由教师手动添加。MVP 阶段建议采用简单的邀请码机制（如生成一个唯一 code）。核心工程问题是：如何建立学生与课程之间的关联关系，并防止重复加入或非法加入。同时需要明确：一个学生可以加入多个课程，一个课程可以有多个学生。

教师视角课程成员管理

需要提供教师查看和管理课程成员的能力，包括查看学生列表、（可选）移除学生等基础操作。核心工程问题是：保证课程的可管理性，否则教师无法控制教学对象。同时需要注意接口权限控制，确保只有课程创建者或教师可以访问该功能。

课程列表与查询接口

需要实现课程列表接口，用于前端展示用户参与的课程。对于教师，应返回其创建的课程；对于学生，应返回其加入的课程。核心工程问题是：根据用户身份返回不同数据视图，并保证查询效率（避免后期数据量增大后性能问题）。可以预留分页能力，但 MVP 阶段可以简化实现。

前端课程界面实现

需要在 web 仓库中实现课程相关页面，包括课程列表页、课程详情页（展示课程信息与成员）。核心目标是：让用户可以直观地进入课程上下文。需要与后端接口联调，实现课程展示与加入流程（如输入邀请码）。同时要处理未登录或无权限访问的情况。

课程系统接口联调与测试

需要完成课程相关接口的前后端联调，包括创建课程、加入课程、获取课程列表等，并通过测试工具验证正确性。核心工程问题是：确保课程数据流转正确（创建 → 加入 → 查询），并验证异常情况（重复加入、权限不足等）。这一阶段要保证课程系统 “稳定可用”，为后续实验系统打基础。

⁋ 1.3 - 实验任务与提交系统

实现实验任务的发布与提交机制，建立完整的实践教学流程，使课程能够围绕实验开展教学活动。

实验模型与数据结构设计

需要定义 “实验（Experiment）” 这一核心实体，包括实验标题、描述、所属课程、发布时间、截止时间等信息，并明确实验与课程的从属关系（一个课程下可以有多个实验）。这一环节的核心工程问题是：实验是教学的核心载体，其结构必须稳定且可扩展。需要提前考虑：是否支持多次提交、是否需要实验状态（未开始 / 进行中 / 已结束），以及是否需要存储实验附件（如说明文档）。

教师发布实验功能

需要实现教师创建并发布实验的接口，并限制只有课程所属教师可以执行该操作。发布时应绑定课程，并设置必要信息（标题、内容、截止时间等）。核心工程问题是：权限与归属控制，确保教师只能在自己的课程下发布实验，同时防止无效或不完整数据（如缺少截止时间）。发布后的实验应对课程内学生可见。

实验列表与详情查询

需要实现实验列表接口（按课程获取）以及实验详情接口，用于前端展示实验信息。核心工程问题是：数据获取效率与结构清晰性，确保前端可以方便获取实验列表，并快速进入实验详情页面。同时需要考虑不同角色的视图差异（教师可见更多管理信息，学生只看到任务内容）。

学生实验提交机制（核心流程）

需要实现学生提交实验的功能，支持上传文件或提交文本/代码（MVP 阶段可以先支持文件上传）。每次提交都需要记录提交时间、提交内容路径、所属用户和实验。核心工程问题是：建立 “实验 → 提交 → 用户” 的完整链路，并确保数据不会丢失或混乱。同时需要考虑：是否允许多次提交（建议允许，并记录历史），以及如何区分最新提交。

文件上传与存储方案

需要设计实验提交文件的存储方式，可以采用本地文件存储（MVP 推荐）或对象存储（后期扩展）。需要实现文件上传接口，并保证文件路径与数据库记录一致。核心工程问题是：文件与数据库数据的一致性问题，以及避免文件覆盖或丢失。同时需要考虑文件大小限制与基本安全校验（避免恶意上传）。

提交记录与历史管理

需要实现提交记录查询功能，允许学生查看自己的提交历史，教师查看所有学生提交。核心工程问题是：保证数据可追溯性，否则无法进行评分或分析。同时需要明确排序规则（按时间）、是否标记“最新提交”、以及是否支持简单筛选（按学生/实验）。

教师查看与基础评估能力

需要提供教师查看学生提交内容的能力，并支持基础评估（例如简单标记或填写评分字段，MVP 可以不做复杂评分逻辑）。核心工程问题是：闭环教学能力，即教师不仅能发布任务，还能查看结果。这里不需要做自动评分或复杂评测系统，只要保证 “能看 + 能评” 即可。

前端实验界面实现

需要在 web 中实现实验相关页面，包括实验列表页、实验详情页、提交界面以及提交记录展示。核心目标是：让学生可以顺畅完成 “查看实验 → 提交实验” 的流程。需要处理文件上传交互、提交状态提示以及历史记录展示，并与后端接口完成联调。

实验系统接口联调与流程验证

需要对实验系统进行完整联调测试，验证整个流程：教师创建实验 → 学生查看实验 → 学生提交 → 教师查看提交。核心工程问题是：验证 “教学闭环是否真正跑通”。需要重点测试异常情况（重复提交、无权限访问、文件上传失败等），确保系统行为稳定可控。

⁋ 1.4 - 前端基础界面与路由框架

构建前端基础页面结构与路由体系，实现用户从登录到课程再到实验的完整操作路径。

前端项目初始化与技术框架搭建

需要在 web 仓库中初始化前端项目（推荐使用 Next.js），并建立基础项目结构（如 app / components / services / hooks 等）。同时需要配置基础依赖（如请求库 axios、状态管理工具等）。这一环节的核心工程问题是：确保前端项目结构清晰、可扩展，避免随着功能增加导致目录混乱或代码难以维护。

路由体系设计与页面结构规划

需要设计前端路由结构，明确各页面路径及跳转关系，例如 /login、/courses、/courses/[id]、/experiments/[id] 等。核心工程问题是：保证用户操作路径清晰且符合直觉，同时为后续扩展（如增加更多模块）预留空间。需要统一路由命名规则，并避免随意添加页面导致结构混乱。

登录页与认证流程实现

需要实现登录页面，并完成与后端登录接口的对接。登录成功后需要保存 token，并跳转到课程页面。核心工程问题是：建立前端认证流程与后端一致，避免出现登录状态不同步问题。同时需要处理登录失败提示、表单校验等基础用户体验。

全局登录态管理与路由守卫

需要实现全局登录状态管理（如使用 React Context 或状态管理工具），并在页面访问时进行鉴权判断，例如未登录用户访问课程页应自动跳转到登录页。核心工程问题是：保证系统访问控制一致性，避免用户在未登录状态下访问受保护页面。同时需要在请求封装中自动携带 token。

课程页面（列表 + 详情）实现

需要实现课程列表页面（展示用户参与的课程）以及课程详情页面（展示课程信息与实验列表）。核心目标是：让用户能够进入“课程上下文”。需要对接后端接口，展示课程数据，并提供加入 课程入口（如输入邀请码）。同时要处理加载状态与空数据情况。

实验页面（列表 + 详情 + 提交）实现

需要实现实验相关页面，包括实验列表（按课程展示）、实验详情页（显示实验内容）以及实验提交界面（文件上传）。核心工程问题是：保证实验流程顺畅，让用户能够完成 “查看 → 提交” 的完整操作。同时需要处理文件上传状态、提交成功/失败提示，以及基础交互体验。

API 请求封装与统一错误处理

需要对前端请求进行统一封装（如封装 axios），包括：自动附带 token、统一处理响应数据结构（code / message / data）、统一错误提示。核心工程问题是：避免每个页面重复写请求逻辑，并确保错误处理一致（如 token 过期自动跳转登录）。这一层会显著提升代码可维护性。

基础 UI 组件与样式规范

需要建立基础 UI 组件（如按钮、表单、卡片等）以及简单的样式规范（可以使用 UI 框架或自定义样式）。核心目标是：保证界面统一性与开发效率，避免每个页面风格不一致或重复造轮子。MVP 阶段不需要追求精美设计，但必须保证清晰可用。

前后端联调与交互流程验证

需要完成前端与后端接口的全面联调，验证完整用户流程：登录 → 查看课程 → 进入实验 → 提交实验。核心工程问题是：验证 “用户视角” 的完整流程是否通畅，而不仅仅是接口是否可用。同时需要测试异常情况（未登录、提交失败等），确保交互行为符合预期。

⁋ 1.5 - API 设计与前后端联调

完成前后端接口对齐与联调，确保系统各模块之间数据流转正确，打通完整用户操作流程。

API 接口清单整理与对齐

需要梳理当前系统所有已实现或计划实现的接口，形成统一的接口清单（建议写入 docs），包括：用户、课程、实验、提交等模块。每个接口需明确路径、方法（GET / POST）、参数、返回结构。核心工程问题是：避免前后端对接口理解不一致，例如字段命名不同、参数缺失等。通过提前对齐接口，可以减少联调阶段的反复修改。

Swagger / OpenAPI 文档完善

需要在后端完善基于 OpenAPI 规范的接口文档，并使用 Swagger UI 提供在线查看和调试能力。核心目标是：让前端可以 “自助开发” 而不是依赖口头沟通。文档中需要包含参数说明、示例请求与响应、错误码说明等。同时要保证文档与实际接口一致，避免 “文档失效”。

前端 API 调用封装与统一处理

需要在前端建立统一的 API 调用层（如 services/ 目录），封装所有接口调用，而不是在页面中直接写请求。核心工程问题是：避免请求逻辑分散在各个组件中，难以维护。封装中需要统一处理：baseURL、token注入、错误处理等，为后续扩展打基础。

用户模块联调（登录流程验证）

需要优先打通用户模块流程：登录 → 获取用户信息 → 登录态维持。核心工程问题是：认证链路是否稳定，包括 token 是否正确传递、是否能在刷新后恢复登录状态、token 失效时是否正确跳转登录。这一步是所有后续功能的基础。

课程模块联调（数据流验证）

需要完成课程相关接口联调，包括：获取课程列表、创建课程、加入课程等。核心工程问题是：验证“ 用户 → 课程” 关系是否正确建立，例如学生加入课程后是否立即可见、教师是否能看到课程成员等。同时需要测试异常情况（重复加入、权限不足）。

实验模块联调（核心流程验证）

需要重点联调实验系统，包括：教师发布实验 → 学生查看实验 → 学生提交 → 教师查看提交。核心工程问题是：验证整个教学闭环是否真正跑通。需要特别关注文件上传是否成功、提交记录是否正确关联用户与实验，以及最新提交是否能正确识别。

统一错误处理与异常流程验证

需要在联调过程中统一处理错误返回，例如：接口失败提示、token 过期处理、权限不足提示等。核心工程问题是：保证系统在异常情况下行为可控且用户可理解，而不是出现无响应或报错页面。同时需要确保前端能够根据错误码做出合理处理（如跳转登录或提示用户）。

联调测试与问题修复循环

需要进行多轮联调测试，每轮包括：完整流程测试 → 记录问题 → 修复 → 再测试。核心工程问题是：发现并解决模块之间的 “隐性问题”，例如数据字段不一致、接口响应延迟、状态更新不同步等。这一阶段往往会暴露大量细节问题，需要持续迭代直到流程稳定。

⁋ 1.6 - 核心数据库设计与实现

设计并实现支撑用户、课程与实验系统的核心数据库结构，确保数据关系清晰、可扩展且支持完整教学流程。

核心实体识别与关系建模

需要基于已有功能（用户、课程、实验、提交）明确系统中的核心实体，并梳理它们之间的关系，包括：用户（User）、课程（Course）、课程成员（CourseMember）、实验（Experiment）、提交记录（Submission）。核心工程问题是：确保数据结构能够完整表达业务关系，例如学生与课程是多对多关系，因此必须通过中间表（CourseMember）实现，而不能简单依赖字段冗余。

用户表（User）设计

需要设计用户表，存储系统中所有用户的基础信息，包括用户名、邮箱、密码（加密）、角色等。核心工程问题是：保证用户数据安全与唯一性，需要对用户名或邮箱设置唯一约束，并确保密码以加密形式存储。同时需要预留扩展字段（如头像、状态），避免后期频繁改表。

课程与成员关系表设计

需要设计课程表（Course）以及课程成员表（CourseMember），分别用于存储课程信息和用户与课程的关联关系。核心工程问题是：正确建模多对多关系，即一个课程有多个学生，一个学生可以加入多个课程。CourseMember 表需要记录用户 ID、课程 ID 以及角色（学生/教师），避免将关系写死在单一字段中。

实验表（Experiment）设计

需要设计实验表，存储实验的基本信息，包括所属课程 ID、实验标题、描述、发布时间、截止时间等。核心工程问题是：确保实验与课程强关联，并支持未来扩展（如实验状态、附件等）。同时需要考虑时间字段的使用（方便后续判断实验是否过期）。

提交记录表（Submission）设计（核心）

需要设计提交记录表，用于存储学生提交的实验结果，包括用户 ID、实验 ID、提交时间、文件路径、是否为最新提交等字段。核心工程问题是：支持多次提交与历史记录追踪，必须允许一个用户对同一实验有多条提交记录，并通过字段（如 is_latest）标识最新提交，方便查询与后续评分。

基础索引设计与查询优化

需要为关键字段建立索引，例如用户 ID、课程 ID、实验 ID 等，以提高查询性能。核心工程问题是：避免随着数据增长导致查询变慢。虽然 MVP 阶段数据量不大，但提前建立合理索引可以避免后期性能问题。同时需要避免过度索引导致写入性能下降。

数据一致性与约束设计

需要为表之间建立基本约束（如外键或逻辑约束），确保数据一致性，例如提交记录必须关联有效用户与实验。核心工程问题是：防止出现 “脏数据”（如不存在的课程 ID、用户 ID）。如果不使用数据库外键，也需要在业务层进行校验，保证数据合法性。

数据库初始化与迁移脚本

需要编写数据库初始化脚本（SQL）或使用迁移工具（如 Flyway），用于自动创建表结构。核心工程问题是：保证不同环境数据库结构一致，避免 “我这边表结构不一样” 的问题。同时需要支持后续版本迭代（例如新增字段）而不破坏已有数据。

数据库与后端代码对齐

需要将数据库表结构与后端实体类（Entity）进行映射，并确保字段命名、类型一致。核心工程问题是：避免代码与数据库脱节，例如字段名不一致导致数据读取错误。同时需要完成基础的 CRUD 操作实现，并进行简单测试验证。

⁋ 1.7 - MVP 集成测试与基础稳定性验证

通过系统化测试验证用户、课程与实验流程的完整性与稳定性，确保系统在真实使用场景下可用、可控、可复现。

构建标准测试流程（核心主线）

需要定义一套 “从用户视角出发” 的完整操作流程，并作为所有测试的基准。这不是简单测接口，而是模拟真实教学场景。核心工程问题是：确保系统核心闭环真正可用，而不是各模块各自正常。建议固定一条标准流程，例如：教师注册登录 → 创建课程 → 学生注册登录 → 加入课程 → 教师发布实验 → 学生提交实验 → 教师查看提交。所有测试都围绕这条主线展开，并反复验证。

功能测试（逐模块验证）

需要对每个模块进行功能验证，包括用户（注册 / 登录）、课程（创建 / 加入）、实验（发布 / 提交）等。核心工程问题是：确保每个功能在正常情况下都能正确工作。测试时需要覆盖基本操作路径，并记录结果（成功 / 失败），避免 “感觉能用但实际有问题”。这一阶段可以手动测试为主，重点是覆盖关键功能。

异常与边界测试

需要刻意测试各种异常情况，例如：错误密码登录、重复加入课程、未登录访问接口、提交空文件、超过截止时间提交等。核心工程问题是：验证系统在异常情况下是否行为合理，避免崩溃或返回不可理解的错误。这一类测试往往比正常流程更重要，因为它决定系统的稳定性与用户体验。

权限与安全性验证

需要测试不同角色的权限边界，例如学生是否能创建课程、是否能查看他人提交、教师是否能访问非自己课程的数据等。核心工程问题是：防止越权访问与数据泄露。这一步必须站在“恶意用户”的角度去测试，而不是只验证正常路径。

数据一致性验证

需要检查关键数据是否在整个流程中保持一致，例如：学生提交后，是否能在教师端看到；课程成员变更后，是否立即生效；最新提交是否正确标记。核心工程问题是：防止 “数据看起来对，但其实不一致”，这类问题在后期会非常难排查。

前后端联动与状态验证

需要重点测试前端与后端之间的状态同步，例如登录状态是否正确保持、token 过期是否处理、接口错误是否正确提示。核心工程问题是：避免 “接口没问题但用户体验崩溃”，例如页面卡死、无提示错误等。

轻量级基础性能与并发测试

MVP 阶段不需要复杂压测，但需要做简单验证，例如：多用户同时提交实验、快速重复操作接口等。核心工程问题是：发现明显的性能瓶颈或接口不稳定问题，避免系统在稍微多人使用时崩溃。

Bug 记录与修复闭环

需要建立简单的 Bug 管理机制（可以用 GitHub Issues），记录发现的问题、复现步骤、修复状态。核心工程问题是：避免问题被遗忘或重复出现。每个 Bug 应包含：问题描述、复现路径、预期行为、实际行为。

最终验收与 MVP 发布标准

需要在测试完成后定义 “可以发布” 的标准，例如：核心流程无阻塞、无严重 Bug、所有关键功能可用。核心工程问题是：明确 “什么时候算完成”，避免无限打磨或过早结束。可以用一份 checklist 作为最终验收依据。