高中信息技术：动态测评系统构建项目式教案

高中信息技术：动态测评系统构建项目式教案

一、教学背景与设计理念

（一）学科核心素养定位

本教学设计依据《普通高中信息技术课程标准（2017年版2020年修订）》，面向高中二年级信息技术选择性必修课程“人工智能初步”与“算法与程序设计”交叉模块。动态测评系统的构建不仅是算法设计与信息系统开发的综合实践载体，更是落实计算思维、数字化学习与创新、信息社会责任三大核心素养的战略支点。【非常重要】在系统开发过程中，学生需将真实测评需求抽象为数据结构模型与算法逻辑，通过持续调试与迭代将抽象规则转化为可执行代码，在此过程中锤炼模块化分解、模式识别、算法效率评估等计算思维能力。同时，系统涉及多终端数据采集与可视化呈现，要求学生综合运用多种数字工具完成协作开发与文档撰写，深度培育数字化学习与创新能力。尤为关键的是，系统采集的学业数据涉及隐私保护与算法公平性，学生在设计评分权重、存储用户信息时必须主动思考技术决策带来的伦理后果，从而内化信息社会责任。【重要】

（二）教材内容整合策略

本设计打破单一教材章节壁垒，采用大单元项目化重组策略。核心知识提取自教育科学出版社《信息技术·必修2信息系统与社会》第四章“信息系统的开发”中关于系统架构设计、前端交互实现的核心案例，同时深度融合浙江教育出版社《算法与程序设计》第三章“数据结构与算法效率”中关于查找算法、排序优化、时间复杂度分析的理论工具。传统教材中数组、队列、哈希表、冒泡排序、快速排序等知识点通常以孤立章节呈现，学生难以感知其工程价值。本设计以动态测评系统的“实时排行榜单”为锚点任务，将静态数据结构与动态算法策略有机串接：数组用于存储原始提交记录，哈希表用于学号与姓名的快速映射，快速排序算法在每两秒的轮询刷新中完成前端重排，倒排索引理念被初步引入以优化按题目维度聚合得分的查询效率。【难点】通过项目载体，学生从“学习数据结构”转向“用数据结构解决并发查询压力”，实现知识的情境化迁移。

（三）学情精准画像

授课对象为高中二年级选修信息技术的学生群体。此前学生已完成Python程序设计基础（变量、分支、循环、函数）、简单算法（枚举、递归初步）以及静态网页三剑客（HTML5、CSS3、基础JavaScript）的学习，具备搭建简易计算器、个人简历网页等微型作品的能力。然而，学情前测数据显示：87%的学生未接触过Web后端框架，92%的学生对“客户端与服务器交互”仅有模糊概念，将URL理解为“网址”而非“资源接口”；同时，学生对“实时”的技术代价缺乏感性认知，普遍认为刷新网页即自动获得最新数据。认知风格方面，高二学生处于皮亚杰形式运算阶段，能够理解抽象的系统架构分层图，但在将UML类图、时序图转化为Flask路由函数时存在明显的“概念-代码”断裂，调试过程中常出现因缩进错误、JSON格式不合法等低级语法问题导致的中断性挫败。【难点】因此，本设计在脚手架中植入大量符合PEP8规范的代码片段注释，并提供可视化的接口调试工具（Postman），以可视化的请求-响应面板弥合抽象协议与具体报文之间的鸿沟。

（四）设计理念与范式突破

本设计秉持“测评即学习，系统即课程”的核心主张。动态测评系统在课堂中扮演双重角色：既是学生需要动手开发的信息系统作品，又是贯穿整个单元、实时诊断学生认知状态的教学评估工具。在第1课时，学生即以“被测评者”身份使用预置的动态测评看板完成前测，亲眼目睹自己的答题数据被采集、聚合、渲染；在后续课时，学生转变为“测评系统的构建者”，为假想的未来用户设计更流畅、更公平的反馈界面。这一元认知闭环促使学生不断反刍“我曾需要什么样的反馈”，从而将技术学习升华为移式设计。课程结构采用威金斯与麦克泰格倡导的逆向设计：首先明确终极表现任务——构建一个能在班级局域网环境下支持50人并发提交、实时刷新排名、支持多条件加权评分的动态测评看板；随后逆推所需的关键知能——HTTP协议、RESTfulAPI、数据库持久化、异步请求、索引优化；最终规划出逐级递进的6课时学习体验。整个过程将“做中学”与“思中学”等量齐观，既强调代码产出，更强调迭代日志、接口文档、反思报告等思维外化制品。【非常重要】

