AI 贪吃蛇生成结果复盘：六份代码记录与交付细节（2026 年 5 月）

1. 实验记录：同一任务，六份输出

原记录称六次使用同一段中文提示词，并在 macOS（Apple Silicon）、Python 3.12 下通过 python snake.py 运行。本文保留了提示词和部分代码，没有附完整六份脚本、终端日志、采样设置或准确的后端模型 ID，因而不能独立复算全部运行结果和行数。

用 Python 写一个贪吃蛇游戏，要求：
- 使用 pygame 库
- 窗口大小 600x600，网格单元 20px
- 方向键控制移动，不能直接掉头
- 吃到食物后蛇身增长，分数 +10，显示在标题栏
- 撞墙或撞到自身时游戏结束，显示 Game Over 和最终分数
- 按 R 键重新开始
- 不要分文件，所有代码写在一个 py 文件里。

这条提示词其实有四层考点，比看上去苛刻：

• 指令遵循：600x600、20px、不分文件——能不能严格按约束写。
• 游戏开发常识：「不能直接掉头」可以用当前移动方向与待生效方向分离来检查，不能只看变量名。
• 外部依赖处理：pygame 不是标准库——模型会不会主动提示安装。
• 跨平台细节：分数显示、Game Over 文案，在 macOS 上会不会乱码。

2. 总览：一张表看完结果

记录日期为 2026-05-19，每个标签只展示一次输出。Claude Code 是工具名称，不能把“Claude Code 4.7”直接当成已核验的基础模型 ID；网页默认选择也不足以确定后端版本。表中标签仅用于识别原记录，不据此比较官方模型规格或总体能力。

3. Claude 记录：依赖步骤与方向缓冲

按原表，Claude 与 GPT 两份回答主动提供了依赖说明。下面保留 Claude 记录中的 macOS / Linux 虚拟环境命令；Windows 的激活命令不同，不能直接复制第二行。

python3 -m venv .venv
source .venv/bin/activate
pip install pygame
python snake.py

代码本身 139 行，模块化得很克制：random_food()、reset_game()、main() 三件套，没多余抽象。我最欣赏的细节是它把方向用 pending_direction 缓冲一帧：

if new_dir is not None:
    if (new_dir[0] + direction[0], new_dir[1] + direction[1]) != (0, 0):
        pending_direction = new_dir

若逐次把按键写入 direction，右行时先按上会把它改成上，再按左可能通过与“上”的反向检查，最终在同一移动步内变成反向。片段中的检查始终参照尚未改变的当前方向，把通过检查的值写入 pending_direction；完整循环还需在移动步统一应用它。

Game Over 用了一个 pygame.SRCALPHA 半透明蒙版盖在游戏画面上，蛇和食物保留可见，玩家能看到自己撞在哪里——这一点 MiniMax 没做，下面会讲。

4. GPT-5.5：颜值最高，函数粒度最细

原表记录 GPT-5.5 主动给出了 pip 安装提示。正文保留了它的配色和函数划分，视觉风格是我喜欢这份输出的主要原因。

原记录统计为 165 行，并列出 7 个函数：draw_grid、draw_cell、draw_snake、draw_game_over、is_opposite、random_food_position、reset_game。这些命名方便定位绘制与状态逻辑，但改尺寸或难度仍可能涉及多个函数。

视觉细节是这次评测的天花板：

BACKGROUND_COLOR = (18, 22, 28)
GRID_COLOR = (31, 37, 46)
SNAKE_HEAD_COLOR = (72, 211, 132)
SNAKE_BODY_COLOR = (50, 174, 109)
FOOD_COLOR = (238, 87, 87)
TEXT_COLOR = (240, 244, 248)

# 单元格收缩 2px 并加圆角
pygame.draw.rect(screen, color, rect.inflate(-2, -2), border_radius=4)

对比其他模型纯黑 + 正绿 + 正红的"配色三件套"，GPT-5.5 这套低饱和深色 + 薄荷绿 + 番茄红、加上 4px 圆角和单元格间隙，跑起来像 iOS 上下载下来的小游戏，完全是另一档视觉。

小遗憾：初始蛇身只有 1 节，长得稍慢。但提示词没规定初始长度，严格说不算扣分。

