第一章 计算思维与编程思维的本质界定 / Chapter 1: The Ontological Definition of Computational Thinking and Programming Thinking

当“编程要从娃娃抓起”的口号响彻各类教育宣传时，绝大多数初学者对编程的认知仍停留在“写代码”“背语法”“刷算法题”的层面：不少人在学习了三个月Python后，仍无法独立解决“如何批量整理手机里的照片”“如何统计班级成绩的平均分”这类简单的实际问题；更有大量非技术领域的从业者，将编程思维视为程序员群体的专属技能，与自身工作完全无关。这种认知偏差的本质，是对<术语>计算思维（Computational Thinking，简称CT）</术语>与<术语>编程思维（Programming Thinking，简称PT）</术语>这两个核心概念的系统性混淆——前者是人类应对复杂问题的通用思维框架，后者是将该框架落地为可执行程序的形式化表达能力，二者共同构成了数字化时代所有个体必备的核心底层能力。

一、核心概念的形式化界定

1.1 计算思维：面向所有人的通用问题求解框架

计算思维的概念最早由卡内基梅隆大学计算机科学教授Jeannette Wing于2006年在《Communications of the ACM》发表的里程碑论文《Computational Thinking》中正式提出^①。在该论文中，Wing明确指出：计算思维是“运用计算机科学的基础概念进行问题求解、系统设计、以及人类行为理解的一系列思维活动”，其核心特征是形式化、抽象化、自动化，且并非计算机科学领域的专属技能，而是所有人在日常生活、工作中都可以使用的通用能力。

从认知科学的角度来看，计算思维的本质是对问题进行“计算式”的拆解：将模糊、非结构化的问题转化为可以被明确描述、可以被量化分析、可以被重复验证的结构化问题。例如，当你计划国庆假期出游时，需要综合考虑时间、预算、目的地热度、交通便利度等多个变量，最终筛选出最优路线——这一过程中用到的“多变量权重排序”“路径规划”等思路，就是典型的计算思维应用，此时你并不需要编写任何代码，仅通过纸笔或思维导图即可完成整个分析过程。

> 💡 电子版侧边栏提示：Wing在2006年提出计算思维概念时，曾明确预言“计算思维将成为21世纪每个人的基础能力，如同读、写、算一样成为必备技能”。截至2024年，全球已有超过40个国家将计算思维纳入K12阶段必修课程，我国教育部也在2022年版《义务教育信息科技课程标准》中明确将计算思维作为核心素养目标之一。

1.2 编程思维：计算思维的可执行落地形式

如果说计算思维是“解决问题的思路”，那么<术语>编程思维（Programming Thinking）</术语>就是“将思路转化为计算机可执行指令的表达能力”。二者的核心差异在于：计算思维可以仅存在于人的头脑中，用自然语言、流程图、数学模型等方式表达；而编程思维必须将解决问题的过程转化为无歧义的、可被计算机逐条执行的、形式化的指令序列，也就是我们通常所说的“程序”。

从本体论角度来看，编程思维是计算思维的一个子集，但并非所有计算思维都可以直接转化为编程思维：前者允许存在模糊的、经验性的判断，而后者要求所有的判断条件、操作步骤都必须满足“确定性”与“完备性”要求。例如，日常计算思维中“天气不好就取消户外活动”的判断是合理的，但转化为编程思维时，必须首先明确“天气不好”的定义：是降水量≥0.1mm？还是空气质量指数（AQI）>100？还是风力≥5级？只有将所有模糊条件转化为明确的量化规则，计算机才能正确执行对应的指令。

二者的关系可以用如下流程表示： ```mermaid graph TD A[现实世界问题] --> B[计算思维：抽象建模、形式化问题定义] B --> C[编程思维：设计算法、编写可执行代码] C --> D[计算机执行、输出结果] D --> E[结果反馈、优化思路] E --> B ```

1.3 二者的边界与关联

计算思维与编程思维并非完全独立，而是存在明确的包含与落地关系：所有编程思维都是计算思维，但并非所有计算思维都需要转化为编程思维。例如，医生规划手术方案时用到的“分步拆解手术风险、预判不同操作的结果”，属于计算思维，但若不需要将方案输入计算机辅助模拟，则不需要转化为编程思维。

