阿隆自留地

文章摘要

2026 年 1 月 13 日，Caleb Leak 被 Meta 裁员。两个月后，他发布了一篇技术文章，描述了他如何教会自己 9 磅重的贵宾犬 Momo 用 Claude Code 制作 Godot 游戏。

这个项目表面上看是互联网上的一个有趣实验——让狗狗按键盘触发 AI 写代码并获得零食奖励。但深入阅读之后，你会发现 Caleb 在这套系统背后投入了大量工程思考：Raspberry Pi 5 广播 UDP 击键信号，Rust 编写的键盘驱动过滤特殊按键，Zigbee 协议控制的 Aqara 智能宠物喂食器每次生成成功代码时自动弹出零食，Claude Code 充当 AI 代码引擎，Godot 4.6 作为游戏引擎（而不是 Bevy 或 Unity）——选择背后都有经过测试的理由。

文章中最重要的一句话不是"Momo 学会了打代码"，而是："AI 辅助开发中的瓶颈，不是创意质量，而是反馈循环的质量。" 这个洞见，结合他在 Godot 场景 linter、play-tester 工具、截图反馈器等工具上的工程投入，构成了这篇文章真正的技术价值。

背景与问题

2026 年初，"vibe coding"已经成为一个热词。Anthropic CEO Dario Amodei 在采访中表示，在可预见的未来，AI 会承担软件工程的大部分工作。OpenAI 的模型也在持续提升代码生成能力。市场上充斥着各种"AI 写代码太棒了"的成功案例，也有等量的"AI 写出来的代码一团糟"的抱怨。

两种声音的张力，指向了一个核心问题：AI 辅助开发的瓶颈在哪里？

Caleb 在博文中给出了一个非常尖锐的答案：不在 AI 的能力上，不在把问题描述清楚上，而在反馈回路的质量上。一个 AI 助手如果没有办法看到自己生成的代码在运行时是否正确，无法检测图形着色器是否渲染正常，无法知道 NPC 的 UID 是否重复——那么它只能在盲人摸象中反复猜测，即使模型能力再强，生成质量也会大打折扣。

这个结论并不是从理论推导出来的，而是来自 Caleb 亲自踩过的坑：他系统性地构建了五个独立的"感知工具"来帮助 Claude Code "看见"游戏运行和代码状态，这些工具直接解决了他遇到的具体问题（重复 UID 导致 Godot 崩溃、着色器引用错误导致无声报错等）。

为了说明这一点，他用了一个极端的比喻：如果一只被实验性训练的狗，在没有任何游戏设计能力的情况下，只要有足够好的反馈工具支撑，AI 就能生产出可以玩的游戏——那么这套反馈工具的价值，就不言而喻了。

核心内容解析

3.1 核心观点提取

整个系统由以下部分组成：

输入层：Momo 的"键盘"

Caleb 给 Momo 配备了一台罗技 Pebble Keys 2蓝牙键盘，以及一台 Raspberry Pi 5，运行一个 Rust 编写的应用 DogKeyboard。

DogKeyboard 的逻辑：

监听键盘所有按键输入
过滤掉"危险按键"（Tab、Ctrl、Backspace 等，防止意外退出 Claude Code 或删除代码）
将合法按键通过 UDP 广播发送给主机上的 DogKeyboard 接收端
接收端将 Momo 的按键注入正在运行的 Claude Code 实例

Momo 按下键盘触发模型输出后，Claude Code 会"收到"这些按键并开始写代码。

反馈层：零食激励

Aqara C1 Smart Pet Feeder 通过 Zigbee 协议连接，每次 Claude Code 成功完成一轮代码生成，自动旋转弹出一份零食（冻干三文鱼 → 训练后期降级为普通猫粮）。整个训练过程持续了两周，Momo 学会了"按键盘 → 等待 → 吃零食"的因果关系，尽管她并不理解中间发生了什么。

AI 层：Claude Code

