人工智能通识课：数据处理的程序化思维

大语言模型能够生成代码，为什么还需要学习编程？因为代码生成之前，需要明确处理对象、规则和结果，并考虑计算方法与资源限制。程序化思维，就是把想法转化为可执行、可验证的处理方案。

图 1：大模型时代为什么仍要学习编程

学习 Python，既是学习表达数据与操作的方法，也是为了理解执行过程、调整代码并核验结果。将需求描述、代码实现和运行验证联系起来，才能更有效地借助大语言模型完成任务。

一、大模型时代的编程价值

1.1 从重复劳动到自动处理

比如，某学院收到 200 份 Word 个人信息登记表，包含姓名、性别、出生年月、民族和籍贯，需要把这些信息整理到一个 Excel 文件中。

人工处理时，必须反复打开文件、定位字段、读取内容、复制和粘贴。文件越多，越容易漏掉一份材料，或把姓名写入性别列。

将处理规则写成程序（Program）后，就可以把同样的操作应用于多份文件。

图 2：人工重复整理与程序辅助处理

自动处理的价值不仅在于速度，还在于规则一致、过程可重复、结果可追溯。不过，同一规则也可能带来同样的错误：如果字段位置判断有误，整批结果都会受到影响。

因此，应先验证单份文件的处理方法，再扩大处理范围。字段缺失、格式变化和重复材料，都应纳入处理规则。

程序化思维（Programmatic Thinking）是把任务表达为明确数据、规则和处理步骤的思考方式。判断是否值得借助程序，可以观察四个特征：

（1）重复性：相同或相似的操作需要多次执行。

（2）规则性：处理步骤和判断条件能够明确说明。

（3）数据化：对象可以表示为文本、数值、表格、图像或文件。

（4）可验证性：能够用样例、规则或参考结果核对输出。

登记表汇总具有重复操作、规则明确、材料数字化和结果可核对等特点。但这些特征只是判断依据，并非严格的必要条件：一次性计算也可能值得编程，重复任务也需要明确规则。

选择方法时，应先检查现有工具能否满足需求，再综合考虑处理成本和出错影响，决定是否编写专门程序。

1.2 从模糊愿望到明确需求

1.2.1 需求描述的四个要素

“帮我汇总登记表”说明了愿望，却没有完整说明程序应该怎样执行。明确的需求至少包括四个要素：

（1）输入数据：材料在哪里，接受哪些文件格式。

（2）数据结构：每份材料有哪些字段，字段怎样组织。

（3）处理规则：提取什么，如何处理缺失、重复和格式差异。

（4）输出结果：保存哪些列，怎样记录来源与待核查事项。

四个特征回答“是否适合程序化处理”，四个要素回答“如何把需求说清楚”，两者用途不同。

1.2.2 任务说明与样例约束

结构化提示词（Structured Prompt）可以看作一份简化的任务说明书：分别说明输入、数据结构、处理规则和输出，并补充运行环境、代码注释及文件保护要求。例如：

“使用 Python 汇总测试文件夹中的 .docx 登记表。字段包括姓名、性别、出生年月、民族和籍贯；字段位置以我提供的虚构样表为准。跳过 Word 临时文件，不修改原件；缺少必需字段的文件写入待核查清单，不补造内容。汇总表保留来源文件名。先说明处理步骤，再生成带关键注释的代码，并给出运行依赖和测试方法。”

样表应展示必要结构，并附正常与异常材料的预期输出。

比如，日期只有年份而没有月份时，是保留原文还是标为待核查，应先约定，不能让程序猜出一个月份。

明确表达有助于减少歧义，但不能保证生成的代码正确。所选工具也应支持实际文件格式，例如 .doc 与 .docx 的文件结构不同，不能未经确认就采用相同的读取方式。

1.2.3 把例外写入处理步骤

伪代码（Pseudocode）用接近自然语言的形式表达程序逻辑，不依赖某一种编程语言。例如：

核对数量与字段内容

“对每一份”表示重复处理，“如果”表示条件判断，读取、写入和保存体现执行顺序。把异常情况写入步骤，才能避免遗漏或错误处理。

1.3 从代码生成到结果验收

1.3.1 人机协作的基本流程

大语言模型（Large Language Model，LLM）可以协助生成代码、解释语句和提出修改方案；使用者则需要明确目标、数据约定和验收要求。编程（Programming）将这些要求落实为程序，人机协作可以按照以下流程展开：

需求描述 → 代码生成 → 代码阅读 → 运行核验 → 反馈修订

图 3：需求、程序与验证的协作流程

模型提供的是候选实现。使用者需要核对代码中的字段位置、判断条件和输出方式，并将发现的问题反馈给模型，修订后重新核验。

