第 1 章　编程是什么

1.1先给计算机「下命令」：指令与程序

想象你雇了一个从零开始、什么常识都没有的机器人厨师。你想让它做一份煎蛋。你会怎么跟它说？

如果你只说一句「给我做个煎蛋」，机器人会原地发呆——因为它不知道「煎蛋」意味着什么，更不知道该从哪一步做起。你必须一步一步拆开讲：

1. 从冰箱拿出一个鸡蛋。
2. 把平底锅放到灶台上。
3. 打开火，调到中火。
4. 往锅里倒一点油。
5. 把鸡蛋在碗边磕开，倒进锅里。
6. 等 2 分钟，翻面。
7. 再等 1 分钟，盛出来。

这每一句「做某件具体的事」，在编程里就对应一条 指令（instruction）。而把这一串指令按顺序组织起来，就构成了一个 程序（program）。

把清单写下来：伪代码

上面这份煎蛋清单，已经非常接近编程里一个重要的过渡工具——伪代码（pseudocode）。伪代码就是「用人话写的程序」：它比日常语言精确（每一步都明确到可以照做），又比真正的代码宽松（不抠语法符号、不管标点缩进）。初学阶段，伪代码是组织思路最顺手的工具——先把步骤想清楚，再考虑怎么写代码。本教材从第 4 章开始写真正的代码，但从这一章起就会大量使用伪代码：它帮助你把注意力放在「做事的顺序」上，而不是被符号规则绊住脚。

写伪代码时有一个关键的判断动作：每一条指令，都必须落在执行者的基本动作清单之内。机器人厨师的基本动作，是工程师预先替它装配好的技能——取物、移动、倒、磕、翻、加热；计算机的基本动作则朴素得多，只有区区几类：存取数据、算术与逻辑运算、比较、跳转。任何复杂任务，最终都要拆解到这几类基本动作的组合上去。你以后写的每一行代码，无论看起来多「高级」，落到硬件上都是这四类基本动作的排列组合——这是全课程最重要的一条因果链，请从今天起就记住它。

这套「拆成清单」的思路，在工程界早就存在，而且用得极其严肃。飞机装配现场的工艺卡（装配指令单）会把一道工序拆成数十个步骤，每一步写明用哪种工具、拧到多少扭矩、检查结果如何留痕；机务维护使用的工卡（检查单）同样逐项列出动作与判据。为什么工程文件要写得这么「啰嗦」？因为执行的人和复核的人可能不是同一个人，执行的时间可能隔了几个星期甚至几年——只有精确到无歧义的指令，才能保证不同的人在不同时间执行出同一个结果。这与程序的要求一模一样：程序之所以可靠，正是因为它把「怎么做」写死到不留任何发挥空间。可以说，工程背景的学习者学习编程，不需要转换思维方式，只需要把「写工艺卡」的严谨程度，平移到「写代码」上来。

diameters = [10.02, 9.98, 10.07, 10.00, 9.94,
             10.05, 10.01, 9.99, 10.03, 9.96]
ok = 0
for d in diameters:          # 逐件检查（第 2~4 步的循环）
    if 9.95 <= d <= 10.05:   # 闭区间判定（第 3 步）
        ok += 1              # 合格计数 +1
print(ok, len(diameters) - ok)

顺带辨析一个微妙的差别：指令与请求。你对同事说「把温度调高一点」，这是请求——同事会结合经验自行决定调多少；你对机器写「温度 = 85」，这是指令——机器不会变通，也不需要变通。日常语言里我们习惯了请求式表达，所以初学者常把「请求」直接写进程序，然后被机器拒绝。写程序请养成一个自查习惯：每写一行，问自己一句——「如果执行者完全没有常识，这句话还能被执行吗？」能，就留下；不能，就拆细。

伪代码还有一层常被低估的价值：它是算法的「通用语」。工程团队讨论方案时，用伪代码把思路钉在白板上，不同语言背景的工程师都能看懂、都能挑毛病；方案评审时先审伪代码（思路对不对），再审代码（写得规不规范）。本章例题 1 的清单就是活例子：哪怕完全不懂 Python 语法，你也能对照清单读懂那段程序在做什么——因为它的骨架是「清单」，不是「语法」。以后每学一个新概念，先问自己「用伪代码怎么写」，你会发现自己始终在学「思路」，而不是在背「符号」。

