简介基于Python与Django实现的主观题自动阅卷系统是一份面向高校毕业设计和课程设计的完整项目源码包适合需要实现在线考试与主观题自动评分的开发者参考。系统围绕六大核心模块展开系统首页、在线考试、试题管理、试卷管理、成绩管理和用户管理覆盖教师出题、学生作答、主观题判分及成绩汇总的完整流程首页还展示服务器IP与系统型号等环境信息。资源包共316个文件主体为Python源码、Django模板、CSS/JavaScript前端页面另有SQL数据库脚本、HTML页面和GIF演示录像整体大小约8.92MB便于本地部署。目前已有232人学习下载。压缩包内附带演示录像和说明文档可直接参考工程结构、阅卷逻辑及数据库初始化脚本既可用于毕业设计答辩展示也可作为课程实训或二次开发的基础。1. 主观题自动阅卷系统拿Python和Django做毕设先想清楚这4件事每年毕业季计算机相关专业的学生在选题时都会撞上同一个需求做一个“主观题自动阅卷系统”。因为这个题目既有技术深度又有明确的应用场景——老师改主观题的工作量太大尤其思政、语文、简答题这类没有标准选项的题目靠人工一份份批改效率极低。用程序去替代一部分“判分”工作正好踩中教育信息化的痛点答辩时也讲得清楚。但很多同学把这个题目做成了“关键词匹配工具”答案里出现几个关键词就给几分结果老师拿真实学生答卷一测分数离谱到没法看。深层原因是没搞清楚主观题阅卷到底在解决什么问题它不是找关键词而是判断两段文本在语义上的接近程度。这里面的核心技术栈其实并不复杂Python做文本处理和相似度计算Django做Web框架接收请求、管理数据、提供页面。系统的基本形态是一个B/S架构的在线答题与阅卷平台学生登录后在网页上作答主观题提交后系统调用算法给出一个预评分老师可以在后台看到机器评分结果并可手动修正作为“标准答案”的参照依据。适合谁来用如果你是计算机、软件工程、教育技术专业的学生想在毕设里同时体现Web开发能力和算法理解这个题目几乎是性价比最高的选择之一。难度可控演示直观且代码量足够撑起一份完整的毕业设计文档。但要把它做成一个真正说得通的项目前面提到的“关键词匹配”玩法必须淘汰接下来把方案讲透。2. 判分核心算法选型从词面匹配到语义相似度的落地取舍主观题阅卷的核心不是Django而是算法层这一块直接决定答辩时老师会不会追问、追问后你能不能答上来。常见的做法是先用分词工具把考生答案和参考答案拆成语义单元再通过相似度算法给出一个0到1的分数映射。下面把这条链路拆开讲清楚。2.1 三种相似度算法的适用边界编辑距离、TF-IDF向量、SimHash先说最容易被误解的编辑距离Levenshtein Distance。它计算的是“把一个字符串变成另一个字符串需要的最少编辑次数”适合用来判断“关键字顺序基本一致、局部有笔误”的短答案比如填空题、名词解释。但对100字以上的简答题编辑距离的区分度会急剧下降两名学生答得意思差不多、表述完全不同编辑距离可能比“答非所问”的学生还大。所以我的做法是只在答案长度小于50个字符时用编辑距离超过这个阈值就切换为向量化方案。TF-IDF加余弦相似度是最稳妥的默认选项。原理是把每份答案先分词再用TF-IDF把分词结果映射成一个高维向量最后计算两个向量的夹角余弦值作为相似度。这个方案实现简单、解释直观尤其适合“参考答案与考生答案用词重合度较高”的文科简答题。但它的弱点也很致命对同义词和句式转换完全不敏感。学生把“改革开放”写成“开放改革”向量方向几乎不变但“坚持党的领导”写成“拥护党的核心地位”这种词汇级同义替换TF-IDF算出来的相似度会偏低。SimHash是另一个可选方向它对长文本做降维指纹计算速度快适合大规模试卷批改但它的精度比较粗糙适合做“初筛”不适合做“打分”的唯一依据。我给毕业设计的建议是把TF-IDF余弦相似度作为主判分器编辑距离作为短答案的补充SimHash作为异常答案的快速筛选项。三者结合才能保证回答“为什么用这个方法”时逻辑自洽。2.2 用jieba分词加TF-IDF算出基础相似度的完整过程先看一段可直接运行的Python代码它完成从“参考答案考生答案”到“相似度分数”的转换import jieba import jieba.analyse from sklearn.feature_extraction.text import TfidfVectorizer from sklearn.metrics.pairwise import cosine_similarity def preprocess(text): # 去掉换行和多余空格避免干扰分词 text text.replace(\n, ).replace(\r, ).strip() # 使用jieba的精确模式分词并将词用空格连接方便TfidfVectorizer处理 return .join(jieba.cut(text)) def calc_similarity(reference, answer): # 参考答案和考生答案同时做预处理 ref_tokens preprocess(reference) ans_tokens preprocess(answer) # TfidfVectorizer把文本列表转成TF-IDF特征矩阵 # 注意这里直接把两份文本放进同一个语料库来计算 vectorizer TfidfVectorizer(token_patternr(?u)\b\w\b) tfidf_matrix vectorizer.fit_transform([ref_tokens, ans_tokens]) # cosine_similarity返回一个2x2矩阵取[0][1]就是参考答案与考生答案的相似度 sim cosine_similarity(tfidf_matrix[0:1], tfidf_matrix[1:2]) return round(float(sim[0][0]), 4) # 测试用一组真实的“参考答案”和“考生答案”验证效果 reference 改革开放是决定当代中国命运的关键一招是坚持和发展中国特色社会主义的必由之路。 answer 改革开放决定了当代中国的命运它是中国特色社会主义发展的必经之路。 print(相似度得分, calc_similarity(reference, answer))这段代码的逻辑分三步先把两段文本用jieba分词并用空格连接再由TfidfVectorizer把分词后的文本转换为向量最后用余弦相似度直接算夹角。需要注意TfidfVectorizer的token_pattern参数——默认的正则表达式在中文场景下会把连续汉字当成一个token导致分词失效所以这里显式指定为按空格分词的模式。另一个关键是“把参考答案和考生答案放进同一个语料库”如果分开构建字典向量空间不一致算出的夹角就没有意义。运行后得到的相似度在0到1之间通常0.5以上说明基本方向一致0.7以上说明表述接近。但绝不能直接拿这个值乘总分当作最终得分原因在下一节讲。2.3 一个必须处理的边界把相似度映射成实际分数直接把相似度乘以满分是很多毕设翻车的地方因为同一道题目、同样水平的答案在不同字数下计算出的相似度波动很大。比如“请简述市场经济的基本特征”参考答案写了200字考生答案只写了40字即使关键词全覆盖余弦相似度也被大量“缺失维度”拉低。因此我一般会增加两个修正因子覆盖率和长度惩罚。覆盖率指考生答案中命中参考答案关键词的比例用简单的集合交集除以参考关键词总数即可。长度惩罚则根据考生答案字数与参考字数的比值动态调整比值小于0.3时乘以0.6的系数在0.3到0.8之间时线性插值大于0.8不做惩罚。最终得分由三项共同决定原始相似度权重占0.5覆盖率权重占0.3长度系数占0.2。权重可以根据不同学科微调但不要在没有真实测试数据的情况下去追求“完美权重”先固定一组合理的默认值留出调参入口即可。核心结论算法选型上TF-IDF余弦相似度是性价比最高的起步方案但必须搭配覆盖率和长度惩罚才能得到相对可信的分数。至于语义层面的深层改进那是进阶选项放到后面章节展开。3. Django后端实现模型设计、评分接口与JWT登录的完整链路选好了算法接下来把一个可运行的Django后端搭起来。这一章的目标不是抄官方教程而是按“教师管理题目、学生作答、系统判分”的业务流把模型、视图和接口连成一条完整链路。3.1 数据库模型设计试卷、题目、答卷与评分记录的四表结构毕业设计的模型设计不宜过度复杂四张核心表足够描述整个业务。第一张是题目表存放题干、参考答案、满分值和适用的算法类型短答案用编辑距离、长答案用TF-IDF第二张是试卷表与题目表是多对多关系同时记录考试名称和创建人第三张是答卷表记录某位学生对某张试卷的提交时间、总得分与是否已人工复核第四张是评分明细表记录每一道题机器评分的过程数据包括原始相似度、覆盖率、长度系数和最终得分——这张表在答辩演示中特别重要它能直观说明“系统不是拍脑袋打分”。from django.db import models from django.contrib.auth.models import User class Question(models.Model): # 题型选择短答案和长答案分别走不同算法 SHORT short LONG long TYPE_CHOICES [(SHORT, 短答案), (LONG, 长答案)] content models.TextField(verbose_name题干) reference_answer models.TextField(verbose_name参考答案) full_score models.FloatField(verbose_name满分) qtype models.CharField(max_length10, choicesTYPE_CHOICES, defaultLONG) keywords models.TextField(verbose_name关键词用逗号分隔, blankTrue) def keyword_list(self): # 把存进数据库的逗号分隔字符串转换成列表供判分算法直接调用 return [k.strip() for k in self.keywords.split(,) if k.strip()] class Paper(models.Model): title models.CharField(max_length100) questions models.ManyToManyField(Question, related_namepapers) creator models.ForeignKey(User, on_deletemodels.CASCADE) created_at models.DateTimeField(auto_now_addTrue) class AnswerSheet(models.Model): student models.ForeignKey(User, on_deletemodels.CASCADE) paper models.ForeignKey(Paper, on_deletemodels.CASCADE) submitted_at models.DateTimeField(auto_now_addTrue) total_score models.FloatField(default0) reviewed models.BooleanField(defaultFalse) # 标记是否被教师人工复核 class ScoreRecord(models.Model): answer_sheet models.ForeignKey(AnswerSheet, on_deletemodels.CASCADE) question models.ForeignKey(Question, on_deletemodels.CASCADE) raw_similarity models.FloatField() # 原始余弦相似度 coverage models.FloatField() # 关键词覆盖率 length_factor models.FloatField() # 长度惩罚系数 final_score models.FloatField() # 最终得分这个模型设计的核心是ScoreRecord表它在毕业设计答辩时能帮你回答两个高频问题第一机器判分的依据是什么答相似度、覆盖率、长度系数三项加权第二分数与人工判分有差异时能不能查答每条分数都留痕。给毕业设计的建议是千万不要为了省事砍掉ScoreRecord表否则你的系统就是一个“黑匣子”答辩老师一旦深究就难以自圆其说。3.2 用Django REST Framework实现判分接口输入答卷返回得分模型建好后下一步是写判分接口。毕业设计场景下强烈建议使用Django REST FrameworkDRF它提供了序列化器、视图集和路由的成熟方案代码量比手写JSON解析少一半以上。核心接口由两步组成接收学生提交的整张试卷答案逐题调用算法得出分数最后汇总返回结果。from rest_framework.views import APIView from rest_framework.response import Response from rest_framework.permissions import IsAuthenticated from django.utils import timezone from .models import Paper, AnswerSheet, ScoreRecord from .scoring import calculate_score class SubmitAnswerView(APIView): # 只有登录用户才能提交答卷未登录返回401 permission_classes [IsAuthenticated] def post(self, request, paper_id): paper Paper.objects.get(idpaper_id) # 请求体是 JSON 格式的答案列表例如 [{question_id: 1, answer: xxxx}] answer_list request.data.get(answers, []) answer_sheet AnswerSheet.objects.create( studentrequest.user, paperpaper, total_score0 ) total 0.0 for item in answer_list: question paper.questions.get(iditem[question_id]) raw_sim, coverage, length_factor, final_score calculate_score( question, item[answer] ) ScoreRecord.objects.create( answer_sheetanswer_sheet, questionquestion, raw_similarityraw_sim, coveragecoverage, length_factorlength_factor, final_scorefinal_score ) total final_score answer_sheet.total_score round(total, 2) answer_sheet.save() # 返回总分和每道题的明细前端直接展示给学生 return Response({ total_score: answer_sheet.total_score, submitted_at: timezone.localtime(answer_sheet.submitted_at).strftime(%Y-%m-%d %H:%M:%S) })这段代码的关键点包括用DRF的APIView和权限类确保接口安全遍历答案组装评分明细、逐题计算并落库返回数据既包含总分也暗示了明细存在方便前端下一步拉取。接口的入参格式需要在项目文档中明确写清楚因为在系统对接时前端传参结构不一致是最高频的联调问题。另一个需要注意的地方是Exception处理——如果请求里包含不存在的question_id这里会直接抛出异常生产环境应当捕获并返回友好的错误提示。3.3 JWT登录与用户权限学生和教师不能看同一个界面Django默认的Session认证在传统多页面开发中够用但如果前端采用了Vue或React分离开发JWT才是更合适的选择。通过djangorestframework-simplejwt只需简单配置即可获得登录获取Token、刷新Token、校验Token的完整能力。# settings.py 中追加的内容 REST_FRAMEWORK { DEFAULT_AUTHENTICATION_CLASSES: [ rest_framework_simplejwt.authentication.JWTAuthentication, ], DEFAULT_PERMISSION_CLASSES: [ rest_framework.permissions.IsAuthenticated, ], } SIMPLE_JWT { # 访问令牌有效期设为2小时毕业设计演示通常不会超过这个时间 ACCESS_TOKEN_LIFETIME: timedelta(hours2), # 刷新令牌有效期设为7天方便演示期间反复使用 REFRESH_TOKEN_LIFETIME: timedelta(days7), # 更新令牌后让旧令牌失效防止同一账号多处登录引发数据错乱 ROTATE_REFRESH_TOKENS: True, }配置完成后通过/api/token/接口提交用户名密码获取JWT之后在请求头中携带Authorization: Bearer token即可访问受保护的接口。学生角色提交答卷、查看自己的分数教师角色管理题目、查看所有答卷——权限区分的落地做法是把角色写成Django Group并在视图中通过request.user.groups.filter(nameteacher).exists()来判断。这样写代码量少且容易测试比引入复杂的权限框架更可控。4. 前端答题页与异步判分从HTTP轮询到WebSocket推送的改造很多毕设做的Django项目并不分离前后端而是使用Django内置模板加JQuery完成交互这本身没有错。但如果你想在答辩时展示一个“实时判分”的效果让系统在点击提交后立即弹出得分不刷新页面就需要引入异步机制。4.1 最稳的起步方案JQuery AJAX轮询提交判分不引入Node.js构建工具链的前提下最可控的方案是JQuery加AJAX轮询。用户在textarea中填完答案点击提交按钮前端通过AJAX把答案发给后端判分接口后端处理完返回总分和明细前端局部刷新页面显示结果。script // 绑定提交按钮的点击事件 $(#submit-btn).click(function () { // 从表单收集所有题目的答案组装成后端要求的JSON结构 let answers []; $(.question-item).each(function () { let qid $(this).data(question-id); let text $(this).find(textarea).val(); answers.push({ question_id: qid, answer: text }); }); // 发POST请求到判分接口附带JWT令牌 $.ajax({ url: /api/paper/ paperId /submit/, method: POST, contentType: application/json, headers: { Authorization: Bearer localStorage.getItem(token) }, data: JSON.stringify({ answers: answers }), success: function (resp) { // 判分成功后用新分数替换页面上原来的总分 $(#total-score).text(resp.total_score); // 弹出提示同时刷新题目列表里的得分状态 alert(提交成功得分 resp.total_score); }, error: function (xhr) { // 401说明令牌过期跳回登录页其他错误在页面直接显示 if (xhr.status 401) { window.location.href /login/; } else { $(#error-msg).text(提交失败请检查网络或稍后重试); } } }); }); /script这段前端逻辑的要点是从DOM中收集数据时通过>import json from channels.generic.websocket import AsyncWebsocketConsumer class ScoreConsumer(AsyncWebsocketConsumer): async def connect(self): # 从URL中获取当前试卷ID它决定了消息推送的频道 self.paper_id self.scope[url_route][kwargs][paper_id] self.group_name fscore_{self.paper_id} # 加入频道组这样该试卷相关的前端页面都能收到通知 await self.channel_layer.group_add(self.group_name, self.channel_name) await self.accept() async def disconnect(self, close_code): # 断开时退出频道组防止后续消息推送到失效连接 await self.channel_layer.group_discard(self.group_name, self.channel_name) async def score_updated(self, event): # 判分完成后由视图层调用group_send触发这里把结果发给浏览器 await self.send(text_datajson.dumps({ type: score_updated, message: event[message] }))落地时注意一点Channels默认的内存Channel Layer在单进程开发时没问题但runserver时如果开了多个进程会互相收不到消息。毕业设计用runserver单进程演示足够如果是生产环境则要换成Redis Channel Layer。异步代码里不要使用同步的数据库ORM调用需要判分时要么把计算放到同步函数里用database_sync_to_async包装要么直接在视图层完成判分后只通过WebSocket推送结果。推荐后者因为它不干扰正常HTTP接口的职责边界。4.3 前端展示判分依据让学生和评审老师都能看到“为什么得这个分”一个容易被忽视但极其重要的功能是展示判分依据。界面上不能只有一个冰冷的分数而应当在每道题下方展示三个数据关键词命中情况哪些词命中了、哪些没命中、相似度得分、长度调整系数。用Django模板或前端JQuery渲染成一个简单表格即可。这样做有三个直接好处一是学生能理解机器判分逻辑而不是质疑分数二是答辩评审能看到“系统不是黑匣子”三是排查问题时能直接定位到某道题是因为关键词覆盖不足还是长度惩罚扣的分。前端展示表格式如下评分维度数值说明文本相似度0.73参考答案与考生答案的TF-IDF余弦相似度关键覆盖4/6参考答案6个关键词中命中4个长度系数0.85考生答案长度为参考的65%施加系数惩罚最终得分满分10分制下得7.1分三项加权计算结果前端渲染表格数据需要后端在提交接口的响应中带上明细或者提供一个独立的明细查询接口。我建议后端返回SubmissionDetail时把ScoreRecord一并序列化给前端省去一次请求往返。表格不需要做得分样式美化清晰明了比花哨更重要。5. 主观题阅卷系统的5个高频踩坑与排查手册这一章集中写我实际开发和毕业设计辅导过程中最常碰到的几个问题。每一条都按照“现象-原因-解决”来写你完全可以把它当成排查手册来用。5.1 同样的答案两次提交得分不一致算分结果不稳定现象同一份考生答案换个时间重新提交一次分数和上次差了10%以上。原因最常见的情况是TfidfVectorizer在每次请求时都重新fit如果参考答案和考生答案的拼写在某些字符上存在细微差异比如全角半角、多余空格分词的切分方式就会变化导致向量空间跟着变。解决把向量化模型在Django应用启动时创建一次后续请求只调用transform不要反复fit。另一个隐蔽原因是用字典存储临时变量时被多线程覆盖Django开发服务器虽然默认单线程但部署到Gunicorn多worker时就会出现。解决方案是在每个Worker启动时单独建立全局对象不能在多个Worker之间共享可变状态。5.2 中文符号和全角字符导致分词完全错乱现象考生答案里全是中文全角括号和句号程序分词后得到一堆碎片相似度接近0。原因jieba的默认词典对全角标点处理能力有限标点被保留并被切到词的边界里造成维度膨胀同时稀释了真正有意义的关键词权重。解决在preprocess函数中增加清洗步骤把所有全角标点转换为半角再用正则表达式过滤掉非中文字符和字母数字以外的符号。我的做法是import re from zhconv import convert # 如果需要繁体转简体的话 def clean_text(text): # 全角转半角统一逗号、句号、括号、引号等常用符号 full_to_half { : ,, 。: ., : (, : ), : !, : ?, : ;, : :, “: , ”: , ‘: , ’: } for full, half in full_to_half.items(): text text.replace(full, half) # 只保留中文字符、英文字母、数字和空格 text re.sub(r[^\u4e00-\u9fa5a-zA-Z0-9 ], , text) return text清洗后必须重新做分词因为在清洗前分词和清洗后分词的结果可能完全不同。这一条如果处理不到位你会在答辩演示现场看到学生答案明明写得不错但系统给出的分数只有满分的一两成评审老师会直接对系统可靠性失去信任。5.3 长文本答案相似度普遍偏高区分度丢失现象一道简述题满分十分所有学生得分都在8分以上因为任何两个谈同一话题的文本在TF-IDF向量空间里夹角都偏小。原因TF-IDF的全局语料只有当前这一份参考答案和一份考生答案IDF权重几乎不起作用词频主导向量方向导致“人云亦云”的泛泛之谈也能得高分。解决两种思路一是引入一个背景语料库计算IDF让“市场经济”“发展”“重要”这些出现频率极高的词获得较低的IDF权重从而凸显真正有区分度的术语二是加大关键词覆盖率的权重把“是否答出核心术语”作为最终得分的主要驱动。我建议毕业设计采用第二种背景语料库的构建工作量会超出预期。5.4 前台页面实时分数刷新失败WebSocket连接闪断现象前端能登录但收不到实时分数推送浏览器控制台报WebSocket连接状态为Closed。原因Channels的ASGI路由与Django的URL路由没有正确绑定最常见的是没有安装channels的daphne服务器而是直接用runserver启动——新版Django Channels要求必须把daphne加入INSTALLED_APPS并在ASGI_APPLICATION中正确指向你的asgi.py。解决在settings.py中将daphne放在INSTALLED_APPS最前面并确认ASGI_APPLICATION your_project.asgi.application。同时检查前端连接的WebSocket地址是否与路由配置一致——HTTP地址带/ws/前缀但WebSocket地址要写成ws://127.0.0.1:8000/ws/paper/1/端口和路径不能混淆。5.5 数据库里没有ScoreRecord记录但界面显示了分数现象学生端显示总分为0或者显示了一个分数但后台明细表为空。原因出现这种“分数凭空产生”的诡异问题通常是在事务中没有处理好缓存或者视图层把计算得到的分数临时扔给了模板而忘了在数据库层面落库。最典型的翻车现场是在视图函数中先创建AnswerSheet记录再循环ScoreRecord落库但循环中途抛了异常外层又没有事务回滚导致AnswerSheet存在而ScoreRecord全部丢失。解决给提交接口加上transaction.atomic装饰器让整个判分过程在一个事务中执行。这样要么全部成功落库要么全部回滚不会有“半截数据”的状态出现。6. 让毕设从“能跑”到“能答辩”算法效果验证与参数调优系统能跑通只是拿到及格分要冲击优秀毕业设计或让答辩老师满意还差两个关键动作效果验证和参数调优。6.1 用历史答卷做离线回归测试相关系数是最有力的证据在系统上线前找指导老师要一批已经人工批改过的真实答卷把机器评分和人工评分成对记录下来计算二者的皮尔逊相关系数。这个数字是你答辩时最有说服力的数据相关系数达到0.7以上就说明系统评分与教师评分趋势一致达到0.85以上可以认为系统具备参考价值。具体做法是把数据导出为CSV然后用Pandas做统计分析import pandas as pd from scipy.stats import pearsonr # 读取历史数据第一列是教师评分第二列是机器评分 data pd.read_csv(scores.csv) teacher data[teacher_score] machine data[machine_score] # 计算皮尔逊相关系数和p值p小于0.05说明相关性显著 corr, p_value pearsonr(teacher, machine) print(f相关系数: {corr:.3f}, p值: {p_value:.3f}) # 同时计算平均绝对误差用于说明机器评分的平均偏差 mae (teacher - machine).abs().mean() print(f平均绝对误差: {mae:.2f})如果相关系数偏低排查方向按优先级检查分词清洗步骤是否正确、关键词覆盖率权重是否过低、长度惩罚是否过于激进。不要漫无目的地调参每一次改动都要重新跑回归测试并记录前后指标。6.2 三个必调的权重参数覆盖率、长度系数和关键词数量覆盖率权重的默认值设为0.3它对得分的影响最大因为关键词是主观题阅卷最直观的判分依据。如果发现“学生意思对但表述方式与参考答案相差较远”导致分数偏低就把覆盖率权重调高到0.4同时降低相似度权重。长度系数的默认逻辑是“字数少于参考60%时惩罚”但如果你的题库中包含大量要求精炼回答的题目这条规则会误伤写得简洁但要点齐全的学生建议把阈值降到40%。关键词数量并不是越大越好参考答案提取8到12个关键词即可超过15个后覆盖率会变得极其苛刻学生几乎不可能命中所有词。调参的核心思路是先把系统跑起来拿一批真实数据看哪些学生分数与教师评分偏差最大再回到他们的答案文本里分析是哪个维度导致的偏差针对性调整对应的权重。整个过程不要超过三天因为毕业设计的时间重心一定在系统稳定性和文档完整性上。6.3 最后的工程检查从录像演示到代码注释的四个细节当分数可信度问题解决后还有几个动手前最容易忽略却又决定体验的细节。录像演示需要提前确认题目和答案的“最优路径”先展示一次得分高的答案再展示一次得分低的答案让评分差异一目了然这比随机输入更能体现系统判别力。代码注释要针对算法函数和模型字段写清楚设计意图尤其是评分权重和长度惩罚系数答辩老师常会追问“这两个参数为什么这么设”哪怕回答“经过回归测试调整”也好过“凭感觉设的”。测试数据保留在项目目录下的samples/里包含五组参考答案和十组考生答案既能用于回归测试也能让演示前快速验证系统是否正常工作。最后检查一遍虚拟环境依赖锁定文件requirements.txt确保换一台机器也能复现运行环境——很多同学演示当天才发现少了某个依赖包这种事一旦发生前面所有打磨都白费了。从我带毕设的经验看这个题目最大的陷阱是“以为算法很容易所以把时间全部耗在网页美化和无关的框架炫技上”结果到验收时机器判分逻辑漏洞百出。反过来只要把算法层和评分解释性做好即便前端朴素一些评审老师也会认可这是一个“有思考深度”的项目。希望这些分析和踩坑记录能帮你少走一段弯路。本文还有配套的精品资源点击获取