附录D 项目评价量规

一、评价原则

评价不以代码行数、模型大小、使用软件数量或演示效果作为主要依据。公共核心项目重点评价学生能否把任务、输入、模型、规则、测试和人的责任连接起来；综合项目增加专业真实性、另一组复现、交接和维护。

建议总分100分。任一项目若违反数据授权、隐私或硬件安全底线，即使其他部分得分较高，也不能判定为可投入使用的成果。

二、通用项目量规

评价维度	权重	优秀	达标	需改进
任务与价值	12	使用者、结果、输入输出、约束、错误后果和验收明确，能够解释为何需要或不需要AI	任务和主要输入输出明确，有基本验收条件	只描述功能或技术，使用者、结果和验收含糊
数据与证据	14	来源、授权、字段、单位、版本和质量问题可追溯，训练与测试隔离	主要数据来源和字段清楚，能发现常见质量问题	材料来源不明，数据泄漏或用成功样例替代测试
AI协同开发	12	保留任务、追问、首版、运行、限定修改、差异和回归证据，学生决策清楚	能提供主要对话和运行修改记录	只保存最终回答或无法说明AI修改了什么
技术机制	14	能沿输入—表示—模型/算法—输出—规则解释关键链，并正确区分生成、预测、优化或感知	能解释主要技术和关键变量	把界面、普通计算或流程自动化误称为模型能力
基线与变量实验	10	有人工/规则/统计基线，只改变一个关键条件，用同一测试比较并解释取舍	有基线或一次变量比较	没有参考方法，或同时改变多项条件得出结论
测试与失败分析	16	正常、边界、陌生和故障样例齐全，指标对应错误后果，分析典型失败	有独立测试和主要错误记录	只展示成功，评价样本与训练混用
安全、权限与责任	10	数据、权限、停止、人工接管和高风险禁区可执行	能指出主要风险和人工确认点	把关键决定交给模型，缺少停止或越权保护
交付与复现	12	文件、环境、版本、说明、`acceptance.py`、真实报告和回滚齐全，另一组能够复现并处理一个故障	能按README运行主要功能和固定测试	只能在原作者电脑演示，缺少版本、测试入口和已知问题

三、四档成绩解释

90—100分：任务、技术、证据和交付形成闭环，可以在明确限制下进入受控试用。
75—89分：主要链路完整，存在可修正缺陷；完成指定回归后可进入下一阶段。
60—74分：能够运行，但任务、数据、测试或交接至少一项明显不足，只能作为学习原型。
60分以下：无法形成可复核工作成果，需退回任务定义或最小实现阶段。

四、一票否决与限用条件

以下情况不能判定“通过”：

使用未经授权的个人、企业或专业数据，或者在项目中明文保存密钥。
模型直接控制市电、燃气、加热、压力、高速运动、门锁、交通工具或医疗设备。
没有独立测试，只使用训练样例或展示样例证明有效。
隐藏完整实现，学生无法说明输入、输出、模型、规则和人的分工。
另一组无法运行且没有环境、版本或故障说明。
语言模型的流畅回答被直接当作专业事实、规程或责任结论。

五、综合项目答辩问题

答辩至少回答：

真实工作目标是什么，不使用AI时怎样完成？
为什么选择当前模型、规则和运行位置？
数据从哪里来，最可能造成什么偏差？
哪个失败样例最改变了你们的设计？
AI生成了哪些文件，学生否决或限定了哪些修改？
哪个错误代价最高，系统怎样停止并交给谁？
另一组复现时遇到什么问题，交付包怎样修订？
什么证据会使你们决定缩小范围、回滚或不用AI？

六、个人学习证据评分

团队项目之外，每位学生提交一页个人说明，回答自己提供了什么上下文、亲手调整了哪个变量、审查了哪次AI修改、发现了哪个失败、作出了什么判断。建议个人证据占课程总评的20%—30%，避免只按小组演示统一给分。