1.3.2 数量核对与内容核对

验收标准（Acceptance Criteria）把“完成”转为具体条件。

登记表汇总至少需要两类核对：

•数量核对：清单中的文件是否全部有处理记录，成功数与待核查数是否合计等于待处理数。

•内容核对：汇总中的姓名、性别和日期是否与来源材料对应，字段有没有错位，格式处理是否符合约定。

比如，三份测试材料中两份完整、一份缺少必需的籍贯字段，预期应得到两条汇总记录和一条待核查记录。即使每份材料都有处理记录，若程序自行补造了缺失内容，结果仍不合格。

临时文件、非目标格式和重复材料应先按约定筛选，单独记录排除理由。只有明确统计口径，数量核对才有意义。

1.3.3 编程学习的三个目标

大模型时代的编程基础，可以围绕三个相互支持的目标建立：

•想清楚：明确对象、规则、例外和正确结果。

•看得懂：沿着关键代码解释数据变化、执行路径与修改位置。

•用得好：选择工具、设计测试、反馈问题并检查修订。

二、自然语言的知识表达

把需求说明白之后，还需要理解一个差异：人用语言传达意图，程序按规则执行操作。大模型连接两种表达方式，却不会自动消除它们之间的距离。

2.1 符号与自然语言

符号（Symbol）通过约定表示事物、概念和关系。文字、数字、地图符号、乐谱和化学式，都依靠相应规则传达含义，使信息得以记录，知识得以积累和传播。

自然语言（Natural Language）借助语境和共同知识交流经验、表达意图，具有以下特点：

•模糊性：边界不明确。“很多”“大约”“高温”没有固定数值。

•歧义性：存在不同解释。“他背着妈妈去看病”可能是背负，也可能是瞒着。

•情境依赖性：含义依赖场景。“这道菜不错”可能是一般赞美，也可能是一次正式评分。

这些特点并非语言缺陷，但用于自动执行时需要补充规则。

“统一出生年月”必须明确目标格式、缺失月份的处理方式和是否保留原文；“找出高分学生”必须明确科目、阈值及是否包含边界。

2.2 形式化与精确表达

形式化语言（Formal Language）使用明确的符号和规则。数学中的 S = πr² 表达圆面积关系；编程语言（Programming Language）中的符号则按其执行规则解释。例如，Python 的 x = 5 是赋值（Assignment），将名称 x 绑定到整数对象 5，而不是数学等式。

形式化使结构和解释更加明确，但“精确”不等于“正确”。

“至少 60 分”包含 60，若代码写成“大于 60 分”，机器仍会精确执行错误条件。数学公式也不因形式严谨就自动成为可直接运行的程序。

大模型可以将自然语言中的目标和约束转换为代码中的数据对象、条件及处理流程。对于未说明的细节，它可能采用常见写法，也可能作出不符合任务需要的假设，因此仍需检查转换结果。

图 4：自然语言、明确规则与程序表达

例如，“按成绩从高到低排列”还需要说明按哪一科或总分排序、并列怎样处理、缺失成绩是否参与。模型可以生成多个语法正确的版本，只有符合约定的版本才适用。

自然语言输入并未取消执行规则，使用者仍需核实需求被转换成了哪些数据、条件和操作。

三、编程语言的计算表达

明确表达之后，需要进一步追问：规则能否形成求解方法，方法是否可以执行，结果如何得到验证。计算思维把这些问题连接起来。

3.1 可计算性与计算边界

3.1.1 机械计算与图灵机

可计算性（Computability）研究问题是否存在机械化求解方法。这里的“机械化”指按明确规则执行，不依赖临时的直觉判断；对规定范围内的有效输入，应能在有限步骤内得到所要求的结果。

图灵机（Turing Machine）用纸带、读写头和有限状态转移规则刻画这样的计算过程。纸带提供可按需扩展的符号存储，读写头读取或改写当前符号，再依规则移动。

比如，规则是“读到 0 就改为 1 并右移，读到 1 就改为 0 并右移，读到空白就停止”。对纸带上的 0110 逐格执行，得到 1001。每一步都有明确依据，不需要猜测。

邱奇—图灵论题（Church–Turing Thesis）将直观的有效计算与图灵机等形式模型联系起来，它是论题，而非已证明的定理。图灵机采用可按需扩展的纸带，实际计算机的存储则有限。

3.1.2 可计算、可行与现实执行

停机问题（Halting Problem）询问程序在指定输入上是否最终停止。可以分析许多具体程序，但不存在一个总能停止、又能正确判断任意程序与输入的通用判定程序。

这说明一般性的自动判断存在边界，但不妨碍通过阅读、测试和推理核验具体程序。