二、教学目标与层级指标

（一）知识与技能目标

1.精准阐述动态测评系统的浏览器/服务器（B/S）三层架构，能在系统框图中准确标注表示层、业务逻辑层、数据访问层的职责边界，并能举例说明各层所采用的主流技术栈（HTML/CSS/JavaScript、Flask/Python、SQLite）。【重要】

2.熟练运用Flask框架编写基本路由与视图函数，掌握request对象获取POST请求中JSON负载的方法，能够使用jsonify构造结构化响应报文，实现符合RESTful设计规范的评分提交接口与分数聚合接口。【高频考点】【非常重要】

3.掌握基于多指标（答题正误、耗时、题目难度、尝试次数）的加权评分数学模型，能够根据教师提供的原始数据样本调整权重系数，并通过柱状图对比不同权重方案下的排名变化，初步形成算法设计中的价值敏感性思维。

4.应用Chart.js或ECharts前端可视化库，通过原生JavaScriptFetchAPI从后端异步获取JSON格式的分数集，调用库函数动态更新图表配置项，实现至少每2秒一次的轮询刷新，并能够处理网络异常时的用户反馈（加载动画、错误重试）。【高频考点】

5.理解数据库索引对查询性能的加速原理，能够在SQLite中为频繁作为WHERE条件与ORDERBY子句的字段（如student_id、submit_time）创建索引，并通过EXPLAINQUERYPLAN分析查询计划，将单表十万级数据量下的聚合查询响应时间压缩至200ms以内。【拓展目标】【难点】

（二）过程与方法目标

1.经历“需求澄清→接口约定→分头编码→集成测试→压力优化”的敏捷开发微型流程，在小组内轮流担任产品经理、后端工程师、前端工程师、测试工程师等角色，体验基于分工协作的真实工程场景。

2.学会使用Postman或Hoppscotch构造并发请求集合，模拟多人同时提交场景，通过观察服务器日志响应状态码与响应时间定位性能瓶颈，并依据二八原则确定优先优化的代码模块。

3.形成系统性排错策略：当动态看板无法刷新数据时，能够按照“浏览器控制台网络标签→服务器终端报错→数据库查询语句”的顺序分层隔离问题，而不是盲目修改代码。

（三）情感态度与价值观目标

1.在小组代码复审过程中，能够以非防御性姿态接受同伴关于代码风格、算法冗余的改进建议，体验集体智慧对代码质量的提升效应。

2.认识到算法权重并非纯粹技术中立的参数，通过模拟不同权重分配下优等生与进步生的排名翻转，建立“技术决策蕴含价值判断”的工程伦理意识。【重要】

3.在数据库设计阶段主动规避明文存储敏感信息，对学生姓名、学号等字段进行脱敏展示，内化“最小权限原则”在信息系统开发中的伦理约束力。

三、教学重难点与标志性突破策略

（一）教学重点

1.前后端异步数据交互机制。【非常重要】【高频考点】突破策略：第4课时采用“黑盒观察法”，学生在浏览器开发者工具的Network面板中逐帧分析Fetch请求的Headers、Payload、Response，将抽象的HTTP报文具象化为可读的键值对；随后修改后端响应数据格式，观察前端图表如何响应变化，建立“请求-响应-渲染”的因果链。

2.基于多条件加权评分的算法模型构建。【核心】突破策略：第2课时引入Excel动态模拟沙盘，学生拖拽权重滑块即时观察10名虚构学生的排名波动，将抽象的数学公式转化为直观的条形图竞赛，极大降低建模门槛。

（二）教学难点

1.实时数据推送的技术选型与代价认知。【难点】突破策略：不强求全员掌握WebSocket，而是通过“轮询压力实验”让学生自我发现每0.5秒请求一次导致服务器崩溃的现象，进而讨论轮询间隔与实时性的最佳平衡点。对于学有余力小组，提供Flask-SocketIO拓展文档作为选学资源。

2.高并发写入时的数据一致性问题。【难点】【拓展】突破策略：第3课时使用线程池模拟50个并发提交请求，部分小组会发现因SQLite默认事务隔离级别导致的数据覆盖丢失。教师不直接给出锁机制代码，而是引导学生为每条记录添加时间戳字段，在应用层通过比较最后更新时间解决冲突，渗透乐观锁思想。

四、教学环境与资源栈配置

（一）物理环境

