AI 基础
什么是计算思维?
计算思维是一种对问题和解决方案进行表述的方式,使信息处理步骤可以由个人、计算机或系统网络系统化地执行。它包括抽象和算法设计,也包括决定应当如何表示以及如何测试所提出的解决方案。
计算思维的范围比编程更广。代码可以实现解决方案,但更困难的工作往往在更早阶段出现:定义目标、分解问题、选择相关细节以及识别自动化不合适的情形。
要点概览
- 在优化过程之前先明确问题。
- 分解将复杂系统拆分为相互作用的部分;抽象隐藏在所选层次上不相关的细节。
- 算法需要输入、输出、假设、停止条件和测试。
- 计算思维并不能消除社会判断、模糊价值或责任归属。

明确问题与目标
确定受影响的人群、要支持的决策、可用信息以及错误的后果。将模糊的需求转化为可观察的结果,避免把易于衡量的代理指标误当作真实目标。
在机器学习中,预测点击次数虽然技术上便利,却可能并不代表满意度。计算思维首先要对这种表述进行测试,而不是直接选择算法。
分解系统与依赖关系
将问题拆分为可以单独推理的组件:数据收集、验证、转换、决策逻辑、用户交互和监控。记录它们之间的接口和反馈,以免局部改进损害整体系统。
分解并非碎片化。团队必须重新组合各部分并进行端到端测试,包括时序、缺失输入以及上游或下游服务的故障。
抽象与表征
抽象保留与问题相关的细节并抑制其他信息。图可以表征连接,表格可以表征记录,概率分布可以表征不确定性。相同的现实情境可能需要针对不同决策采用不同的表征方式。
所有表征都会遗漏某些信息。务必记录单位、类别、时间窗口以及缺失情况。结构化与非结构化数据的区别会影响可表达的内容以及哪些转换可能丢失上下文。
设计算法并谨慎自动化
算法是具有输入、步骤和输出的明确定义的过程。需考虑正确性、终止性、复杂度、内存、失效行为以及结果是确定性的还是概率性的。先使用示例和边界情况再进行概括。
自动化应包括验证以及对不支持输入的安全响应。一个运行快速却编码错误目标的过程并不是改进。人工审查可以成为算法系统的一部分,而不是证明其失败的证据。
测试、迭代与概括
单元测试检查组件;集成测试检查接口;场景测试检验端到端行为。比较预期结果与实际结果,追溯错误至假设,并在证据与预期冲突时重新表述问题。
概括即询问该方法是否能够超出用于设计的示例进行迁移。声明有效范围。涉及权利、价值或争议目标的问题需要除计算之外的参与式判断与治理。
计算思维的核心实践
计算思维将问题框定为人或机器能够执行的解法。分解把复杂目标拆解为可管理的部分;模式识别发现重复结构;抽象保留任务相关信息;算法设计规定步骤和条件。表征同样重要:表格、图、状态、坐标和数据类型使某些操作简便而另一些困难。其目的在于严谨的问题求解,而非单纯学习写代码。
良好的分解会定义各部分之间的接口和所有权。抽象应隐藏偶然细节但不隐藏实现正确性所需的约束。算法需要输入、输出、前置条件、不变式、终止条件以及错误行为。伪代码、流程图、决策表和示例都有助于实现前的思考。效率考虑时间、内存、通信、能耗和人工成本,但优化应在正确的基线之后进行。某些问题在规模上是不可判定或计算上不可行的,这使得近似和权衡成为必需。
测试、调试与数据推理
测试从需求中导出用例:正常、边界、空、格式错误、重复、极端和对抗性。调试形成假设、观察状态、定位原因并验证修复而不引入回归。可复现性记录输入、版本和环境。面对数据问题时,要询问观察是如何抽样、测量、标注、缺失以及转换的。算法即使执行完美,也可能因表征或数据生成假设无效而得出错误结论。
自动化会改变过程及其激励。要明确谁提供输入、谁受输出影响、存在哪些例外以及上诉或纠正机制如何运作。隐私、可访问性、安全性和公平性应在问题定义阶段就考虑,而非事后补救。确定性规范适用于精确规则;当模式必须从数据中估计且错误可评估时,机器学习更为合适。选择不自动化有时也是正确的计算决策。
教学与实践技能
学习者应使用实体步骤、伪代码、电子表格和代码解决同一问题,以观察表征如何改变推理。项目应要求解释与测试,而不仅仅是产生可运行的输出。在组织内部,计算思维提升需求撰写、工作流设计、数据分析以及与工程师的协作。其持久价值在于使假设显式化、构建可复现的过程,并识别出不确定性或人工判断阻止问题简化为单一算法的情形。
案例演示:设计校车路线算法
学生将任务分解为站点、乘客、容量、时间窗口、行程时间、无障碍需求和安全约束。他们将道路网络表征为图,创建一个简单的贪心路线,并在已知解的小案例上进行测试。边界测试包括无乘客、不可达站点、车辆故障以及需要无障碍校车的乘客。只有在正确性和约束可见后,才会比较效率。
随后课堂讨论权衡:最短距离可能导致单个乘客行程过长或服务不均。他们加入公平性和弹性指标,记录假设,并允许规划者基于理由进行覆盖。个人地址受到保护,示例数据为合成数据。该练习表明抽象使计算成为可能,同时决定了哪些人类需求会体现在模型中。计算思维包括认识到干净的优化目标可能遗漏重要价值或例外情况。
实施证据与运营准备
生产决策需要的不仅是成功演示。必须定义预期用户、运行环境、输入、输出、依赖、所有者以及每项关键故障的后果。建立可复现的基线和版本化的评估集后再进行调优。测试常规案例、边界条件、格式错误或缺失输入、分布漂移、依赖中断、误用以及最可能被忽视的群体或环境。测量任务质量时同时关注校准或不确定性、延迟、吞吐量、资源成本、可访问性、隐私和安全性。记录每一次转换和阈值,以便独立审查者能够复现结果并区分证据与吸引人的原型。
上线前,指定发布、例外、变更、回滚和退役的责任人。采用分阶段发布,保留安全回退,并通过有意注入的故障验证监控。运营遥测应揭示输入质量、输出行为、模型或规则版本、依赖健康状况、人为覆盖以及已确认的结果,同时避免收集不必要的敏感数据。设定警报阈值并指派响应负责人,随后在部署后审查真实世界证据,而不是假设离线性能会持续。每当数据源、用户、模型、供应商、政策、硬件或目标变化时,都应重新评估。维护中的系统还需有文档化的恢复、事件学习、删除与保留流程,以及明确的停用或替换时点。
常见问题
计算思维与编码是同一回事吗?
不是。编码是在编程语言中表达指令;计算思维则包括问题表述、表征、算法设计、测试与评估。
所有问题都能用计算方法解决吗?
不是。某些问题是不可判定或不可行的,许多人类问题具有模糊的目标或价值冲突,计算本身无法单独解决。