所以，编程的第一层真相其实非常简单：

1.2程序 = 一串精确的指令序列

上一节说程序是「指令的集合」，但光「集合」还不够。一个能跑的程序，它的指令必须满足三个硬条件。缺一个，计算机就会卡住或出错。

条件一：精确，不能含糊

跟人说话，我们可以含糊：「多放点盐」「差不多熟了就出锅」。人靠经验和舌头能猜出你的意思。但计算机不行——它不知道「多」是多少，「差不多」是什么标准。

在程序里，你得写：「加 3 克盐」「当锅里的蛋边缘变白且中心不再流动时翻面」。每个量、每个条件都要精确到计算机能直接判断。

「含糊」的根源，值得多想一层：自然语言的量词没有固定参照系。「多放点盐」里的「点」，取决于你上一次放的量、这锅菜的咸淡、说话人的口味——每听一次，参照系都会漂移。而程序语言里，一切量都有字面值（如 3）或变量（如 salt，指向一个确定的数值）作为唯一参照。写 salt = 3 的那一刻，「盐量」这个概念就被钉死成一个数，任何人、任何时刻读到这一行，理解都完全一致。所谓精确，就是给每个概念锁定一个不可漂移的参照。

还要注意：精确的粒度要恰到好处。「加 3 克盐」对煎蛋是精确的，写成「加 3.0027 克盐」就过了——精度只需满足任务需要。工程上这叫「与需求匹配的精度」：图纸标注公差 ±0.05 mm，就按 ±0.05 mm 检验，不必搬出纳米级仪器较真。精确 ≠ 冗长；把精确用在该用的地方，是写程序（也是写工程文件）的基本功。

条件二：无歧义，一句话只能有一个意思

「把那个箱子搬到那边」——「那个」是哪个？「那边」是哪边？这句话有无数种理解方式，就叫有歧义。程序语言被设计成每个符号、每个词都有且只有一个含义，就是为了彻底消灭歧义。你写 1 + 1，它只能是「一加一」，不可能是别的。

自然语言的歧义比比皆是。经典例子：「咬死了猎人的狗」——是狗被咬死了，还是狗把猎人咬死了？两种解读都成立，人靠语感选一种，机器却没有语感可用。自然语言是几千年自然演化的产物，歧义是它的固有属性，永远清不干净；而程序语言是一种人造的形式语言（formal language）：先定一张有限的符号表，再定一套严格的文法（grammar），规定什么样的组合合法、每个合法组合是什么意思。规则有限、封闭，所以每个合法程序有且仅有一种解读。你在第 2 章会看到，这套文法是靠「翻译程序」强制执行的——不合法的句子根本进不了门。

无歧义的收益有代价：你必须迁就文法的死板——全角半角、缩进、括号配对，差一个字符都不行。初学者常抱怨这些规则烦人，但换个角度想：正因为规则死板，你写的程序在千里之外的另一台机器上，才会被一模一样地理解。死板不是缺陷，死板是承诺。

条件三：有序，顺序不能乱

煎蛋必须先「倒油」再「打蛋」，反了就会粘锅。程序也一样：指令是按先后顺序执行的，先写先执行，后写后执行。这个「从上到下」的顺序，是程序最基本、最核心的执行规则。

顺序的严格性，不是谁规定的「编程礼仪」，而是硬件执行方式决定的。预告 1.3 节的结论：CPU 里有一个专门的寄存器，时刻记着「下一条指令在哪」，它只会自动指向「再下一条」——「从上到下逐条执行」是 CPU 的物理本能。同一个指令集合，换一种排列顺序，执行结果可能完全不同：先「倒油」再「打蛋」是煎蛋，先「打蛋」再「倒油」，油还没热、蛋液已经流了一灶台。三个条件里，「有序」离硬件最近，也最没有商量余地。

