做计算机毕业设计选系统类题目的同学，十有八九都经历过这样的焦虑：题目拿到手框架没头绪，代码写了一半发现需求理解偏了，最后勉强写完又担心答辩过不了。校企合作的大学生实训管理系统这个题，这几年在高校里出现频率相当高，说不清是学校在推产教融合的硬性需求，还是题库里的长期保留项目，反正每年都有人选，每年都有人做到一半换题。这篇文章就围绕这个题目，从选题拆解到技术落地，再到论文答辩，把整个过程中的关键节点和实操经验捋一遍。我基于实际开发这类系统的常见做法，把项目整体拆解讲透，代码层面的核心模块也会给出直接能用的实现思路。不管是刚拿到题目不知道怎么起步，还是已经写了一半因为需求纠缠想放弃，这篇文章都能给你一个明确的方向。
1. 项目到底在解决什么问题
1.1 校企合作实训场景里的真实痛点
先把需求讲透。很多同学拿到这个题目，第一反应是做成一个"实习生管理系统"，无非是学生登录、企业登录、发个实习任务、学生交个周报。但你要真按这个思路去答辩，评委大概率会追问一句：你这个系统和普通的任务管理软件有什么区别？
校企合作这种场景，真正的痛点在哪？我做了几个类似项目之后总结下来，比较典型的有这么几个：
第一是信息断层。学校从组织层面有实训教学计划，企业有人才培养需求，但两边系统不互通。很多高校目前的流程仍然是这样的：教学秘书通过微信群或者Excel表格下发实习通知，学生自行找企业盖章，校内导师通过邮件收周报，企业导师的反馈意见写在纸质表格里，期末教务处统一收各类材料归档。这中间的信息损耗非常大——学生的真实在岗情况、企业导师的实际评价、校内导师的过程跟踪，都分散在不同的载体里，学期末汇总成绩时教务人员光是核对表格就要花好几天。
第二是过程数据缺失。产教融合这件事，学校真正看重的是实习过程有没有落实，而不是终期的一份鉴定表。企业导师辅导了哪些内容，学生遇到什么问题、解决了什么，这些过程数据需要留存。以前的系统往往只做一个结论性的评分，过程性的记录一盘散沙，真到了教学质量评估或专业认证的时候拿不出支撑材料。
第三个是多方协同的组织成本。一个实训项目牵扯到校内导师、企业导师、学院管理员、教务处、学生本人五类角色，每个角色关心的信息不一样：学生想看得清楚自己的任务安排和成绩反馈，企业导师要方便查看学生跟进记录和提交的材料，校内导师需要定期给出指导建议和评分，学院管理员要掌握进度汇总和统计报表，教务处则需要全局监控各专业的实习执行情况。没有统一的平台，这些信息流转全靠人工转发和汇总，效率极低且容易出错。
这个系统能解决的问题，就是把这套流程线上化：项目发布、学生报名、企业审核、过程记录、双导师评价、成绩生成，全链路在一个平台里跑完。对学校来说，过程数据自动沉淀；对企业来说，学生选拔和过程管理有迹可循；对学生来说，实习任务和反馈随时可查。课程设计做到这个完整度，就已经比市面上很多半成品高一个档次了。
1.2 核心用户与角色权限分析
这个系统的角色划分比较典型，适合作为权限设计的实践。通常我会把它分成六类角色：
| 角色 | 核心操作 | 权限边界 |
|---|---|---|
| 学生 | 报名实训项目、提交周报月报、查看评价结果 | 只能看到自己相关的项目和记录 |
| 企业导师 | 审核学生报名、查看学生周报、给出阶段性评价、发布企业任务 | 只能操作自己名下/本企业的项目和关联学生 |
| 校内导师 | 审核所在学生的报名、跟踪学生实习进度、给出校内评分 | 只能管理自己带教的学生 |
| 学院管理员 | 审核实训项目发布、查看本学院统计数据、管理师资配置 | 学院维度数据 |
| 校企管理员 | 管理企业信息、审核企业导师账号、查看企业合作项目 | 企业维度数据 |
| 系统管理员 | 所有配置、账号管理 | 全局维度 |
这样设计有个好处，就是可以直接拿来做RBAC权限模型。别急着给每个角色写一套独立的登录逻辑，用一张user表加上角色字段就够入门了，进阶方案就用Spring Security或Sa-Token做细粒度控制，答辩讲权限设计这块能讲得很充分。
1.3 核心业务流程梳理
流程是整个项目的骨架，先把主流程理清楚再动手写代码，可以避免后期大改：
教务处/管理员发布实训项目，往往包含岗位名称、招收人数、报名截止时间、实习周期等信息。学生在截止日期前看到项目并提交报名申请，报名阶段通常需要附上简历或选课情况等补充材料。校内外导师负责对报名学生进行审核，这个环节可以设计成“企业导师初筛+校内导师确认”的双重审核机制，避免企业完全不熟悉学生背景导致错配。
审核通过后，学生进入正式实习周期。实习周期内系统按周和按月自动生成填报任务，学生定期提交工作内容和总结，校内导师和企业导师分别对提交内容进行评价，评价结果计入过程成绩。执行过程中如果出现岗位调整或提前终止等异常情况，管理员可以手动调整状态并留痕。实习周期结束后，系统根据双导师评分、过程完成度等情况生成综合成绩，导出到教务系统归档；最终实训报告和各项材料进入历史档案，支撑后续的教学评估查询。
这一条主线捋顺了，后面数据库设计和模块划分就有了明确的依据。
2. 技术选型与架构设计
2.1 为什么用SpringBoot而不是传统SSM
毕设里出现这个题目，主流技术选型就是SpringBoot。有些同学可能纠结，学校课程里教的是Spring MVC + JSP那套老古董，直接上手SpringBoot会不会有风险？不会，反而更稳。
SpringBoot的意义在于把配置的复杂度降下来。传统SSM你需要自己搞定web.xml、springmvc.xml、mybatis-config.xml三份配置文件的协调，光一个包扫描路径错了就能排查半天。SpringBoot用自动配置把大多数默认场景覆盖掉，你只要关注业务代码本身。这一点放到开发效率上差别很大——我接触过的同学里，用SSM写这类系统光环境搭建就花了两周，用SpringBoot的脚手架项目第一天就能把用户登录跑起来。
选择SpringBoot还有一个实际的考量：答辩时评委对新技术的接受度。SpringBoot从2016年发布至今已经非常成熟，它解决了什么问题、和Spring生态的关系，稍微准备一下就能讲清楚。相比之下，用传统SSM反而显得技术陈旧，评委的第一印象就不太好。
版本选择建议用SpringBoot 2.7.x，不用刻意追3.x。SpringBoot 3要求JDK 17起步，有些实验室机器JDK还在8，部署时候环境问题会折腾半天。2.7版本配合JDK 8，稳得一批，兼容性也是所有版本里最成熟的。如果要用更高版本一定要注意前后端依赖兼容性。
2.2 数据库设计的核心思路
这类管理系统的数据库设计，核心不在表的数量多，而在关系梳理得是否清晰。给出我的一份常用表设计清单，你可以根据自己的业务细节再扩展：
| 数据表 | 核心字段 | 设计说明 |
|---|---|---|
| user | id, username, password, role, name, phone | 统一账号表，角色通过字段区分 |
| enterprise | id, name, industry, contact, credit_code | 企业信息，由管理员维护 |
| student_profile | id, user_id, major, grade, student_no, resume_url | 学生扩展信息，与user一对一 |
| teacher_profile | id, user_id, title, department, enterprise_id | 导师扩展信息，企业导师关联企业 |
| training_project | id, title, description, enter_id, max_students, start_date, end_date, status | 实训项目主表 |
| signup_record | id, project_id, student_id, status, audit_comment, audit_time | 报名记录，状态字段标识审核进度 |
| intern_batch | id, project_id, student_id, school_teacher_id, enter_teacher_id, start_date, end_date | 学生在项目下的实习批次 |
| report_record | id, intern_batch_id, type(week/month), content, file_url, submit_status, school_score, enter_score | 周报/月报，用type字段区分 |
| evaluation_task | id, intern_batch_id, evaluator_role, score_item, score, comment | 评价任务，支持多维度评分 |
| notice | id, title, content, receiver_role, publish_time | 通知公告，面向角色推送 |
有几个设计上的建议值得特别强调。逻辑删除字段比物理删除更符合这个场景：实训记录属于教学留痕数据，删除操作按学校管理规范通常需要保留操作日志，我用框架自带的逻辑删除就能避免误删带来的数据安全隐患，同时加删除人、删除时间字段记录操作轨迹。乐观锁版本号放在报名和评价这类并发关注度高的表上，防止两个导师同时审核时出现状态覆盖。实习批次表要加唯一约束，保证一个学生在同一时间段只能参与一个实训项目，这个约束在数据库层面做一次硬校验，能挡住大多数业务bug。
状态字段不要用无含义的数字。比如status用0、1、2会让后续维护非常痛苦，我习惯在Java里建枚举类，数据库存字符串编码（如PENDING、APPROVED、REJECTED），这样代码可读性高，排查日志问题的时候看到状态值就能直接对应上业务含义。
2.3 前端方案与工程目录规划
毕设的前端不建议从零手写，时间和精力投入产出比不划算。常见的选择有两个：一是Vue3 + Element Plus自己搭一套轻量前端；二是直接基于RuoYi等开源前后端分离框架做二次开发。如果目标是尽快把系统跑通，我更推荐后者，因为框架里已经把登录、权限、用户管理、代码生成这些通用能力都做好了，你只需要专注于业务代码。
不过用开源框架有个前提：答辩前必须把框架自带的代码理解清楚。很多同学用了RuoYi之后，被问到时"这个菜单权限是怎么做的"，支支吾吾答不上来，印象分直接就降了。
如果你选择技术栈是Vue3 + Element Plus + Spring Boot这种组合，目录规划建议按模块分包，而不是按技术层分包：
com.example.training ├── common // 公共类：统一返回结果、异常处理、工具类 ├── config // 配置类：拦截器、跨域、文件上传 ├── controller // 控制层：按业务模块分包 │ ├── admin │ ├── enterprise │ ├── student │ └── teacher ├── service // 业务逻辑层 ├── mapper // 数据访问层 └── entity // 实体类按模块分包的好处是，当你想找报名相关的接口时，直接进controller/student就能找到，不用在一堆类里翻。答辩演示时也容易讲：点击报名，请求到StudentSignupController，再进SignupService，层层往下走，逻辑清晰。
3. 核心模块开发实战
3.1 实训项目发布与报名模块
整个系统的第一个核心业务点，是项目发布和报名。这里藏着两个坑：一是学生重复报名同一个项目，二是学生在时间冲突的情况下报了多个项目。这两个问题不处理，后患无穷。
在Service层加一个防重复校验：
public Result signUp(SignupDTO dto, Long studentId) { // 1. 校验项目是否存在且处于报名中 TrainingProject project = projectMapper.selectById(dto.getProjectId()); if (project == null || !"SIGNING".equals(project.getStatus())) { return Result.fail("项目不存在或不在报名期内"); } // 2. 防止重复报名 Long count = signupMapper.selectCount(new LambdaQueryWrapper<SignupRecord>() .eq(SignupRecord::getProjectId, dto.getProjectId()) .eq(SignupRecord::getStudentId, studentId) .eq(SignupRecord::getIsDeleted, 0)); if (count > 0) { return Result.fail("你已经报名过该项目，请勿重复提交"); } // 3. 报名人数上限校验 Long signed = signupMapper.selectCount(new LambdaQueryWrapper<SignupRecord>() .eq(SignupRecord::getProjectId, dto.getProjectId()) .in(SignupRecord::getStatus, "PENDING", "APPROVED")); if (signed >= project.getMaxStudents()) { return Result.fail("该项目报名人数已满"); } // 4. 插入一条待审核记录 signupMapper.insert(new SignupRecord(project.getId(), studentId, "PENDING")); return Result.success(); }时间冲突的校验稍微复杂一点。学生报名时，系统要去比对已审核通过的实习批次时间区间：
private boolean hasTimeConflict(Long studentId, LocalDate startDate, LocalDate endDate) { LambdaQueryWrapper<InternBatch> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(InternBatch::getStudentId, studentId); wrapper.eq(InternBatch::getStatus, "RUNNING"); wrapper.le(InternBatch::getStartDate, endDate); wrapper.ge(InternBatch::getEndDate, startDate); return internBatchMapper.selectCount(wrapper) > 0; }核心就是区间重叠的判定条件，"当前实习的开始时间小于等于新项目的结束时间，且当前实习的结束时间大于等于新项目的开始时间"，两条记录如果有任何一个时间点重叠，就说明冲突。这个条件推导清楚，代码只有四行，但很多同学到答辩被问到这里时才反应不过来，所以要理解背后的区间交叉原理，面试或答辩时都是加分点。
3.2 实习过程记录：周报、月报的提交与审核
过程化管理的核心体现，就在周报/月报这一块。设计上有几个细节需要提前想清楚：
用一张表通过type字段区分周报和月报，不要建两张结构几乎一样的表。这样查询某个学生的全部记录时一个条件就搞定，代码也简洁。
提交时间窗口的控制很关键。实训期间，系统在每周日开放周报提交，持续到次周二截止，逾期标记为补交。这个逻辑我用一个状态字段加时间判断来处理：submit_status在0为未交，1为已交，2为补交，3为已批阅，这样成绩统计时能直接区分按时完成和补交的情况，学分绩点换算时有据可依。
内容方面，周报应包含文本内容和可选附件。学生提交后，企业导师和校内导师可以分别查看并给出点评。注意这里的点评只是过程反馈，不做评分，真正的评分集中在评价任务模块。这样的设计符合"过程记录和结果评价分离"的教学管理理念，如果实训期间有任何争议或申诉，导师点评记录就是最有力的原始凭证。
以下是提交周报的Service层核心代码：
public Result submitReport(ReportSubmitDTO dto, Long studentId) { // 1. 查询当前进行中的实习批次 InternBatch batch = internBatchMapper.selectOne(new LambdaQueryWrapper<InternBatch>() .eq(InternBatch::getStudentId, studentId) .eq(InternBatch::getStatus, "RUNNING")); if (batch == null) { return Result.fail("当前没有进行中的实训项目，不能提交周报"); } // 2. 防止同一时间段重复提交 Long count = reportMapper.selectCount(new LambdaQueryWrapper<ReportRecord>() .eq(ReportRecord::getInternBatchId, batch.getId()) .eq(ReportRecord::getType, dto.getType()) .eq(ReportRecord::getSubmitDate, dto.getSubmitDate())); if (count > 0) { return Result.fail("该时间段报告已提交，不能重复提交"); } // 3. 保存报告，状态设为待批阅 ReportRecord record = new ReportRecord(); record.setInternBatchId(batch.getId()); record.setType(dto.getType()); record.setContent(dto.getContent()); record.setFileUrl(dto.getFileUrl()); record.setSubmitStatus("SUBMITTED"); reportMapper.insert(record); return Result.success(); }这个模块里的一个加分项：在管理端做一个提交率统计。可以看到某个实训项目下，有多少学生按时提交、多少学生补交、多少学生未交。一张柱状图或者饼图，加分效果直接拉满。ECharts接入也不复杂，后端提供一个按项目ID查统计数据的接口就行。
3.3 校企双导师评价体系的实现
双导师评价是这个系统最有区分度的功能，也让它在毕设答辩时可以重点展开。设计思路我建议做两层评价：
第一层是过程性评价，和第二点的周报点评不同，是在关键节点由双导师对学生的表现打分，比如中期评价和终期评价。每次评价包含多个评分项，比如工作态度、专业能力、协作沟通、成果质量，每个评分项按1到5分打分；第二层是总结性评分，实习结束后由双导师分别给一个综合分，最终成绩按“企业导师50% + 校内导师50%”加权汇总。
表结构上，评价项建议单独建一张表，方便后续调整权重。如果你想让项目更加细致，可以在评价任务表里增加evaluator_type字段，标识这条评价记录是来自企业还是校内，再做一次聚合统计就能得到学生成绩。
@TableName("evaluation_task") public class EvaluationTask { @TableId(type = IdType.AUTO) private Long id; private Long internBatchId; private Long evaluatorId; // 评价人 private String evaluatorType; // ENTERPRISE / SCHOOL private String scoringItem; // 评价项，如"工作态度" private Integer score; // 1-5分 private String comment; private LocalDateTime createTime; }做这个模块的时候要注意一个细节：评价者对同一个学生在同一个评价轮次不能重复打分，这个校验必须在Service层做，不能只靠前端隐藏按钮。否则两个浏览器页面同时打开，先提交的还没刷新，后提交的就能重复插入一条记录。
我在做完整项目时还会加一个评价超时提醒机制：企业在终期评价结束前三天还没有提交评价时，系统自动生成待办提醒。设计思路是用定时任务每天扫描一次，查一下当前日期近截止日期但状态为待评价的记录，插入到notify表。这个功能很小，但是在答辩时，能表现出你对业务流程的思考深度。
3.4 成绩汇总与实习报告导出
当所有评价数据都有了，学习成绩的汇总就很自然了。学院管理员选择专业、年级、实训项目批次，一键生成成绩单。成绩计算逻辑写在Service层，这里要注意的是分数保留精度，建议使用BigDecimal运算而不是double，否则容易出现86.0变成85.99999的尴尬情况，答辩展示会被抓着不放。
导出成绩单用EasyExcel或POI。EasyExcel更推荐，内存占用更少，API也更简单：
EasyExcel.write(outputStream, ScoreRow.class) .sheet("实训成绩") .doWrite(dataList);生成的Excel里面包含学生姓名、学号、专业、班级、项目名称、企业导师评分、校内导师评分、总分、等级（优秀/良好/中等/及格/不及格）这些列。界面展示之外再带一个Excel导出能力，整个系统的完整度就很像样了。
另外学生端也提供一个实习证明导出功能，生成一份简单的PDF或Word证明，包含实习单位、起止时间、岗位名称。技术上我用的是poi-tl这类模板引擎，准备好一个Word模板，数据填充进去再转PDF输出。这个功能在企业真实场景里非常实用，也给系统加分。
4. 开发过程中我踩过的坑
4.1 状态流转混乱导致的权限隐患
开发初期我上来就写状态修改接口，没有做统一的状态流转控制。结果出现了一个很尴尬的bug：学生报名后，企业导师还没审核，管理员直接改了状态为进行中，系统也没拦住，后续周报和评价流程全部错乱。
后来我建了一个状态机枚举类，把所有合法的状态流转路径列出来：
public enum SignupStatus { PENDING("待审核", Arrays.asList("APPROVED", "REJECTED")), APPROVED("已通过", Arrays.asList("RUNNING", "REJECTED")), REJECTED("已拒绝", Collections.emptyList()), RUNNING("进行中", Arrays.asList("FINISHED")); // ... }每次状态变更前先做一次合法性校验，不合法直接抛异常。用这种方式毕设项目里状态类问题基本绝迹。顺便说一下，这个设计在论文里也能作为系统健壮性的一个亮点来写。
4.2 数据权限隔离没做好，企业导师看到了别人的学生
这个问题是最容易翻车的。企业导师和企业管理员登录后，如果查询学生列表时没有根据企业ID做过滤，就会看到其他合作企业的学生数据。这个问题在开发阶段往往发现不了，因为测试数据太少，到了答辩演示时万一评委让现场操作，数据泄露当场社死。
我采用的方案是在Mapper层强制加入企业维度条件，不让上层调用者决定：
@Select("SELECT * FROM intern_batch b " + "INNER JOIN training_project p ON b.project_id = p.id " + "WHERE p.enterprise_id = #{enterpriseId}") List<InternBatch> listByEnterprise(@Param("enterpriseId") Long enterpriseId);更稳妥的方案是使用MyBatis-Plus的拦截器做数据权限自动过滤，但那样对初学者理解成本高。用上面的显式传参方式，虽然代码多一点，但每一处查询都清晰可见，答辩时讲数据隔离也更容易让人信服。
4.3 文件上传的本地存储路径问题
系统里学生要上传简历、周报附件、实习报告，文件上传功能不可或缺。毕设一般不会单独上OSS对象存储，本地存储就能满足需求，但这里有个常见的坑：文件存储路径和Tomcat部署路径分离。本地开发时FilePath写到D:/upload/，部署到服务器后这个路径不存在，导致文件上传后无法访问或服务重启时丢失文件。
建议把上传路径配置到application.yml里：
file: upload-path: ${UPLOAD_PATH:./upload/}应用启动时检测目录是否存在，不存在就自动创建。同时注册一个虚拟路径映射，把本地路径映射到/web/upload/**这等URL前缀下，用户访问这个URL时由项目进行物理路径映射，直接连通web访问链路。这个细节做扎实，部署环境迁移也会很省心。
上传文件的类型校验也不能只在前端做，前端限制只是减少无效请求，后端必须做一个真正的扩展名和文件头校验。特别是简历附件的上传，我最开始只校验了扩展名，结果有人上传了一个名为resume.pdf的exe文件，也能成功。后来加上文件头（magic number）校验，才把这个漏洞堵上。
4.4 多角色登录后的权限控制细节
登录我用的是JWT（JSON Web Token）方案。用户在登录接口拿到token，后续请求放在Authorization请求头上，后端通过拦截器解析token获取用户ID和角色。这种方式前后端分离用起来比较顺手。前端用Vue的话，在axios拦截器里统一做token携带和401响应处理。
这里有两个容易遗漏的细节：
一是前端路由守卫。页面跳转时要先检查用户角色，比如企业导师访问学生管理页面，前端路由该拦就拦一下，不要说登录了就能访问所有页面。
二是按钮级权限。普通角色不能看到系统设置的入口，这个在菜单渲染时就要根据后端返回的权限列表动态生成。
简单做法是用v-if判断用户角色来显示或隐藏，代码直观，但需要你在前端维护一份角色和按钮的映射表。严谨做法是做前端指令权限，将权限码绑定在按钮的判断上，后端不校验的时候前端也能拦住大量非法请求。
5. 论文撰写与答辩准备的实战经验
5.1 论文结构怎么搭才不空洞
系统类毕业设计的论文框架是有套路可循的，大致是：选题背景、需求分析、系统设计、系统实现、系统测试，再加上前后总结。很多同学写出来的论文内容空泛，原因在于需求分析和系统设计章节没有深度，大段大段的背景文字在凑字数，系统功能设计流于表面，评委看了就知道是模板粘贴的产物。
需求分析章节，建议用表格把所有用户角色和每一个核心功能对应起来。比如“学生”这一行的功能清单写清楚报名、周报提交、查看成绩；“企业导师”这一行写清楚学生管理、报告批阅、评价打分。这样一张表拿出来，功能需求一目了然，也方便评委快速了解系统全貌。
系统设计章节，要把数据库表结构作为重点，核心表一张张列出字段并且注明设计原因。我建议画一个E-R图放在论文里，评审老师对数据库设计这一块是比较看重的。
系统实现章节，避免整页代码堆砌。挑三四个核心模块，比如防重复报名、评价状态流程、成绩汇总公式，每个给出核心代码片段和必要的运行结果截图说明。代码截图可以直接截运行效果图和一些展示页面，注意截图清晰、界面布局整洁、命名规范，这些细节在论文盲评阶段很影响印象分。
5.2 实操演示顺序这样安排最稳
答辩演示是很多人最心虚的部分。我的建议是提前把演示脚本写好，按以下顺序操作：
第一，登录页先展示系统角色选择，然后以管理员身份进入。第二，管理员创建企业信息和实训项目，这一步要提前准备好数据，因为现场创建容易因网络等原因卡顿，提前设计好一个模板以快速录入。第三，切换到学生账号，执行报名操作，注意展示报名时的重复和时间冲突校验逻辑，这两点恰恰是答辩中最容易提问的技术细节。第四，回到管理端审核报名，再切回学生端提交一份周报，同时展示企业导师的批阅操作。第五，双导师各打一次分，去成绩汇总页面查看加权成绩，导出成绩表格文件。第八，完整展示ECharts统计图表页面。
整个演示控制在10到15分钟。之前有位同学答辩时演示到文件上传，结果上传了一个几十MB的视频导致页面卡住，气氛整段垮掉。素材一定要提前准备一个几百KB的PDF和一张压缩过的JPG，测试一遍上传流程，确保演示不卡顿。
5.3 时间规划建议
毕设拖延是常态，这个题目如果想完整做完，给一个比较保守的时间规划：
| 阶段 | 时间和任务 |
|---|---|
| 第1周 | 完成需求分析和数据库设计，输出E-R图和表结构文档 |
| 第2周 | 搭建项目骨架，完成登录认证和角色权限控制 |
| 第3-4周 | 完成实训项目发布、报名、审核主流程 |
| 第5-6周 | 完成周报、评价、成绩汇总核心模块 |
| 第7周 | 文件上传、通知提醒、统计图表等增强功能 |
| 第8周 | 系统测试、修复bug、完善界面细节 |
| 第9-10周 | 撰写论文初稿和准备答辩演示 |
按这个节奏来，完成度和论文质量都是理想的。不用贪功能，核心流程完整闭环、细节打磨到位，就已经能拿到不错的成绩了。
我在帮很多学生梳理过这类系统之后，最大的感受是：这个题目的上限很高，但下限也不低。同样是基于SpringBoot，有的人做出来就是个简单的CRUD框架，有的人能做成一套有业务深度的教学管理平台。区别不在技术多花哨，而在于对业务场景的理解是否到位。把校企合作中“过程化监控”和“双主体协同”这两件事讲明白，系统自然就立住了。开发过程中如果遇到卡住的地方，别硬扛，反复琢磨流程逻辑，多画几遍时序图，多数问题都能豁然开朗。
