我花了 4.44 美元，让最强的代码模型徒手写了个鲁布·戈德堡机械，结果竟然……

最近关于 AI 编程助手的讨论热度一直居高不下，尤其是各家模型在长上下文和复杂逻辑处理上的能力。我也一直想找个机会，不搞那种常规的“增删改查”Demo，而是来点稍微“变态”的测试，看看现在的所谓“最强代码模型”到底成色如何。

鲁布·戈德堡机械测试运行画面

Claude 5 生成的鲁布·戈德堡机械运行效果，前半段物理模拟较为流畅。

于是，我决定向 Claude Fable 5 发起挑战：在一个没有任何物理引擎库支持的单一 HTML 文件中，徒手用 Canvas 和原生 JavaScript 实现一个鲁布·戈德堡机械（Rube Goldberg Machine）。

这可不是简单的动画播放，而是要求模型自己模拟重力、碰撞、动量传递等物理逻辑，并让 10 个步骤自动连锁触发。为了测试公平，我采用了最严苛的 One-shot 模式：一次性投喂 Prompt，中途不追问，不改代码，直接看最终产出。

我设计的 Prompt 要求非常细致，目标是在前端构建一个包含 10 个步骤的连锁反应装置：

除此之外，还要求具备 Play/Pause/Restart 的 UI 控制，60FPS 流畅动画，以及现代扁平化的视觉风格。这基本上是让 AI 在没有“上帝”（物理引擎）的帮助下，自己创造一个物理世界。

等待的过程是漫长的，模型经过约 21 分钟的“思考”和生成，最终吐出了一份代码。让我们先看下这次生成的账单：

光看数据，模型的输出量相当惊人，生成了一段非常长的代码逻辑。那么，运行效果如何呢？

测试数据概览

本次挑战共耗时 21 分钟，消耗 Token 成本约为 4.44 美元。

如果满分是 10 分，我愿意给这次尝试打 6 分。这 6 分主要送给前 5 步。

在前半段，模型的表现确实超出了我的预期。小球滚落的加速感、骨牌倒下的传递逻辑，甚至锤子挥动的动画帧率，都处理得相当丝滑。在没有引入 Matter.js 等物理库的情况下，模型能凭空写出这么流畅的刚体碰撞模拟，确实展现了强大的编码直觉。

然而，翻车发生在第 6 步之后。

就像我们在很多复杂项目中遇到的那样，逻辑链条越长，崩塌的概率就越大：

第 6 步断裂：当第二个小球落在跷跷板上时，并没有触发预期的跷跷板倾斜运动，小球像是被胶水粘住了一样。这很可能是模型在处理力矩平衡计算时出现了逻辑断层。
第 7 步玄学：虽然跷跷板没动，但后续被发射的物体却“凭空”出现了。这说明模型“记住了”剧情，但却跳过了物理触发逻辑，直接写死了结局。
第 8 步死循环：因为物体没有真正运动去触碰按钮，后续的火箭发射和烟花庆祝自然也就成了泡影。

整个连锁反应在中途戛然而止，相当于花了 4.44 美元看了一半的烟花秀。

这次实验虽然不算完美，但暴露出的问题非常有代表性，对于想用 AI 做复杂开发的我们来说，有不少避坑经验：

隐性知识难以显性化：物理模拟涉及大量微积分和向量计算，模型虽然“看过”很多代码，但在没有物理引擎辅助的情况下，很难精确复现复杂的物理约束（比如摩擦力、弹性系数的微小差异）。
长上下文记忆的“注意力涣散”：从第 1 步到第 10 步，逻辑跨度很大。模型在处理后半部分时，似乎“忘记”了前半部分定义的物理规则，转而采用了更简单粗暴的硬编码方式。
调试能力的缺失：人类程序员写这段代码，肯定需要不断地运行、调整参数（比如重力加速度、碰撞阈值）。但 One-shot 生成切断了“反馈-修正”的闭环，导致第一版的代码往往只能在简单场景下生效。

如果你也想尝试类似的复杂 Web 项目开发，不要指望一次性生成完美代码。我建议尝试以下“组合拳”：

引入成熟的库：除非是为了验证模型算法能力，否则在实际开发中，请明确要求模型使用 Matter.js 或 Planck.js 等专业 2D 物理引擎。这能让模型专注于逻辑设计，而不是重造车轮。
模块化 Prompt：不要把所有步骤写在一个 Prompt 里。先让模型写好“球体运动”模块，测试通过后，再让它写“骨牌碰撞”模块，最后进行组装。人类做工程讲究分治，AI 也一样需要。
人工干预不可少：当生成几百行代码后，人工介入关键逻辑的 Debug（比如那个跷跷板的力矩计算），效率远高于让模型重猜。

虽然这次 Claude Fable 5 没能跑完全程，但它在一个没有外部依赖的单文件中，徒手写出了前半段流畅的物理动画，依然让我感到惊艳。

失败本身也是一种能力验证。 它证明了目前的大模型在处理高度耦合的长逻辑链时，依然存在天花板。但也提醒我们，在使用 AI 辅助开发时，合理的架构设计和人类专家的把舵，依然是不可或缺的。

下次如果我要再测，可能会把价格打得更高一点——毕竟，看着 AI 瞎琢磨的过程，也是一种别样的乐趣嘛。