二者的核心差异可以归纳为三个维度： 1. 表达形式差异：计算思维可以用自然语言、流程图、数学模型表达，编程思维必须用编程语言（如Python、C++、Java等）或伪代码表达； 2. 严谨性要求差异：计算思维允许存在合理的模糊区间，编程思维要求所有规则无歧义、无边界遗漏； 3. 输出物差异：计算思维的输出是“问题解决方案”，编程思维的输出是“可编译/可执行的程序代码”。

二、编程思维与日常思维、数学思维的异同辨析

要深入理解编程思维的本质，需要将其与人类最常用的两种思维模式——日常思维、数学思维进行对比，明确其独特特征。

2.1 编程思维 vs 日常思维：从模糊经验到形式化规则

日常思维是人类在长期生活实践中形成的经验性思维模式，其核心特征是模糊性、情境性、经验性，通常不需要对问题进行完全量化的拆解，仅通过过往经验即可快速做出判断。而编程思维的核心特征是形式化、可复现、无歧义，要求将所有的判断条件、操作步骤转化为明确的规则。

我们以“判断一个数是否为偶数”为例对比两种思维的差异：

• 日常思维的表述：“能被2整除的数就是偶数”，这一表述在绝大多数场景下是成立的，但存在模糊空间：什么是“整除”？负数算不算？0算不算？输入不是数字怎么办？
• 编程思维的表述需要覆盖所有边界情况，以Python代码为例：

```python def is_even(num):

首先校验输入类型，排除非数字情况

if not isinstance(num, int): raise TypeError("输入必须为整数类型")

明确0属于偶数，负数同样适用偶数规则

return num % 2 == 0 ``` 可以看到，编程思维比日常思维多了三层严谨性要求：第一，对输入进行合法性校验；第二，明确边界情况（如0、负数）的规则；第三，确保逻辑的普适性，不会因场景变化而出现歧义。

再以“买菜的选品”为例：日常思维的决策逻辑可能是“挑新鲜的、便宜的买”，而编程思维需要先对“新鲜”“便宜”进行量化定义：新鲜度以“采摘后时长”为标准，24小时内为优，48小时内为良，超过72小时不考虑；价格以“单位重量单价”为标准，同时设置新鲜度的权重系数（新鲜度权重0.7，价格权重0.3），最终通过加权评分筛选最优商品。这种将模糊经验转化为可量化规则的过程，就是日常思维向编程思维转化的核心。

2.2 编程思维 vs 数学思维：从证明正确到可执行、可复用

数学思维与编程思维同属严谨的逻辑思维范畴，二者都要求逻辑自洽、无矛盾，但核心目标存在本质差异：数学思维的核心目标是证明命题的正确性，只要逻辑链条完整、结论正确即可；而编程思维的核心目标是设计可被计算机执行、可复用、可维护的解决方案，除了要求逻辑正确，还要考虑执行效率、资源占用、扩展性等工程化要求。

我们以“计算1到100的所有整数之和”为例对比两种思维的差异：

• 数学思维的解法：直接使用高斯求和公式，$$S = \frac{n(n+1)}{2}$$，代入$n=100$即可得到结果$S=5050$，只要公式推导正确，结论就是成立的。
• 编程思维的解法需要考虑更多工程化因素：如果$n$的规模达到$10^9$，公式计算是否存在数值溢出风险？如果后续需要扩展为“计算1到n的所有偶数和”，当前的解法是否可以直接复用？如果输入n不是正整数，是否需要做容错处理？基于这些考虑，编程思维的代码实现可能如下：

```python def sum_1_to_n(n: int) -> int: """ 计算1到n的所有正整数之和 :param n: 正整数上限 :return: 总和 """

输入合法性校验

if not isinstance(n, int) or n < 1: raise ValueError("n必须为大于等于1的正整数")

使用公式计算，Python自动处理大整数溢出问题

return n * (n + 1) // 2 ``` 可以看到，编程思维在数学思维的基础上，额外增加了输入校验、边界处理、可复用性设计（函数封装、类型标注、文档说明）等工程化要求，这也是二者最核心的差异。

二者的核心差异可以归纳为如下表格： | 对比维度 | 数学思维 | 编程思维 | |----------------|-----------------------------------|-----------------------------------| | 核心目标 | 证明逻辑正确性、结论正确性 | 设计可执行、可复用、可维护的解决方案 | | 严谨性要求 | 逻辑自洽、无矛盾即可 | 逻辑自洽+边界覆盖+容错处理 | | 效率要求 | 通常不关注计算效率 | 必须考虑时间复杂度、空间复杂度 | | 复用性要求 | 定理可复用，但无工程化封装要求 | 要求代码模块化、可移植、易扩展 | | 输出物 | 证明过程、结论 | 可执行的程序、算法 |