Claude Code 使用了精心设计的 system prompt：扮演一位"用神秘谜语沟通的古怪电子游戏设计师"，并附带一份强制清单：生成的游戏必须包含音效、WASD 控制、至少一个敌人、可见的玩家角色。这份清单确保了 Momo"乱按"产生的指令不会导致 AI 生成一个空屏。

感知层：五个反馈工具

这是系统中最有技术含量的部分：

截图工具（Screenshot Tool）：Python 脚本，随时截取游戏运行时的当前画面，以 base64 编码传给 Claude Code，使模型能"看到"游戏现在的样子
play-tester 输入工具（Play-tester Input Tool）：模拟真实玩家的按键序列，让 Claude Code 可以在游戏运行时测试 WASD 控制是否正常
场景 linter（Scene Linter）：检测 .tscn 文件中的重复 UID 问题——Godot 场景文件有时会生成重复节点 ID，这会导致静默崩溃，而 linter 可以在问题发生之前发现它
着色器 linter（Shader Linter）：检测 .gdshader 文件中的错误引用，确保着色器资源可以被正确加载
输入动作映射器（Input Action Mapper）：验证游戏中的按键绑定（如 WASD → 移动）是否已经被正确定义，防止 Claude Code 写了一个永远读不到按键输入的游戏

3.2 技术深度分析

为什么选择 Godot 而不是 Bevy 或 Unity？

Caleb 在文章中明确描述了他的选型过程：最初尝试了 Bevy（一个 Rust 游戏框架），但发现 Claude 在 Bevy 坐标约定（如世界坐标系、物理坐标系）上频繁犯错，这与 Anthropic 训练数据中 Bevy 代码样本数量少有关。

Unity 有更丰富的训练数据，但 Caleb 尝试的 MCP（Model Context Protocol）bridge 不稳定，频繁断线。

Godot 4.6 胜出的核心原因：.tscn 文件是纯文本格式。相比 Unity 的二进制/混合格式，Godot 场景文件可以直接被 Claude Code read，直接 diff，直接 patch。这对 LLM 来说是一个巨大优势——它可以精确感知场景树结构，不需要通过 GUI 操作来理解层级关系。

Hacker News 上的一位用户 fabiancelotto_ 也印证了这一点：他实测 Godot .tscn 文本格式让 LLM 能直接读写，而其他引擎的场景文件对 LLM 几乎是黑盒。但他也发现了一个真实问题：Godot 场景文件有时会生成非唯一 UID（通常在合并来自不同版本的场景时），Claude 无法自动检测到这一点，必须依赖外部 linter。他的解决方案是在项目的 AGENTS.md（Claude Code 的指令文件）里加入如下命令：

# 针对重复 UID 的预防措施
find . -name "*.tscn" -exec grep -l "uid=" {} \; | xargs -I{} sh -c '
    uids=$(grep -o "uid=\"[^\"]*\"" {} | sort); 
    unique_uids=$(echo "$uids" | uniq); 
    if [ "$uids" != "$unique_uids" ]; then echo "Duplicate UID in {}"; fi
'

Memory.md 的双刃剑

Claude Code 允许在项目中维护一个 Memory.md 文件，AI 会将跨会话需要记住的信息写入其中。Caleb 发现这个机制有时会起到相反的效果：当 Momo 的一个游戏连续生成了几个 neon 赛博朋克风格的关卡之后，Claude Code 在 Memory.md 里记下了"用户偏好 neon 风格美术"，之后即使 Momo 的指令触发了完全不同的方向，Claude 也会不断生成 neon glitch 效果——造成了所谓的"审美锁定"。

解决方案：定期清空 Memory.md，通过 system prompt 而不是累积记忆来维持风格指引。这个发现对所有使用 Claude Code 进行长期项目的开发者来说都有参考价值：Memory.md 是有状态的上下文，而不是无害的便条纸，它会对后续生成产生主动影响，需要主动管理。

训练过程：两周的行为塑造