计算机教室采用小组岛式布局，每四台学生机围绕一台公用显示器，便于代码互审与结对编程。教师机部署双屏显示，主屏投射教学演示代码，副屏实时刷新由教师端动态测评系统采集的各小组开发进度（如是否已完成接口定义、是否已首次成功提交分数）。局域网内搭建内部PyPI镜像源，加速Flask、Faker等第三方库的离线安装。

（二）软件工具链

1.开发环境：PyCharmEdu或VSCodewithPython插件，统一缩进为4空格，默认换行符为LF。

2.版本控制：使用GitHubClassroom创建模板仓库，每个小组Fork后独立开发，教师端通过GitStats插件实时统计各仓库提交热力图。

3.接口协作：腾讯文档建立团队空间，嵌入SwaggerUI风格的API描述表格，支持评论@提醒与历史版本追溯。

4.测评工具：前测与后测采用基于Flask自研的课堂应答系统，该系统本身即为本次项目的简化版原型，实现教学工具与教学内容同构。【非常重要】

（三）脚手架资源

教师预先封装“动态测评看板脚手架V1.0”，目录结构如下：

/classroom_grader

/static

css/bootstrap.min.css及自定义样式表

js/echarts.min.js,custom-chart.js（预留fetch占位符）

/templates

index.html（包含看板容器及初始化脚本）

app.py（Flask应用主程序，已引入必要模块，路由函数为空函数体）

utils.py（空函数calculate_score待实现）

models.py（SQLAlchemyORM定义，但默认使用SQLite，可降级为原生sqlite3）

requirements.txt（精确锁定Flask2.1.3,Faker13.15.0等）

脚手架可在1分钟内启动并显示静态页面，极大降低初次接触后端的认知负荷，学生成就感从“HelloWorld”升级为“运行了一个带图表的网站”。【非常重要】

五、教学实施过程（核心篇幅）

本单元共安排6课时，每课时45分钟。教学过程采用“阶梯挑战”模式，每课时设立一个核心里程碑，全部里程碑贯通后形成完整的动态测评系统。以下详尽阐述每个课时的师生活动、技术操作、嵌入式测评与标注说明。

（一）架构认知与原型沉浸（第1课时）

1.情境锚定与需求唤起（8分钟）

教师展示传统纸笔课堂测试的痛点：教师逐题念答案，学生交换批改，课代表汇总分数耗时30分钟以上，且无法即时呈现全班知识盲点。随后，教师以极快速度在浏览器中输入本地地址，大屏出现一个实时跳动的柱状图，横轴是学生姓名化名，纵轴是本次随堂测验的得分。教师随机抽取一名学生，现场回答一道关于“HTTP状态码”的选择题，答题结束后两秒，大屏上该生对应的柱状图立即升高。全班哗然，好奇心被瞬间点燃。教师追问：这个“魔法”是如何实现的？学生小组讨论1分钟，在白板上画出自己猜测的组件。大部分小组能画出“学生手机/Pad”“大屏幕”“后台电脑”三个要素，但难以描述数据传输方向。此时教师不急于纠正，而是保留原始猜想，待课时末回看。【热点】

1.三层架构具身模拟（12分钟）

教师邀请9名学生上台，三人一组扮演“浏览器客户端”，三人扮演“Web服务器”，三人扮演“数据库”。教师扮演网络传输介质。第一轮：“客户端”向“服务器”喊话“我要提交张三的分数”；“服务器”向“数据库”喊话“请存储张三分数85”；“数据库”回应“存储成功”；“服务器”向“客户端”回应“提交成功”。第二轮：“客户端”喊话“我要获取最新排行榜”；“服务器”向“数据库”喊话“查询所有分数并按总分降序”；“数据库”将写有排名的纸板交给“服务器”；“服务器”转发给“客户端”。模拟结束后，教师将刚才的活动映射为黑板上的B/S三层架构图，并标注每个箭头对应的HTTP方法（POST/GET）。此活动将不可见的协议交互转化为肢体语言和口语指令，全班参与度极高，彻底破除对后端的神秘感。【难点突破】【非常重要】

1.脚手架运行与初次修改（20分钟）

学生打开PyCharm，载入脚手架项目。教师采用“驱动式演示”：教师操作一步，学生跟做一步。第一步：配置Python解释器并安装依赖包（pipinstall-rrequirements.txt）。第二步：运行app.py，点击终端出现的链接，全班齐声读出浏览器标题栏“动态测评看板-原型”。第三步：教师演示如何将静态硬编码数据[{'name':'李明','score':88},...]