把这三条标准放到工程现场检验，你会发现它有个工程界的「孪生兄弟」。适航与工艺管理中有条通行原则：可复现——一份合格的工艺文件，任何一名合格工人、在任何一班、按文件执行都应得到同样结果。「按需拧紧」显然不满足可复现；「用定扭矩扳手拧至 25±2 N·m 并做标记留痕」才满足。「可复现」与程序三条件（精确、无歧义、有序）本质上是同一件事的两套说法——一套对人，一套对机器。这也解释了为什么工程师群体转型编程往往上手很快：严谨度是现成的，缺的只是一门「翻译」语言。

最后辨析一个容易走偏的误区：精确不等于事无巨细。有人为了「精确」，把每条指令塞满限定词，结果清单没人读得下去——对人如此，对机器同样糟糕：指令越多，出错的面就越大。正确的做法是精确到任务需要的粒度，然后停手。检验零件只要两位小数，就别写三位；控制目标到 1 ℃ 就够，就别控制到 0.1 ℃。程序与工艺文件的共同美学是：每句话都必要，且每句话都无歧义。

本节的三个条件还可以压成一句口诀：锁定量、锁解读、锁次序。锁定量，让每个概念有唯一参照（精确）；锁解读，让每句话只有一个含义（无歧义）；锁次序，让执行路径唯一（有序）。以后每写完一段程序，都可用这三把锁自查一遍——三把锁都锁上了，机器才肯接活；哪把锁没锁上，报错或者错跑就等在哪把锁后面。

1.3计算机如何「执行」程序

程序写好了，计算机到底是怎么「照着做」的？要回答这个，得回到「计算机软硬件」那门课讲过的 CPU。这里我们把关键机制快速串起来，建立「程序 ↔ 硬件」之间的因果链。

你写的程序（比如 3 + 5），最终会被翻译成一串机器指令——就是一堆 0 和 1 组成的编码。CPU 拿到这串指令后，会陷入一个永不停歇的循环：

1. 取指（Fetch）：从内存里「读」出下一条指令。
2. 译码（Decode）：看懂这条指令是什么意思——它让 CPU 做什么。
3. 执行（Execute）：真正去做这件事，比如把两个数加起来。
4. 写回（Write-back）：把结果存回内存或寄存器。

做完这四步，CPU 又回到第一步去取「下一条」指令……如此循环几十亿次，直到程序结束。这就是著名的 取指-译码-执行循环（fetch-decode-execute cycle），也叫指令周期。

幕后主角：程序计数器与时钟

这个循环为什么能「自己转起来」而不跑偏？靠一个幕后主角：程序计数器（Program Counter，PC）。它是 CPU 里一个专门的小寄存器，内容始终只有一句话：「下一条指令存放在内存的地址 X」。取指那一步，CPU 就是按 PC 里的地址去内存把指令搬回来；一条指令执行完，PC 自动加上一个固定长度，指向紧挨着的下一条——除非碰到跳转指令，把 PC 直接改写成一个全新地址。你以后写循环、写条件分支，落到硬件上全是「改写 PC」这一个动作。所以，「程序从上到下顺序执行」不是一条抽象规定，而是 PC 不断加一的物理过程的直接结果——1.2 节条件三的谜底在这里。

循环的「节奏」由谁打拍子？答案是时钟（clock）。CPU 内部有一个以固定频率振荡的电路，像节拍器一样发出一连串「嗒、嗒、嗒」，每一下节拍，电路各部分统一前进一步：该取指的取指、该运算的运算、该写回的写回。我们说某处理器「主频 3 GHz」，意思是它每秒打 30 亿拍。主频越高，四步循环转得越快。日常工作中你不需要关心节拍如何产生——抽象又一次把细节藏好了；但做时间关键的计算时（见下面的工程视角），「数拍子」就是硬功夫了。

freq = 3e9            # 时钟：每秒 30 亿拍
cpi  = 4              # 每条指令平均 4 拍
ips  = freq / cpi     # 每秒指令数
print(ips)                    # 750000000.0 -> 7.5 亿条/秒
print(100 * cpi / freq * 1e9) # 133.33... -> 100 条约需 133 纳秒
print(int(0.1 * ips))         # 75000000  -> 眨眼间 7500 万条