Momo 的训练本质上是经典的操作性条件反射（operant conditioning）：

第一周：按键盘立刻给冻干三文鱼，建立"键盘 = 好事"的关联
第二周：过渡到按键 → 等代码生成 → 才给零食，建立"等待"的耐受性
成功后：降级到普通猫粮，防止营养失衡（9 磅的狗吃太多冻干三文鱼会拉肚子）

值得注意的是，Momo 并没有"理解"代码生成。她的输入本质上是随机的——Caleb 称之为"高质量随机性注入器"（a high-quality random number generator with fur）。这个随机性，通过精心设计的 system prompt 被约束到了"产出可玩游戏"的边界内。

3.3 实践应用场景

Momo 的案例对真实 AI 辅助开发有如下可操作的借鉴：

为你的 AI 开发流程设计反馈工具，而不是只优化 prompt。 大多数开发者在使用 Claude Code 或 Cursor 时，把绝大部分精力放在"怎么把问题描述得更清楚"上。Caleb 的洞见是：prompt 质量有收益递减规律，但反馈工具的投入往往有更高的边际回报——截图比"告诉 AI 游戏看起来怎样"要有效 10 倍，linter 比"让 AI 自我审查"要可靠 10 倍。

使用 AI 友好的文件格式选择工具链。 如果你有工具选项的自由，优先选择用纯文本表达状态的系统：.tscn 而不是 Unity 二进制格式，Markdown 配置而不是 XML，JSON schema 而不是 GUI 配置。LLM 能直接理解和操作的格式，是 AI 辅助开发效率的基础设施级别的决定。

主动管理 Claude Code 的 Memory.md。 如果你发现 AI 开始"固执"——总是生成某种风格、某种架构、某种技术选择——不要只是在 prompt 里对抗它，而是检查 Memory.md，清空那些已经过时的"偏好记录"。

深度分析与思考

4.1 文章价值与意义

这篇文章最打动技术社区的，不是"狗狗会打代码"的噱头，而是它以一种极端形式演示了 AI 辅助开发的一个核心命题：系统的反馈机制，比使用系统的主体能力更决定系统的输出质量。

Momo 没有任何游戏设计知识，无法形成任何设计意图，她的键盘输入纯粹是随机噪声。但在足够好的反馈工具支撑下，这个随机噪声输入链路，产出了六个可以实际游玩的游戏，其中最复杂的《Quasar Saz》有六个关卡和一个 boss。这个结果的意义在于：反馈系统的工程质量，对 AI 辅助开发输出质量的贡献，可能超过了"人的创意能力"本身的贡献。

这个结论如果成立，对 AI 接替人类工作的讨论有深刻影响：不是人的创意和判断力变得不重要，而是"创意到实现之间的工程管道质量"变得越来越重要。构建高质量反馈工具的能力，将成为 AI 时代软件工程师的核心竞争力之一。

Hacker News 上有评论精准地总结了这一点："魔法不在于输入的质量，而在于围绕输入建立的系统。"（The magic isn't in the input, it's in the system around it.）

4.2 对读者的实际应用价值

如果你是游戏开发者： Godot 4.6 + Claude Code 的组合，在 2026 年已经是一个经过实测的可行流程。.tscn 文本格式带来的 LLM 可读性优势，是对 Unity 的 AI 辅助开发体验的有意义的差异化。scene linter 和 shader linter 的逻辑可以用几十行 Python 或 Bash 实现，值得作为任何 Godot + AI 工作流的标准配件。

如果你是工具开发者： Caleb 构建的五个反馈工具展示了一类新的"AI 原生工具"设计模式——不是为人类提供可视化界面，而是为 LLM 提供结构化、可解析的关于系统状态的信息流。截图→base64→Claude 这个管道，可以被应用到任何有视觉输出的系统（UI 测试、游戏 QA、数据可视化验证）。