还应区分三种情况：

•尚未解决：例如哥德巴赫猜想（Goldbach’s Conjecture）。有限范围的检验不能替代对整个命题的证明，也不能因为尚未证明，就将相关求解问题判为不可计算。

•资源不足：某些任务有算法，但所需时间或内存超出现实条件。

•涉及物理动作：比如烹制汉堡，程序可以计算控制指令，真正操作还需要感知与执行设备。

数据能够编码、任务能够描述，都不等于已经找到可执行的求解算法。

3.2 计算思维：抽象与自动化

3.2.1 从现实问题到计算模型

计算思维（Computational Thinking）关注怎样表述问题和组织方案，使求解过程能够有效执行。周以真（Jeannette M. Wing）在 2006 年发表的论述推动了这一概念的广泛传播。抽象与自动化是理解程序化处理的两个重要方面。

•抽象（Abstraction）保留与目标有关的特征，建立合适的对象和关系。

•自动化（Automation）把明确的求解过程交给机器执行。

登记表汇总时，字体颜色通常可以忽略，字段位置与含义不能忽略。每份表可以抽象为“字段与值”的集合，再分为读取、检查、写入和核对几个步骤。

完整路径可以写为：现实问题 → 建立模型 → 设计算法 → 实现程序 → 运行验证。建模不一定需要复杂数学，关键是明确保留哪些对象、关系与约束。

3.2.2 七桥问题：保留关键关系

哥尼斯堡七桥问题（Seven Bridges of Königsberg）询问：能否沿一条路线，恰好经过每座桥一次？

欧拉（Leonhard Euler）通过研究陆地与桥的连接关系分析这一问题。用现代图论语言表达，可以把四块陆地表示为顶点（Vertex），把七座桥表示为边（Edge）。陆地面积、桥梁长度和地图画法都不影响结论，关键在于哪些陆地由桥相连。

图 5：七桥问题的抽象过程

顶点的度数（Degree）是与它关联的边数。七桥图四个顶点的度数为 3、3、3、5，全部为奇数。

对于所有非孤立顶点相互连通的无向图（Undirected Graph），存在恰好经过每条边一次并回到起点的路线，当且仅当所有顶点度数为偶数；存在起点与终点不同的此类路线，当且仅当恰有两个奇度顶点。七桥图有四个奇度顶点，因此两种路线都不存在。

这个例子说明，通过抽象保留陆地与桥的连接关系，可以从图的结构判断是否存在符合要求的路线。

3.2.3 积分近似：重复计算的自动化

求定积分时，可以利用原函数得到精确值，也可以通过有限次计算得到近似值。两种方法的依据和处理步骤不同。

（1）利用原函数精确求值

对于区间上的连续函数 f(x)，若 F′(x) = f(x)，牛顿—莱布尼茨公式（Newton–Leibniz Formula）给出：

例如，x² 的一个原函数是 x³/3，因此：

这里得到的是精确值，不需要用矩形面积近似。

（2）利用矩形面积之和近似求值

如果原函数难以用便于计算的形式表示，或只能获得离散采样数据，就可以考虑数值积分（Numerical Integration）。仍以 x² 在区间 [0,1] 上的积分为例：

（1）把区间等分为 n 段，每段宽度为 1/n。

（2）取各段右端点的函数值作为矩形高度。

（3）将 n 个矩形的面积相加，得到近似值。

图 6：矩形求和与积分近似

矩形面积之和称为黎曼和（Riemann Sum）。本例中，当 n 趋于无穷时，黎曼和趋近于黎曼积分（Riemann Integral）的值；有限次求和则给出近似值。

当 n = 4 时，右端点法得到 0.46875；当 n = 1000 时，得到 0.3338335。对于本例的等分右端点法，近似值始终大于精确值 1/3，误差随 n 增大而减小。

程序可以自动完成取点、计算和累加；使用者仍需确定区间、方法和分段数，并核查误差。

3.3 算法与程序

3.3.1 算法的基本要求

算法（Algorithm）是对某类问题求解步骤的明确描述。

常见基本要求包括有限性（Finiteness）、确定性（Definiteness）和可执行性（Effectiveness），以及明确的输入（Input）与输出（Output）：输入可以为零个或多个，输出应体现求解结果。

比如，求 48 与 18 的最大公约数（Greatest Common Divisor，GCD），可以采用欧几里得算法（Euclidean Algorithm），也称“辗转相除法”：48 除以 18 余 12，18 除以 12 余 6，12 除以 6 余 0，结果是 6。每一步都有明确规则，余数逐步减小，过程最终停止。

算法独立于具体编程语言。

