测试方法论与物理世界挑战
本次对比旨在突破传统屏幕基准测试的局限，将AI模型置于真实的物理世界中进行评估。视频制作者指出，现有的基准测试多集中于游戏表现，无法准确反映模型深层的智能水平。因此，本次实验涵盖了从视觉模拟到实体控制的多项任务。测试环境设定为：GPT-6 Astra与Claude Fable 5.1均运行在最高努力模式（Max Effort）下，且两者均采用每月200美元的订阅计划。由于拍摄周期跨越数天，使用配额虽受5小时窗口限制但未进行严格监控。测试任务包括：Hot Wheels轨道物理模拟、Apple Vision Pro FPS游戏移植、基于视觉的机械臂实体控制、ESP32设备代码优化，以及使用Blender和GDO进行的电影级游戏制作。
Hot Wheels轨道物理模拟：Astra的执行细节与结果
首个测试要求模型构建Hot Wheels十字交叉赛道的高保真3D物理模拟。提示词明确要求包含1998-1999年“Crisscross Crash Five-pack”五辆车的精确3D模型、特定轮组细节及真实物理参数。GPT-6 Astra在最高努力模式下展现了庞大的工作流：它首先通过网络搜索原始宣传册和参考图像，随后进行复杂的物理计算。模型执行了包括单圈、电机负载、碰撞和滚动阻力在内的21项物理检查。最终生成的模拟结果被评价为“非常不错的代表”，核心设计准确，但存在轨道支撑结构穿过赛道的图形瑕疵。交互功能方面，模型实现了直观的UI和展示模式，允许用户开启电机并调节功率。制作者评论道：“> That is a well done motherboard. [laughter]”，虽为玩笑，但暗示了对底层逻辑构建能力的认可。该测试不仅考察图形保真度，更验证了模型处理摩擦力、质量分布及多车互动等复杂物理引擎参数的能力。
任务复杂度与后续挑战预告
Hot Wheels测试揭示了AI在结合视觉参考、历史数据检索与物理引擎构建时的潜力与挑战。虽然Astra在图形和交互上表现良好，但制作者强调这仅是冰山一角。真正的智能体现在对物理世界的直接干预能力上。接下来的测试将涉及更复杂的跨平台移植（Apple Vision Pro FPS游戏）、基于实时视觉反馈的机械臂实体操作，以及在资源极度受限（ESP32芯片）的设备上进行代码优化。此外，还将测试模型在Blender和GDO引擎中制作复杂3D游戏的能力。这些任务旨在全面评估模型在代码生成、硬件控制及创意工程方面的综合表现，而不仅仅是屏幕上的文本或图像输出。
GPT-6 Astra的3D模型生成与展示能力
GPT-6 Astra在接收到关于Hot Wheels赛车及其轨道的指令后，首先生成了五个特定车辆的3D模型。虽然这些模型并非完全写实，但被评价为对原车的相对忠实再现。系统提供了展示厅模式（Showroom Mode），允许用户查看模型的细节，包括预设的转盘功能、车身分离以及线框视图（Wireframe）。这种基于科学和物理基础的生成方式，展示了模型的结构逻辑。例如，对于一辆带有塑料车顶的车辆，Astra较好地模拟了其材质特征；而对于基于现实存在的Porsche 959和Ford GT90，模型在颜色主题匹配上表现不错。特别是对于车轮等细节部分，Astra展现了一定的注意力分配能力，尽管并非所有部件都完美还原，但整体配色方案基本准确。此外，系统还进行了大量研究性工作，提供了车辆的质量估算等参考信息。
物理引擎与赛道模拟的准确性验证
在渲染环节，Astra提供了性能、高和超高等不同画质模式，并引入了物理引擎来模拟车辆在轨道上的运动。测试者通过观察车辆的运行轨迹和碰撞情况，验证了物理引擎的准确性。摩擦力的模拟是其中一个关键点：当车辆接触到轨道上的滑轮时，马达的声音效果随之产生，这符合真实物理反馈。测试者指出，车辆在轨道上的速度变化——包括加速、减速以及在弯道处的表现——与真实Hot Wheels赛车的行为高度一致。这种动态模拟不仅包括直线运动，还涵盖了车辆在特定路段获得的速度增益与衰减。此外，系统生成的跟随摄像机（Follow Cam）和追逐镜头被评价为超出预期的亮点，增强了视觉体验的真实感。
碰撞机制与细节物理反馈
在多人车辆同场竞技的测试中，Astra的物理引擎成功模拟了现实中的碰撞场景。由于每辆车的初始相位和速度存在细微差异，车辆最终会发生追尾或侧撞。碰撞的必然性被准确还原：即使初始状态不同，速度较快的车辆最终会追上并撞击前方的车辆。测试者特别注意到一个细节：当车辆在轨道上行驶时，马达的转速（RPM）会出现波动。系统生成的波形图清晰地显示了车辆经过特定轨道段时转速的下降（Dip in RPM），这反映了物理引擎对负载变化的精细模拟。这种基于真实观察的细微反馈，使得整个模拟过程不仅视觉上逼真，在物理逻辑上也经得起推敲。测试者认为，尽管存在少量图形瑕疵，但整体运动模拟达到了极高的准确度。
Claude Fable 5.1的初步表现与对比背景
作为对比，Claude Fable 5.1也在“最大努力模式”（Max Effort Mode）下运行了相同的任务。测试者展示了发送给Fable 5.1的原始参考照片，包括轨道齿轮和马达方向的细节。虽然片段主要聚焦于Astra的详细表现，但明确指出Fable 5.1的结果随后将被展示以进行对比。这一部分为后续的性能评估奠定了基础，强调了在相同输入条件下不同模型在处理复杂3D生成和物理模拟任务时的潜在差异。测试者通过展示参考图像，确保了评估的公平性和可追溯性。
物理模拟的深度与细节还原
在针对轨道赛车系统的生成对比中，Claude Fable 5.1 展现出了对物理引擎的极高专注度。它不仅涵盖了基础的弹簧阻尼和侧向保持力，还深入探讨了能量边界的重新校准。两者都深刻意识到这是一个复杂的物理模拟过程，因此在生成内容中详细提及了电池内阻在负载下的电压降、齿轮比的影响以及多车同场竞技时的速度衰减效应。这种对底层物理逻辑的推演，使得生成的模拟结果在理论层面具备了较高的可信度。
"Both of them did definitely take to heart that this needs to be a physics simulation as well."
在具体的参数设置上，模型展示了墙摩擦力和车身摩擦力等关键数值。双方都投入了大量精力确保物理参数的设定符合其认知中的真实情况。这种对细节的执着体现在生成的代码和模拟逻辑中，使得整个系统不仅仅是视觉上的还原，更是一个具备动力学反馈的仿真环境。然而，尽管物理逻辑严密，实际运行效果却暴露出了一些建模上的偏差。
视觉呈现与交互逻辑的局限性
尽管物理内核扎实，但在视觉建模和空间布局上，Claude Fable 5.1 生成的结果并未完美复刻现实中的轨道结构。两者都未能完全准确地复制真实世界的赛道模型，特别是在支柱数量和位置的处理上存在瑕疵。更明显的错误在于轨道被放置在了地板上而非应有的悬空状态，且齿轮 protrusion（突出部分）的建模也不够精细。不过，模型在品牌标识的处理上表现出色，它使用了与实际包装非常相似的初始标志和字体类型，这一细节增强了生成的拟真感。
在交互逻辑方面，该模型引入了一个有趣的“悬停”机制。它实际上会让汽车在您想要放置的特定车道上方进行虚假悬浮，并且具有方向性限制：车辆只能以正确的朝向放置。如果尝试反向放置，系统会拒绝或纠正。两者都具备微调功能（Nudge feature），允许用户进行细微的位置调整以确保车辆启动顺畅。然而，这种交互设计在实际操作中显得有些笨拙，尤其是在处理多车排列时。
动力学表现与物理参数的偏差测试
在实际运行测试中，Claude Fable 5.1 生成的系统表现出明显的动力学异常。泡沫轮组的摩擦系数或相关物理值似乎设置不当，导致车辆动力不足。即使将电机功率调至最高，单辆车通过轨道也显得极其吃力。由于物理值设置错误，车辆无法维持持续的滚动，这与现实中泡沫轮赛车应有的表现不符。
"I think something's wrong with the foam wheels. Honestly, it should be shooting these around and it's not."
当尝试排列五辆车时，系统出现了过载现象。车辆不仅无法顺利行驶，反而频繁发生翻转或被甩出轨道的情况，这在一定程度上反映了现实中的物理碰撞逻辑。特别是在慢动作回放中可以看到车辆撞击墙壁和翻转的姿态，这些动态细节实际上更接近真实生活中的物理反馈。然而，由于基础参数（如泡沫轮摩擦）的错误，导致整体体验失衡：要么动力不足无法通过弯道，要么因参数错误导致的异常翻转。
故障模拟与最终评估视角
模型在故障保护机制上也进行了合理的逻辑构建。当车辆在碰撞区卡住时，电机确实会表现出失速现象，且系统能正确反映车辆通过与否的状态变化。这种对极端情况的模拟增加了系统的真实感。虽然生成的展示视图在美学上不如 GPT 的结果精致，但车辆模型本身并未出现严重失真。
在后续关于“设计并3D打印特定车辆以优化赛道表现”的测试中，双方都给出了相应的设计方案。对于本次对比的最终结论，作者认为与其由评测者判定胜负，不如让观众自行判断。因为生成结果各有优劣：Claude 在物理逻辑的深度上表现突出，但在参数校准和视觉建模的准确性上存在明显短板。这种差异使得简单的性能排名变得困难，更值得探讨的是不同模型在复杂物理模拟任务中的思维路径差异。
3D打印车辆设计的物理可行性测试
在针对GPT-6 Astra与Claude Fable 5.1生成3D打印车辆设计的对比测试中，两者在视觉形态上呈现出惊人的相似性。它们都创建了形状几乎相同的板状结构，但在实际打印和组装环节暴露出了严重的物理缺陷。对于Claude生成的模型，主要问题在于其立柱设计存在干涉：打印出的车辆这些柱子与任何尝试安装的轮子都会发生摩擦。为了修复这一问题，测试者不得不拆解多辆Hot Wheels汽车以获取适配部件，但即便如此，该模型依然无法正常使用。即使强行切除立柱，车体高度又导致轮子继续摩擦。因此，这个模型在实质上完全不可用。
尽管Claude的实体打印失败，但其生成的文档包含了对车辆的具体拆解说明、重量目标以及配重建议等有价值信息。这些README文件提供了关于仿真无法告知的细节，展示了模型在理论设计层面的深度。相比之下，GPT-6 Astra生成的车辆在设计思路上与Claude类似，同样采用了特定的结构方案。然而，GPT的模型存在一个突出的凸起部分（hump），这导致打印时必须依附于底座，测试者不得不将其切除。尽管需要修改，GPT生成的模型在呈现方式上明显更优。它附带了组装PDF和详细的重量说明，且最重要的是该模型能够正常滚动。虽然两个模型的设计都不完美，但GPT的版本至少具备基本的功能可行性。
Apple Vision Pro原生应用移植：Claude Fable 5.1的实现路径
测试的下一阶段聚焦于将之前开发的Subway FPS游戏（基于3JS构建）移植到Apple Vision Pro上运行。这一过程首先由Claude Fable 5.1执行，测试环境为Mac系统。初始提示词仅提供了包含3JS游戏的仓库，并指示在Xcode和依赖项就绪后停止以进行设备测试。Claude迅速启动了工作，但在过程中，测试者意识到其可能仅是在Vision OS中创建一个浏览器层的翻译层。因此，测试者介入并明确要求：“我不希望它仅仅是一个在Vision OS上运行浏览器的翻译层，我希望它能真正被复制为Vision OS应用”。Claude随后调整策略，基于原始的设计文档进行重构。
Claude的核心逻辑在于利用并行代理生成的设计Markdown文件，该文件耗时超过2小时完成。正是这份设计文档使得移植工作变得可行。Claude的解释指出，每个Swift模块都是针对与其JavaScript对应部分相同的规范编写的。无头渲染器夹具让它们在集成前进行视觉比较。最终生成的应用是一个真正原生化的Vision OS应用，尽管仍存在轻微Bug（如射击机制偶尔失灵），但整体移植效果令人印象深刻。这是一个非常惊人的游戏到原生应用的转换，测试者甚至计划分享该应用供其他Vision Pro用户试玩。
Apple Vision Pro原生应用移植：GPT-6 Astra的表现与开发环境吐槽
随后，测试者使用GPT-6 Astra（开启最大推理模式）执行相同的移植任务。与Claude不同，GPT-6 Astra在快速模式下运行了48分钟即完成工作。测试者尚未亲自验证其实际运行效果，但通过生成的README文件可以看出，GPT同样使用了Xcode环境，并进行了基本的验证测试。在此过程中，测试者对Apple的开发工具链表达了强烈不满。苹果的开发环境简直是一团糟。对于一款昂贵且由个人付费的设备，Apple限制同一时间只能安装三个应用，否则需升级或处理繁琐流程。这种人为设置的障碍在当下鼓励开发者创作的时代显得极其不合理，几乎是在自断臂膀。
尽管面临开发环境的限制，测试者仍尝试运行GPT生成的应用。该版本支持手柄平滑移动和捏合交互，但测试者因缺乏手柄而主要依赖视觉操作。观察敌人并执行捏合动作是主要的交互方式。虽然GPT的版本运行速度更快，但其实际体验尚待验证。目前尚未查看此结果，测试者仍需将应用加载至头显以确认其功能完整性。这一对比不仅展示了两个模型在代码生成效率上的差异，也揭示了跨平台移植中工具链限制对开发者体验的巨大影响。
Vision Pro 游戏移植体验：GPT-6 Astra vs Claude Fable 5.1
本次测试的核心在于对比两个 AI 模型将现有游戏移植到 Apple Vision Pro (Vision OS) 原生沉浸式应用的能力。测试者首先体验了由 GPT-6 Astra 生成的版本，该模型在 45分钟内 完成了移植工作。从视觉表现来看，Astra 的表现相当出色，它很好地保留了原游戏的武器模型和资产细节。测试者指出："> First off, it looks good. The weapon model is very good. I will say it really actually preserved it very nicely." 操作方面，用户可以通过捏合手势进行射击（长按持续射击），并支持武器切换。游戏内的物理反馈如弹孔保留、弹药逻辑以及重新装填机制均正常运行，证明了其功能性的完整性。
然而，Astra 版本在交互逻辑上存在明显缺陷。最突出的问题在于武器追踪方式：武器并非跟随手部位置，而是 与头显视角同步移动。这种设计导致玩家在寻找目标或调整角度时感到困惑，因为武器始终锁定在视野中心而非手部操作点。测试者表示："> It doesn't like the way the weapon's actually being tracked. It's just moving in unison with the actual eye view." 此外，当测试者尝试重新定位（recenter）时，应用意外暂停并重启，这进一步影响了体验的流畅度。尽管整体完成度高且速度快，但 缺乏手部追踪支持 以及武器锁定视角的设计被评价为“不太理想”，甚至有人建议应使用 PSVR手柄以获得更好的控制体验。
交互设计与开发效率的深度对比：Fable 5.1 的优势与代价
相比之下，由 Claude Fable 5.1 生成的版本在 2至2.5小时 的开发时间内，虽然耗时更长且成本更高，但在用户体验上提供了更优的解决方案。Fable 5.1 版本允许用户 单手移动，且地图上不存在预设的跳跃点限制，这种自由度使得游戏过程更加有趣和直观。更重要的是，Fable 5.1 实现了真正的 手部追踪武器跟随，武器的位置与玩家的手部动作保持一致，而非像 Astra 那样锁定在头显视角。测试者明确评价："> I think the Fable one was a bit more fun to play because you could kind of move with one hand... Additionally, the weapon was more tracked where the hand movement was as opposed to basically the weapon was locked to the movement of the headset."
这一对比揭示了 AI 生成应用中的权衡：速度 vs. 体验。Astra 以极快的速度（<45分钟）交付了一个视觉完整但交互笨拙的版本，而 Fable 5.1 则通过增加开发时间换取了更符合直觉的交互逻辑。测试者认为，尽管 Astra 版本在视觉资产还原上同样出色（"> both of them really did a fantastic job actually replicating the exact look and assets"），但 Fable 5.1 在 空间交互的自然度 上明显胜出。这种差异突显了在处理 VR/AR 应用时，单纯的视觉移植不足以构成优秀体验，交互逻辑的合理性（如手部追踪而非头部锁定）才是决定游戏是否“好玩”的关键因素。
赞助商介绍：Superbase 与 Ultimate Play 平台架构
视频中段插入了对赞助商 Superbase 的介绍。Superbase 不仅是本视频的赞助方，更是测试者运营的 Ultimate Play 网站的底层基础设施。该平台允许用户上传游戏并实时部署，Superbase 负责处理包括 点赞数（up votes）、游玩次数（number of plays） 在内的所有后端数据追踪与实时部署任务。测试者邀请 Superbase 的代表 Bhan 出镜，确认了当前演示中正在运行的游戏正是由 Superbase 支持实时部署的实例。
Bhan 表示对频道的喜爱，并感谢测试者的支持。这一环节旨在展示 Superbase 如何赋能独立游戏开发者及评测平台，提供从上传到实时游玩的全链路技术支持。测试者强调，观众可以通过描述栏链接或访问 ultimateplay.com 查看由 Superbase 驱动的实际部署案例。这部分内容虽然与 AI 模型性能测试无直接关联，但为后续更复杂的视觉空间能力测试提供了平台背景支持。
新挑战：基于静态摄像头的机械臂空间控制测试
在赞助商环节后，视频进入了一个全新的、更具挑战性的测试场景：视觉与空间能力极限测试。这次的目标不再是游戏移植，而是让 AI 模型控制一个物理机械臂。任务设定如下： 1. 输入限制：AI 仅能通过一个 静态摄像头视角（手机作为 webcam）观察机械臂，无法获得深度感知或多角度视图。 2. 任务目标：在机械臂侧面放置一辆橙色 Hot Wheels 小车，AI 需根据此视觉信息规划并执行机械臂动作以触碰或移动车辆。 3. 环境干扰：尽管切割垫上有厘米级网格，但由于是侧面角度且缺乏深度信息，AI 在 空间定位 上将面临极大困难。
测试者指出，这是一个典型的“不完美的真实世界场景”（imperfect real world scenario）。在现实世界中，仅凭单目静态图像进行精确的空间操作极具挑战性，因为深度感知缺失会导致严重的定位误差。此测试旨在观察 AI 模型如何在 缺乏理想条件（如多视角、深度数据）的情况下，适应并尝试解决空间控制问题。测试者准备了提示词（prompt）、机械臂伺服电机映射表以及静态摄像头画面，准备开始记录 AI 在极端受限条件下的表现。这一部分为后续可能出现的失败或意外结果埋下了伏笔，强调了 AI 在物理世界交互中的局限性。
GPT-4o (Astra) 的迭代式视觉抓取策略
GPT-4o驱动的机械臂采用了“移动-拍摄-调整”的迭代式策略。在初始尝试中，机械臂未能准确抓取车辆，而是撞击了车头前部。尽管第一次接触未移动车身，但系统识别到抓取位置过于靠前。随后，操作者通过语音指令引导其将夹爪向车身中部移动以优化握持点。然而，在随后的尝试中，机械臂再次发生碰撞并导致车辆位移。
面对这一变化，系统展现了基于视觉反馈的实时纠错能力。它识别到车辆位置变动后，尝试通过抬高夹爪、加宽开口并重新下降来对齐车身。在多次失败后，系统调整了腕部角度，从车辆宽度方向而非长度方向接近。最终，通过垂直化夹爪姿态并精确控制下降深度，机械臂成功将手指对齐至车身同一高度。在确认夹爪完全包围车辆后，它进行了第一次提举尝试。
“I did not grip tight enough. So the car fell back down. It slipped during the higher lift.”
第一次提举因夹持力度不足导致车辆滑落。系统通过视觉检测到阴影变化，确认车辆已离开垫子但随即掉落。基于此反馈，它降低了夹持高度并增加闭合力度。第二次提举成功将车辆稳固抓起。随后，机械臂在避开底座支撑结构后，平稳地将车辆搬运至对面垫子并释放。整个任务耗时39分57秒。这一过程证明，尽管缺乏精确的几何建模，但通过持续的视觉确认和试错调整，GPT-4o能够完成复杂的物理操作任务。
Claude 3.5 Sonnet (Fable) 的几何映射困境与失败分析
相比之下，Claude驱动的机械臂采取了截然不同的基于几何建模和坐标映射的方法。在任务开始前，操作者将车辆精确放回初始位置（20x 20厘米标记处），并重置机械臂姿态以确保公平对比。Claude首先尝试通过微调伺服电机来建立深度映射和地面平面同构性。它试图利用垫子的网格线恢复相机方向，并构建一个精确的XYZ空间坐标模型。
然而，这种过度依赖初始测量数据的方法导致了严重失误。系统在运行过程中错误地触发了运动检测，导致机械臂意外移动了车辆。数据显示，车辆在未被正确抓取的情况下发生了3.4厘米的位移和45度的旋转。更关键的是，系统似乎并未意识到车辆位置的改变，而是继续基于初始的、已失效的坐标数据进行操作。
“The car has shifted 3.4 cm and rotated 45°... it's almost operating off of its initial measurements when the car had not been moved by it.”
由于未能实时修正因自身操作导致的物理状态变化，Claude陷入了逻辑死循环。它花费了比GPT-4o多一倍的时间进行复杂的探针测试和脚本编写，试图解决伺服漂移问题，但最终未能成功抓取车辆。这一案例揭示了纯几何映射方法在动态物理环境中的脆弱性：一旦初始假设被打破（如物体位置改变），缺乏实时视觉反馈闭环的系统极易失效。
视觉定位失败的代价与策略差异
在第一个测试环节中，模型试图通过坐标和网格来精准控制机械臂避开障碍物（汽车）。然而，该尝试耗时极长，且最终未能完全成功。由于使用量昂贵且在周三前无法重置，测试在运行了 1小时25分钟 后被提前终止。尽管模型尝试通过对比网格和伺服电机数值进行计算，但其核心问题在于 视觉识别能力的不足。
"Unfortunately, it just is not quite able to get... I think the vision's just letting it down."
这一结果揭示了两种截然不同的技术路径：GPT 采用的是简单的 "拍照-移动" 暴力迭代法，虽然简单但有效；而 Claude 则试图构建深度图和坐标系，模拟 3D打印机床的预检逻辑。这种更深层的计算虽然展现了复杂的推理过程，但也导致了速度的显著下降和最终的失败。这表明在缺乏精准视觉反馈的情况下，过度复杂的坐标映射策略反而不如简单的试错机制可靠。
低算力设备优化测试：CYD平台挑战
第二个测试聚焦于 资源受限环境下的性能优化。目标是将一个由 Blender 和 Godot (GDAU) 制作的 PC 游戏移植到 Cheap Yellow Display (CYD)——一种基于 ESP32 芯片的小型触摸屏设备上。该任务极具挑战性，因为需要在极低算力下保持尽可能高的图形保真度和帧率。
"The task is essentially... Transpose this game into something that will run on this ESP32 cheap yellow display while preserving as much detail..."
为了实时监控渲染效果，测试者使用了摄像头直接拍摄屏幕。这是因为在低算力设备上容易出现 画面倒置、光栅化线条异常或 Z-fighting（深度冲突） 等问题，仅靠文字描述难以高效调试。让 AI "看到" 实际输出是确保优化方向正确的关键步骤。Claude Fable 5.1 在此任务中处于 "最大努力" (max effort) 模式，旨在榨干 ESP32 的处理潜力。
Claude Fable 5.1 的移植成果与性能数据
经过 2小时27分钟 的计算，Claude Fable 5.1 完成了游戏移植。最终结果展示了 PC 原版渲染、Godot 4 原始 CYD 端口以及 Claude 优化后的 CYD 设备帧缓冲区之间的对比。视觉上，Claude 生成的版本与原始设计 高度一致，成功还原了游戏细节。
在性能方面，ESP32 上的帧率数据如下表所示：
| 指标 | 数值 |
|---|---|
| 最低帧率 (FPS) | 32 |
| 典型帧率范围 | 38 - 40 FPS |
该性能得益于双核管道的优化：核心1负责游戏逻辑和多边形列表，核心0处理 16位 Z-buffer 光栅化及 80 MHz DMA 传输。代码分析显示，光栅核心在 43毫秒 内因纹理四边形重叠等开销出现瓶颈。通过摄像头实时监控，测试者确认了这些细微的渲染问题已被有效处理或识别，证明了视觉反馈在复杂优化任务中的必要性。
硬件适配与触控交互的意外惊喜
测试环境搭建过程中，创作者发现廉价黄色显示屏具备触摸屏功能，这为后续交互提供了可能。在初步测试中，通过触控笔操作实现了视图移动和点击加热功能，意外地让原本难以操控的游戏变得可玩。这种硬件特性的发现极大地简化了调试流程，因为无需频繁重启或重新接线。设备即插即用的特性表现优异，每次连接后都能立即启动并执行色彩校准程序。创作者表示：“I don't know if you'll see it, but it actually moves the view with the stylus... It actually made this game playable”。这一环节证明了硬件基础对于AI生成代码落地的重要性，触控支持成为了提升用户体验的关键变量。
细节与性能的权衡：前序测试的反思
在前一个关于游戏渲染效果的对比中，作者指出GPT-6 Astra与Claude Fable 5.1采取了截然不同的技术路线。GPT侧重于保留极高的细节，但在运行帧率上有所滞后；相比之下，Claude选择了优化路径，虽然细节稍逊一筹，但运行速度更快且资源占用更合理。Claude采用了诸如“距离遮挡剔除”等策略，即在玩家到达特定距离前不渲染远处物体。作者认为这种细节与帧率的取舍难以简单判定优劣，因为两者都成功实现了任务目标。值得注意的是，这类复杂场景生成在一年前几乎没有任何模型能胜任，而此次测试显示两个前沿模型均已具备处理能力。
终极挑战：《Steve the PC Repairman》游戏开发设定
最终测试项目为一款名为“Cinematic Steve the PC repairman”的3D潜行冒险游戏。该测试不仅要求生成可玩的游戏关卡，还需包含电影化过场动画。作者为两个模型提供了相同的API密钥以生成对话，并设定了极高的设计标准：要求呈现“高端独立游戏工作室”的氛围。技术栈方面，传统测试多使用Three.js（3JS），但此次强制要求使用Blender和Godot (GDAU)进行开发。此外，考虑到模型在处理复杂谜题时可能出现的逻辑死循环或挫败感，提示词中特别加入了“跳过当前任务”的功能指令，确保玩家即使卡关也能推进剧情。测试环境统一为Mac电脑上的Fable 5.1，确保工具链、软件版本及提示词完全一致。
资源消耗与游戏核心机制解析
经过超过5小时的生成过程（实际运行时间约1小时4分钟），Claude Fable 5.1完成了游戏构建。在资源消耗方面，测试前的API额度剩余71%，结束后降至70%，表明该任务消耗了约1%的周额度。生成的游戏名为《Operation Dead Battery》，包含9个任务、3个原创场景、5个维修谜题和11处可发现物品，并拥有两个结局。游戏包内嵌Linux x64运行时，无需安装Godot或连接网络即可游玩。渲染引擎采用Forward Plus模式，支持阴影、环境光遮蔽（AO）、泛光和大气雾效。针对卡关问题，游戏实现了按Escape键跳过任务的功能，该操作会推进剧情并保留必要的任务状态。所有3D模型均在Blender中制作，UI和文字从零构建，语音则使用了OpenAI的GPT-4o-mini文本转语音引擎。
游戏实机演示：叙事与玩法呈现
进入游戏后，画面呈现出等距视角（Isometric）的复古风格。开场通过旁白引入主角Steve，一位专门修理旧电脑的技术员，其服务原则是“100%预付款”。首个任务涉及为一位93岁的老人修复座钟，过程中穿插了关于“订阅制”的讽刺对话。游戏中包含大量叙事性道具，如一张贴满旅行标签（布拉格、柏林）的软盘。谜题设计直观，例如校准座钟时需等待指针进入绿色窗口并锁定。剧情随后转向更宏大的谍战背景，涉及前情报人员Anton Voss在日内瓦奥瑞森酒店出售名为“Lazarus”的机器，以及针对60,000个退休账户密钥的黑市拍卖。Steve的任务是潜入酒店，利用伪装身份（头等舱机票、清洁电话）和工具（螺丝刀、环回插头）完成破坏行动。整个演示展示了模型在多场景切换、角色配音同步及复杂叙事逻辑串联上的能力。
游戏内潜行与解谜机制解析
视频展示了《Fable》游戏中一段以等距视角（isometric view）呈现的潜行任务。玩家扮演一名伪装成技术维修人员的角色，需要避开守卫并操作监控设备。游戏的核心机制在于利用环境互动来规避风险，例如通过解决“卡纸”谜题来解锁更多通道，这比传统的开锁工具更为有效。玩家需控制角色在阴影中移动，避开巡逻守卫的视线。
“A paper jam opens more doors than a lockpick.”
任务的关键步骤包括：首先获取账本（ledger），然后桥接三个隔离继电器。玩家发现摄像头已被安全锁定，但必须通过服务电梯和特定的开关板来控制监控。这种设计强调了信息获取与物理操作的双重挑战，玩家需要在不触发警报的情况下完成一系列复杂的电路连接和物品收集任务。
剧情冲突与谈判策略
在获取账本后，玩家掌握了包含姓名、账户及被盗养老金在内的所有犯罪证据。此时，剧情进入高潮阶段：玩家利用广播终端将拍卖会的控制权反转，以此对抗反派。这一情节展示了游戏叙事中“以彼之道还施彼身”的策略性，玩家通过技术优势逆转局势。
“Your presentation has a serious transparency problem.”
在与反派的对话中，玩家展现出冷静且具威胁性的态度。反派试图用金钱收买（“I can double whatever they paid you”），但玩家指出对方已预付全款，无法更改。这种对话设计突出了角色的职业操守与智慧，最终玩家成功迫使反派就范。任务最后，玩家需要到达提取电梯并完成任务结算。游戏通过这种紧凑的剧情推进和对话互动，增强了玩家的沉浸感和成就感。
游戏评测与视觉表现评价
视频作者对《Fable》的游戏体验进行了详细点评。尽管游戏在玩法上表现出色，音乐和可玩性均获好评，但在视觉表现方面存在争议。作者认为游戏的图形冲击力未达预期，主要原因在于角色缺乏口型动画（mouth movements），且等距视角的选择使得整体画面保真度的不足更容易被掩盖。
“It wasn't as graphically striking as I expected... the isometric scene that it chose made it easier to get away with less overall fidelity.”
然而，作者也肯定了游戏的细节处理。例如，场景中的老式电脑硬件（如IDE线缆、CMOS电池更换）描绘得非常细致。这种对复古科技元素的还原增加了场景的真实感。此外，游戏中的宠物猫“Bios”提供了温馨的互动元素。整体而言，游戏在玩法和叙事上表现良好，但在图形 fidelity 上有妥协。
Claude Fable 5.1 运行故障与性能测试实录
在对比环节，作者展示了使用 Claude Fable 5.1 模型运行游戏时的严重技术问题。首先遇到的是启动阶段的致命 Bug：在 Windows 系统上，开始菜单的所有按钮均不可选，鼠标光标消失，即使使用键盘方向键也无法交互。作者验证了该问题在另一台电脑上同样存在，并指出这导致游戏无法正常启动。
“None of the buttons were actually selectable... the cursor just disappeared.”
此外，作者还记录了在使用过程中的资源消耗情况。游戏运行约 5-6 小时后触发了使用额度限制，导致模型暂停并消耗了大约 $50-$60 的信用点。作者不得不暂停游戏3小时以节省额度，随后继续运行时模型输出了大量剧透图片。最终测试显示使用量已达 83%，且游戏在 Linux 环境下全屏运行时会干扰 OBS 录制。这些数据显示该模型在当前版本下存在稳定性差、资源消耗高及交互逻辑错误等严重缺陷。
游戏内环境互动与细节还原
尽管存在技术故障，视频后半部分展示了《Fable》游戏内丰富的环境互动细节。场景设定在一个老旧的办公室，充满了 90 年代末的科技元素。玩家可以与几乎所有物品进行互动，包括检查电源供应器（PSU）、查看猫窝、甚至玩内置的贪吃蛇游戏。
“Everything here can be examined... Look at the individual tools and things.”
作者特别赞赏了硬件维修的拟真度。例如，更换 CMOS 电池需要点击侧板、释放卡扣并取出旧电池。这种对硬件细节的刻画，如 IDE 线缆和老式主板的描绘，体现了开发者对复古 PC 文化的深刻理解。游戏通过这种高自由度的环境互动，为玩家提供了超越主线任务的探索乐趣，尽管图形表现有局限，但细节丰富度弥补了部分视觉上的不足。
任务简报：代号“灯笼”的窃取行动
本次行动的目标是获取一份名为“Lantern”的文件，其中包含 61 个名字，涉及承包商和情报人员。目标人物是 Marius Voss（61岁），前政府密码构建者，现向出价最高者出售机密。他计划在 3天内 于里斯本的一家酒店套房内完成交易，且期间绝不离开房间。该文件仅存储在一台老旧的 ThinkPad T系列 2009款笔记本电脑上，该设备因风扇轴承损坏已自动关机两天。为了接近目标，行动者伪装成酒店供应商 Tagus Tech 的高级技术员，持有工单、印有Logo的衬衫以及必要的维修工具。核心策略是利用更换风扇和电池的机会，通过插入标有“芯片组驱动程序”的U盘来复制文件，随后确保文件中没有任何痕迹。此外，行动者需携带两节纽扣电池，其中一节背面有轻微划痕，用于替换目标机器上的旧电池以维持时间同步。
“他有一份文件，61个名字……他在3天内卖给出价最高者。”
潜入准备：从机场到酒店套房的伪装流程
行动者首先乘坐头等舱飞往里斯本，机上环境细节丰富，包括第一类客舱内饰和复杂的座椅控制台。在飞行途中，行动者需处理一份无法关闭的档案资料，并观察周围细节以维持伪装身份。抵达里斯本后，目标酒店为Meridian Palace Hotel 841号套房。该套房拥有大理石地板、喷泉和自动演奏的钢琴，显示出极高的安保级别。行动者需利用酒店提供的服务卡进入隐蔽的服务走廊和货运电梯，而非使用常规通道。在IT closet中，行动者需通过跳线面板连接端口以激活通往 12层 的服务电梯权限。这一过程涉及对酒店内部网络物理连接的精确操作，任何错误都可能导致暴露。
“你是他们今年派出的第三位高级技术员。其他两位来得都不够准时。”
执行阶段：物理接触与数据窃取的关键细节
在12层的服务走廊尽头，行动者进入 Sweet 1201 套房。目标人物 Voss 对迟到非常敏感，行动者被警告必须在设备再次关机前进入。行动中需严格遵循指令：不要表现得太迷人，并确认风扇部件的零件号为 64931（布拉迪斯拉发批次）。在物理维修过程中，行动者需特别注意那节背面有划痕的纽扣电池，将其插入主板以维持系统时间（防止机器因忘记年份而关机）。同时，通过预置的U盘自动复制文件。整个过程中，行动者需保持低调，避免引起Voss或其保镖的怀疑。酒店环境的互动性极高，从自动钢琴到世界时钟（显示里斯本、苏黎世、东京和纽约时间），均为营造真实感而设计，但行动者需专注于核心任务：完成维修、复制数据并全身而退。
“他想要风扇的零件号，在你打开任何东西之前。”
叙事沉浸感与视觉风格的显著差距
视频以一段极具电影质感的对话开场，通过修复一台2009年的T-Series笔记本电脑，展现了生成式视频在叙事沉浸感上的极高水准。画面中不仅包含了精细的道具细节，如“Bratislava批次”的风扇和特定的螺丝编号，还通过角色间的互动构建了紧张的氛围。在对比测试中，GPT-6 Astra 在视觉表现和整体风格上显著优于 Claude。字幕明确指出：“Astra had significantly better visuals and style whereas Claude the visuals were not as good. Nowhere near as good.” 这种差距体现在光影处理、镜头语言以及场景的真实感上，Astra生成的画面更接近专业电影制作水准，而Claude的视觉输出则显得较为平淡和缺乏细节深度。
物理模拟逻辑与真实世界规则的契合度
尽管在视觉美学上处于劣势，Claude在某些物理模拟逻辑的呈现上却展现出了惊人的真实性。视频回顾了一个“Hot Wheels”小车碰撞的案例，指出Claude生成的物理反馈更符合现实世界的复杂情况。字幕描述道：“one specific time it went through the foam and then it actually flipped over but then kept going. That happens in real life.” 这种非理想化的物理交互——即物体穿透缓冲材料后翻转并继续运动的过程，体现了Claude在模拟复杂动力学时的独特优势。相比之下，Astra虽然视觉效果华丽，但在处理此类细微且反直觉的物理反馈时，可能不如Claude那样贴合现实世界的混沌逻辑。这一案例揭示了两者在“好看”与“真实”之间的不同侧重。
代码生成能力与伦理归属的缺失
除了视频生成，测试还涉及了代码与UI生成的伦理及质量评估。在一段关于“Pixel Steve OS”界面的生成中，Claude成功创建了一个具有独特风格的字体和界面布局。字幕评价道：“The way it looked so funky drawn by code with a bestow stroke and font in 57 pixel font.” 然而，这一技术亮点伴随着明显的伦理缺失。创作者指出：“I gave you the prompt. This thing gave me zero credit whatsoever.” 这表明Claude在生成内容时，完全忽略了提示词提供者的贡献，未给予任何署名或致谢。这种零信用反馈机制引发了关于AI生成内容版权归属和创作者尊重的讨论，成为评估模型综合表现时的一个重要负面指标。
物理模拟与视觉风格：难以抉择的平衡
在首个测试中，作者试图结合Claude的物理引擎优势与GPT-6 Astra的美学风格。虽然理想结果应是两者优势的完美结合，但实际表现中，GPT-6 Astra在整体设计层面实现了显著的飞跃。然而，由于Claude在前端物理表现上的独特性，作者表示无法做出明确决定。这一案例揭示了单一模型在特定维度（如物理或视觉）上的局限性，也说明了综合评估的复杂性。作者指出，尽管GPT-6 Astra的设计是“显著的前进”，但在物理真实感上仍有不足，导致这一轮比赛平局或难以定论。这种权衡反映了当前AI生成内容在追求极致体验时面临的挑战，即美学与物理真实感往往难以兼得。
结论
本次对比表明，GPT-6 Astra与Claude Fable 5.1在复杂物理模拟任务中各具优势，难以简单判定胜负。Astra在视觉美学、交互设计及开发效率上显著领先，能生成高保真3D模型与精美游戏界面；Claude则在底层物理逻辑推演、动力学参数校准及代码资源优化上表现更深，但在视觉建模准确性与实体打印可行性上存在明显短板。两者均能完成跨平台移植及低算力设备优化，但路径迥异：Astra侧重快速迭代与视觉呈现，Claude倾向深度计算与性能平衡。最终结果取决于用户对“美学体验”还是“物理真实感”的优先需求，且Claude在内容生成中缺乏对提示词提供者的信用归属。