AI与编程
用大模型做科创项目:学生自己完成的部分在哪
大语言模型让很多复杂功能变得容易实现,但如果项目只是调用接口、包装界面,学生自己的工作就很难体现。本文说明大模型类项目中学生可以深入的方向,以及报告中怎样说明分工和测试。
文章目录收起
有了大语言模型,做一个能对话、能回答问题的“智能助手”变得很容易,调用接口、写个界面,一两天就能完成。但评委看到这样的项目,常常会问:这里面哪些是你做的?如果答案只是“我调用了接口”,项目就很难有说服力。
先问自己三个问题
- 我的项目解决的是谁的什么具体问题?
- 去掉大模型,我的项目还剩下哪些工作?
- 我怎样证明这个项目真的有效?
这三个问题回答清楚,项目才有自己的内容。
学生可以深入的方向
| 方向 | 学生可以做的工作 |
|---|---|
| 明确场景 | 选一个具体、窄的场景,例如帮助低年级同学理解科学课实验步骤 |
| 资料整理 | 整理该场景需要的准确资料,让回答有依据 |
| 流程设计 | 设计提问和回答的流程,决定什么情况下怎样回应 |
| 效果评测 | 设计测试题,统计回答的准确率和问题类型 |
| 安全限制 | 设计规则,避免给出错误、不适合的回答 |
其中“效果评测”最容易做出有研究价值的内容。
效果评测怎么做
以“科学课实验助手”为例:
- 准备50个学生可能会问的问题,覆盖不同实验。
- 事先写好每个问题的标准答案要点。
- 让助手回答,逐条对照,标记“正确”“部分正确”“错误”。
- 统计各类结果的比例,分析错误回答有什么共同点。
- 改进资料或提示后,再测一次,比较前后结果。
| 版本 | 正确 | 部分正确 | 错误 |
|---|---|---|---|
| 第一版 | 31 | 11 | 8 |
| 补充实验资料后 | 40 | 7 | 3 |
这样的数据能清楚地说明学生的工作带来了什么改进。
关注错误和风险
大模型有时会给出看起来很有道理、实际上是错误的回答。项目中可以专门研究:
- 在什么样的问题上容易出错?
- 怎样设计提示或规则减少错误?
- 遇到不确定的问题,怎样让助手如实说“不知道”?
研究这些问题,比展示助手能回答多少问题更有价值。
报告中说明分工
报告里要清楚写明:使用了哪个模型或接口,哪些功能由模型提供,哪些部分是自己设计和完成的。测试数据、改进过程、遇到的问题,都要如实记录。
使用中的注意事项
- 不要把同学的个人信息输入到在线模型中。
- 测试时如果涉及其他人,要告知并征得同意。
- 生成的内容如果用在报告中,要注明来源,并自己核对准确性。
大模型是强大的工具,但项目的价值在于学生用它解决了什么问题、怎样验证效果。把注意力放在场景、评测和改进上,大模型项目同样可以做得扎实。
资料与编写说明
原创方法文章,诺篮Stem编辑部根据项目指导经验整理
资料核验:2026-10-01从阅读,走到自己的项目
咨询项目方向孩子有想法,却不知从哪里开始?
带上兴趣、年级或已有作品,先聊清楚当前最需要解决的问题。