学生AI科创项目怎么测试？正常、边界与异常输入记录方法

一个AI作品在演示时给出正确回答，能说明“这次运行成功”，但还不足以说明作品稳定。项目报告想讲得有依据，需要回答另一个问题：换一组输入，它还能做到什么，在哪里会失败？

本文提供适合项目学习的测试组织方法，不是某项比赛的评分标准，也不涉及特定平台或模型的效果保证。

先写清作品只解决什么问题

例如“帮助整理校园植物观察记录”，比“做一个万能科学助手”更容易检验。先规定接收什么输入、输出什么结果，以及哪些任务不在范围内。范围越清楚，后续越容易区分“功能还没做”和“原本功能出错”。

这个例子是方法示例，不是真实学生案例。

准备三类测试，而不是重复播放同一个成功案例

测试素材应使用自己整理且适合公开的数据；含个人信息的学生记录，不应直接拿来做公开演示。涉及照片、文字或开放数据时，记录来源和使用条件。

给每条测试保留同样的字段

建议记录测试编号、输入、预期表现、实际输出、判断依据、程序或配置版本，以及修改说明。预期表现要在测试前写，而不是看到结果后再改标准。

“回答挺好”不好复查；“缺少地点时先询问地点，不编造观察位置”更容易判断。测试数量不需要用一个看起来很大的数字装饰报告，但至少应该覆盖作品宣称能够处理的主要情况。

改进前后，用同一组任务比较

修正一次失败后，先重测原任务，再检查其他任务有没有受影响。保留初次结果和修改后结果，不只展示筛选过的成功截图。

如果某次输出不同，可以记录现象，不急着声称系统“学会了”。把能由测试证明的部分、自己的推测和仍未解决的问题分开，结论才不会超过证据。

报告里怎样说明学生自己的工作

区分现成模型或平台提供的能力，以及学生完成的需求分析、界面、程序连接、数据整理和测试。引用工具并不会让项目失去意义；说不清自己的选择和贡献，才会让解释变得空泛。

展示时可以选择一个失败案例：原来哪里不对、学生怎样发现、尝试了哪些办法、修改后有什么改善、还有什么限制。这通常比连续播放成功动画更能说明项目过程。

需要了解项目测试和反馈范围，可查看已有项目诊断；准备赛事展示时，再核对对应赛事的规则和报告与答辩指导。