三、编程思维的三大核心支柱

编程思维并非单一的能力，而是由三个相互关联的核心支柱共同构成：<术语>算法设计能力（Algorithm Design Ability）</术语>、<术语>逻辑推理能力（Logical Reasoning Ability）</术语>、<术语>问题分解能力（Problem Decomposition Ability）</术语>。三者共同构成了编程思维的核心框架，缺一不可。

3.1 问题分解能力：将复杂问题拆解为可执行的最小单元

问题分解是编程思维的第一步，也是绝大多数初学者最欠缺的能力：很多人面对复杂问题时，第一反应是“我做不到”，而非“我可以把大问题拆成小问题逐步解决”。问题分解的核心逻辑是分治（Divide and Conquer）：将一个规模大、复杂度高的大问题，拆解为若干个规模更小、逻辑更简单的子问题，直到每个子问题都可以被转化为计算机的原子操作（即不能再拆解的最小执行单元，如“判断两个数的大小”“给变量赋值”等）。

我们以“开发一个校园点餐小程序”为例，说明问题分解的过程： 1. 顶层大问题拆解为4个一级子问题：用户端功能、商家端功能、平台管理功能、支付功能； 2. 用户端功能进一步拆解为二级子问题：用户注册登录、菜品浏览、购物车管理、订单提交、订单查询； 3. 订单提交功能进一步拆解为三级子问题：校验购物车是否为空、校验用户地址是否填写、调用支付接口、生成订单号、写入订单数据库； 4. 最终拆解到原子操作：判断购物车商品数量是否>0、获取用户输入的地址信息、调用微信支付API接口等。

可以看到，经过四层分解后，原本看起来非常复杂的“开发点餐小程序”问题，被拆解为若干个可以直接用代码实现的原子操作，每个操作的逻辑都非常简单，组合起来即可完成复杂的功能。这种分解能力不仅适用于编程，也适用于所有复杂问题的解决：比如写一篇论文，可以拆解为选题、文献调研、搭建大纲、填充内容、修改润色等步骤，每个步骤再进一步拆解，即可避免“面对空白文档无从下笔”的困境。

> 💡 电子版侧边栏提示：初学者常见的误区是“一上来就想写完整的代码”，结果写了十几行就发现逻辑不通，最终放弃。正确的做法是先画流程图、写伪代码，把整个逻辑理清楚后再写代码，遇到复杂问题先做分解，不要试图一步到位。

3.2 逻辑推理能力：确保方案的正确性与完备性

如果说问题分解是“把问题拆小”，那么逻辑推理就是“确保每个小问题的解决逻辑是正确的”。编程思维对逻辑推理的要求远高于日常思维：日常思维允许存在“大概”“可能”“差不多”的判断，而编程思维要求所有的判断条件、逻辑分支都满足确定性、一致性、完备性三个要求。

• **确定性**：同一个输入在任何时候都必须得到相同的输出，不能存在“有时候对有时候错”的情况；
• **一致性**：所有的规则不能相互矛盾，例如不能同时定义“年龄≥18岁为成年人”和“年龄<16岁为成年人”；
• **完备性**：必须覆盖所有可能的输入情况，不能存在逻辑遗漏，例如判断用户权限时，不能只考虑“管理员”和“普通用户”，还要考虑“未登录用户”“被封禁用户”等边界情况。

我们以“判断用户是否有权限查看某篇文章”为例，说明逻辑推理的完备性要求：

• 不完善的逻辑：`if user.role == "admin" or user.role == "vip": return True`，这一逻辑遗漏了“作者本人可以查看自己的文章”的情况，也遗漏了“文章是公开的，所有用户都可以查看”的情况；
• 完善的逻辑需要覆盖所有情况：

```python def can_view_article(user, article):

情况1：管理员拥有所有权限

if user.role == "admin": return True

情况2：文章作者可以查看自己的文章

if user.id == article.author_id: return True

情况3：公开文章所有用户可查看

if article.is_public: return True

情况4：VIP用户可以查看所有非加密文章

if user.role == "vip" and not article.is_encrypted: return True

其他情况无权限

return False ``` 可以看到，完善的逻辑推理需要穷尽可能的所有情况，不能存在逻辑漏洞，这也是编程和日常思维最大的差异之一：日常思维中“差不多就行”的模糊判断，在编程中会直接导致程序崩溃、数据错误等严重问题。

