贪吃蛇AI省内存：两行代码的1600倍陷阱

400个元素存2比特信息？这种浪费在神经网络训练里能忍吗？

一位开发者在优化贪吃蛇AI时，发现方向编码这个看似 trivial 的细节，竟成了内存优化的最大瓶颈。从1600字节到250字节，差距藏在两行代码里。

1600倍的内存黑洞

先回顾背景。这位开发者之前用二元平面编码（Binary Plane Encoding）表示贪吃蛇状态：三个通道分别标记蛇头、蛇身、苹果位置。这个方案把游戏分数翻倍，但留了尾巴。

第四个通道是方向。蛇的当前朝向用uint8编码：0=上，1=右，2=下，3=左。为了匹配矩阵形状，这个单值被铺满了整个20×20的平面。

算笔账：400个格子，每个存一个0-3的整数，实际信息只有2比特。通道级别的开销是1600倍。

更糟的是连锁反应。另外三个通道都是二值的，本可以按位打包（1比特/元素）。但方向通道的2比特打破了这一切——整个状态被迫保持uint8格式，无法压缩。

最终代价：每个状态1600字节（20×20×4通道×1字节）。理论下限是250字节（20×20×5通道×1比特÷8）。一个通道的2比特，卡住了整个优化链条。

直觉方案的翻车现场

四个方向，两个比特，够用了吧？开发者的第一直觉很几何：用两个二值通道，一个表示南北分量，一个表示东西分量。

北：南=0，东=0
南：南=1，东=0
东：南=0，东=1
西：南=0，东=0

发现问题没？北和西都映射到(0,0)。碰撞了。

这个失败很隐蔽。四个方向对应四种比特组合，数学上没毛病。但"有没有南北分量"和"有没有东西分量"这两个问题，对正交移动来说是错的。

正交移动严格一维。垂直移动时，水平分量恒为零。但"不是东"和"不是西"在单比特里是同一个值。0无法区分"静止的水平状态"和"两种相反方向"。

两个比特确实能编码四个状态。只是这两个比特选错了。

换个问法：轴+符号

正确的编码同样用两个比特，但问题变了：

轴比特：走哪个轴？（0=垂直，1=水平）
符号比特：朝哪个方向？（0=负，1=正）

北：轴=0，符号=0 → 00
南：轴=0，符号=1 → 01
西：轴=1，符号=0 → 10
东：轴=1，符号=1 → 11

四个方向，唯一编码，无歧义。"哪个轴"和"哪一端"这两个问题，对正交移动永远有且只有一个答案。

符号约定（北是正还是负）无所谓，CNN会学会你的映射。关键是问题本身要匹配数据的结构。

开发者顺便提了一嘴：如果是8方向游戏，轴+符号方案能扩展到3比特（2轴比特+1符号比特），或者直接用3比特做one-hot。但正交移动的贪吃蛇，2比特够了——只要问对问题。

为什么这件事值得动手试试

这个案例的有趣之处不在技术深度，而在优化层级的错位。开发者最初在算法层发力（二元平面编码），却漏掉了表示层的低效。1600倍的浪费藏在最不起眼的地方：一个常数的存储方式。

更典型的是调试过程。直觉方案"看起来对"，数学验证也过关，却在边界情况（正交移动的零分量）上翻车。这种错误在神经网络输入工程里极其常见——特征工程的bug往往不崩溃，只是让模型学得慢一点、差一点。

最后，这个优化有明确的行动门槛：检查你的状态表示，有没有"铺满平面"的标量？有没有本可二值化却被迫用整数的通道？内存瓶颈有时不在模型大小，而在数据管道的细节。

如果你也在做强化学习的游戏AI，现在可以打开代码看看了。