「数指令周期」听起来像老古董，但在今天的安全关键工程里仍是硬技能。飞机上的舵面控制计算机、发动机控制器、液压系统的调节单元，这类设备必须在确定的时间内完成计算并输出结果——晚一拍，控制作用就失效。工程师要能回答「最坏情况下这段控制程序要跑多少拍」，这就要逐段分析指令数、逐拍核对。你现在算的「每秒 7.5 亿条」，就是这门功夫的第一步。同时你也该意识到一个朴素的事实：程序能跑起来，从来不是理所当然——它是 CPU 以纳秒级节拍、机械循环几十亿次的结果。这份「机械的可靠」，正是机载设备敢把生命攸关的任务托付给计算机的底气。

辨析两个容易混淆的「循环」：CPU 的指令周期循环是硬件固有的物理行为，通电就转、永不停止，不依赖任何程序；程序里的循环语句（第 8 章正式学）是写在代码里、靠跳转指令实现的「回到上面某一行再执行一次」。前者是转的机器，后者是机器转的内容。打个比方：唱片机一直在匀速旋转（硬件循环），而唱片上录的副歌重复了三遍（程序循环）——一个是播放器的本能，一个是音频内容的编排。两者层次不同，缺一不可。

最后补上一块关键拼图：指令本身也住在内存里。你大概默认「程序」是硬盘上的一个文件，跟「数据」是两类东西；但在内存的视角下，指令和数据毫无二致——都是一串 0/1，按地址排成一列长队。取指这一步，本质就是按程序计数器里的地址，去这排格子里「取货」。CPU 之所以不会把一张照片错当成指令去执行，是因为它只按 PC 指的地址依次取——程序与数据在存储上不分家，区分靠的是「谁在读、什么时候读、按什么方式解读」。这个「程序当数据存」的设计思想叫「存储程序」原理，是现代计算机的基石，软硬件课程会专门展开；这里你只需记住：所谓「执行程序」，就是 CPU 在内存这排格子里，按地址一格一格向前——取一件、读懂它、照做、再前进一格。你往手机里装一个 App，发生的事情不过是一段指令序列被拷贝进存储器，等着 CPU 按地址逐条取用；软件之所以能被复制、安装、分发，正因为它的本体就是一串可拷贝的数据。

1.4人机「对话」的本质：零容错与语境

很多人第一次写代码会崩溃：明明看起来「没问题」，机器却报错。要理解这种挫败感，得先理解人和计算机「对话」方式的根本不同。

人和人交流，靠的是三样东西：语境（我们之前在聊什么）、常识（世界是怎么运转的）、容错（你说错一个词我也能猜出意思）。这三样，计算机一样都没有。

计算机和你的「对话」，是一种极端不对等的关系：

这就是为什么新手会觉得计算机「不讲理」：你不是在跟一个「聪明但偶尔装傻」的人对话，你是在跟一台极其诚实、极其死板、绝不脑补的机器对话。它不会猜你「本来的意思」，它只执行你写出来的意思。

报错是善意，照做才危险

「零容错」听起来冷酷，但请对它公平一点：报错其实是善意的拦截。计算机拒绝你的代码，通常分三类情形，严重程度依次递增——语法错误：你写的不是合法句子，在翻译阶段就被拦下，程序根本没开始跑（漏个引号、错个函数名都算这类）；运行时错误：句子合法、跑起来了，但执行途中摔倒（比如除以零、找不到文件）；逻辑错误：全程无报错、顺利跑完，但结果不符合你的意图。前两类机器会「叫」出来，第三类机器毫无察觉——它对你的意图一无所知，它只核对「写出来的意思」。

所以真正的危险从来不是「报错多」，而是「不报错但错了」。这也解释了工程软件为什么要在测试验证上投入巨大：机载软件的验证与确认体系，本质上就是系统性地围剿第三类错误——用成千上万条测试用例去逼近「程序做的，就是你想要它做的」。初学阶段请建立这样的心态：满屏报错不必沮丧，那是机器在告诉你「问题找到了，位置在这」；最难缠的敌人，是安安静静的错。