修改为使用Faker库生成中文姓名和随机分数。学生修改代码后刷新浏览器，看到柱状图的姓名和数值全部变化，发出“哇”的感叹。第四步：挑战任务——将柱状图颜色由默认蓝色改为渐变色，并添加折线图展示班级平均分变化趋势。基础薄弱学生至少完成姓名修改，基础较好学生可深入阅读ECharts配置文档。此环节全员获得即时正反馈，零代码焦虑。【非常重要】

1.概念即时诊断与元测评示范（5分钟）

教师端启动课堂应答系统，大屏显示二维码。学生扫码后进入三道选择题的答题界面。题目1：动态测评系统通常不包含以下哪一层？（A表示层B逻辑层C物理层D数据层）。题目2：HTTP协议是一种（A有状态协议B无状态协议C文件传输协议D邮件协议）。题目3：以下哪个JavaScript库最适合绘制实时刷新图表？（AReactBEChartsCjQueryDVue）。学生提交后，大屏看板上的柱状图立即更新为全班各选项选择人数分布。教师指着看板说：“这个看板本身就是一个动态测评系统，而它现在展示的数据，正是大家对动态测评系统的理解程度。”学生瞬间理解“元测评”的含义，意识到自己既是使用者又是开发者。教师根据错误率重点解析第2题，明确重申HTTP的无状态性，为后续讲解会话管理埋下伏笔。【高频考点】【非常重要】

（二）核心算法与接口契约（第2-3课时）

1.加权评分算法建模工坊（第2课时·25分钟）

教师发布需求文档V1.0：测评系统不能仅以“正确/错误”二元计分，必须纳入完成用时（秒）、题目难度（0.5~1.5）、首次尝试标志。小组需在20分钟内给出一个数学公式，并说明公式体现了何种教育理念。A组提出总分=正确得分×难度系数+(30-耗时)/30×10

，但未处理耗时大于30秒时出现负分的情况。B组提出使用max(0,(30-耗时))

保护，并增加系数防止负分。C组引入对数函数压缩长耗时差异。教师将各组公式录入Excel，使用同一组原始数据运行，全班看到排名顺序因公式不同而发生剧烈变化。教师提问：“假如你是被测评的学生，你希望采用哪一组公式？为什么？”学生回答呈现出“希望奖励速度”“希望更看重正确率”等多元价值取向。教师总结：没有绝对客观的算法，权重即价值观。随后学生各自在utils.py

中实现本组讨论确定的公式，并通过教师下发的5组单元测试。测试通过的小组举手示意，教师记录完成时间，并鼓励组内交叉检查浮点数舍入逻辑。【重要】【热点】

1.API优先与接口文档协作（第2课时·15分钟）

教师强调在分布式开发中，必须先约定接口再写代码，否则前后端无法对接。每个小组进入腾讯文档模板，协作编辑/api/submit

接口规范。必填字段包括：student_id（string），question_id（int），is_correct（boolean），time_cost（float），difficulty（float）。选填字段：attempt_times（int，默认为1）。响应体规范：{"code":201,"message":"success","data":{"submission_id":"uuid","score":87.5}}。组长负责分配谁写字段描述、谁写示例值、谁写错误码说明。教师通过文档修订历史查看每位成员的贡献占比，计入过程评价。此环节将编码工作前置为设计工作，极大减少后续因字段名拼写错误导致的联调返工。【非常重要】

1.数据库持久化与参数化查询（第3课时·30分钟）

脚手架中的models.py

已包含SQLAlchemy的声明式基类，但教师为了强化SQL基本功，要求学生在app.py

中使用原生sqlite3模块完成本次项目。教师提供建表语句：

CREATETABLEstudents(idPRIMARYKEY,name);

CREATETABLEsubmissions(idINTEGERPRIMARYKEYAUTOINCREMENT,student_id,qidINTEGER,scoreREAL,submit_timeTIMESTAMPDEFAULTCURRENT_TIMESTAMP,FOREIGNKEY(student_id)REFERENCESstudents(id));

学生将Flask路由中原来追加到列表的代码替换为INSERT语句。第一轮尝试，部分学生直接使用字符串格式化拼接参数，教师立即叫停，展示著名的“小罗伯特';DROPTABLEstudents;--”漫画，强调SQL注入危害。全体学生修改为cursor.execute("INSERTINTOsubmissions(student_id,qid,score)VALUES(?,?,?)",(sid,qid,score))

