机器人项目该怎么评价？老实的回答是：给造出这台机器人的思考过程打分，而不是给它在桌面上开过去的那三十秒打分。一次成功的演示只能说明这个小组最终做出来了，却说不清谁真的理解了代码、谁抄了同学，也说不清是不是一次凑巧塞好的线救了一个本来就有问题的设计。机器人课上好的评价，看的是一路上积累下来的过程证据，并且把调试当成一项本身就值得给分的能力。

这一点在六月最要紧：第二学期的成绩单要交了，你得把一整个学期热热闹闹的动手活动，变成一个经得起追问的分数。如果你手上唯一的材料就是最后那次运行，能写的东西少得可怜。如果你有日志、迭代记录和简短的复述讲解，分数几乎自己就写好了。

为什么“它动了”是个很弱的评分依据

最终演示只是从一个充满噪声的系统里取的一个样本。电池会掉压，地面的摩擦力和试验台不一样，早上光线下调好的循迹小车，到了下午阳光从窗户照进来时表现又不同。两个小组可能沿着完全不同的路径得到同样的可见结果：一组是推理出来的，另一组是硬试出来的——改数字改到某次能跑为止。只按结果打分，等于给两者同样的奖励，也就悄悄地在告诉你最优秀的那批学生：理解与否无所谓。

这还会惩罚有野心的尝试。一个小组挑战更难的机构、做到了 80%，在演示当天看上去可能还不如一个求稳的小组。如果你的评分量规只看终点线，学生就会学着去挑简单的问题做。评价过程，才能让你诚实地为更难的尝试给分。

评价过程，而不只是成品

把大部分权重挪到学生在动手过程中自己产出的证据上。三样材料几乎承担了全部工作，而且都不需要什么专门的软件。

• 设计日志。每节课写一条带日期的短记录：我们试了什么、原本预期是什么、实际发生了什么、下一步要改什么。半页就足够。价值在于预期和实际之间的落差，因为学习就发生在这个落差里。
• 迭代记录。一份持续更新的版本清单，每次改动配一行理由。“v3：把左电机调慢了，机器人一直往右偏。”这是判断学生在推理还是在猜的最清楚的一扇窗。在我们的积木编程Canvas 上，保存历史本身就已经呈现出这个演进过程，所以这份记录可以简单到只是标注哪几次保存重要、为什么重要。
• 同伴复述讲解。一个项目算完成之前，由小组里的一名成员用大白话向另一个小组讲解代码或结构中被指定的某一段。你听两分钟就够。自己写出这段逻辑的学生能讲下来；抄来的学生会卡在第一个“为什么用这个而不是那个”上。

这三样的目的都是把看不见的思考变得可见，好让你除了最后那次运行之外还有别的东西可打分。

一份为调试给分的评分量规

调试才是机器人开发真正的工作内容，所以它应该占实实在在的分量，而不是被当成需要藏起来的失败。量规里点明这一项，学生的行为就会变：他们会开始把出了什么故障写下来，而不是悄悄回滚到备份、假装什么都没发生过。

对于在sheenbot主板或任何同类套件上做的常规项目，一份简单的四维量规就很好用。把分数拆开，让任何单独一维都撑不起一个薄弱的项目。

• 理解（25%）——学生能否说清自己方案的每一部分做什么、为什么这么做。
• 过程与迭代（30%）——日志和迭代记录的质量；有没有证据表明每次改动都是对着一个预测去检验的，而不是随手乱调。
• 调试（25%）——故障是怎样被定位和修好的；一个被清楚记录下来、找到并解决了的缺陷，得分应该高于一个完全没有任何问题记录的项目。
• 结果（20%）——最终成品是否达到了任务要求。它仍然算分，只是不再占主导。

注意，结果是占比最小的一维。这是有意为之。当学生看到一个被认真追查出来的缺陷比一个干净得可疑、毫无记录的项目更能得分时，他们就不再掩饰自己卡壳的地方，而会开始把过程亮出来。

小组作业与公平

任何动手类科目里最老的抱怨都是“搭便车的人”：一个学生操作笔记本，其他人在旁边看着。过程证据是你最好的防线，因为它天生就是按个人来的。每个成员各写各的简短日志；复述讲解由你点名的学生来做，讲的也是你指定的那一段，而不是他们事先排练好的那段。每节课轮换一个看得见的角色，让操作员、搭建员和测试员每周都换人，并把这个轮换记录下来。

把一小部分分数留给个人，其余算集体。常见的拆法大约是团队 70%、个人 30%，而个人这部分几乎全部来自该学生自己的日志和他的复述讲解。这足以让偷懒无处遁形，又不至于把一个协作项目拆成四个单人项目。竞赛的赛制本来就偏向这个思路：备战 FTC 的队伍要接受工程笔记的评审，记录的是整个赛季，而不只是比赛日那台机器人，这正是你在课堂上要培养的习惯。

让它能长期做下去

如果这些做法让你的批改量翻倍，它们一样撑不下去。工具要轻。日志就半页，对着三个问题打钩带过，而不是每份都写一段反馈。复述讲解在课堂上当场完成，占用的是你听讲的时间，而不是晚上的时间。迭代记录你扫一眼就行，不必逐行细读。从一开始就把检查点编进课程序列，而不是在最后才把评价硬贴上去——就像我们的学院课程体系把简短的反思节点分散在项目全过程中，而不是在终点来一次大审判。长在工作内部的评价，比单独一场批改活动可持续得多。

要点

“机器人动了”是起点，不是分数。把评价的重心挪到过程证据上：带日期的设计日志、诚实的迭代记录，以及简短的同伴复述讲解。做一份为理解和调试付分的量规，把最终结果留成占比最小的一维，而不是故事的全部。这样一来，你的成绩单更好写，闷声搭便车的学生更难藏，而学生学到的是真正能带出教室的那一课：在真实的工程里，思考本身就是产品。