有人会问：如今的人工智能助手不是能「猜」我的意思吗？这里要做一个重要的辨析：AI 的「猜」，是程序用概率模型算出来的推测，它的底层依然是精确的数学运算与一条条指令的执行；猜中了你觉得贴心，猜偏了你需要纠正——所谓「智能」，是建立在零容错的机械执行之上的高层能力。地基越机械，楼层才越敢往上盖。先学编程打地基，再谈各种智能应用盖楼，顺序不能反。

1.5编程、程序与算法的关系

还有两个词经常和「编程」混在一起：算法（algorithm）和 代码（code）。把它们的关系理顺，你对「编程」的理解就完整了。

• 算法：解决问题的思路和步骤，是「怎么做」的方法，跟语言无关。比如「从 1 加到 100」的算法可以是「一个个加」，也可以是「(1+100)×50」。算法是脑子里的方案。
• 代码：用某种编程语言把算法写出来的具体文字。同一套算法，可以用 Python 写，也可以用别的语言写，文字不同，思路一样。
• 程序：最终能交给计算机运行的那份完整代码。

算法的三个硬性质：无歧义、有限步、可行

并不是随便一份「步骤清单」都有资格叫算法。一个合格的算法必须同时满足三个硬性质：无歧义——每一步在任意执行者眼里含义唯一（这继承了 1.2 节的标准）；有限步——整个流程必须在有限次操作后终止，「一直搅拌直到好喝」就不算算法，因为「好喝」可能永远等不来、流程可能永不收尾（那是「过程」，不是「算法」）；可行——每一步都必须落在执行者的基本动作清单里、在有限时间内可完成，「等天气转晴再起飞」对计算机不可行，因为「改变天气」不在它的基本动作清单上。算法，就是步骤的精确化：把「大概这么做」推进到「严格这么做」。

这三个性质合起来划出一条清晰的边界：菜谱、工艺卡、检查单都是步骤清单，但只有同时满足三条的才配称为算法；而程序，是把算法用编程语言落实成机器可执行的形态。这也决定了做事的正确顺序——先有合格算法，再谈写程序。算法错了，代码写得再漂亮，也只是在精确地执行一个错误。

total = 0
for i in range(1, 101):         # 算法 A：从 1 逐个加到 100
    total += i
print(total)                    # 5050

print((1 + 100) * 100 // 2)      # 算法 B：首尾配对，3 步出答案

这道「1 加到 100」绝不只是数学趣题，它是工程计算的普遍缩影。处理一批试验数据要逐行累加求和？那就是算法 A 的翻版——数据一万行，就要做近万次加法。有没有算法 B 式的捷径？常常有：等差数列求和有闭式公式，常用统计量有现成公式，数据分析库甚至把整批运算一次性交给底层高度优化的机器码去完成（第 10 章数据结构还会再遇到这个思想）。拿到问题先问一句「有没有更聪明的步骤」，再动手写代码——这个习惯的价值，会随你处理的数据规模变大而指数级放大。

最后辨析「算法」与「程序」的关系边界。算法是思想：语言无关、平台无关，写在纸上、讲给别人听都成立；程序是实现：受具体语言语法、受机器资源的约束。同一个配对算法，用 Python 写是一个样子，用其他语言写是另一个样子，但两者承载的是同一套思路。工程审查里常说「审算法」与「审代码」是两道独立的关口，原因正在于此：思想错了，改实现救不回来；实现错了，再好的思想也落不了地。两道关都要过，但顺序永远不变——先算法，后代码。

这一整套关系，可以用一句话收尾：

最后把本章开头的机器人厨师召回来说一句收尾的话：它按清单逐条执行，每一步都机械、每一步都可预测——而恰恰是这种可预测性，让工程师敢把关键工序交给它，也让你将来敢把自己写的小工具交给团队使用。编程建立的信任链条是：语句精确 → 指令可预测 → 结果可复现 → 责任可追溯。这条链条的第一环，就是本章反复念叨的「把话说死、说准」。下一章我们回答一个新的问题：既然机器只认 0 和 1，人类为它垫了哪些「台阶」，让我们不必直接跟 0/1 搏斗？