。此环节使参数化查询成为肌肉记忆。【高频考点】【非常重要】

随后学生编写/api/scores

路由，从submissions表中按student_id分组聚合SUM(score)作为总分，JOINstudents表获取姓名。部分小组遇到因数据类型不一致导致JOIN失败的问题，通过反复比对建表语句中id字段的类型与传入参数的字符串类型，自主解决问题。

1.并发压力初体验与事务认知萌芽（第3课时·15分钟）

教师分发给每组一个简易的Python并发脚本，使用threading

模块模拟20个线程同时向本组服务器的/api/submit

发送请求。许多小组发现，并发提交后查询排行榜，总分合计数与预期严重不符，部分提交似乎“丢失”了。教师引导观察SQLite默认事务隔离级别（可串行化），但在高并发写入时如果没有显式BEGIN/COMMIT，可能出现读写锁竞争导致写入失败但未抛出异常。教师不要求学生此时实现完美事务，而是提出问题：“怎样才能保证并发写入不丢数据？”学生答案包括“排队处理”“加锁”“改用更强大的数据库”。教师肯定所有思路，并预告下节课的缓存与索引优化同样与并发相关，形成学习期待。【难点】

（三）前后端联调与实时渲染（第4课时）

1.Fetch异步请求与动态图表更新（15分钟）

学生打开custom-chart.js

，删除原有的option.series.data

硬编码，编写asyncfunctionloadScores()

。函数内部使用awaitfetch('/api/scores')

获取响应，解析为JSON，然后通过myChart.setOption({series:[{data:json.data}]})

更新图表。首次运行出现跨域错误？教师预先在Flask后端安装Flask-CORS扩展并配置允许所有来源，屏蔽无关干扰。学生观察浏览器控制台Network面板，清晰看到每隔2秒发起的XHR请求。此时教师追问：如果把await

去掉会怎样？学生尝试发现图表无法更新，深刻理解异步等待的必要性。【非常重要】【高频考点】

1.轮询策略权衡与WebSocket拓展（15分钟）

学生为实现“动态”效果，在window.onload

中添加setInterval(loadScores,2000)

。服务器日志飞速滚动，部分学生担心服务器压力，将间隔改为5000毫秒。教师提出场景：如果全班50人每人每2秒请求一次排行榜，服务器每秒要处理25次聚合查询，每次查询涉及全表SUM。学生计算并惊呼。教师展示使用Flask-SocketIO实现的简易在线聊天室，无需客户端主动请求，服务器即可推送新消息。学生立即理解这是“真·实时”。但教师说明WebSocket需额外维护长连接状态，本次项目仅作为选做拓展。各小组自行决定轮询间隔，大部分设置为3000毫秒，并添加当document隐藏时清除定时器的性能优化代码。【难点】【拓展】

1.用户体验细节打磨（10分钟）

学生为看板增加三个微交互：加载数据时柱状图区域显示半透明遮罩及“更新中…”文字；网络错误时在图表上方显示红色告警条，并自动重试3次；鼠标悬停柱状图显示该生详细提交记录（最近5次得分及时间）。这些功能虽非主逻辑，但极大提升了作品完成度。学生参考MDN文档及ECharts官方示例，锻炼查阅资料解决具体问题的能力。【重要】

1.组间接口互测与契约修复（5分钟）

各小组将本机IP地址写在白板右上角。相邻小组交换IP，访问对方的/api/scores

接口。A组发现B组返回的JSON字段是studentName

而接口文档约定的是student_name

，导致自己前端渲染失败。A组在腾讯文档上@B组后端工程师，B组立即修改路由返回字段，并发布修复版本。这个过程紧张有趣，学生切身体会到接口约定不一致带来的集成成本，强化契约精神。【热点】

（四）压力测试与性能优化（第5课时）

1.基准测试与瓶颈定位（10分钟）

教师下发基于Locust的压力测试脚本，设置用户数100，孵化速率5，目标主机为各小组服务器。测试开始后，学生通过任务管理器或top

命令观察到Python进程CPU占用迅速接近100%，响应时间从30ms飙升至4000ms。教师要求每组记录下压测开始后第一次成功请求的响应时间，以及压测过程中错误率。数据记录后，教师宣布第一轮优化挑战开始。【非常重要】

1.索引优化实战（15分钟）

教师引导学生思考：排行榜聚合查询涉及GROUPBYstudent_id

