用Vim宏实现康威生命游戏：从录制到命令解释器

有段时间我特别喜欢在终端里折腾一些看起来没什么用、但做起来很上头的事。有一天盯着 Vim 的宏录制功能，我冒出一个念头：如果只用q录制、@回放这一套最基本的东西，不碰 vimscript，不装插件，能不能把康威生命游戏跑起来？这个想法被同事评价为“纯粹是闲的”。但真开始录之后，我发现它比想象中更能训练对编辑器的理解。

标题里的“手元”，按我自己的理解，就是一份亲手操作、边做边解说的记录。这里不会给你一大段直接复制就能跑的完整宏代码，因为完整版本往往很长，而且不同终端、不同棋盘尺寸都会影响具体按键。但我会把宏为什么能实现生命游戏、录制时最该注意什么、遇到问题怎么查，讲得尽量清楚。

先把观点放在前面：用 vim 宏实现生命游戏，本质上不是在一个文本编辑器里硬塞一个游戏引擎，而是把一组有限状态演化规则翻译成按键序列。难点从来不是规则本身，而是状态管理、边界处理和宏的终止条件。

1. 宏编程的本质：从“录操作”到“命令解释器”

1.1 宏不是自动按键机，而是可组合的命令流

很多人第一次接触宏，会把它理解成“批量重复按键”。这个理解不算错，但会低估它能做的事。宏录制机制的本质是：你把一串按键写入一个命名寄存器，之后随时可以按名字回放。qa表示把后续操作录制进寄存器a，再次按q结束；@a表示把寄存器a里保存的按键序列执行一遍。这里的关键不是“录”，而是“可组合”。宏里面可以继续调用另一个宏，可以包含查找命令，也可以包含替换命令。

如果愿意，你甚至可以让宏在执行到某个查找命令时因为找不到目标而自动中断。这就让宏具备了条件判断的雏形：找到就继续，找不到就停。再加上@a在宏内部自我调用，就构成了递归。于是你会发现，宏并不是只能做简单替换，它其实是一套运行在编辑器里的命令解释器。

我每次给别人演示宏的时候，都会用一个例子：在两个文件里分别有一批格式相似的行，手动改需要重复十几步。录一个宏，切到下一个文件，按一次@a，再往下一个文件去执行。整个过程不是“播放录像”，而是“调用函数”。一旦你把这个心智模型建立起来，宏就不再是抄近路的小技巧，而是一个正式的工具。

1.2 为什么宏能表达计算

为什么宏能做到这些？因为它的运行依赖三个要素。第一，缓冲区文本本身是存储，既有棋盘状态就写在文件里，不需要额外数据结构。第二，查找命令是判断，/xxx能定位到目标，搜索失败则中断；这个失败机制在宏里可以被当作一个隐含的条件分支。第三，寄存器是临时变量，宏内容存在寄存器里，不同寄存器之间的调用可以传递控制流。

我们通常说某个环境“图灵完备”，意思是只要给它足够的时间，它能表达任何可计算过程。宏编程在这个层面上很接近图灵完备：有存储、有判断、有循环。它不像 Python、C 那样容易读，但表达能力确实存在。理解这一点之后，再看生命游戏就会觉得顺理成章。

当然，这里说的“计算”不是指宏适合写算法题。宏里的循环没有明确的循环变量，判断也得靠命令是否失败来间接表达，所以它的表达能力很原始，阅读和维护成本很高。但这种原始恰恰能用来做思维训练：当你只能用最少的机制表达流程时，你会更清楚流程的哪一部分是真正的核心。

1.3 生命游戏为什么适合放进宏里

康威生命游戏的规则不需要重复太多：在一个二维网格里，每个格子只有活或死两种状态；对每一个格子，统计周围 8 个邻居中活细胞的数量；活细胞在邻居数为 2 或 3 时继续存活，否则死亡；死细胞在邻居数恰好为 3 时变为活细胞。这个规则看起来需要大量数值计算，但如果把网格写成一个字符矩阵，比如用O表示活，用.表示死，那么每一代演化本质上就是一次文本形态变换。

宏做得最好的事情，恰恰就是按固定规则反复处理文本。你只需要把“计算邻居数”和“决定下一代状态”这两步翻译成若干条 vim 命令，然后把这一轮命令录进宏里，剩下的事就是不断回放。这也是为什么这个实验虽然不能证明 vim 比编程语言强，却能证明宏的抽象能力被大多数人低估了。

另一个角度看，生命游戏之所以经典，是因为它用极其简单的局部规则涌现出复杂整体行为。宏录制也一样，单个按键动作毫无智能，但组合成宏之后，它能持续执行一个完整的演化策略。两者在概念上是同构的：小规则 + 重复迭代 = 复杂结果。

2. 最小可运行流程：先把循环跑起来，再谈规则

2.1 准备一个纯文本棋盘