如果你在研究 AI 辅助开发流程： Memory.md 的"审美锁定"问题是一个值得系统研究的现象。它背后的机制是 LLM 对上下文的偏好强化：越早出现在 context window 里的信息越难被后续输入覆盖。这个现象在所有有持久化上下文的 AI 助手中都存在，不只是 Claude Code。

4.3 可能的实践场景

AI 辅助游戏 jam（Game Jam）。 有了类似 Caleb 这样的反馈工具套件，一个熟练的开发者可以在 48 小时 game jam 期间生成并迭代 5-10 个原型想法，而不只是做出一个。工具链建立之后，AI 的迭代速度远超手写代码，约束条件变成了"有多少清晰的设计意图"而不是"有多少时间写代码"。

狗狗游戏的下一步。 Caleb 提到 Momo 的最新游戏《Quasar Saz》已有六个关卡和 boss，并且即将"公开发布"。这引发了一个有趣的问题：如果一只狗设计的游戏发布在 Steam 上，什么样的信息披露是合适的？"由 AI 生成"在法律和伦理上已经越来越清晰，但"由非人类生物触发的随机输入驱动 AI 生成"是一个尚未有先例的新类别。

模拟退火视角下的游戏设计。 Hacker News 上有一个颇为有趣的比喻：Momo 的随机输入，相当于给游戏设计空间中的模拟退火（simulated annealing）过程注入热量——防止优化过程陷入局部最优，同时在每次大跳跃之后，Claude Code 的反馈工具扮演了"冷却"的角色，将跳跃约束到可玩状态。这个视角提供了一种理解随机性在创意工具链中价值的新语言。

4.4 个人观点与思考

Caleb 被 Meta 裁员后做 Momo 项目这件事本身，构成了一个关于 AI 时代工程师身份的隐喻。

一方面，他是一位 Meta 研究工程师，代表的是 AI 正在取代的那类高薪知识工作；另一方面，他用自己的 AI 技能和工程直觉，构建了一个 9 磅重的随机输入器加上五个精密反馈工具的系统，生成了一批真实可玩的游戏——这个过程本身是一种新的工程创造，不是"被 AI 取代的工作"，而是"围绕 AI 构建系统的工作"。

这两件事发生在同一个人身上，时间线只差了几个月，恰好说明了这个时代转变的剧烈程度：从"AI 可能威胁工程师工作"到"工程师必须重新定义自己在 AI 流水线中的位置"，中间没有太长的缓冲期。

Momo 按下键盘的那一刻，也许象征着某种边界的消融：在一个好的工具链面前，谁按下了键并不重要，重要的是你是否能把"按下键之后"的事情工程化得足够好。

技术栈/工具清单

硬件层：

Raspberry Pi 5：UDP 按键广播主控
罗技 Pebble Keys 2（K380s）：蓝牙键盘，Momo 使用的物理输入设备
Aqara C1 Smart Pet Feeder：Zigbee 协议智能宠物喂食器，训练奖励硬件
Zigbee 协调器（USB dongle）：连接 Aqara 设备与 Raspberry Pi

软件层：

DogKeyboard（Rust）：过滤特殊键、UDP 广播击键到主机
Claude Code（Anthropic）：AI 代码生成引擎
Godot 4.6（C# 脚本）：游戏引擎，.tscn 文本格式
Python：截图工具（Screenshot Tool）实现
Memory.md：Claude Code 跨会话状态管理文件

自制反馈工具：

Screenshot Tool：游戏截图→base64→Claude Code 视觉反馈
Play-tester Input Tool：模拟 WASD 按键序列验证控制逻辑
Scene Linter：Godot .tscn 重复 UID 检测
Shader Linter：.gdshader 资源引用错误检测
Input Action Mapper：Godot 输入动作绑定验证

Momo 生产的游戏（截至文章发布）： DJ Smirk / Munch / Zaaz / Oracle Frog of Rome / Octogroove / Ewe Heard Me! / Quasar Saz（6 关卡 + boss）