和ORDERBYtotal_score

，目前是全表扫描。学生在DBBrowserforSQLite中执行EXPLAINQUERYPLANSELECT...

，确认扫描方式。随后执行CREATEINDEXidx_student_idONsubmissions(student_id);

及CREATEINDEXidx_submit_timeONsubmissions(submit_time);

。再次执行压测脚本，绝大多数小组发现响应时间下降50%以上。教师进一步提问：“索引能无限添加吗？”学生通过实验发现，增加索引后写入操作（INSERT）变慢。教师总结“读写权衡”，这是架构师的核心决策之一。【高频考点】【难点】

1.缓存策略初探（12分钟）

针对排行榜数据实时性要求为秒级、并不需要每次请求都查库的特点，教师引导学生使用全局字典实现简单缓存。在/api/scores

路由开始时检查cache['ranking']

是否存在且未超过有效期（如5秒），若有效则直接返回缓存数据；否则查库并更新缓存。学生实现后再次压测，发现CPU占用明显下降，吞吐量翻倍。教师提示这是“空间换时间”的典型范例，并预告Redis缓存数据库将是后续课程重点。【重要】【拓展】

1.优化报告提交与版本标签（8分钟）

学生将优化前后的响应时间对比图（截图）粘贴入项目根目录的OPTIMIZATION.md文件，并使用Git打上标签v1.1-optimized

。教师通过GitHubClassroom可视化面板查看哪些小组完成了索引+缓存双重优化，给予对应积分奖励。

（五）项目路演与元测评闭环（第6课时）

1.系统路演与真实性检验（20分钟）

每组上台进行3分钟极限演示。台下学生被指定为“刁钻用户”：故意输入超长字符串作为学生ID，观察是否崩溃；连续以0.1秒间隔狂点提交按钮，测试幂等性；请求不存在的API端点，查看404页面是否友好。台上组紧张应对，台下组通过手机端简易评分界面为每个演示组打分。评分维度包括：功能完整性（40%）、异常处理能力（30%）、界面美观度（20%）、创新亮点（10%）。所有评分数据实时插入教师总看板，大屏立即生成各组得分柱状图。此时，整个教室变成了一个巨型动态测评系统现场。【非常重要】【热点】

1.评分者信度与算法改进（15分钟）

教师导出全班互评原始分数，用箱线图展示每组得分离群值。学生发现某组得分明显偏低，查看详情发现是竞争对手组故意给1分。教师提问：“如何消除评分者恶意极端分？”学生立刻迁移项目中的加权评分经验，提出去掉一个最高分、去掉一个最低分再取平均。教师进一步引导中位数截尾均值（如去掉前10%和后10%）。学生现场在Excel中操作，发现调整后排名趋于稳定。此环节实现“用自己开发的系统理念，改进评价系统本身”的元认知闭环。【难点突破】

1.反思日志与知识图谱生成（10分钟）

学生登录个人博客或云笔记，完成三项反思：我的代码哪一部分最值得自豪？项目中遇到哪一个Bug耗时最长，如何解决？如果动态测评系统用于高考，我会担心哪些伦理风险？教师收集所有日志，使用Pythonjieba分词与WordCloud生成高频词云。“死锁”“索引”“权重”“隐私”等词汇成为视觉焦点，教师据此规划后续复习课专题。

六、教学评价体系

（一）过程性评价构成（60%）

1.代码仓库活跃度（15%）：基于GitInspector统计，要求每位成员总提交次数不少于8次，单次提交修改代码行数不低于5行。杜绝仅修改README等非代码文件的搭便车行为。【重要】

2.接口文档协作贡献度（10%）：腾讯文档修订历史显示每位成员新增/修改单元格次数，且内容必须涉及字段类型、默认值、约束等实质内容，而非仅排版美化。

3.性能优化报告（20%）：需包含优化前响应时间、优化后响应时间、优化原理文字说明、代码片段前后对比。格式采用Markdown，图表清晰，逻辑自洽。

4.同伴互评与贡献度校准（15%）：使用Web端360评价表，每位组员对其他三人贡献度进行星级评定，结合教师课堂观察，使用HAM加权算法剔除明显偏袒或报复性评分。

（二）终结性评价构成（40%）

1.系统路演评委分（25%）：取班级互评经中位数截尾处理后的平均分，确保公平性。

2.单元纸笔测验（15%）：包含5道选择题、2道简答题。选择题覆盖HTTP方法语义、Flask路由装饰器用法