——“求余计算器”教学记
高一的信息技术课上，我第一次抛出这个问题时：你们是代码的搬运工吗？教室里安静了几秒，然后一个学生小声说：“老师，代码不就是复制粘贴吗？能运行就行啊。”这句话让我愣了一下。
一直以来，Python教学为了赶进度，我习惯把基本代码框架提供给学生，让他们填写核心的判断条件和输出结果。表面上看，学生完成了任务，程序也跑通了。但课后我问他们“为什么要这样写”，大多数学生一脸茫然——“我就是照着贴的，没想过为什么。”
从“填空”到“从头写”
这次我设计了一个“求余计算器”的任务：输入被除数、除数和用户给出的答案，让计算机判断答案正确与否。
第一课时讲理论，我用了20分钟讲解了求余运算的逻辑和判断语句的结构，剩下时间让学生尝试写代码。结果发现，大部分学生连if语句的基本缩进都会出错，更不用说理解input()返回的是字符串、需要int()转换。下课铃响时，全班只有不到五分之一的学生写出了能运行的代码。
问题出在哪里？理论讲得再清楚，学生不动手敲一遍，那些知识点永远是老师的，不是他们的。第二课时：放手让学生“手搓代码”
第二课时我调整了策略。不提供任何现成代码，只给任务要求和一张思路导图：
用input()获取三个数
用%计算实际余数
用if比较实际结果与用户答案
输出“正确”或“错误”，如果错了还要输出正确结果
这节课我给足了时间——整整40分钟让学生从零开始敲代码。允许他们互相交流、查资料、试错。教室里响起了此起彼伏的键盘声和讨论声。
“老师，我忘记把input转成整数了！”
“原来%是取余啊，我还以为和除号一样。”
“为什么我判断对了但输出总是‘错误’？……啊，我把等号写成赋值号了！”
这些声音让我很欣慰。学生在主动思考，而不是被动粘贴。
在学生编写过程中，我走到每个人身边，逐一查看代码。不讲空话，直接指出问题：
“你看看第三行，变量名写错了，大小写不一致。”
“你的if后面少了冒号，Python靠这个识别代码块。”
“逻辑没问题，但能不能把输出语句写得更友好一些？”
被点到的学生立刻修改，然后再跑一遍程序。当屏幕上终于出现“正确！”或“计算错误，正确余数是X”时，他们脸上那种“成了！”的表情，比任何分数都真实。
有个平时不爱发言的男生，反复调试了6次才成功。最后一次运行时，他几乎跳起来：“老师老师，我的求余计算器活了！”
下课前，全班50人都成功提交了能运行的代码。虽然风格各异——有人只用了一个if-else，有人写了嵌套判断，还有人加上了循环让程序可以重复使用——但每一个都是亲手敲出来的。
更重要的是，学生开始主动交流代码了。“你这里可以优化一下”“我用elif实现了三种情况判断”。这种氛围，是复制粘贴永远给不了的。
回到那个问题：Python教学只有部分语句，甚至复制粘贴行吗？
不行。
复制粘贴能让学生快速完成任务，但无法培养程序思维。编程的本质不是记住语法，而是学会拆解问题、设计逻辑、调试错误。这些能力，只有在亲手敲代码、反复试错的过程中才能真正获得。
当然，完全“手搓代码”需要时间。两课时的安排——第一课时讲清核心概念，第二课时给足动手时间——是比较可行的方案。关键是第二课时老师要走下讲台，做一对一的“代码医生”，让每个学生都能在被理解、被指导的过程中，享受到程序从“报错”到“运行成功”的那种真实乐趣。
现在，每次开始新任务前，我都会问学生同样的问题：“这段代码，你打算复制粘贴，还是自己写？”
答案正在悄悄改变。