先准备环境。打开 Linux 终端里的 vim 或 vi，新建一个文件，把棋盘用一个固定宽度的文本矩阵表示。字符选择建议统一：用.表示死细胞，O表示活细胞。不要混用空格和制表符，因为后面做替换命令时，分隔符越少越不容易出错。棋盘宽度先设小一点，比如 6 列、6 行，方便观察每一轮变化。

如果想严格兼容传统 vi，建议在录制时优先使用那些几十年来都稳定的基础键：0、$、j、k、h、l、:s、/、?、q、@、G。vim 里的一些扩展命令在传统 vi 环境里未必可用，所以对这个演示来说，用基础键更稳。

2.2 先录一个最简单的宏

在正式录生命游戏之前，先录一个最简宏，建立循环的手感。把光标放在第一行，依次按下面的键：

qa x j q

这段宏的意思是：开始录制到寄存器a，删除当前光标所在字符，光标移到下一行，结束录制。之后执行@a，就会删除当前行的一个字符；执行10@a，就会连续删除 10 个字符，前提是文件里有那么多内容。这个例子虽然简单，但它证明了宏回放不是机械地重放按键，而是每次都基于新的光标位置产生新结果。

常用操作可以整理成一张表：

更贴近状态变换的一个例子是：先手动把当前行里的某种字符替换成另一种字符。比如:s/O/x/g，然后j下移。确认这组操作符合预期后，再按qa把同样的操作录进去。这能避免录制时反复修改按键。不要小看这一步，很多宏出问题，不是因为规则复杂，而是因为录制者自己也没想清楚每一步会产生什么结果。

2.3 手动验证一遍，再开始录制

很多初学者一上来就想把完整的生命游戏规则录进宏，结果录到一半按错一个键，就得全部重来。我建议的顺序是：先在命令行模式下，手动执行一遍这一轮应该做的替换操作，确认输出结果和预期一致；然后把同样的操作录进宏。这里的核心原则是“先能手动跑通，再考虑自动化”。一条命令在单次执行时都不稳定，录进宏之后只会更不稳定。

录制宏时建议遵守这三个原则：

• 先手动执行，再录制。
• 每次只加一个小功能。
• 回放一次后立即检查缓冲区。

这样做看起来很慢，但实际最稳。生命游戏的宏问题不在录制本身，而在于你很难判断“是这一步替换错了，还是上一轮状态已经被污染了”。手动验证能帮你把问题隔离在更小的范围内。

2.4 生命游戏宏的骨架结构

把完整规则放进来，宏的骨架大致是这样的：

宏 a 的执行流程（示意）： 1. 定位到棋盘左上角 2. 对当前行执行一组状态变换替换命令 3. 移动到下一行 4. 如果还有下一行则继续，否则结束

其中第 2 步在完整实现里会被展开成很多细节：要同时考虑当前格子的旧状态、周围 8 个方向和邻居计数。这不是宏本身做不到，而是按键序列会变得非常长。实践里更常见的做法是把“每一步替换”从简单规则开始验证，再逐步叠加。先让棋盘上某一种局部模式能正确变化，再扩展到全盘。

3. 真正的坑：新旧状态、边界和光标位置

3.1 最优先解决“同时更新”

生命游戏有一个容易被新手忽视的性质：所有格子是同时更新。上一轮棋盘是快照，下一轮状态完全基于快照计算。如果在宏里一边扫描一边直接改原字符，改到后面的格子时，它周围的邻居可能已经被改成新一代了，结果自然是错的。所以，宏里必须安排一个快照区。常见做法是把当前棋盘复制到文件末尾，所有计算都以快照为准，完成后再用结果覆盖真正的棋盘区域。这一步看起来增加了很多命令，但没有它，整个宏就是不可靠的。

不要一上来就把100@a拉满。先用1@a观察一次，确认宏做了你预期的事，再逐步增加循环次数。

宏能不能自己停下来，是这个实验里另一个有趣的问题。最直接的方式是使用计数回放：100@a，让宏连续执行 100 次。但这要求你知道 100 次迭代大概够用，而且如果中间出错，很难定位。另一种方式是递归宏：在宏的最后放一个@a。这会让宏执行完一轮后再次调用自己。如果宏内部某条查找命令找不到目标，命令会报错，连锁反应会让宏停止。这个机制很有用，但也有风险：一旦终止条件没有被触发，宏就会一直执行下去，只能靠编辑器报错或手动中断。

3.2 边界细胞和棋盘扩展

棋盘边缘是第二个大坑。规则里每个格子都有 8 个邻居，但棋盘第一行的上面没有行，最后一列的右面没有列。如果直接按内部格子的方式处理边缘，替换命令会默认缺省的邻居不存在，也就是死亡。结果棋盘每迭代一轮，边缘都会出现预料之外的收缩。更麻烦的是，生命游戏里有名的滑翔机一旦移动到棋盘边缘，就可能消失。解决思路是先给棋盘外围垫一圈全 0 的“哨兵行和哨兵列”，宏只处理内部区域；这样边缘格子也能正常计算邻居数。

