一个学生看到一道数学题，很快就知道应该怎么做。

求平均数。

计算百分比。

比较两个结果。

代入公式。

在纸上，他可能几分钟甚至几十秒就能得到正确答案。

但是，如果把要求改成：

请用 Python 写出这个问题的解决过程。

同一个学生却可能突然停下来。

第一行应该写什么？

哪些数需要定义为变量？

应该先计算哪一步？

中间结果要不要保存？

什么时候需要 if？

什么时候需要循环？

这时，我们很容易得出一个结论：

这个学生不会 Python。

但问题未必这么简单。

他可能已经理解了数学，也掌握了一些 Python 语法。

真正缺少的，是另一种能力：

把自己脑中的解题思路展开成计算机可以一步一步执行的过程。

“我会做”并不等于“我能把过程完整表达出来”

来看一个简单的例子。

三个数：

12、18、30。

求它们的平均数。

学生可能直接写：

[
(12 + 18 + 30) / 3 = 20
]

对于一个理解平均数概念的人来说，这已经足够了。

我们知道为什么要相加。

也知道为什么除以 3。

很多思考过程根本不需要写出来。

但如果让计算机完成同样的任务，我们必须把过程表达得更明确：

a = 12
b = 18
c = 30

total = a + b + c
average = total / 3

print(average)

数学知识没有改变。

改变的是表达思维的方式。

在人脑中可以被压缩的一系列步骤，现在必须被展开。

人脑可以跳步，程序不能

学生在纸上计算时，常常会自动完成很多没有写出来的操作。

例如：

一件商品原价 500 元，打八折后多少钱？

一个理解百分比的学生可能马上想到：

[
500 \times 0.8 = 400
]

甚至不需要明确写出“折扣金额”。

但是，在程序中，我们可以把整个过程拆开：

price = 500
discount_rate = 20

discount = price * discount_rate / 100
final_price = price - discount

print(final_price)

这里出现了几个不同的对象：

  • 原价；
  • 折扣比例；
  • 折扣金额；
  • 最终价格。

人脑可能把这些关系压缩成一个熟悉的计算。

而编程要求学生明确回答：

每一个量是什么？它从哪里来？它和下一步有什么关系？

这正是很多困难出现的地方。

数学答案和计算过程不是同一层知识

学校里的数学学习很容易让学生把注意力集中在答案上。

答案是多少？

公式有没有用对？

最后的数字对不对？

但程序设计提出了另一个问题：

这个答案是怎样产生的？

这两个问题并不相同。

假设：

x = 10
y = 20

print(x + y / 2)

学生本来想求两个数的平均值。

他的数学想法可能完全正确：

先把两个数相加，再除以 2。

但实际代码表达的是：

[
10 + (20 / 2)
]

而不是：

[
(10 + 20) / 2
]

正确写法应该是：

average = (x + y) / 2

print(average)

当然，我们可以告诉学生：

“这里少了括号。”

但这只是修改了一个错误。

更重要的问题是：

为什么学生脑中的正确数学关系，在变成代码时发生了变化？

这才是值得诊断的地方。

Python 不知道你“本来想表达什么”

人与人交流时，可以依靠语境。

一句话即使没有把所有信息说出来，对方往往也能理解。

我们会自动补充缺失的信息。

会根据经验推断说话者的意思。

甚至会忽略一些不影响理解的小错误。

计算机不会这样做。

它不会想：

“这个学生大概是想先把两个数加起来。”

它只执行已经写出的指令。

因此，编程迫使学生面对一个非常重要的问题：

我的想法是否已经被表达得足够明确？

这也是为什么编程不仅是在学习命令和语法。

它同时训练一种更严格的思维表达方式。

在数学题和 Python 之间，还有一个经常被忽略的层次

我们有时把学习过程想成：

数学题 → Python

实际上，中间还有几个重要阶段：

题目 → 理解题意 → 数学模型 → 运算步骤 → 算法 → 代码 → 验证

任何一个阶段都可能出现问题。

学生可能正确理解题目，但不知道应该建立什么数学关系。

也可能数学模型完全正确，却不知道怎样把它拆成步骤。

还可能算法已经清楚，只是在 Python 语法上出错。

甚至程序可以正常运行，但它解决的根本不是原来的问题。

所以：

代码错了，并不能自动说明学生的 Python 不好。

我们必须知道错误究竟从哪一层开始。

会写 Python 语法，也不一定会把数学问题程序化

学生可能已经学过：

  • 变量；
  • input()；
  • print()；
  • if 条件；
  • 循环；
  • 函数。

如果练习明确要求：

“请使用 if。”

他可能会做。

如果老师说：

“这里写一个 for 循环。”

他也可能写得出来。

但真正的问题通常不会告诉学生应该使用什么结构。

学生必须自己判断：

哪些是输入数据？

最终需要得到什么？

哪些中间结果必须保存？

有没有不同情况？

某个操作是否需要重复？

步骤之间有什么依赖关系？

这时考查的已经不只是 Python 语法。

而是算法思维。

真正的理解，会在题目发生变化时表现出来

如果练习和课堂上的例题几乎一样，学生可以模仿原来的代码。

但如果我们改变条件呢？

例如：

  • 三个数变成三十个数；
  • 折扣率根据价格变化；
  • 某些数据必须被排除；
  • 输入值可能不符合要求；
  • 一个计算结果决定下一步执行什么；
  • 同一程序必须处理不同的数据。