同一方法可以采用 Python 或其他语言实现；同一任务也可以使用不同算法。求 1 到 100 的和可以逐项累加，也可以用公式计算，两者都得到 5050，操作次数却不同。

3.3.2 猴子吃桃：迭代与递归

猴子在前九天每天早上吃掉现有桃子的一半，再多吃一个，第十天早上吃桃前剩下一个。第一天早上有多少个桃子？

若吃桃后剩下 m 个，吃桃前就有 2 × (m + 1) 个。根据这一递推关系（Recurrence Relation），可以采用两种计算方式。

（1）迭代：从已知数量逐步反推

迭代（Iteration）从第十天的一个开始，反复计算前一天的数量：

• 第九天：2 × (1 + 1) = 4。

• 第八天：2 × (4 + 1) = 10。

继续更新，依次得到 22、46、94、190、382、766、1534。

迭代的要点是明确初始值、更新规则和次数。本例共更新九次，得到第一天的数量。

（2）递归：将问题转化为同类子问题

递归（Recursion）通过求解同类子问题完成当前计算。设 a(i) 为第 i 天早上吃桃前的数量，则：

求 a(1) 需要先求 a(2)，依次求到 a(10) = 1；再返回计算 a(9) = 4、a(8) = 10，最终得到 a(1) = 1534。

递归的要点是明确递归关系和终止条件，使调用逐步接近已知结果，再逐层返回计算。本例以第十天的一个桃子为终止条件。

两种方法使用相同的关系：迭代连续更新当前数量，递归通过同类调用与返回组织计算。

3.3.3 数据组织与控制结构

数据结构（Data Structure）规定数据怎样组织和访问，算法规定怎样处理。

比如，登记表的字段名称与字段值需要建立对应关系，输出列还需要保持规定顺序。

“算法 + 数据结构 = 程序”概括了程序设计的两个重要方面。

程序还涉及运行环境、输入输出与异常处理；某些持续运行的软件也不以整体终止为目的，不能把所有程序都等同于一个有限求解算法。

顺序结构（Sequence）、选择结构（Selection）和循环结构（Iteration）是程序设计的三种基本控制结构。

登记表处理中，读取和写入按顺序执行，字段是否完整决定处理路径，文件清单组织重复处理。沿这些步骤追踪数据，有助于核对代码是否符合需求。

参考阅读：

四、编程方式的演变

从任务到模型，再到算法与程序，人始终需要把意图落实为执行规则。编程方式的演变减少了表达这些规则的负担，大模型是在这条演变路径上增加的协作工具。

4.1 从机器语言到高级语言

4.1.1 表达层次的提升

机器语言（Machine Language）使用处理器能够执行的指令编码。

汇编语言（Assembly Language）用助记符表示指令，仍依赖具体架构。

高级语言（High-level Language）提供更接近问题表达的数据类型、控制结构与函数。

高级语言通过编译器（Compiler）或解释器（Interpreter）等工具运行，使人不必逐条书写机器指令。使用机器语言编写，也不保证比高级语言生成的机器代码更高效；实际效率取决于算法、实现和运行条件。

4.1.2 程序组织方式

编程范式（Programming Paradigm）关注怎样组织程序。

面向过程（Procedural Programming）围绕步骤和函数，面向对象（Object-Oriented Programming）把相关数据与操作组织到对象中，函数式编程（Functional Programming）强调函数组合并减少不必要的状态变化。

登记表汇总可以先按“读取—检查—汇总—保存”组织函数，也可以借助文档、表格和记录对象完成操作。这些方式可以配合使用，不是相互替代的历史阶段。

参考阅读：

4.2 大模型辅助编程与 Python

自然语言辅助编程（Natural Language-Assisted Programming）在需求与代码之间增加了转换层：使用者描述目标，模型生成候选实现，再通过阅读、运行和反馈逐步修订。模型也可以协助测试，但测试范围和结果仍需核查；再次解释代码，不能替代独立验证。

Python 语法相对简洁，便于从代码中辨认字段、条件判断、循环和函数调用。其标准库和第三方库提供了文档、表格、图像、统计及机器学习等处理工具，使学习者可以更多地关注任务本身和处理规则。

学习基础语法的目的，是沿着程序解释它如何执行，指出需求变化时应改哪里，再用样例核实修改。无需先背熟全部库函数；应逐步具备独立理解关键代码和查阅文档的能力。

小结

程序化思维从明确需求开始，通过抽象、算法与数据结构组织处理步骤。大语言模型可以辅助生成代码，学习者仍需理解执行过程、计算边界和资源限制，并通过运行与核验，判断程序是否符合需求。

“点赞有美意，赞赏是鼓励”