5. DeepSeek V4 Pro：国产里最干净的一份代码

原表记录 DeepSeek 为 123 行，GLM 为 116 行，且两者都记录为可运行，所以 DeepSeek 并非最短。行数只描述这次输出，不能当成质量排名。我更想讨论的是它把游戏状态集中放进一个字典：

state = {
    "snake": [(cx, cy), (cx - 1, cy), (cx - 2, cy)],
    "dir": pygame.K_RIGHT,
    "food": random_food([...]),
    "score": 0,
    "alive": True,
    "move_timer": 0,
}

这种偏函数式的写法在 pygame 教程里其实不常见，但很干净——重开游戏一行 state = reset() 就够，避免一堆全局变量。另外，下面的片段展示了累积经过时间再决定是否移动的写法：

dt = clock.tick(15)
state["move_timer"] += dt
if state["alive"] and state["move_timer"] >= 100:
    state["move_timer"] = 0
    # move one step

这段代码把渲染限在约 15 FPS，并累积 dt，达到 100ms 才移动；但它没有保证每 100ms 移动一次。约 66.7ms 一帧时，常要两帧才达到阈值，随后归零还会丢掉余量。它展示了按经过时间判断的思路，若要稳定步长，还需保留余量、处理追赶和暂停；不能据此称为生产级固定时间步实现。

扣分点是两个：第一，没主动提环境配置，pygame 没装的同学卡在 ModuleNotFoundError 就走了。第二，初始没 set_caption，窗口启动时标题栏显示默认的 "pygame window"，第一感官有点廉价。

6. Kimi 2.6：本地化意识有，但栽在字体上

Kimi 的片段主动使用了中文标题和 Game Over 文案；GLM 记录中也有中文文案，因此不是六份里唯一做中文界面的输出：

pygame.display.set_caption("贪吃蛇 - 分数: 0")
score_text = font.render(f"最终分数: {score}", True, WHITE)
restart_text = font.render("按 R 键重新开始", True, GRAY)

中文文案符合这次中文提示词的使用语境，但下面的字体名依赖目标系统实际安装的字体：

font = pygame.font.SysFont("simhei", 36)
game_over_font = pygame.font.SysFont("simhei", 48)

simhei 是字体家族名，不能假定每台 Windows 都有，也不能断言 macOS 或 Linux 无法安装。记录中的环境没有匹配到可用中文字形；pygame 的默认回退也不保证覆盖中文。应检查字体文件与实际文案的字形覆盖，而不是只按操作系统推断。

下面是作者补充的字体探测示意。未找到候选时明确报错，避免悄悄回退后继续显示缺字；找到字体后仍需用实际中文文案检查字形。交付时也可随程序提供授权允许分发的 CJK 字体文件：

def load_chinese_font(size):
    candidates = ["PingFang SC", "Heiti SC", "Microsoft YaHei",
                  "simhei", "WenQuanYi Zen Hei", "Arial Unicode MS"]
    for name in candidates:
        path = pygame.font.match_font(name)
        if path:
            return pygame.font.Font(path, size)
    raise RuntimeError("Install a CJK font or supply a licensed font file")

这里能确认的是中文文案和字体选择之间的交付缺口；本题没有测试 Kimi 的长文本阅读能力。

7. 智谱 GLM 5.1：意外补了 WASD，可惜也栽在字体

GLM 5.1 最让我意外的是主动支持了 WASD 键——提示词里只说了"方向键"，是它自己脑补出来的：

if event.key in (pygame.K_UP, pygame.K_w) and direction != (0, 1):
    next_dir = (0, -1)
elif event.key in (pygame.K_DOWN, pygame.K_s) and direction != (0, -1):
    next_dir = (0, 1)
elif event.key in (pygame.K_LEFT, pygame.K_a) and direction != (1, 0):
    next_dir = (-1, 0)
elif event.key in (pygame.K_RIGHT, pygame.K_d) and direction != (-1, 0):
    next_dir = (1, 0)

这种"自带想象力"的小动作很加分，是优秀模型的标志。视觉上 GLM 也加了 4px 圆角和单元格内缩，颜值不输 GPT-5.5。