这时，单纯记住代码结构就不够了。

学生必须理解：

为什么程序是这样组织的。

这也是“会做一道题”和“掌握一种方法”的区别。

AI 可以生成代码，但不能替代这个认知过程

现在，得到一段正确代码非常容易。

学生可以搜索类似例题。

可以复制现成程序。

也可以让 AI 生成完整解决方案。

这些工具本身并不是问题。

关键在于：

学生是否理解得到的代码为什么这样工作？

可以进一步问：

  • 为什么需要这个变量？
  • 如果数据改变，哪一部分代码也要改变？
  • 为什么这里使用条件？
  • 为什么这个操作必须先执行？
  • 能不能不用看代码，先解释整个解决过程？

如果这些问题无法回答，那么程序即使能够运行，也不能证明学生已经掌握了背后的知识。

GeoGebra、Excel 和 Python 展示的是不同的思维结构

同一个数学问题可以放进不同工具中。

但工具并不是完全中性的。

GeoGebra特别适合展示函数、几何对象以及数学关系的视觉变化。

Excel非常适合处理表格、数据序列、公式和重复计算。

Python则会把过程结构暴露得更加明显：

先做什么？

后做什么？

什么条件下执行？

什么操作重复？

哪些结果需要继续使用？

因此，一个学生会使用 GeoGebra，并不意味着他自然就会用 Python 表达同一个问题。

会使用 Excel 公式，也不意味着他已经掌握算法思维。

这不是简单的“会不会使用软件”。

而是学生能否在不同的知识表示方式之间进行转换。

如果数学本身还是用外语学习的呢？

在国际教育环境中，问题还可能多一层。

学生可能用英语、德语或其他语言学习数学，然后再使用 Python 完成任务。

此时真正的路径可能是：

题目语言 → 理解题意 → 数学模型 → 运算过程 → 算法 → Python

所以，最后出现在代码里的错误，可能实际上从语言理解阶段就已经开始了。

例如，学生可能：

  • 没有准确理解某个数学术语；
  • 忽略了题目中的限制条件；
  • 误解了两个量之间的关系；
  • 正确完成了计算，却回答了另一个问题。

在这种情况下，把“语言”“数学”和“编程”完全分开教学，并不一定能够找到真正的困难。

有时，语言本身就是学科思维的一部分。

与其马上改代码，不如先让学生把思路说出来

如果老师直接写出正确程序，当前这道题很快就能完成。

但如果目标是让学生以后能够独立解决问题，那么更有价值的是先问：

  • 已知什么？
  • 要求什么？
  • 第一步是什么？
  • 为什么先做这一步？
  • 会产生什么中间结果？
  • 下一步依赖哪个结果？
  • 有没有条件判断？
  • 有没有需要重复执行的操作？
  • 最后怎样检查结果是否合理？

还有一个非常重要的问题：

如果暂时不用 Python，你能不能把解决过程一步一步解释清楚？

如果不能，那么困难可能还没有到代码这一层。

先找到问题发生在哪一层

在 Levitin Language School，学生无法把数学题写成 Python 程序，并不会自动被理解为“Python 学得不够”。

首先需要判断问题发生在哪里。

可能是：

  • 数学概念；
  • 题意理解；
  • 逻辑关系；
  • 把问题拆成步骤的能力；
  • 算法思维；
  • Python 本身；
  • 学习该学科所使用的语言。

只有找到真正断裂的位置，教学才能针对原因，而不是只修改最后出现的错误。

在 Language Learnings 的国际学习环境中，这一点尤其重要：语言可能不仅是学习对象，也可能是学习数学、编程和其他学科的工具。

而在 Tymur Levitin 的教学方法中，关键问题不仅是：

“答案对不对？”

还包括：

“这个答案是通过什么思维机制产生的？”

因此，三个层面相互加强：

Tymur Levitin —— 对学习机制、知识转换和错误来源进行分析与诊断；

Levitin Language School —— 根据学生的实际需要连接语言、数学、编程及其他学科；

Language Learnings —— 在国际学习环境中连接语言能力与知识的实际使用。

数学 + 编程 + 语言

有些学生真正需要的是数学。

有些需要的是 Python。

有些两者分别都会，却不知道怎样把数学思维转换成算法。

还有一些国际学校的学生，需要同时解决另一个问题：

如何用学习语言理解并处理学科知识。

所以，真实的学习需求未必能被简单归入一个标签。

它可能正好位于几个领域的交叉点：

数学 + 逻辑 + 编程

或者：

语言 + 学科 + 编程

找到这个交叉点，往往比单纯增加练习数量更重要。

了解更多

如果学生能够在纸上正确解决数学问题，却无法独立把它写成 Python 程序，首先值得判断的是：困难究竟来自数学、逻辑、算法、Python，还是学习语言。

在 Levitin Language School，学习可以根据学生实际需要组合语言、数学、编程以及其他学科，而不是先把学生的问题强行归入某一个固定课程标签。

Language + Subject 的学习路径也适用于那些使用外语学习数学、计算机科学或其他学科的学生：语言在这里不仅是学习目标，也是获取和运用知识的工具。

Levitin Language School
https://levitintymur.com/

Language Learnings
https://languagelearnings.com/

Tymur Levitin
创始人兼校长
Levitin Language School / Language Learnings

全球学习。个性化方法。

© Tymur Levitin。保留所有权利。