如果目标是观察滑翔机这类会持续移动的结构，就还要预留扩展空间。棋盘不能卡死，否则结构撞到边界就断了。预留多少取决于你想跑多少代，这里没有统一答案，只能在使用时提前想清楚。

3.3 光标位置决定宏能否重复

宏录制时记录的是按键，不记录当时的绝对文件位置。回放时，每个移动命令都会从当前光标位置开始重新解释。因此，一个宏要能重复使用，最好在宏开头先做一个明确的定位动作，把光标放到一个确定的起点。如果只在宏结束时不放回原位，第二次执行通常就会错位。一个常用的经验是：每次执行完一轮，把光标放回棋盘左上角，这样下一轮可以以同样的前提开始。如果目标是兼容传统 vi，定位时优先考虑0和G这类基础命令，而不是 vim 的gg扩展。不同环境下gg是否能使用并不一致，为了少踩坑，建议使用兼容性更广的写法。

单次执行正确，不代表宏能稳定复用。宏能重复的关键，是每次执行结束后都能回到一个确定的起点。

3.4 宏跑飞后的排查链路

宏跑飞的时候，先不要急着改规则。按下面的顺序排查：

1. 看现象：是完全没有变化、状态错乱，还是一直停不下来？
2. 看输入：棋盘字符是否统一，是否有隐藏空格或制表符，编码是否正常？
3. 看光标：宏录制的起点和结束位置在哪里，有没有来回跳行？
4. 看寄存器：用:reg a查看宏实际录了什么，里面是不是混进了移动、缩进、误按的键。
5. 看边界：第一行、最后一行、棋盘外的哨兵区域有没有被宏误操作。
6. 看兼容性：如果换到另一台机器的 vi 上跑，有没有依赖某个只在 vim 里存在的命令。

排查时最有效的方法是把10@a改成1@a，把连续播放改成单步执行。每执行一次宏，就观察一次缓冲区变化，很快就能定位到是哪一条命令出了问题。

4. 能带走什么：宏的边界与选择判断

4.1 宏本身也是一套迷你语言

跑完这个实验，最直接的收获不是掌握了某个冷门命令，而是重新理解了宏的表达能力。宏里可以出现自我调用，可以依靠查找失败退出，可以在不同寄存器之间互相调用。这意味着它并不是一个简单的按键匣子，而是一套受限制但完整的迷你语言。用过一次之后，日常写 vim 命令时会更关注命令是否“可重复执行”：这条移动命令是否会因光标位置不同产生不同结果，这条替换命令的作用范围是否被精确限定。这个意识对写脚本、写自动化流程同样有迁移价值。

可以把这个实验当成一个通用的三步法：先最小化、再扩展、最后清理。第一步，只处理一个单元格或一行单元格，确认状态变换正确；第二步，扩展到一个棋盘，加入邻居计数和边界处理；第三步，把快照区、临时标记、输出目录都清干净，让宏可以重复执行。这套方法不只适用于宏，也适用于任何自动化流程。

4.2 什么时候用宏，什么时候写脚本

那是不是以后能用宏解决的问题都用宏？不是。宏适合的是格式统一、逻辑简单、需要交互式观察效果的编辑任务。一旦任务需要大量参数、复杂分支、异常恢复，或者以后还要维护修改，脚本语言会是更稳的选择。可以按这个表格快速判断：

宏也常被用来做跨文件批量操作，但任务复杂度一旦上升，比如需要按日期判断、需要计算差值，宏就会很快变得难以维护。这不是宏能力不够，而是它的设计目的本来就不是面向大型程序。

4.3 这个演示适合谁，不适合谁

这个演示适合谁？适合对 vim 有基本了解、想进一步理解命令组合的开发者，也适合想给新人讲清楚“编辑器也能编程”的老师。它不适合谁？不适合想找一个生产级生命游戏实现的人，也不适合把 vim 当成 IDE 替代品、不打算深入命令模式的用户。另外，如果只是想在 Linux 服务器上快速做一个好玩的项目，用 Python 或 awk 肯定会更容易。宏实现生命游戏的价值不在效率，而在约束条件下思考问题的过程。

宏的价值不在“快”，而在把一次临时操作沉淀成可复用的命令组合。

长期来看，值得关注的是 vim/vi 在现代开发环境中的角色。宏编程不会让你变成更快的程序员，但它会改变你使用编辑器的方式：从“每次手动敲命令”变成“先构建一批可复用的命令组合”。这种思维对写 shell、写脚本、做自动化都有帮助。

最后回到标题里的“手元”。如果有一天你也在 Linux 终端里打开 vi，想起这篇文章，我建议你先别急着复刻一个完整的生命游戏。先录一个最简单的宏，让它删除一个字符、跳到下一行；再录一个宏，让它做一次状态替换。等这两步都顺手了，再往里面叠加相邻计数、边界哨兵、快照清理。你会发现，真正有收获的不是最后那张动态棋盘，而是你被迫去想的那些东西：状态不能互相污染，边缘需要特殊处理，光标位置必须稳定。这些东西在任何编程环境里都是同样重要的。