逻辑推理能力还体现在对算法复杂度的分析上：我们通常用<术语>时间复杂度（Time Complexity）</术语>和<术语>空间复杂度（Space Complexity）</术语>来描述算法的效率，用大O符号$O(f(n))$表示算法执行时间/空间随输入规模$n$增长的上界。例如，遍历一个长度为$n$的数组的时间复杂度是$O(n)$，而二分查找的时间复杂度是$O(\log n)$，当$n$达到$10^6$时，$O(n)$的算法需要执行$10^6$次操作，而$O(\log n)$的算法仅需要约20次操作，效率差异超过5万倍。这种对逻辑效率的推理能力，是编程思维区别于普通逻辑思维的核心特征。

3.3 算法设计能力：将逻辑转化为可复现的执行步骤

算法是解决特定问题的、明确的、可复现的步骤序列，<术语>算法设计能力（Algorithm Design Ability）</术语>就是设计这种步骤序列的能力。很多人误以为算法设计就是背排序、查找等经典算法，实际上算法设计的核心是根据问题的特征，选择最合适的解决路径，而非盲目套用现有算法。

我们以经典的“倒水问题”为例：现有3L和5L的两个空杯子，如何量出恰好4L的水？日常思维的解法是“反复尝试倒水”，而算法设计需要先对问题进行建模： 1. 定义状态：每个状态可以用元组$(a, b)$表示，其中$a$是3L杯子的水量，$b$是5L杯子的水量，初始状态为$(0, 0)$； 2. 定义操作：所有可能的操作包括“装满3L杯”“装满5L杯”“倒空3L杯”“倒空5L杯”“3L杯倒向5L杯”“5L杯倒向3L杯”6种； 3. 定义目标状态：$(4, x)$或$(x, 4)$，即任意一个杯子中的水量为4L； 4. 通过状态转移搜索路径：$(0,0) \to (3,0) \to (3,5) \to (0,5) \to (3,2) \to (0,2) \to (2,0) \to (2,5) \to (3,4)$，共8步即可得到4L水。

这一过程就是典型的算法设计：通过抽象建模，将现实问题转化为可计算的状态空间，再通过规则搜索找到可行路径。算法设计能力的高低，核心体现在对问题的抽象能力、对规则的选择能力、对效率的优化能力上：同样是解决倒水问题，经验丰富的算法工程师会优先选择广度优先搜索（BFS）算法，确保找到的路径是最短路径，而不会选择盲目尝试的低效方法。

三大核心支柱并非独立存在，而是相互支撑、缺一不可的：没有问题分解能力，复杂问题无法落地；没有逻辑推理能力，分解后的子问题会出现逻辑错误；没有算法设计能力，无法将逻辑转化为可执行的步骤。三者的关系可以用如下图示表示： ```mermaid graph TD A[编程思维] --> B[问题分解能力<br/>Problem Decomposition Ability] A --> C[逻辑推理能力<br/>Logical Reasoning Ability] A --> D[算法设计能力<br/>Algorithm Design Ability] B --> B1[大问题拆解为子问题] B --> B2[子问题拆解为原子操作] C --> C1[逻辑确定性] C --> C2[逻辑完备性] C --> C3[逻辑一致性] D --> D1[规则抽象建模] D --> D2[路径搜索优化] B1 & B2 & C1 & C2 & C3 & D1 & D2 --> E[可执行的程序] ```

四、编程思维的价值与应用场景

4.1 数字化时代的通用核心能力

长期以来，编程思维被视为程序员群体的专属技能，但这一认知早已不符合当前数字化社会的发展需求。麦肯锡2024年发布的《全球数字化人才报告》显示：未来10年，全球超过50%的工作岗位需要从业者具备基础的编程思维能力，当前全球具备编程思维能力的从业者占比不足15%；我国工业和信息化部2023年发布的数据显示，当前我国数字化人才缺口超过2000万，其中非技术岗位（如运营、市场、财务、人力资源等）的数字化能力需求同比增长47%，增幅远超技术岗位。

编程思维的价值早已突破技术领域的边界：金融从业者用编程思维设计量化交易模型，提升交易效率；市场从业者用编程思维分析用户行为数据，优化营销策略；生物学家用编程思维处理基因测序数据