SeigRobotics开题之前，我想先把一个很多人容易忽略的问题说清楚：你做的这套教学评价系统，不是简单把纸质问卷搬到网页上，而是要在“计算机组成原理”这门课的特殊性上做文章。这门课卡在计算机系统结构的最底层，抽象程度高、实验环节重、学生两极分化严重，一套照搬通用课程的评价系统，大概率会在实际课堂里吃灰。设计这套系统时，我首先锁定的目标不是“评价功能齐全”，而是“评价维度贴合课程特性、数据输出能指导教学改进、评价闭环能真正跑起来”。
这份开题报告，既是给评审老师看，也是给自己梳理技术方案和工程边界。下面我就从背景分析、模块设计、数据库建模、权重算法、技术选型、安全兼容到进度安排，把整套设计思路展开说。
1. 为什么计算机组成原理课程需要一套独立定制的教学评价系统
1.1 课程本身的特殊性决定了评价方式不能“一刀切”
计算机组成原理课程和数据库、操作系统这类偏软件理论的课不一样，也和纯编程的课程不一样。它的知识结构横跨数字逻辑、汇编、体系结构、存储层次、I/O 系统多个层面，教学难点集中在几个地方：
- 抽象概念密度高，比如流水线冒险、Cache 映射方式、中断响应流程，如果没有图形化演示或实验辅助，学生单靠听课很难真正建立系统观。
- 实验环节占比大，从 Logisim 搭电路到基于 MIPS 指令集的单周期 CPU 设计，再到可能涉及的流水线扩展，每个阶段的学生体验差异非常大。
- 学生基础跨度大，有的学生数字逻辑底子好，有的学生 C 语言都有障碍，同样的教学内容在不同群体里反馈差距悬殊。
这种情况下，如果评价系统只设置“老师讲得清楚吗”“PPT 做得好不好”“课程是否有收获”这十几个通用题目，收集到的数据充其量只能说明学生喜不喜欢这门课，完全回答不了“Cache 映射这个知识点到底有多少人真正理解了”“实验二的三级反馈在哪里断档了”这类可以指导教学改进的问题。
1.2 传统教学评价模式的几个真实痛点
我在参与本科课程助教和教学改革项目时，接触过几轮常规教学评价流程，问题非常集中：
- 评价时间滞后。学校统一组织的学生评教放在期末，学生回忆一个学期前的具体教学细节已经很模糊，数据颗粒度粗糙，只能反映整体满意度。
- 评价维度单一。大多数评价表围绕教师态度、讲解能力、作业批改及时性，几乎没有针对具体知识模块、实验环节、教材配套资源的专项反馈。
- 评价结果难以追溯。即使某次评价显示“实验指导书不够清楚”，也无法定位到具体实验、具体班级、具体时间节点，教学改进缺少抓手。
- 评价数据隔离。学生的评教数据、出勤数据、实验成绩、作业完成情况存放在不同平台，无法交叉分析，比如“Cache 那一章没听懂的学生，是否在后续实验里也集中出现问题”这类问题根本找不到答案。
1.3 系统设计的三个核心约束
基于以上问题，我在系统设计阶段给自己定了三个约束条件：
第一，评价单元必须足够细。不能只有整门课的总体评价，至少要做到按知识模块（比如“存储系统”“中央处理器”）和按实验项目（比如“实验三：单周期 CPU 设计”）两个粒度采集数据。
第二，评价主体必须多元。除了传统的学生评教，还要加入教师自评、督导评价和系统自动采集的客观数据形成对照。学生说“听懂了”不算数，还要看实验完成质量是否匹配。
第三，评价结果必须形成闭环。系统不能止步于输出报表，要能生成教学改进建议，并在下一轮开课时追踪改进效果，否则就只是一个好看的数字仓库。
正是这三个约束，决定了后面所有的功能模块和技术选型。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 系统需求分析：角色模型、评价闭环与功能边界
2.1 五类用户角色的职责划分
教学评价系统最容易犯的错误是只围着“学生填表、老师看分”打转，角色设计过于单薄。我按照实际教学管理链路，将用户划分为五类：
| 角色 | 核心职责 | 典型操作 |
|---|---|---|
| 系统管理员 | 维护基础数据、账号授权、系统配置 | 管理用户、分配角色、设置指标库、参数配置 |
| 授课教师 | 查看评价结果、发起自评、维护课程信息 | 填写自评表、查询历史评价、导出分析报告 |
| 学生 | 提交课程评价、实验反馈、学习体验反馈 | 在线填写问卷、查看个人评价记录 |
| 教学督导 | 随堂听课评价、专项检查 | 填写督导量表、调阅课程评价数据 |
| 教务管理员 | 统筹评价任务、处理异常评价 | 发布评价批次、审核指标、汇总全校数据 |
这个角色划分的要点在于“评价任务”和“评价指标”是分离的。教务管理员可以每学期发布若干个评价批次，每个批次绑定不同角色需要填写的量表，而不是把一套量表硬套给所有人。
2.2 评价闭环的四个阶段
整个系统不是简单的问卷业务流，而是围绕“教学改进”构成一个闭环，我把它定义为四个阶段：
阶段一：数据采集。 通过在线问卷、实验节点小测、课堂反馈等多种方式收集主观和客观数据。主观数据来自学生、教师自评、督导，客观数据来自系统对接的实验提交记录、作业成绩和考勤数据。
阶段二：智能分析。 系统对主观评分进行加权聚合，自动生成课程画像。比如将“存储系统”知识模块下的所有评价条目聚合为一个维度分，再和该模块对应的实验成绩做相关性分析，输出“该模块授课逻辑清晰，但学生对替换算法的理解明显薄弱”之类的诊断。
阶段三：反馈呈现。 教师端不是一个简单的分数列表，而是带趋势图、班级对比、知识点热力图的综合看板。教学督导可以看到改进建议的闭环状态。
阶段四：改进追踪。 每一条改进建议都可以创建改进任务，设定下一个学期的检查点，学期结束时必须回填改进结果。如果同一知识点在连续两个学期都被系统标记为薄弱项，系统会向教研组发出提示。
2.3 功能边界与非功能需求
在开题阶段就明确“系统不做什么”同样重要，否则开发过程中需求会像雪球