easy-vibe Stage 2 大作业实战：基于 Express 与多角色权限构建在线考试与管理系统的完整指南
【免费下载链接】easy-vibe💻 vibe coding 101｜The first course for AI-native product builders.项目地址: https://gitcode.com/GitHub_Trending/ea/easy-vibe
导读
本文是 easy-vibe 课程 Stage 2（初中级全栈开发）的综合实战项目指南，围绕一份真实的 PRD 文档，带领你从零构建一个包含学生端、管理后台与官网前台三大子系统、基于 Node.js + Express 的在线考试与管理系统。读完本文，你将掌握如何从 PRD 提取开发任务、设计多角色权限控制与页面路由、用 Express 实现完整考试业务链路（登录鉴权 → 考试发布 → 答题提交 → 自动判分 → 成绩统计），并完成端到端联调与上线交付。
项目全景：为什么选择"在线考试系统"作为大作业
本实战项目是 easy-vibe Stage 2 大作业 体系中的第二个主线项目（大作业 2），它与大作业 1「文案生成 SaaS」形成递进关系：前者带你跑通现代 SaaS 最常见的"登录、生成、数据库、支付、管理后台"主链路，而本项目的核心价值在于多角色业务系统——学生和管理员登录后看到的页面不同、可执行的操作不同，这是教培、SaaS、后台管理等实际业务场景中反复出现的关键模式。
根据 Stage 2 课程索引 的定位说明，本大作业重点练习的能力包括：角色权限、题库建模、考试流程、提交记录、批改与统计，最终交付物是一个同时具备学生端和管理端的考试平台。
项目由三个子系统构成，各自的职责边界清晰：
| 子系统 | 职责 |
|---|---|
| 官网前台 | 平台介绍、登录入口 |
| 学生端 | 考试列表、答题、提交、成绩查看 |
| 管理后台 | 题库管理、考试管理、提交记录、成绩统计 |
后端统一使用 Express，需要支持的能力包括：登录鉴权、角色权限、考试与题库管理、提交流程与自动判分、成绩与统计管理。
在动手之前，请确认已经掌握以下前置知识：
- 前端页面设计与组件库使用（UI 设计、现代组件库）
- 后端接口设计与开发（接口代码编写）
- 数据库基础与 Supabase（从数据库到 Supabase）
- Git 工作流与部署（Git 和 GitHub 工作流、部署 Web 应用）
学习目标
完成本实战后，你将能够：
- 阅读并理解一份真实的 PRD，从中提取开发任务清单
- 设计多角色系统的权限控制和页面路由
- 使用 Express 实现完整的后端 API
- 实现考试、提交、自动判分的业务链路
- 完成端到端联调，交付一个可演示的业务系统原型
整个项目按四个阶段推进：需求分析 → 搭建骨架 → 后端开发 → 联调上线。
第一部分：需求分析
1.1 阅读 PRD，回答四个核心问题
本项目的需求文档即仓库内的 PRD.md。打开文档后，请带着以下四个问题去读，它们决定了后续所有设计与代码：
- 系统包含哪几个角色？各自能做什么？
- 页面清单是否完整？学生端和管理端分别有哪些页面？
- 支持哪些题型？每种题型的判分逻辑是什么？
- 考试的完整流程是什么？（发布 → 开始 → 作答 → 提交 → 判分 → 查看成绩）
⚠️ 如果以上问题没有明确答案，不要开始写代码。需求理解不清楚是导致返工的最常见原因。
对照 PRD，可以确认如下关键结论，这些是后续开发的事实依据：
角色与权限：PRD 将系统定义为典型的双角色模型，权限边界严格隔离：
| 角色 | 权限 |
|---|---|
| 学生 | 查看考试、开始答题、提交试卷、查看成绩 |
| 管理员 | 管理题库、考试、提交记录和成绩统计 |
技术选型建议（来自 PRD 第 1.1 节）：前端使用Next.js或React + Vite，后端使用Node.js + Express，数据库使用PostgreSQL，鉴权采用JWT + Role-based Access Control（基于角色的访问控制）。站点入口约定为三个独立子域：官网前台www.xxx.com、学生端app.xxx.com、管理后台admin.xxx.com，入口分离本身就是权限隔离的第一层体现。
MVP 范围：第一版必须包含登录、学生考试列表、学生答题页、提交结果与历史成绩、管理后台、题库管理、考试管理、提交记录与成绩查看；明确不做随机组卷、复杂防作弊、多校区多租户、监考视频——这意味着开发时不必为这些能力预留过度设计。
产品借鉴点：PRD 建议参考真实教学产品（如 Canvas 的信息分层：学生端与管理端职责清晰、不把全部功能放进同一个视图；Moodle 的题库与考试管理思路：题目、考试、提交、成绩应是独立模块）。由此提炼出页面设计原则：学生端强调"流程感"、管理端强调"配置感"、成绩页强调"结果感"、后台首页强调"概览感"。
1.2 确认系统架构
根据 PRD 梳理出系统的整体架构：
同时，PRD 定义了清晰的状态流，这是后端数据建模与接口设计时必须遵守的约定：
- 考试状态：
草稿 → 已发布 → 已关闭 - 提交状态：
进行中 → 已提交 → 已评阅 / 待复核 - 学生成绩：
未出分 → 已出分
第二部分：搭建项目骨架
2.1 用 AI 生成前端页面骨架
技术栈要求为Next.js App Router + TypeScript + Tailwind CSS + shadcn/ui。页面清单共 9 个页面，直接作为提示词（Prompt）输入给 AI：
请基于当前 PRD，帮我生成一个在线考试与管理系统的前端骨架。 技术栈要求： - Next.js App Router - TypeScript - Tailwind CSS - shadcn/ui 页面清单： 1. 首页 / 2. 登录页 /login 3. 学生考试列表页 /student/exams 4. 学生答题页 /student/exams/[id] 5. 学生成绩页 /student/history 6. 管理后台首页 /admin 7. 考试管理页 /admin/exams 8. 题库管理页 /admin/questions 9. 提交记录页 /admin/submissions 要求： - 学生端页面强调清晰、专注、易答题 - 管理端页面使用侧边栏 + 顶部栏布局 - 先使用 mock 数据，不接真实接口 - 注意桌面端和移动端的基本可用性对照 PRD 的页面架构（3 套入口、10 个大页面）可以验证：上述 9 个页面加上官网首页，正好覆盖 PRD 中列出的全部核心页面——官网首页 1 个、学生端登录/考试列表/答题/历史成绩 4 个、管理后台首页/题库/考试/提交记录/成绩统计 5 个。先使用 mock 数据、不接真实接口是刻意为之：它让你在骨架阶段就能确认交互与视觉，避免前端后端并行开发时互相阻塞。
2.2 完善学生答题页
答题页是学生端的核心页面，值得单独一轮提示词重点打磨：
请继续完善学生答题页。 这是一个在线考试系统的答题页面，需要包含： - 顶部显示考试标题、倒计时、已答题数量 - 中间显示题干和选项 - 支持单选、判断、简答三种题型 - 左侧或顶部有答题卡，显示每道题是否已作答 - 点击提交前弹出确认框 先用 mock 数据实现交互，不接真实接口。 要求： - 界面简洁，不要像后台表格页 - 倒计时要醒目，但不要制造过强压迫感 - 有空状态和 loading 状态这里隐含了 PRD 的非功能要求：答题页在倒计时和断网提示上要有明确反馈；同时答题卡（每道题是否已作答）与提交确认框直接支撑"学生能顺利完成考试流程"这一核心目标。注意区分：答题页是"考试场景"，界面要像考试而非后台表格；而管理端则是"配置场景"，用侧边栏 + 顶部栏承载大量管理功能。
2.3 完善管理员后台
管理员后台第一版聚焦三个核心区域：
- 考试管理：创建考试、设置时长、发布状态
- 题库管理：新增题目、编辑题目、按题型筛选
- 提交记录：查看学生提交、分数、时间
这三个区域分别对应 PRD 中的考试管理（创建考试、绑定题目、设置开始时间和时长、发布/关闭考试）、题库管理（新增/编辑题目、分类筛选、批量导入）与提交记录（查看学生提交、答案详情、人工复核），也对应后端成绩统计页所需的数据来源。
2.4 验证页面结构
骨架完成后，逐项检查：
- 学生端和管理端入口是否分开
- 登录页、考试列表、答题页、成绩页是否完整
- 管理端题库、考试管理、提交记录页是否可访问
- 学生端和管理端的页面风格有明显区分
如果你在前端搭建阶段卡住，可以回顾这些章节：从数据库到 Supabase、应用后端接口设计与开发、使用现代组件库更新你的界面。
第三部分：后端开发
3.1 登录与权限控制
后端是 Express。把需求完整交给 AI，注意提示词中明确要求"0 基础讲解"+"目录结构"+"中间件职责"+"环境变量不硬编码"+"验证方法"：
请把我当成 0 基础，帮我完成在线考试系统的登录与权限控制。 后端使用 Express。 目标： 1. 学生和管理员都可以登录 2. 登录后返回用户角色 3. 学生只能访问 /student/* 相关接口 4. 管理员只能访问 /admin/* 相关接口 5. 未登录用户访问受保护页面时跳转 /login 实现要求： - 给出清晰的目录结构建议 - 明确说明中间件负责什么 - 涉及环境变量的地方不要硬编码 - 完成后说明如何验证权限是否生效关于目录结构与分层，可以直接复用本课程 《应用后端接口设计与开发》 中给出的工程结构范式——不要让 AI 把所有代码堆进一个server.js：
my-api-project/ ├── .env # 环境变量（JWT 密钥、数据库连接串等敏感信息） ├── server.js # 项目入口（启动服务、注册全局中间件） ├── package.json # 依赖管理 ├── src/ │ ├── routes/ # 路由层：定义 URL 路径与请求方法 │ ├── controllers/ # 控制器层：解析请求参数、调用服务、返回响应 │ ├── services/ # 服务层：封装数据库交互与核心业务逻辑 │ └── middlewares/ # 中间件：鉴权、错误捕获等 └── docs/ # API 文档目录在权限设计上，多角色系统通常需要两类中间件配合：认证中间件（解析 JWT、确认用户已登录）与授权中间件（校验角色是否为 student/admin）。PRD 明确要求"学生端和管理员端权限必须严格隔离"，因此服务端接口也要做角色校验——这同时也是评分标准中"进阶要求"的一项：服务端接口也有角色校验。
3.2 考试与题库管理接口
建议按以下模块实现接口（表中同时列出了接口的完整路径）：
| 模块 | 推荐接口 |
|---|---|
| 考试管理 | GET /api/exams、POST /api/admin/exams、PATCH /api/admin/exams/:id |
| 题库管理 | GET /api/admin/questions、POST /api/admin/questions |
| 开始考试 | POST /api/submissions/start |
| 提交试卷 | POST /api/submissions/:id/submit |
| 成绩记录 | GET /api/student/history、GET /api/admin/submissions |
对照 PRD 第 8 节接口草案（/api/auth/login、/api/exams/:id、/api/admin/scores等共 12 个接口），可以发现上面这张表是它的核心子集，两者共同构成了完整的后端 API 面。设计时注意三点：
- 接口命名清晰：遵循 RESTful 规范，用资源名词而非动词命名路径（如
GET /api/exams而非GET /api/getExams），方法语义交给 HTTP 动词（GET/POST/PATCH）； - 统一 JSON 返回结构：所有接口返回一致的
{ code, data, message }风格结构，前端可以直接统一处理； - 分层清晰：controller、service、middleware、db 各司其职，便于测试与维护。
可以参考如下提示词让 AI 一次性生成：
请帮我为在线考试系统设计并实现 Express API。 功能范围： - 管理员创建考试 - 管理员维护题库 - 学生查看已发布考试 - 学生开始考试并创建 submission - 学生提交答案后自动判分单选题和判断题 - 简答题先标记为待复核 - 学生查看自己的历史成绩 - 管理员查看所有提交记录 要求： - 接口命名清晰 - 返回统一 JSON 结构 - 代码中区分 controller、service、middleware、db 层 - 说明每个接口如何测试3.3 判分逻辑
判分逻辑是考试系统的核心业务规则，按题型区分处理：
- 单选题：用户答案与标准答案一致则得分
- 判断题：同样可以自动判分
- 简答题：第一版先只保存答案，分数为空，状态为
reviewed = false（待复核）
这一规则与 PRD 的建议数据模型完全对应：questions表通过type（题型）、options（选项，jsonb 类型）、correct_answer（标准答案）、score（分值）字段支撑自动判分；submissions表通过status、total_score字段承载"待复核/已评阅"状态流转。PRD 明确"简答题是否只做人工复核"是待确认项，因此第一版实现为人工复核（或后续 AI 辅助）是稳妥的选择。
PRD 中给出的核心数据表结构如下（PostgreSQL）：
profiles ( id uuid primary key, email text, role text, created_at timestamptz ) exams ( id uuid primary key, title text, description text, duration_minutes int, status text, created_at timestamptz ) questions ( id uuid primary key, type text, stem text, options jsonb, correct_answer text, score int, created_at timestamptz ) submissions ( id uuid primary key, exam_id uuid, student_id uuid, status text, total_score numeric, submitted_at timestamptz )💡 加分项：如果你想让系统具备 AI 能力，可以让管理员在后台输入"主题 + 难度"，由模型先生成一批候选题目，经人工审核后加入题库。这属于加分项，不是必选项——注意不要因为追求加分而拖垮主线进度。
第四部分：联调与上线
4.1 端到端测试
前端骨架、后端 API 就绪后，必须至少验证两条完整链路：
- 学生链路：学生登录 → 查看考试列表 → 开始答题 → 提交 → 查看成绩
- 管理员链路：管理员登录 → 创建考试 → 添加题目 → 发布 → 查看提交记录
测试时重点核对 PRD 的非功能要求：交卷后成绩和答题记录能否稳定落库、自动判分与人工复核状态是否清晰、答题页倒计时与断网提示是否有明确反馈。可以借助课程中介绍的 Postman/Apifox 与 Jest 思路（见 接口代码编写 第 5 节）对核心接口做自动化验证，让 AI 帮你生成 Postman 导入配置与单元测试用例。
4.2 部署
部署方案按模块拆分：
- 前端部署到 Vercel / Zeabur
- Express API 部署到 Zeabur / Railway / Render
- 数据库使用 Supabase Postgres 或托管 PostgreSQL
部署前检查清单：
- 环境变量是否齐全（JWT 密钥、数据库连接串、API 地址等）
- 前后端 API 地址是否正确
- 登录态在生产环境是否正常
- 管理员账号是否能真实访问后台
- README 是否包含启动、部署、测试说明
关于 Zeabur 的具体部署流程，可以结合 部署 Web 应用 一课完成。
交付物要求
完成本项目后，需要提交以下内容：
- 可访问的线上演示链接
- 源码仓库链接（含 README）
- PRD 文档
- 核心页面截图（首页、学生考试列表、答题页、管理后台）
- 60 秒演示视频（覆盖学生答题流程和管理员管理流程）
README 至少包含：项目简介、核心页面说明、技术栈、本地启动步骤、环境变量清单。
评分标准
| 维度 | 基本要求 | 进阶要求 |
|---|---|---|
| 页面完整度 | 学生端和管理端主要页面都可访问 | 页面风格统一，移动端基本可用 |
| 业务闭环 | 学生可登录、参加考试、提交并查看成绩 | 管理员可完整创建并发布考试 |
| 数据正确性 | 提交答案后能写入数据库，客观题能自动判分 | 简答题支持人工复核或 AI 辅助 |
| 权限控制 | 学生与管理员访问边界清晰 | 服务端接口也有角色校验 |
| 工程交付 | 项目可运行、可部署、README 清晰 | 有演示视频和测试说明 |
对照这张表可以得出优先级结论：先保证基本要求全部闭环，再逐项冲击进阶要求——比如先确保"提交答案落库 + 客观题自动判分"跑通，再考虑简答题的人工复核或 AI 辅助。
提交前最终检查
- 首页、登录页、学生端、管理端页面均已完成
- 学生可以正常开始考试并提交答案
- 管理员可以创建考试并查看提交记录
- 客观题分数能够自动计算并写入数据库
- 学生与管理员权限边界已验证
- 项目已部署或具备完整本地运行说明
参考资料
- UI 设计
- 使用现代组件库更新你的界面
- 从数据库到 Supabase
- 大模型辅助编写接口代码与接口文档
- Git 和 GitHub 工作流
- 如何部署 Web 应用
- 项目需求文档 PRD
【免费下载链接】easy-vibe💻 vibe coding 101｜The first course for AI-native product builders.项目地址: https://gitcode.com/GitHub_Trending/ea/easy-vibe
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