GLM 使用的是 pygame.font.SysFont(None, 48)，并没有硬编码 simhei。原记录称中文结束文案出现缺字；它与 Kimi 的共同问题是未确保字形覆盖，具体字体选择路径不同。

还有个工程性小问题：GLM 5.1 没把游戏循环放进 main()，所有逻辑在模块顶层裸写、没有 if __name__ == "__main__": 入口。能跑，但工程感差一档，复用起来要先重构。

8. MiniMax 2.7：区分运行记录与设计意见

原表把 MiniMax 记为“未跑通”，行数记为 135，但没有保留错误栈或完整脚本。下面的片段只能支持具体设计意见，不能据此定位启动失败原因。Snake / Food 分类、像素坐标或未用方法本身都不会必然导致程序无法运行。

第一个低级错误：游戏结束时蛇和食物全部消失。

if game_over:
    # 显示 Game Over 文本
    ...
else:
    snake.draw()
    food.draw()

片段在 game_over 分支只绘制文字，不再调用蛇和食物的绘制方法。若此前清空背景，玩家会失去碰撞位置的视觉参照，这是我不喜欢的体验选择；提示词并未要求保留死亡画面，不能把它直接算作无法运行。

第二个问题：坐标系统用了像素而不是网格。

self.body = [(WIDTH // 2, HEIGHT // 2)]  # (300, 300) 像素
self.direction = (CELL_SIZE, 0)           # (20, 0) 像素

片段使用像素坐标并以 CELL_SIZE 为步长，这也是可行实现。换网格尺寸时要保持位置、碰撞边界和绘制一致，但并非使用像素坐标就不能扩展。原文还记录了未调用的 def grow(self): pass；它可以作为清理项，不能单独证明增长逻辑失效。

这篇文章不据一份输出评价 MiniMax 的全部编码或多模态能力。若要复核原来的失败记录，需要先补齐脚本、错误日志和运行环境。

9. 共性问题：原记录中 4/6 份缺少安装提示

把 6 份对比放一起，最显眼的共性问题就一条：除了 Claude 4.7 和 GPT-5.5，其余 4 家全部默认你已经把 pygame 装好了。

这件事对老手没影响，但对新手是"AI 写的代码跑不起来"最常见的根因。一段贪吃蛇代码生成出来，丢到一个新机器上，没装 pygame 就一句 ModuleNotFoundError: No module named 'pygame' 把人劝退了。

另一个可从片段对照的问题是中文字体覆盖：Kimi 请求 simhei，GLM 使用默认字体。两者都需要核对目标设备的中文字形，不能概括成“都硬编码 Windows 字体”或“非 Windows 一律乱码”。可选做法有：

• 规避：UI 文案全英文（Claude / GPT 选这条）。
• 探测：用 pygame.font.match_font() 把 PingFang / Heiti / YaHei / WenQuanYi 一起列入候选，按操作系统挑能用的。

这组记录更适合提醒开发者检查依赖、输入和字体这些交付细节，而不是据此推断所有国产或国际模型的能力差距。

10. 这次对照能支持哪些结论

• 可见代码：方向缓冲、状态字典、字体选择和 Game Over 绘制是可以逐段讨论的具体差异。
• 历史运行记录：表格保留原作者的运行判断和行数，但缺少完整脚本，不能当成可重复通过率。
• 未测项目：API 价格、吞吐、长文档、多模态和生产项目维护都没有在这道题中测量，因此不给性价比或总体能力排名。

下一轮若要比较稳定性，应固定模型 ID 和工具版本，保留完整输出与运行日志，并对每个配置重复同一组操作。一次贪吃蛇输出更适合做代码评审案例。

11. 把观察变成下一次验收动作

• 依赖：在干净虚拟环境安装 pygame，再运行脚本，记录完整报错。
• 输入：右行时快速按上、左，检查一次移动步内是否出现非法反向。
• 界面：检查首次标题分数、Game Over 文案和 R 重开；中文文案在目标设备上逐字确认。
• 计时：分别记录帧率和移动步长，不能只看代码中写了 100 就认定是 100ms。

可以用 Text Diff 对照生成稿和修订稿，再用 颜色对比度检查器 辅助检查配色。实际能否运行仍要在 Python 环境中验证。

常见问题